Every loved up, soon to be wed couple starts out wanting a small wedding. It just makes sense right? “Let’s keep it small and spend the money on our honeymoon or a downpayment for a house”. But as I’m sure you know, this well meaning intention soon starts to go pear shaped.
There is an ever growing guest list, when inviting Uncle Charlie means you also have to invite his latest “new friend”, Mel. If you invite Kyle, you’re going to have to invite Todd, you all play golf together right? Next thing you know the humble daisy has been replaced by tulips flown in from the Netherlands, Cake pops have evolved into a 5 tier masterpiece, and of course, we simply couldn’t have a wedding without a gin bar right?
Your wedding budget is now blown, and that down payment or dream honeymoon is a thing of the past. Keeping things simple on your wedding day is extremely difficult, and it’s all those ‘lets just add this one thing” decisions that quickly (and expensively) add up.
The same is true for your MVP (Minimum Viable Product).
Unfortunately, this is one thing I have experienced time and time again, and has been one of my biggest learnings over the years. At the beginning of a project, both the client and dev team agreed that we would stick to the “minimum” and “viable” rules.
Yes, it’s agreed, we are only doing an MVP. The bare minimum product, built as slim as possible, to get it out there as soon as possible, to be tried, tested and prodded by real clients in the actual market. But time and time again, our good intentions for a slimmed down MVP get thrown out the window with each “lets just add this one thing… and before we know it, what we are still considering an ‘MVP’ is a giant beast equipped with flashy new features and ‘must haves.’
In this article I am calling on all future Fintech founders to end the cycle! Stay focused on your ultimate business goal and be disciplined. Here’s why:
What’s all the fuss about MVPs anyway?
An MVP is a minimum viable product, a basic version of your product which covers the core, fundamental features (ideally feature) that allows you to solve your user’s main problem (or at least what you believe your users main problem to be).
An MVP is the quickest way to get your testable product to market and see if it will actually succeed with real users. This shouldn’t deprive your product of its unique selling points, but should focus it more narrowly on the simplest viable version of itself.
The faster you release your product, the faster you’ll benefit from the feedback loop. The sooner you will be able to test the market and know if your product passes or fails the ultimate test.
Don’t be another failed startup statistic! Instead, shorten your feedback loop.
Many start up founders think they know what their users want, or how they will use the product. That’s why they’ve started the business in the first place. However, there is a very real chance that this assumption is just plain wrong. The last thing you want to do is build out a set of features which are never used – unwanted and unneeded features are an expensive endeavour. Rather start small and iterate from there, pivoting completely if it comes to that, but do so with real information from the market and not your own hunch. By building out an MVP, you limit the upfront investment and mitigate some of the risks involved in complex and expensive software development.
That’s the beauty of an MVP, it allows you to keep your costs limited while still getting a product out there to be vetted. As they say, the proof is in the pudding (or wedding cake if we’re going to stick to our analogy). So let’s do a taste test before committing to a 5 tiered cake, shall we? Let’s find our early adopters, allow them to use the platform, begin to love it, and then only iterate, pivot or continue based on their real needs, usage patterns and feedback, not on your preconceived ideas.
How to ensure you stick to it?
Define an MVP as quickly as possible:
At the beginning of the project clearly define your business goal and the problem you are trying to solve for your users. From there define exactly which minimum requirements are needed to achieve this. At Nona, we do this through our Consultation & Discovery process which we’ve developed during our 10 years of operation and successfully run for dozens of founders in your position.
Be clear about your MVP intentions, right from the initial design phases:
Design is cheap in comparison to development. Adding a button here or there or changing the way an onboarding flow works could take very minimal design effort, but could have huge implications during development – which could have huge implications for your budget.
Don’t fall into this trap of “just do it in design”, as many start ups do. My suggestion, design exclusively for MVP only. No bells and whistles. You can start adding additional features during iterations once you’ve received real user feedback.
Hold each other accountable:
As a Fintech founder, it is essential for you to constantly hold on to your business goal and the core problem you are trying to solve. Remind yourself of this goal throughout the process. The best question to ask is: “Do I really need this new feature to test my MVP?” If the answer is no or even maybe – bank it! It’s probably a great idea, but not for now. As product/project managers, it is your responsibility to hold your clients accountable and to push back when required, you’re the expert.
In conclusion, maintain a laser focus on what you want to accomplish, blue sky thinking is encouraged and necessary, but you need to be disciplined for an MVP. Don’t let yourself fall into the “just one little thing” trap, all these little things add time and distract you from your main goal. Once again, what we think our users will value, isn’t necessarily what they will value.
In other words, it might be time to say no to that gin bar at the wedding!
If you’re looking for help planning, designing and building your MVP – book a consultation with one of our Co-Founders and let’s see if there’s a fit!