What is a MVP?
5th June 2020
I'm not going to tell you - there's a link below for you if you don't already know about MVPs. What I will cover are some thoughts about how MVPs are conducted in two different innovation cultures, and some watch-outs for both.
Reading time: 6 minutes
Next week: Update: two months in to working for myself
There are lots of different ways to create a MVP, and ultimately the size and shape will depend on what company you're working in, the team culture, the product, and what you're trying to achieve. I think that as long as you get value out of the exercise, and you can be confident that your learnings are valid, then it doesn't matter how quickly or not you can build it, and the cost will vary (as long as the value you get back is higher).
This post tackles something that I've been thinking about for a while - the differences between creating an MVP in an ideas-led scenario vs. in a needs-led scenario. This has been triggered by reading recently about Outcome-Driven Innovation. Hopefully this might help you to get a better start with your MVP, as I believe that understanding whether "ideas" or "needs" are driving your decision to create an MVP is key to having a smoother MVP experience.
In an ideas-led culture, your approach to product development is likely to be arranged around a process of thinking of ideas for a product, service or solution first and then wanting to test and validate how well the idea works with minimum effort. It's unlikely that you'll have really put huge effort into discovering any true customer needs to address first, but you have an idea you think will be great, and you want to test it.
Be prepared to fail, don't just set out to succeed
Failing fast and failing quickly are buzz-phrases I hear a lot, and I like the sentiment, but does your MVP team prepare for this? As you're testing an idea, before you start, do you all agree what failing looks like and stick to it, or is there a risk that confirmation bias can kick in? If you only focus on setting out to succeed, and think a 15% uplift will indicate that your MVP is a success but only get 13%, will the team still count a success anyway? A counter to confirmation bias is to measure for failure as well as success. If your failure measurement is met, then you know the MVP has failed, no discussion.
You may need more than one MVP before you can move beyond MVP
An ideas-led culture by definition means that not all ideas will succeed. You're also more likely to come up against collective belief (one usually more outspoken person gives an opinion, two others agree, and then the whole room quietly nods its head) and HIPPOs. In these situations, an MVP is probably that last thing you need as the insights are likely to be ignored or disregarded anyway, so why bother? You have other problems! If your MVP doesn't completely fail, and doesn't completely succeed (this is common), what do you do? My mitigation here would be to make it clear to stakeholders up-front that ideas-led MVPs can require iterations, and so you may not find success, failure or traction until MVP v3.
Don't always trust your users
By focussing on ideas first, you're testing by observing real users, but you may not have given yourself the opportunity to discover better ideas. Users of an MVP, even if you survey them afterwards, are unlikely to give you indications of what a better solution might be since they won't know all possible solutions. Be really hard on yourself in the idea generation and selection phase - involve all the experts. Don't just get your designers to make it look as good as possible, get engineering & technology input and advice up-front; make sure all the skillsets involved can input into idea generation and selection. It shouldn't ever be just something that designers do in a room on their own - they may not come up with the best possible solution to test.
In a needs-led culture, you'll be focussed first on finding the unmet needs of your target audience, you'll then start creating something that answers them and probably be using an MVP process to validate. Before you create a MVP, you're likely to know what unmet need it's going to address and so your chances of success are already going to be higher than with an ideas-led MVP. However, you still need to consider a few things.
Is the unmet need you're trying to satisfy clearly communicated?
Let's say you've identified an unmet customer need that you want to address with your MVP. Can you articulate this need in a way that your stakeholders will understand and agree with? If you don't, and you launch a MVP, you could find yourself proclaiming to Sales that you have an amazing way to sell more of widget A when Marketing don't want to to sell more of widget A because long-term, it causes more churn. Your need statement may have been wrong, or more likely, you didn't get agreement across the areas of the business impacted as to what the customer need actually is.
Are your customer needs statements correct?
When defining the unmet needs you're tackling with your MVP, have you thought about whether it's actually, a want, a requirement, a benefit, a task, or a problem? These are all different concepts requiring different approaches. As an example, you might have identified a need for customers to pay online for an existing product where this hasn't been an available option before. Be honest with yourself - is that really a need in 2020, or is it simply a hygiene factor? If so, why are you bothering with a MVP? What will you learn, that people like to pay for things online? Erm...
Don't believe in latent needs
Straight in with a latent need example here, or rather an example of what some think is a latent need when it isn't. The success of Netflix over Blockbuster is sometimes described as answering the latent need to stream movies online - I completely disagree. The real need was always there and hasn't changed; I need to rent a movie so that I can watch it because it's cheaper than buying it outright. Or even simpler - I need to see a movie. How has that changed? It hasn't. When streaming technology matured enough, Netflix identified a better way to answer the existing need using a new technology. Simple. No latent needs uncovered here! This is the story of the $3000 movie rental MVP - from 1975! Answering the same need differently is still innovation, but to be clear the need to see movies was always there; what George Atkinson discovered wasn't a hidden, unanswered need, but a better way to answer an existing one. Bringing this back to MVP, the message here is that if you're told that you can't possibly identify all the needs before you start an MVP process, it's not true. This is just as important to recognise when you're analysing the results. If you see that your MVP is being used to fulfil a different need to the one you intended, it's not latent - it was always there. It just wasn't the same unmet need you were testing an MVP for!
Last week's blog
I discovered Agile methodology about 10 years ago. There's a lot written about it already, but this article is a light-hearted summary of my take. Actually, this isn't just about Agile - it's about any and all methodologies for software delivery!
Reading time: 5 minutes