Minimum Viable Products - Could this be the answer to unsuccessful product launches?
In part three of our blog series Insights, we show you how you can implement new ideas and business models both quickly and cost-effectively.
We plan new business models and put them into practice. Captain Jake is back to help us out here: We want to find, test and implement new ideas.
In part two of our blog series you’ve seen that most of the time companies don’t understand their customers’ problems. Then they end up developing products that miss the market requirements.
In this blog, we show you how you can implement new ideas and business models both quickly and cost-effectively.
The most important thing we’ve discovered is that the central assumptions behind every new business model will always be only partially correct. Despite even the most extensive of experience, some of these will get it all wrong.
We want to have the best possible chances of success. So we have to test out our assumptions as cost-effectively as possible. What we learn from doing this will influence the further development of our business model. We’ve kept our customers involved from the very first day and that’s paid off now: Our idea satisfies a real need that customers have. Next, we will concentrate on implementing this idea.
Let's take a closer look at this using an example: One of our clients is a medium-sized bank. Their customers had switched to other banks or didn’t possess the up-to-date knowledge. At that time, the terms "Neobanks", "Challenger" or "FinTechs" were still unknown. So the bank, together with Horváth & Partners and FinnoConsult, decided to go for a new business model: a new digital product line exclusively as an app – not available in branches or online.
In digital product development, each channel means high financial expenditure. This meant that concentrating on a single channel was very cost-effective.
Testing the Central Hypotheses – Build
First, we take the assumptions behind a business idea that have been subconsciously made and transform them into precisely formulated hypotheses. We then evaluate these according to three questions:
• How important are they for the idea?
• How unsure are they?
• How easily can we test them?
It can sometimes be a shame that as a society we like to hold on to our convictions. If something contradicts us, then we deem it “wrong”, and critical tests are "not representative" for us. So we can push on without wavering. We hate to admit we were wrong. However, what we really need is a culture of questioning. Tests and customer statements are important, even more so when they make us feel uncomfortable. But questioning must also have consequences for product development: Critical questions have the potential to change an idea, maybe even bring it to a halt.
Assumptions that can bring down a project are called "deal-killer hypotheses". In the first step we want to test these deal-killer hypotheses. To do this as quickly and easily as possible, we need a greatly simplified version of our product. By simplified we mean that we build just enough to test our hypothesis. For example, the product could be a website, an email with a link or a roadside sign.
Let’s take Netflix as an example: The streaming service began sending out DVDs in 1997. The deal-killer hypothesis is this: "We can send DVDs cheaply without damaging them." To test this assumption, the founder sent 10 DVDs in envelopes from various post offices to himself.
There was also a deal-killer hypothesis in the example of our bank: "Customers don't need branches or websites for banking services."
Defining the Acceptance Criteria – Measure
Now we can test the hypothesis. First we have to answer the question: “When did the hypothesis pass the test?”
A possible answer for the Netflix example could be: "Nine out of ten DVDs were delivered undamaged, one may be slightly damaged." Carrying out this test takes just a few days and costs next to nothing.
With our online bank the test was even easier. Monitoring the customer user behaviour showed that most of them had not set foot in a branch or been on the website in the last 12 months. And yet these customers were still very active members of the bank. This data analysis took an hour and cost nothing at all.
The test also had positive side effects: We were able to gather additional information about possible target groups and their specific interests.
Use the Results Wisely – Learn
You’ve just seen two simple examples. What have they revealed to us? We must formulate deal-killer hypotheses clearly and test them accurately. After that we can implement new ideas in a targeted manner and develop new business models faster.
Then we ask ourselves: "Have our hypotheses been confirmed?", if not: "How much were they out by?" and "What did we learn from the test?". The answers teach us how we must adapt our business model. Because a test only makes sense if we learn from it!
Using our medium-sized bank as an example, we had planned a structure that displays “all important information at a glance” when we launched. Thanks to our tests we learned that this “flood of information” would not be helpful for customers, but that it actually acts as a deterrent. Grateful for what we learned, we radically simplified the display and in doing so achieved greater acceptance.
Repeat the Pattern – Repeat
We have to go through the "Build – Measure – Learn" pattern more than once. It’s a cycle that constantly improves our idea or our business model. With each step we put our own assumptions to the test. We keep on doing this until we have a marketable product. However, it’s not possible to test everything in advance. Some things we only learn when the product is actually on the market. We call the first marketable product the "Minimum Viable Product (MVP)".
What was that at our bank? Within 9 months we placed a fully functional digital bank online as our MVP. This allowed us to prevent customers from switching to other banks. Our strategy followed exactly the approaches we have presented to you in this blog so far.
A word of warning
Reid Hoffman, Co-Founder of LinkedIn, once said: "If you are not embarrassed by the first version of your product, you've launched too late."
In principle this is true, but a product also has competition. And customers will compare your product with already existing ones. If your product fails when it’s first launched, it will not get a second chance. This means that we have to differentiate between pure test products and marketable products. You must take this into account during development.
The first marketable version of your product will not meet your expectations. That cannot and should not be the case. That being said, it must really fulfil at least one “job to be done” for at least one narrowly defined target group.
You can then establish or expand your product. You can read more about this in the fourth part of our series.
We look forward to hearing from you!
Do you want to be flexible like Captain Jake? Then contact us and steer your projects to success.
David is Senior Project Manager for Strategy & Innovation at Horváth & Partners. Together with Finnoconsult, David supports companies in setting up digital ventures from strategic alignment to launch.