Testing your business idea and ensuring product / market fit is an essential part of developing your startup.
But what’s the best way to do this? For the products we are building at Fullreach, and for those our clients are developing, we run MVTs – minimum viable tests. We use MVTs to check our ideas, and if the test is successful only then do we invest in building an MVP (minimum viable product). Why do we go for MVTs over MVPs at the testing phase? Because they’re faster, more affordable and more flexible.
I want to share a brief breakdown of what MVTs are and why I think they’re a smarter option than MVPs for testing your business concept.
First up, let’s deal with the basics.
What is an MVT?
An MVT is a tool for figuring out if you have a business idea that is going to fly or flop. With any new product or business, you’ll need to discover if there is really demand for what you’re building. And MVTs help you do this.
There are 2 essential characteristics of an MVT:
- It must test a hypothesis that is fundamental to your idea,
- It must include some sort of action.
Testing a hypothesis
As Gagan Biyani explains in his super-detailed analysis of the whole MVT process, an MVT can take many forms:
- it could be a simple landing page with a subscription form for interested customers,
- or it could be a trial at executing a certain part of your business.
Because I work on developing tech products, pretty much all our tests are landing pages. But what you build all depends on what the hypothesis is that you’re trying to test. Just always remember that you’re testing a hypothesis, not a product. All you need from an MVT is an answer to a question, not a functioning solution. For example, if it is fundamental for your new business to understand if people will pay two times more for a more sustainable version of an existing product, you don’t need to build that product yet. You just need a yes or no for this question:
Will customers spend two times more for a sustainable version of X?
Requiring an action
As Biyani rightly points out, getting people to actually do something as part of the test is essential.
“If your riskiest hypothesis is whether people will want your product, do not ask them. Force them to pay for it with their time or their money.” Gagan Biyani
The reason you shouldn’t ask is simple – people will say much more than they will do.
Ask someone if they like the sound of product X and 90% might say “sounds great”. But ask them to pay some of their hard earned cash for product X and perhaps only 10% will. You can see how this could be problematic for a new business’ forecasts.
By getting people to act in your test, you get a better understanding of whether they are really interested. Typical actions we use in our tests are:
- Subscribing for updates for a new product,
- Giving their feedback or opinion on a certain topic,
- Sharing with their friends or network,
- Agreeing to a demo call or conversation.
Why are MVTs better than MVPs?
OK, here we reach the key point. Because many of you will be thinking: “MVPs can do all of these things too.” Yes, they can. They’re just a slower, more expensive, less flexible and less focused way of doing them.
Speed
Designing an MVT does take some time at the ideation stage. You need to think really deeply and critically about the solution you’re working on and what hypotheses you need to prove. But once you’ve found the right hypothesis, everything else goes at rocket speed. Creating a page, running ads to it and getting concrete results can all happen in a matter of weeks or months.
Contrast that with an MVP, which can take many months just to develop – even longer if you need to build a team to develop it, which leads us on to …
Resources
I want to say this as simply as possible – you can run an MVT with zero code. And this means there is a much lower financial investment required. Even MVPs for relatively simple products can eat into your budget, and if you’re trying to build something more complex, you’re going to end up spending a lot.
And another key point here is your team. You can run MVTs without having a technical team, or with a minimal one (Gagan Biyani’s approach is to run MVTs before he finds a technical co-founder). This solves a huge problem for early stage start-ups – the need to recruit tech talent.
Not only is it time consuming and difficult to find the experienced developers you’ll need, it is also expensive. This is one of the biggest reasons why I think MVPs are a bad idea for early stage startups. Think about it: you invest all that time, energy and money into recruitment just to build an MVP just so you can see if your business is viable.
That all seems the wrong way round.
Instead, you could run a lean MVT process to work out if your idea will fly. Then you can go about securing funding and building a long-term team. Something I’ve noticed when building the team here at Fullreach is that it’s much easier to hire a skilled developer when you can show them that you already have product/market fit. So MVTs actually help in the recruitment process. You can give potential employees a long term vision they can buy into, all backed by solid evidence.
Flexibility
OK, I’ve said a lot about speed and resources, so let’s keep this one short.
MVTs are more flexible because they are simple and light. MVPs, on the other hand, can often get away from you really quickly (trust me, I’ve been involved in those types of projects). Someone has a great idea for a product feature to add, another starts thinking about user experience and adds an additional touch. Before you know it, your MVP is a huge project. Then you finally launch it and discover it’s not the right fit for the market – and changing it is super complicated.
Even if your MVP does prove your business is viable, there’s still a problem. Your MVP will probably become the foundation for the whole product, but it was only developed to be a simple early version of it. It would be better to start again from scratch now you know the concept works, but this means throwing out the work you’ve already done.
With MVTs, in contrast, you have massive flexibility. Changing the tests is sometimes as simple as adapting the copy on a landing page, or targeting a slightly different audience. And, once you’ve proved your hypothesis, you can start from a blank page when it comes to actually building your product.
Focus
The final point here is focus. As I’ve already mentioned, MVPs can easily get very complicated, very quickly. And this actually limits their value as a way to test your business idea.
Say you launch your MVP and it doesn’t take off. How do you diagnose what’s gone wrong? Perhaps the concept is fine, but the app itself has problems. Or maybe the app is fine, but the business idea itself doesn’t work. It can be hard to understand.
With an MVT, you’re only testing a single hypothesis. When clients say yes to it, you know the business idea is sound.
MVPs vs MVTs – the takeaways
Don’t get me wrong – I’m not saying MVPs are not valuable. We build them all the time. But what I am saying is many early stage startups build their MVPs too soon. Our rule here at Fullreach is that we only start working on an MVP once we know the business concept behind it is sound.
And to prove that, we use MVTs. As I’ve argued in this article, MVTs are fast, flexible and resource-light. They can also help you to be laser-focused on what your customers actually need, plus they’re a good tool for recruiting developers too. If you can prove to potential employees that your business idea is rock solid, they’ll feel more confident about getting onboard.
Have you worked on an MVP that has snowballed? And are there any other effective ways to test your business concept without using up all your resources? I’d love to hear in the comments what your experience of using MVTs or MVPs has been. And I’ll be sharing another article soon with a step-by-step process for running an MVT.
