A stepwise approach to help you define a real MVP

An 8-Step Approach to Help You Define a Real MVP

From a problem to a well-defined MVP in 8 steps: understand the problem, your users, the market and your competitors; define your ‘complete product’ as a backlog of product features; assess your features, rank them and select the smaller set that can bring enough value to your early customers; so they are happy enough to stay engaged and promote your product.

1. Frame the problem

One of the most important steps in the product development process — is the understanding and proper articulation of the problem. It is a good idea to use a model, a structure to help you formulate the problem with clarity.

Start by describing the ideal situation versus the current one, and how certain users are impacted by this gap

Support your problem statement with statistics and facts — for example figures to describe the size of the problem or the potential of the opportunity. Keep it simple and clear- a structured, well-understood articulation of the problem with no technicalities and fancy terms.

The problem statement should become part of your ‘common corporate language’: your team, your investors, your sponsors and other stakeholders should all be able to instantly understand it and reference it when reviewing your solutions and product plans.

2. Identify your users

Make sure you know who you are solving for! Identify and name the different classes of users in the context of your problem; document their needs and the problems they are experiencing; identify their pain points; their expectations, and the best-possible experience they could have in this context.

Define Success criteria for each class of users.

3. Understand your users

Identifying your users is different from understanding your users. You need to apply empathy, study your users and deeply understand their profiles, habits and needs. You could use existing research and public domain insights; or host user interviews and focus groups — to validate both your problem statement and your potential solution.

4. Validate the problem

Having your problem defined with clarity, allows you to validate it with your key stakeholders — including your customers or end-users: challenge the problem and make sure it is worth-solving; study the impacted users and document how they are affected by this problem. During this process, try to answer the following questions:

Do users know any potential solutions to the problem?
Is this the most significant problem they are facing– in this context?
Are there any workarounds they are using?
How would their situation improve if there was a good solution?
Would they pay for such a solution?

At this point, you must also scan the market and the state-of-the-art to figure out if there are existing products or services — addressing the same problem; and if so, it is critical to understand how.

Startups and the Importance of Agile Product Development

5. Ideate and draft potential solutions

Having a well-defined and validated problem, enables you ideate and explore potential solutions. At this stage, I would recommend starting by setting the context — make sure your team is aligned and has a deep, shared understanding of the problem space — the situation, the ideal state, the users, the personas; the pain points and the opportunity.

Then, move on to an ideation phase — you need ideas on how to solve the problem and provide value to your customers. Ideation could take the form of a series of brainstorming sessions, or design sprints or internal contests like hackathons.

Whatever the form or methods you select, make sure your team is capturing all of the ideas, into a system. This is important to allow fast iterations over this set of ideas, and post-processing: you will have to evaluate each idea and attach metadata and artifacts as you go. Depending on the scale of your initiative, an ideation system could add significant value by organizing and speeding up the entire process.

Assuming a set of great ideas and potential solutions is there, iterate through the following steps:

Review all your abstract ideas and prioritize them based on their potential and feasibility. Do not discard ideas; assign priorities instead (this will allow ideas to stay active and be reconsidered under different circumstances in the future). Prioritization will allow you to pick the most promising ideas, using not just opinions but a standardized ‘idea assessment framework’.
Combine ideas as necessary — merge or group them — to draft an overall solution or product definition
Iterate and refine the product draft; make sure that has the integrity required to call it a ‘product’
Start Small — but Think Big and define a long-term product road-map
State your assumptions — and how you are going to validate them

6. Define your ‘full Product’

The Minimum in the MVP implies that you already have the Big Picture, the product vision! 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 good definition of the ‘complete product’.

Assuming you have this bold product vision, the next step is to define your ‘complete product’ as a long list of User Stories — your product backlog. It is important to understand here, that this is the full version of your product / not just your MVP!

Another important point is that you don’t have to apply feasibility, cost or other constraints at this stage; my advice is to describe everything — even the most crazy and expensive product features, as you will be able to prioritize and manage them at a later stage.

This way, you don’t have to skip, drop or archive an idea for a feature that looks ‘ahead of its time’ or not well-understood yet. Instead, you should include them in your backlog with a lower priority — but they will still remain discoverable and potentially useful in the right context.

Iterate and keep defining more user stories, until your product is described in full .Your ‘full product’ backlog should have all the features you can think of, reflecting the needs of all users identified so far; and all in the form of solid user stories.

7. Define your MVP — the Minimum Viable Product

A this point you have the definition of your ‘full product’ — the complete not the minimum. What you need now, is a process to find the best minimum subset of features from the complete product backlog.

This ‘best minimum subset of features’ which delivers enough value to your early customers to keep them happy and engaged, is what the MVP is all about: the first instance of your real product, which will help you to go to market faster, with minimum implementation costs and the right feedback loops enabled.

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

Next step is to rank the User Stories, with the highest priority at the top; then, you have to apply business and product sense to draw the red-line which will define the top-n stories as the basis for your MVP.

How to run a successful Design Sprint

8. Define how success would look like

By now you have a great basis for building your MVP: you have a solid problem statement, deep understanding of your users, the market and the technology, along with a prioritized product backlog.

Before you start implementing your product, it is a wise move to define specific Success Criteria — and how to track the involved figures. Identify the key metrics and the underlying data points; define and document the KPIs (Key Performance Indicators) — which will reflect the performance of your product against time and other dimensions.

Think of how your assumptions and hypotheses are linked to those metrics and KPIs. Setup a system to monitor these KPIs and how close they are to the pre-defined success. You will probably need a funnel to measure conversion rates and a special dashboard — as a single and reliable point of reference regarding the performance of your product.

Next steps: Build, Measure, Learn; iterate

The process described so far, will hopefully give you a well-defined MVP. You will know what to build, why, for whom and possibly when and how.

But this is just one part of the story: to succeed you have to ‘make it happen’— you need an excellent MVP execution as well. Follow modern agile engineering practices — build, measure, learn and iterate fast; always with the user in mind.

Comments, suggestions and questions welcome! https://www.linkedin.com/in/gkrasadakis/

The Minimum Viable Product, explained.

Related articles

Cover image: pixabay

A stepwise approach to help you define a real MVP — Minimum Viable Product