Building an MVP: How to define the first instance of your product

Defining great products is a demanding process - it needs talent, inspiration, knowledge, and insights along with great prioritization, management skills, and a deep understanding of the true meaning of minimum viable product. Especially the definition of the MVP is particularly difficult as the team has to envision the product but also focus on the best possible set of features to start with - and then iterate fast by building additional ones. Here is a method for defining an ‘MVP’ that is indeed a Product with the Minimum set of features that increase the likelihood of being Viable.

1. Frame the problem

One of the most important steps in the product development process is the analysis and decomposition of the primary problems that need to be solved. Business problems have multiple aspects; they impact various stakeholders in different ways, and they live in complex ecosystems that need to be clearly depicted. It is a good practice to use a model, a structure to help in formulating the problem with clarity.

Start framing the problem by describing the ideal situation vs reality, and how certain users are impacted. Provide statistics and facts — for example, figures to describe the size of the problem or the potential of the opportunity. 

Keep it simple and clear: the problem statement must be well-structured, in simple language - with no technicalities, buzzwords and fancy terms. In fact, the problem statement should be standardized and used by all stakeholders - e.g. product managers, analysts, developers, sponsors, and investors should all be able to easily articulate and consume ‘problems worth solving’ - expressed through a simple, well-understood, standard form.

→ Check also: How to Set up the Innovation ‘Dream Team’

2. Identify the users

At this point, the product team must ensure that they understand who they are solving for. The process is simple - the team identifies and names the different classes of users in the context of the problem. For each of the identified users, the team documents their apparent needs and the problems they are facing - their pain points, expectations, and the best possible experience they could have in this context. Finally, the team sets the draft success criteria for each class of users.

3. Understand the users

The previous step is about Identifying the users, which is very different from understanding them. To do so, the product team must study the users and acquire sufficient knowledge about their profiles, priorities, needs, and habits. Team members must apply empathy and use various research techniques to get insights and achieve a state where they can think as a user. Existing knowledge and public domain insights, along with user interviews, surveys, and focus groups are all great ways for getting a better sense of the users — and also for validating the problem statement and candidate solutions.

4. Validate the problem

Having defined the business problem with clarity, allows the product team to validate it with key stakeholders — including customers or end-users. The objective is to question the problem itself and ensure it is a worth-solving one. During this process, the team must try to answer the following questions:

1. Are users aware of any alternative, even partial solutions to the problem?

2. Is this the most significant problem the users are facing in this context?

3. Are there any workarounds they are using to avoid the problem or mitigate it?

4. How would their situation improve for the users if there was a good solution?

5. Would users pay for such a solution?

6. Is the problem aligned with the overall strategy and the purpose of the company?

7. Are there more important, more impactful problems to solve?

At this point, the team must also scan the market and the state-of-the-art to figure out if there are existing products or services that attempt to address the same problem. If there are, it is critical to understand how they are approaching the problem and also collect any evidence regarding their success.

Check also our unique Innovation Toolkit - a collection of seven innovation templates that empower teams to frame problems, shape ideas, run hackathons and more.

5. Ideate and explore solutions

The process of ideation should be based on a solid, shared understanding of the problem space — the situation, the ideal state, the personas, their pain points, and the associated business opportunity. The next ‘problem’ to solve is the generation of ideas — the team needs potential solutions that provide value to both the users/ customers and the company. Ideation could take the form of a series of brainstorming sessions, design sprints, or internal contests like hackathons.

Regardless of the form or methods of ideation, the team must ensure that all the ideas are being captured, using a standard format, and, ideally, into a system. This is important to allow fast iterations over the resulting set of ideas so the team can perform necessary merging, grouping, ranking, and enrichment. Depending on the scale of the initiative, an ideation system could add significant value by accelerating the entire process.

As soon as there is a set of high-potential ideas, the team must iterate through the following steps:

1. Review all ideas and prioritize them based on their potential and feasibility. During this step, the team must not discard ideas. Instead, it is wise to assign priorities - this allows ideas to stay active and be reconsidered under different circumstances in the future. Prioritization allows the team to pick the most promising ones, using not just opinions but a standardized and more objective ‘idea assessment framework’.

