A True MVP Enables Agility in Product Development

Tags: , , , ,

Minimum Viable Product, or MVP.

It’s right there in the name: “minimum”. Yet many companies sabotage this critical step of product development by using a definition of minimum that is anything but.

Our teams know that overstuffing an MVP can lead to disastrous consequences for a final build. That’s why they work so hard to balance feature requirements with timeline, budget and end-customer expectations from day one.

Here are two of the biggest mistakes companies make in building an MVP and how you can avoid them.

Right Size Your MVP

Many of our clients come to us with product ideas that are not rooted in production realities like time horizon and budget. Some come to us expecting too much in too short a time and for too small of a budget. Others have the reverse problem.

Journal My Health is a health app that allows people to document their experience with chronic conditions like Long COVID and combine it with measured and observed data like their blood pressure, sleep quality and barometric pressure. By tracking this over time, they can help their care teams better customize care that produces that best quality of life for them.

Ahead of their launch, the Journal My Health team came to Chariot asking for a clickable prototype in PowerPoint that they could share with investors and some initial customers within three months to test the idea and secure buy-in.

Our designers immediately realized that we could deliver a more robust MVP much more quickly and efficiently. And by putting an actual app in the hands of their testers and investors, Journal My Health could dramatically shorten its time-to-market and get a critical headstart on design input for future iterations of the product.

In the space of just a couple of weeks, Chariot built an iOS app with no backend that lived exclusively on customers’ phones. It only allowed users to make authored journal entries in the first version. We made these ruthless design decisions to put something out into the world for feedback knowing we could reassess and move forward faster in our next phases.


By putting an actual app in the hands of their testers and investors, Journal My Health could dramatically shorten its time-to-market and get a critical headstart on design input for future iterations of the product.


We knew that limiting data storage to each phone would not work long-term for the product vision, but enabling cloud connectivity was an unnecessary time and budget commitment in this first version. It was also evident that committing to integrations with wearable devices was too much at this stage without first testing customers’ willingness to make basic journal entries. And by focusing only on iOS, we cut our development workload and timeline in half.

This emphasis on critical, no-frills features allowed us to give Journal My Health a workable app for their initial users with more functionality than they’d expected in less time than they envisioned. It resulted in outside investment in the company, a core group of engaged users, and what is a more fully enhanced and pleasing experience for customers today.

Trust Your Customers

Recently, a new Chariot client handed us an MVP spec sheet that included hundreds of page and feature requirements. As a big company, they were concerned their reputation was on the line every time they proposed something new. So, they wanted even this MVP to reflect the same experience as their more mature apps and solutions.

Nothing could be further from the truth. Time and again, we’ve seen companies use proper positioning and expectation setting with customers to test very basic, early ideas and concepts with exceptional results. In many cases, customers actually value being “along for the ride” and will be more generous with their time and patient in their judgement when asked to participate in the development process.

The Journal My Health experience is instructive here again. The core features in their MVP build were an enrollment agreement that included their name, the choosing of which symptoms and treatments to track and their first journal entry. It also enabled ongoing journal entries like how many hours they slept, stress level and overall health. That’s it. Nothing more.


Using Figma to draft the earliest iterations of the minimum viable product.


We knew that wasn’t enough and customers would eventually want more. But we wanted users to help choose the features and functionality that were most important to them so they were invested in the success of the app, and we told them as much in communications from the founding team. Over time, input from customers led to new layers of features like data feeds, integrations with remote or wearable devices and notification reminders to make a daily entry.

The key lesson for any company is to communicate openly and often with customers. Set expectations that this is an MVP, ask for their patience and input as part of a deliberate journey that will eventually provide them with a fully-functioning solution that best meets their needs.

Oftentimes, your customers know what they want, but not what they really need – until you allow them to begin playing with a nascent concept. Providing them with a true MVP allows you to grow together. Giving them too overstuffed of an MVP overshoots the mark and can be confusing or overbearing. Starting small allows you to develop to their needs, which ultimately benefits your business.

Agility in Product Development

The altruism that perfect is the enemy of good applies in product development. The key is to make the first customer-facing version dead simple. That allows you the opportunity to layer on iterations and solicit feedback along the way.

It also makes it much easier to pivot or adjust if the feedback is not what you expected. If you do too much in your early versions, then you’re already committed and have to spend more time and money on reworking the original concept.

A true MVP enables agility and responsiveness in your product design and development. It gets you to feedback and full product much faster and with less spend than overdesigning and then resetting an overstuffed MVP.

At Chariot, this mindset that it’s better to “design and refine” than “bet and regret” is one we encourage in all client engagements.