I love working with new and growing product creators. Helping them hone their craft, pointing out pitfalls along the path, and sharing what I’ve learned from my own experience lets me see my work history through different lenses and makes all the hard lessons worth it.
While chatting with a group of interns about minimal viable products (MVPs), a question came up:
How do you define the scope of an MVP?
The simplicity of the question belies the wisdom hidden within it. Miscalculating the scope of an MVP can have grave consequences for a product, leading to cost and timeline overruns and risking user experience.
Getting MVP scope right means implementing the minimal experience and functionality needed to solve the user’s problem. Getting it right also means knowing exactly where to draw the line between enough and too much functionality for a peerless new invention.
An MVP is meant to be a great Version 1. It’s a version that meets the lowest threshold of usability in order to begin gathering user feedback. MVPs often make good soft launch releases or serve as prototypes for future, more robust implementations.
Because they are typically early stage products, MVPs are often built with scant resources and time. A well-defined MVP delivers a complete product experience with the lowest effort and within shortest timeline possible.
These interns appreciated that the decisions they made in their field would mobilize the company’s resources, and they wanted their work to deliver the highest possible value for the smallest possible effort.
To answer their question, I asked them to envision a product they knew well, like the chairs they were each sitting on. We discussed what makes a chair a chair. Does it have a back? What about arm rests? How many legs does it have? What’s the difference between a stool and a chair?
There are thousands of different types of chairs. Gaming chairs have speakers built into them. Barber chairs elevate and lower the seated client. Office chairs often spin and recline.
But a minimal chair? We agreed the MVP chair has four legs, a seat, and a back. It has a back so that it isn’t a stool. It doesn’t have arm rests because those aren’t essential features. Our MVP chair consisted of only the essential components to achieve the user’s primary goal of sitting.
This kind of simple chair is quick and easy to build. The time from idea to the first person sitting down in it is reduced as much as possible. Adding other features, like arm rests, a reclining back, or a headrest would extend the timeline and possibly require more hands for implementation. These are excess features and nice-to-haves.
Building the Software Chair
Developers write software to solve problems. Similar to how a chair solves the problem of sitting down, software solves all kinds of different problems for users. An application may solve the problem of sending an email, editing a photo, publishing a website or any other array of goals the user is trying to complete.
Defining an MVP for software means looking for the “chair” in the application or feature being considered. Let’s say you’re building a booking application for hospitality services. A typical booking application has a back-end database and a front-end user interface. These components are like raw materials that make up a chair, like the wood and glue or plastic and screws that a chair is made of.
Defining a successful MVP is just beyond this, where you articulate what the database and UI are meant to do. Think about a booking app you’ve interacted with recently, such as for lodging, a flight, a fitness class or car rental. The objective of such an app is simple: select a date and time slot for your booking, fill out a form with personal information, and receive a confirmation.
This typically means there is a searchable and filterable list view, a detail view of the appointment, a form, and a confirmation screen. Most booking forms also include email and sometimes SMS confirmations and reminders. Some allow you to create an account and store your personal information for future bookings. Others may even allow you to set your preferences and alert you to when bookings you’re interested in become available.
But how much of all of this functionality is required for it to be an MVP? To understand this, first define the goal of the app. In this case, it’s to book an appointment. If you are building an MVP for an application where the core user goal is to book an appointment, then everything directly outside of that goal is potentially ancillary.
I use the word potentially here because if the value prop of your booking app is extended functionality beyond the core goal–say, a weather-aware app that suggests activities to book that are compatible with the given weather–then your MVP may be more than just the core booking experience. But the principle is the same: remove everything except what is absolutely essential to accomplish the core goal of the product or feature.
The chair or MVP version of a booking app can be, when it is reduced down to its most primitive elements, a list view, a detail view, a form view, and a confirmation view. Anything beyond this functionality is extraneous, so adding it to your scope may slow you down. While the experience may not be the most compelling or complete feeling for the end user, the goal of building an MVP isn’t to dazzle your users. It’s great if that happens, but the goal is to ship the primitive thing that solves the user’s problem and continue building in small, focused sprints once the MVP is complete.
Why not just try to build the whole thing?
As product builders, one of the hardest things for us to do is project a timeline for a given project. When we’re building for our side hustles as solo developers, it doesn’t usually matter how fast we build something. Building something on our own time that isn’t directly tied yet to revenue or supported by sales or funding means that a project can be completed at a leisurely pace without serious consequences.
Building products for other people is a significantly different relationship. When working for a client, they are typically paying by the hour or on a release schedule. They have a goal that is important enough for them to invest their money into, and a lengthy delivery timeline could cost them a competitive edge or eat into essential capital that the business needs for daily operations. By breaking a project down into the most primitive components, we aim to deliver value to the customer in small but complete-feeling tranches of work.
This gives the customer a sense of progress and allows them to give feedback to course correct along the way. If executed well, it may also mean that the customer can begin generating revenue early on in the product’s lifecycle, which is good for them and therefor good for you.
In a larger company, the stakes may not be as high as a make-or-break delivery timeline with an individual client, but they are nevertheless significant. This is because as product builders we are often at or near the center of activity for a company. This means that customers and other stakeholders are downstream of product decisions and benefit or suffer from those decisions.
A product or feature that takes too long to build because it was given too much or an undefined scope can lead to churn. A protracted release could disrupt planned marketing campaigns and other promotional activities. In the worst cases, companies sometimes string together what looks like a robust, feature rich product, but under the hood is a mess of technical debt and architecture that won’t scale.
It the MVP is defined well, then it often means that a base foundation has been laid that can be built upon. Each iteration after that, if it also takes the MVP approach, delivers progressive value for the customer over and over again. In this way we not only start by defining and building the chair, but each subsequent improvement is its own chair.
Conclusion
Now that nearly anyone without any developer experience can build software with the help of AI, one of the key problems that one inevitably encounters is context rot. This happens after excessive iteration and code generation; it’s a breakdown of the LLM’s ability to maintain awareness of the terrain and elegantly build upon the output of previous iterations. One way to prevent this is to build in a series of MVPs. That is, to focus iterations on small improvements that consistently deliver value.
The reason I wrote this article isn’t because of AI though. I wrote it because for a long time in tech there has been so much dogma and mystique surrounding product management, and this has created partially a strict interpretation of MVPs and also partially such a frequent use of the acronym that suggests everyone understands what it means.
In reality, an MVP is a complex concept because it doesn’t have or require a strict definition. The definition changes depending upon what you’re building and what medium you’re working in. Defining an MVP is more of an art and a feeling than it is a result of rigorous academic listing of requirements.
This is why I suggest to new product managers to develop an understanding about MVPs and scope by reflecting upon something that already exists and something that they use every day. It’s not until we develop a firm grasp on product design for common objects that we are well equipped to define and articulate the scope for such an abstract medium as software.