2. Combine ideas when it makes (product) sense — merge or group them — to draft an overall solution or a coherent product definition.

3. Iterate and refine the ‘product draft’ - make sure that the solution under formation has the required integrity to be called ‘product’.

4. Start small, but think big and define a long-term product roadmap.

5. State all key assumptions and open questions - and also how you are going to validate/answer them.

6. Define the ‘Complete’ Product

A common mistake is when the team ‘easily’ identifies a set of ‘obvious’ use cases as the MVP — without a clear product vision and a sufficient definition of the ‘complete product’. In fact, the Minimum in the MVP implies that you already have the Big Picture, the product vision. 

Assuming that this bold product vision is there, the next step is to define the ‘complete product’ as a long list of Epic User Stories that form the initial product backlog - the full version of the product (not just the MVP).

Another important point is that there is no need to apply feasibility, cost, or other constraints at this stage. I always advise product teams to briefly capture everything — even the craziest and most expensive product features: with effective prioritization and refinement, the product backlog can host both the big thinking around the product and the laser-focused MVP definition.

This way, the product team does not have to skip, drop or archive feature ideas that look ‘ahead of their time’ or ones that are not well-understood yet. Instead, the team includes them in the backlog with a lower priority — thus keeping them discoverable and potentially useful in the right context, at the right time.

The process continues - the team Iterates and keeps adding more user stories until the product is described in ‘full’ - practically when there are no more meaningful stories to add: The ‘full product’ backlog should have all the features the team can think of, reflecting the needs of all the classes of users identified.

Check also our unique Innovation Toolkit - a collection of seven innovation templates that empower teams to frame problems, shape ideas, run hackathons and more.

7. Define the Minimum Viable Product

Having the ‘full product’ defined provides a great basis to spot its minimum, viable, first instance. To do so, the team needs a method to scan the ‘complete product backlog’ and select those features that form the best, minimum subset - the one that is expected to deliver enough value to early customers and thus keep them happy and engaged. This best, minimum subset is the first instance of the real product, which helps the product team to go to market faster, with minimum implementation costs, less risk and the right feedback loops enabled.

To find this minimum subset, the product team must carefully analyze each User Story — in terms of reach, value to the user, the importance of solving the problem, and also in terms of cost and feasibility. This way, all the user stories in the product backlog get a priority (a number — ideally as a function of the expected value, impact, and feasibility).

The next step is to rank the User Stories, with the highest priority at the top. This process takes more than one iteration over the product backlog: relative prioritizations must be challenged and competing features must be assessed carefully from both user and business angles. The team has to apply sound business judgment and product sense to draw the red line which defines the top n stories as the basis for the MVP.

8. Define a Measurement Framework

Along with the MVP definition, the product team must also define what success looks like. This can be done by identifying the key success criteria, in alignment with the strategy of the company, the product vision, and the expectations from the customers. The key metrics and the underlying data points must be identified and documented - as they set the basis for defining the Key Performance Indicators (KPIs) that reflect the performance of the product against time and other dimensions. To obtain a good understanding of the performance of the product, the team must set up a measurement and reporting framework - typically a funnel to measure conversion rates and a specialized dashboard as the single point of reference regarding product performance.

The ongoing Product Innovation

The process described so far, helps product teams to define good MVPs - smaller instances of the product that still solve the major problem for the customer and thus have an increased likelihood to be viable. The MVP definition reflects what to build, why, for whom, and when.

But this is just one part of the story: a successful product must also be built in the right way - it also requires great implementation of the defined MVP. And here is where agile product development makes the difference: by leveraging fast iterations, user-centricity with systematic feedback loops, and a product innovation mindset, the released MVP becomes a ‘platform for experimentation’, the ‘vehicle’ that helps the product team identify unarticulated user needs, the next most important features to build or even pivots towards different business models and solutions.

The launch of the MVP is only the start of the agile journey - an ongoing product innovation process.

Check also: our unique Innovation Toolkit - a collection of seven innovation templates that empower teams to frame problems, define product concepts, shape ideas, run hackathons, and more.