The MVP, or minimum viable product, is a critical milestone for any ambitious fintech startup. But if you ask 10 founders to define what an MVP is and what it should include, we just about guarantee you’ll get 10, wildly different answers — some more accurate
than others.
At Advapay, we often find that these misconceptions are a key reason MVPs underwhelm (or never make it to launch at all). So, in this article, we’ll share what we’ve learned about building successful fintech MVPs through hard-won experience:
- What an MVP is (and isn’t)
- The pitfalls to avoid when you’re building one
- How to scale
What is a minimum viable product?
Gartner defines ‘MVP’ as a product or feature that has the minimum capabilities required to effectively address the target customer’s pain points. To put it in plainer
language, it’s the simplest possible version of a product that’s still useful to those you want to offer it to.
While this definition is technically accurate, it’s also unhelpfully vague. There are two issues in particular which founders risk misconstruing or overlooking completely.
The first is that ‘simplest’ doesn’t mean prototype — a basic version of the product, that may or may not work. The value must be clear to the user straight away.
Of course, nobody expects an MVP to work without a hitch. If anything, wanting everything to be ‘perfect’ is another pitfall which can derail your launch.
That said, the whole point of an MVP is that it enables you to collect feedback from real users, which you can then use to refine your product and go-to-market strategy. For that feedback to be helpful, the MVP must work reliably and show a clear competitive
advantage.
So, if you’re a payments startup, for instance, your MVP should nail the core payment flow and demonstrate why it’s a better solution than your competitors (or, at least, why it has the potential to be the better solution).
The second, equally important issue is that you should keep your MVP’s focus narrow.
This is for both practical and logistical reasons. It’s much easier to develop a product and hone its USP when you focus on a very specific audience. If you try to be everything to everyone, the likelihood is that you’ll end up being nothing to nobody.
Are you making these critical MVP mistakes?
Mistaking your MVP for a prototype — and, at the other extreme, perfectionism — and trying to be everything to everyone are the most common mistakes we see at the design and development stages.
But there are pitfalls that can make it challenging to take things to the next level at the feedback stage, too. And, equally, you can make mistakes post-launch which will hamper your ability to scale.
The friendly feedback bubble
Did you rely too much on your personal network when you launched your MVP?
While there’s value in getting encouraging feedback at the early stages of what is often a long and challenging journey, the problem with this approach is that friends and colleagues are inherently biased.
The danger here is that they might sugarcoat their feedback or avoid addressing certain issues altogether. This skews expectations. You move forward thinking your product is in good shape, only for it to fall flat once you make it more widely available.
Aside from getting a more objective picture of what you’ve done well and where you need to improve, marketing your MVP to a wider audience is also useful for other reasons.
First, it helps more accurately gauge customer acquisition costs — essential for working out if your business model will be viable at scale.
Second, it’s an opportunity to refine your messaging and onboarding.
The latter two are especially important, because the market at large will be much less forgiving of a subpar experience than those with whom you have personal relationships.
According to the Payments Innovation Forum, 26% of customers won’t complete onboarding, going up to 50% or more when the process has too much friction.
Third, your personal network might not be representative of your target market.
With very few exceptions — for example, fintechs that serve niche verticals or very large enterprises — you can’t reach profitability unless you scale. Going as wide as possible with your MVP ensures you address the right pain points for a large enough audience.
Taking an intentional approach to iteration
A common mistake we see clients make once they’ve launched their MVP is trying to address every single bit of feedback they receive. This is not just impractical, but impossible.
Yes, if you’ve targeted your MVP with sufficient accuracy, the vast majority of your customers will share similar pain points.
The flipside is that feedback is, by definition, subjective. It will be coloured by individual users’ priorities, ways of working, and use cases, by each organisation’s idiocyncracies, and by many other complex, interdependent factors.
This is where having a clear USP — and a clear idea of your roadmap, at least in the short-to-medium term — comes into its own.
Would addressing the feedback enhance your USP and bring you closer to achieving your product and strategic goals?
If so, you should take it on board.
But if the feedback is incidental, irrelevant, or directly contradicts those goals, you can safely ignore it.
More to the point, debugging should take precedence over new features. Adding new capabilities to your product when basic functionality is broken is like building a castle on dry sand. Eventually, the shaky foundation will collapse, and so will your product.
From idea to MVP: A planning and development checklist
We’ve talked at length about what not to do when building an MVP. But what does a ‘good’ workflow look like?
At Advapay, we recommend a phased approach, followed by a value judgement about where to go next. This workflow will vary depending on the specific firm, product, and goals, but it should broadly follow this logic:
- Research and idea validation
- Planning
- Development
- Launch and iteration
Phase 1: Research and validation
Mark Zuckerberg famously said that tech firms should
move fast and break things.
The fintech industry is packed with cautionary tales of firms that did this with catastrophic results —
Okra,
Solid, and
Synapse, just to name three recent examples. But moving too slow is also problematic, because it risks you losing out to more nimble competitors.
So how do you strike the right balance? Or, to twist a phrase, move fast without breaking things?
Our view is that moving fast doesn’t mean putting the MVP together as quickly as possible, but
testing as many hypotheses as possible, as quickly as possible.
This may sound like semantics, but it’s an important distinction. One that turns business and product development planning on its head.
Instead of throwing stuff at the wall and hoping some of it sticks, this approach allows you to discard those ideas that aren’t well-received during market research, and use your resources to hone and improve the ideas you do validate.
For best results, use as big a sample as possible. At Advapay, we recommend interviewing at least 100 potential users to make sure your findings are statistically significant.
You should also take possible future developments into account. Planning, development, iteration, and, crucially, growth, will be much easier to achieve if your architecture allows for it from the get go.
Phase 2: Planning
The biggest benefit of fast, comprehensive testing is that it gives you space to be deliberate about your choice of partners and infrastructure.
Having already tested your assumptions reduces the risk of costly pivots. In turn, this means you can base decision-making not solely on how much flexibility a partner or vendor can give you (though this is still important). But based on how well they can
meet your needs.
For partners, the most important criterion is whether they’ll accept your client type and risk profile, followed by their capabilities, the quality of their APIs and other technical integration capabilities, and, lastly, price.
Needless to say, you’ll want to choose one or two partners that will do all of the above at a reasonable cost.
A good way to go is to try and negotiate tiered pricing. This might work out more expensive initially, but goes down as your product proves itself. You’ll also want to secure preliminary approvals before making significant infrastructural investments.
For core software vendors, capability is the most important criterion. How easy do they make it to develop the features and functionality you’ve validated in phase 1? Will they allow for efficient future scaling and customisation? And what’s the all-in cost?
Phase 3: Development
Alongside helping with partner and vendor selection, proper research and validation also takes away the guesswork from your product roadmap.
Your interviewees will flag what is most likely to make your product stand out from the competition. The features that come up most often are the biggest opportunities for you to differentiate your offering and gain a competitive edge.
We typically recommend developing the lowest effort, highest impact features first. This will allow you to build and ship a stable, reliable MVP more quickly.
Phase 4: Launch and iteration
This is where you collect feedback, track KPIs, and test and refine your messaging and onboarding processes based on real user behaviour.
The most valuable KPIs at MVP stage — or at any stage, for that matter — are revenue-focussed, key amongst them gross margin, followed by CAC, customer lifetime value, churn rate, and daily and monthly active users.
These are metrics that connect directly to your bottom line. As validating as metrics like app downloads, registered users, and social media activity can be, they’re rarely an accurate indication of how well you’re doing. Case in point,
50% of users who download a fintech app never complete registration.
We’ve said this already, but it bears repeating. Fixing critical bugs should be your number one priority at this stage. It’s only once the product is as stable as you can reasonably make it that you should start looking at developing new features.
User feedback on the MVP gives you valuable data over and above your initial research that helps in form what you prioritise next. Again, we recommend starting with the highest impact, lowest effort features first and working your way up.
You’ve launched your MVP. Now what?
Most fintech founders will tell you their ultimate goal is growth at scale.
But launching your MVP isn’t the finish line of this particular race. It’s not even the starting line, for that matter, but the area behind the track where you warm up and test for issues that might force you to retire.
A good rule of thumb is to collect three to six months of data before you start thinking about what’s next. Does the response to your MVP confirm your initial hypothesis? Are you hitting your KPIs? And what does the data tell you about user behaviour?
Most importantly, are there any technical or resource constraints that might not make it feasible to achieve the scale you want at this stage of the game?
As critical as speed is in an increasingly competitive landscape, you shouldn’t go off at a trot when you’re not yet ready to walk. Let the data guide you, so you can be sure you’re building on solid foundations.