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 theanalysis 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 structureto help in formulating the problemwith clarity.
Start framing the problem by describingtheideal situationvsreality, andhow certain users are impacted. Providestatistics and facts— for example,figures to describe thesize of the problemor thepotential 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 statementshould 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 andnamesthe different classes of usersin 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 Identifyingthe users, which is very different fromunderstandingthem.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 isa worth-solving one. During this process, the team must try to answer the following questions:
Are users aware of anyalternative, even partial solutionsto the problem?
Is this the most significant problem the users are facing in this context?
Are there anyworkarounds they are using to avoid the problem or mitigate it?
How would their situation improve for the users if there was a good solution?
Would users pay for such a solution?
Is the problem aligned with the overall strategy and the purpose of the company?
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 needspotential 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 likehackathons.
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 systemcould 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:
Review all ideas and prioritize thembased on theirpotentialandfeasibility.During this step, the team must not discard ideas. Instead, it is wise to assign priorities - this allows ideas tostay activeand be reconsideredunderdifferent circ*mstances 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’.
Combine ideaswhen it makes (product) sense — merge or group them — to draft an overall solution or a coherent product definition.
Iterate and refine the ‘product draft’ - make sure that the solution under formation has the required integrity to be called ‘product’.
Start small,but think bigand definea long-term product roadmap.
State all key assumptions and open questions - and also how you are going to validate/answer them.
6. Define the ‘Complete’ Product
A common mistakeis when the team ‘easily’ identifies a set of‘obvious’ use cases as the MVP —without a clear product visionand asufficient definition of the ‘complete product’. In fact, theMinimumin the MVP implies thatyou already have theBig Picture, theproduct vision.
Assuming that this boldproduct vision is there, the next step is todefine the ‘complete product’ as along list of Epic User Stories that form the initial product backlog - thefull version of the product(not just the MVP).
Another important point is thatthere 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 togo to market faster, withminimum implementation costs, less riskandthe right feedback loops enabled.
To find this minimum subset, the product team must carefully analyze each User Story — in terms ofreach, value to the user, theimportance 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 torank 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 applysound businessjudgment andproduct senseto 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 implementationof 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.
