How to Build Minimum Viable Product?
Why aim for an MVP?
When bringing a new product to market or looking to launch a new project internally, one of the most important things is to ensure that you validate your assumptions as early as possible so that you don’t waste time developing the wrong things. The term “Minimum Viable Product” describes such a process. Although originally coined by Frank Robinson in 2001, the term was brought to the mainstream by Eric Ries in his popular book “The Lean Startup”.
Without a narrow focus on MVP, it’s easy for software development teams to go away and spend a year building a system which turns out to be unfit for purpose.
- Why aim for an MVP?
- How to identify what your MVP is
- 4 Steps to Building a Compelling Value Proposition
- Step 1: DEFINE the problem set
- Step 2: EVALUATE whether your you have a compelling value proposition
- Step 3: MEASURE potential Gain/Pain ratio
- Step 4: BUILD compelling value proposition statement
- Ensuring laser focus
- Turning your list into actionable items
- Choose your delivery approach and form your teams
- Start building and stop planning
Context is everything
It’s important for us to get picky here, what do you think Minimum Viable Product means? MVP in its original and purest term, as defined by “the lean startup” means “that version of a new product which allows a team to collect the maximum amount of validated learning about customers with the least effort”. This could just be a sign up link on a website where users can enter their details.
Many people who say they want an MVP often actually want an “MMP” or “Minimum Marketable Product” which is the minimum set of features required in your product before you can start selling it. Note the difference, MVP is a product which might not function brilliantly but allows you to learn; whereas MMP is the first marketable version of your product.
Due to the above, some people argue that the original definition of MVP is actually now more akin to a “Minimum Viable Experiment”. Whilst this might seem like nitpicking, it’s important to ensure that your project team is all on the same page, so get this agreed up front.
How to identify what your MVP is
MVP/MMP semantics aside, the first question to ask is “what are we trying to achieve from this launch”. This can be done by having a discussion amongst your key stakeholders with some probing questions such as:
- What questions do we want to answer about this product?
- What functionality do we need to build in order to answer the above questions?
- What are the relevant user journeys that will be provided and how fully functional will they be?
- Do we want to test some hipotesis, and if so what parameters will we utilise?
A good starting point would be to work on building a compelling value proposition statement that all stakeholders agree with.
4 Steps to Building a Compelling Value Proposition
Establishing a substantive value proposition is critical if you want to start the journey from your idea to building a successful product. In its simplest terms, a MVP should be taken as “Minimum Value Proposition”. A good starting point for this is developing a statement that explains what benefit you provide for who and how you do it.
As you set out to create value proposition, consider the following four steps:
Step 1: DEFINE the problem set
A problem well stated is a problem half solved. Foundation of defining a value proposition involves 4Us framework. A definitive yes to the majority of its questions means you are on the right path toward a compelling value proposition. Otherwise, consider re-evaluating and revising your idea.
- Is the problem Unworkable? Does your solution fix a broken business process where there are real, measurable consequences to inaction?
- Is fixing the problem Unavoidable? Is it driven by company projected growth, market, governance or regulatory changes?
- Is the problem Urgent? Is it one of the top few priorities for a company?
- Is the problem Underserved? Is there absence of valid solutions to the problem you’re looking to solve?
Step 2: EVALUATE whether your you have a compelling value proposition
After you determined the problem set and validated its criticality, ask yourself: What is unique and compelling about your MVP? Think of your ideas in the context of the 3Ds and evaluate if your project opens up the potential for a breakthrough solution:
- Discontinuous innovations – Does it offer transformative benefits over the status quo? Good enough isn’t good enough if it can be better, and better isn’t good enough if it can be great.
- Defensible technology – Does it create unfair competitive advantage? Data, algorithms (Machine Learning and Artificial Intelligence) and workflow automations are some of the keys to technology advantage.
- Disruptive business model – Does it create value and/or cost optimization that help catalyze the growth of a business?
Step 3: MEASURE potential Gain/Pain ratio
One of the most effective exercises for evaluating value proposition is by measuring the gain/pain ratio which compares the benefits obtained from using your idea versus the cost to switch to your solution.
You should look for solutions that offer game-changing benefits with minimal modifications to existing processes or environments. Simply put: disruptive innovation would ideally be non-disruptive to adopt.
Non-disruptive is critical to MVP success. Strive to deliver an order of magnitude improvement over the status quo. If you can’t deliver a 10x gain/pain promise, users will typically default to “do nothing”.
Step 4: BUILD compelling value proposition statement
Once you have gone through the defining, evaluating and measuring steps, you are ready to BUILD your value proposition. For this you can take your target users groups and for each of them write a value statement following this format:
For (target users) Who are dissatisfied with (the current alternative) Our solution provides (key problem-solving capability) Unlike (alternative solutions).
Ensuring laser focus
Bear in mind that depending on your organisation and the familiarity with lean/agile ways of working your stakeholders might not be able to bring themselves to reduce their ever-growing requirements list to a suitable sub-set.
This is where expert facilitation and coaching needs to come into play, with a laser focus on objectives, rather than long wish lists of functionality that aren’t essential. A good question to ask is “is it possible to launch without this” or “could the customer still complete their journey without this item”. Do you really need that integration, or could it be managed manually?
Turning your list into actionable items
The real skill is turning your list of stakeholder requirements into an actionable list of items that can be built. One good way of doing this is by using the process of “User Story Mapping” and grouping related items into “Themes”, building a list of “Epics” that sit underneath these themes and then from these large deliverable epics, create a list of actionable and deliverable “User Stories” (non solutioned, user focused problem statements which can be delivered in a short period of time).
Choose your delivery approach and form your teams
In order to begin building your MVP you will need to come to a decision on how your development teams will operate and what their structure and design will be.
It’s important to involve the teams in these decisions to come to a shared agreement on the best delivery approach because in doing this, the team members will be more engaged and you will have a better outcome.
You might choose Scrum, Kanban, Scrumban, Waterfall, or a mixture of all of these. You’ll need to identify the best team size and the cross-functional skills required so that the teams can achieve what they need to without requiring unhealthy dependencies on other areas of the business.
Some important questions to ask are:
- Do we value iterative delivery with periodic check-ins (Scrum) or would we prefer to start with continuous development, limiting WIP, optimising for flow and reduced cycle time? (Kanban)?Alternatively, do we want to spend a lot of time nailing down our complete requirements up front and then delivering in large phases (Waterfall, not suited to MVP approaches)?
- What skills do we need within our team to be able to deliver on our chosen tech stack, languages and architectures?
- If we don’t have all the skills we need within the team, will we be impeded by our external dependencies? If so can we do anything about that?
All the above can be answered by running a facilitated discussion amongst the team and creating a “Team Charter” so that everyone is on the same page.
Start building and stop planning
A famous artist once said “How do I know what I want to create until I start painting”. Once you’ve identified a suitable subset of MVP items, start building something. Start building anything. Create a “strawman” set of wireframes that people can throw rocks at and knock down. Do it as soon as possible.
The development teams may wish to start their work ahead of the first set of requirements being fed in and this is often known as “Sprint Zero”. The development team need time to get their development environments set up, repositories and other collaboration tools.
Once this has occurred, the key thing is to get something built, firstly so that you can seek a good alignment within the internal team, but more importantly to get something released to your users or customer base so that you start gathering valuable and actionable feedback.