Getting real with minimum viable products

Making a success of the continually misunderstood and misused method.

Designing and building minimum viable products (MVPs) for experimentation is a crucial part of a great product design and development process and yet the term feels like it’s been hijacked. It’s been taken by the uninformed and assimilated into the acronym heavy business world by executives that know no better.

The blame can’t be placed solely at the feet of the business; product teams need to accept some of the criticism for both the way they talk to the business and their often ineffective implementation of MVPs.

Whether this has already happened in your business or you’re right at the beginning of the Lean journey, hopefully the advice below will help to create a minimum viable product process that brings real value to both your customers and business.

Start by building MVPs with a goal in mind

To make a success of MVPs their full potential needs to be utilised appropriately by identifying what it is the team needs to learn first; this should form the objective the team works towards.

Consider what the riskiest assumptions are or whether there are any gaps in the team’s customer or product knowledge. Understand what the measures of success are that will validate the most important learnings about the customers or product.

Even at this early stage the measures of success don’t have to be arbitrary, look at what data there is about the current customers base, their usage, interactions and behaviours. Consider what change in those behaviours will validate the success of the MVP.

Without that goal or objective to achieve it may be difficult to get a decent plan off the ground. There’s also the risk that the wrong type of information could be collected and measured, providing only false or skewed learnings to work from.

Equally if the product team doesn’t fully understand the reasons behind using an MVP or even how to go about the process of designing, building and measuring them, the real value of building this way will be lost.

Identify what the focus of the MVP should be

There are two focus areas for minimum viable products:

1. Increasing learning — build, measure, learn, repeat
2. Delivering value — build smart for business and customer value

Each focus area has it’s own tactical ways of implementation (some of which are expertly detailed in this talk by Ralf Jeffery) that can be used in different scenarios, dependent on what needs to be learnt and how quickly the feedback is required.

The selection of them is dependent on what has been identified as the riskiest assumption, the most valuable learning or how mature the team’s Lean processes are. The business processes and people involved with that team could also be determining factors.

Increasing learning — build, measure, learn, repeat
With this first focus area the team needs to be running a Lean UX design and development process, as part of that process they will be identifying their assumptions about the feature and from these creating testable scenarios: hypotheses.

The MVP will be used to validate those assumptions, using the hypotheses created, by understanding what the market wants and measuring user interest, usage and interaction to determine whether to proceed.

With this method there’s only one real purpose of the MVP and that’s to validate the riskiest assumptions by collecting usage and behavioural data to prove whether those assumptions are true or false.

Remember that this is just an experiment and that can come in many forms. A customer survey, new product email, button tracking, push notification, simple landing page, social media, small scale feature change or any other cheap and fast way to collect user data will all be valuable.

The important factor is fast and cheap measurement and validated learning; the experiment doesn’t have to be a full feature or product built in code. The experiment can be anything that has the possibility of real live measurement and quick turnaround feedback that is valuable to the team’s ability to learn about their user’s behaviours.

The MVP will only be successful if the team has the ability, trust, space and time to repeat the process until they have something that customer’s both want and need. If their Product Manager doesn’t allow that team to fail in order to learn then the process becomes meaningless and the team will be too nervous to get it right first time. This will probably result in wasteful upfront design and analysis.

Fail fast and keep learning. This first method is best used if the team have identified very risky assumptions in the discovery and ideation phases of design. It’s best to know as soon as possible whether those assumptions are true or false before continuing to build anything more substantial and getting it wrong.

Delivering value — build smart for business and customer value
Designing and building a limited functionality feature or product to start delivering customer and business value straight away.

Enabling the business to get to market quickly is an honourable endeavour and if done correctly this second focus area can still produce valid learnings, maybe even more so than the implementation above.

This method is best utilised when the assumptions are less risky, when there is pressure from the business to move quickly, when there’s already a good understanding of customer interest from research or if market influences demand it.

Bringing business value is important and if that can be done quickly while effectively measuring customer behaviour it can be a winning situation. If there is less risk involved with some of the assumptions this will most likely achieve more and still allow the team to react and move quickly.

The team could potentially learn more because they’re providing something useful to the customer; rather than just an experiment to measure user behaviour there’s something valuable for customers to use. That usage will therefore have more meaning and provide deeper insight into their behaviours, wants and needs.

However the team will need to be ready for that as when there is more to measure, there is more to learn and there is more to act upon. The team may need a more robust process for capturing and monitoring data and the Product Manager will need to allow them time to do this and ideate potential next steps.

To aggregate data and highlight themes in customer behaviour over time the limited functionality MVP might have to be left running for a longer period. The team will also need data analysis capabilities to help identify useful patterns and avoid false positives.

Build small and bring business value early. This second method is best used if the team have identified lower risk assumptions in the discovery and ideation phases of design. If the team already have an understanding of what customers want they can start to bring some customer and business value while using the data to identify what customers really need.

Involve the business by building trust and influence

Without trust the team won’t be able to change the mindset of management and build MVPs with real purpose.

Building trust with people external to the product team requires clear examples of success or failure; where small steps were made to understand customer behaviour and where appropriate evolution of the product was inline with what customer’s really need.

Business stakeholders will not allow the team to build true MVPs without those clear examples of how the process works and the value it can bring. This might mean going ahead with some small scale experimentation first, out of their line of sight or on features that aren’t business critical.

Building influence with stakeholders has to be a priority if any process is to be changed and that’s no different if Lean practices are to be employed by the team. Speak their language, move away from trying to explain what ‘Agile’ or ‘Lean’ are, or what ‘build, measure learn’ means, or how ‘MVPs’ are used.

‘Minimum viable product’ is a scary term for them, no one wants a minimum product, so don’t use that language. Keeping terminology behind closed doors is going to ensure new processes are adopted and understood before the rest of the business catches on and potentially misuses them.

Business people talk business language and they have selective hearing towards that language; listen to how they speak and respond using their terms where possible.

The MVP process can be easily explained as the first step to building a full feature or product. Delivering business value is important to them and their agenda, if that happens in a much shorter time frame it will mean they get on board with this way of product development sooner.

Showing business stakeholders upfront a plan of potential iterations based on these small steps and what value should be expected at each stage will help them realise the potential of starting small, building fast and pivoting based on learnings if required.

How to identify a poor MVP process

All these methods are perfectly good, but understanding the difference and when to use each one is important as they can all be used as a tactic to aid a practical build, measure, learn process if done correctly with the right objectives in mind.

Designing and building MVPs outside of these focus areas should raise questions and there are obvious red flags to an incorrect and potentially harmful MVP process;

• pressure from the business to build something
• the highest paid person’s opinion on what should be built
• no plans on how to measure user interaction and behaviour
• no plans of how to validate the data and learn from it
• no process to iterate the feature after release
• management not accepting failure as a process of learning
• little or no trust that features will be optimised over time

If any of these reasons are apparent then the team isn’t really building an MVP; they’re just building the first phase of a feature… of which there probably won’t be a second phase for some considerable time, losing all the value of building this way.

Take a look at this checklist created by Paulo Caroli, are you answering ‘yes’ to all of these questions?

“Choose wisely…

…for while the true MVP will bring you validated learning, the false MVP will take them from you.”

True words spoken from the Grail Knight in Indiana Jones and the Last Crusade! While the right MVP method could be the Holy Grail for the product team and their customers, going about it in the wrong way could spell disaster in the long term.

If you’re looking for more about Agile, Lean, design and culture you can follow me on Twitter @ndxcc or read more on Northern Dynamics