Seven simple steps to keep your MVP on track
The Minimum Viable Product or MVP is a term that doesn’t get a huge amount of love in the development world these days. Which is a huge shame, because frankly I still passionately believe it is one of the most valuable concepts in tech development. It’s vital to building up a successful app (and app business).
The MVP has been replaced by:
MLPs (Minimum Loveable Products)… yuck.
MDPs (Minimum Desirable Product)… urgh.
MAPs (Minimum Awesome Product)… oh FFS!
MILTSMIWTMIP (Minimum I Love This So Much I Want to Marry It Product)… ;-)
And you want to know why so many new concepts around the MVP has emerged?
Because you’re not building an MVP correctly!
You have to be absolutely brutal when you’re planning out an MVP. It’s got to do one thing, and do it really, really, REALLY well. It’s got to be refined down to the essentials. It has to be bare bones, whilst still working well enough to offer users a smooth experience. And most importantly, it’s got to have a way to prove whether it holds value.
The biggest problem with developing a pure MVP is that it’ll piss off virtually all of your stakeholders. They are not going to get their own way. Looking round the room you’ll see a range of departments all looking miserable because you’re not going to build what they want you to build.
It’s not a nice place to be. Do it right and all those naysayers will suddenly brighten up. Do it badly and everyone will be massively grumpy.
A true MVP is little more than a proof of concept. And it is one that you should be willing, happy and keen to dispose of without another thought if it doesn’t deliver the results you’re looking for.
It takes heart and courage to build. And you have to be ready to blow it to smithereens equally rapidly.
So how do you make sure you’re building a real MVP? Here are seven quick hints…
1. Define the single function the app needs to carry out
One single function. Not two, three, four. Not one and a half.
No room for negotiation. It’s like the “You can have it in any colour as long as it is black” argument.
The best apps do one thing really well. Once their proof-of-concept has been proven they’ll grow and add features. The very best apps will add features, remove features, tweak features. But they’ve earned the right to do that because they’ve established their audience and proved their worth with their MVP.
Keep it simple. Keep it true to the key idea behind your app. Add the fancy stuff later.
2. Ban the “wouldn’t it be nice”
Once you’ve got your central defining feature be on your guard for the dreaded mission creep. The “could we just” or “wouldn’t it be nice” or “I’ve been thinking”…
This is sometimes much easier to achieve when you are an App Development Agency working with a partner because by this stage you’ll have a scope of work agreed, a contract in place and obvious financial implications in play. Once you can start invoicing for real world monetary value you’ll often be able to head off most of the development scope changes.
With an internal development team this will mean you’ll need to respond to all those ‘small’ little feature requests, decline them and keep on focusing on the core product.
Be strong. You’ve got this.
3. Know what success looks like… and how you’re going to measure it
This could very well make or break your MVP. You need to be able to quantify if your app is working or not. With your run-of-the-mill consumer-facing ecommerce apps this can be relatively straight forward and can be pared back to pounds and pence collected. But what if your app doesn’t have a monetization strategy? Are you looking at download numbers? Or engagement metrics? Stickiness? How long people spend in your app? Churn? Subscriptions? Shares?
You need to know what you need to measure. And stick to your guns. We’re always of the opinion that user metrics trump downloads every time. If a handful of customers LOVE your app and spend extended amounts of time engaging with and using it, the likelihood is that you are on to a winner. You can buy downloads later on with your marketing spend and advertising.
When you’re building an internal app, gauging success can be a bit more tricky. Say your app is designed to speed up the submission of paperwork from a remote sales force. Is success defined by how much time it saves the business… or the salesperson? Is it a success if only half of your sales team use it? Again, here it can be tough to choose. In this example it doesn’t really matter at the outset if not everyone is using it. You can train your sales team. It might not even be a failure if it doubles the amount of time it takes for an individual sales person to submit the paperwork if it improves the general company-wide workflow process by a larger amount of time.
The key is establishing the ground rules at the beginning. Sticking to them. And having the data to back you up when you declare your MVP a success or a smoking crater of a failure.
4. Have an agreed timetable and MVP lifecycle
This can be a double-edged sword. You need to give your MVP enough time to prove itself. At the same time, an MVP can’t stay an MVP forever. If it is working you’ll need to transition it from an MVP state into a product. Once that happens you’ll need to run ongoing development and you can start exploring tentative feature upgrades.
That’s the fun bit.
You’ll also need to agree at what point you need to put your MVP out to pasture. When maintaining it no longer makes sense.
When to say goodbye.
Or sometimes when you’ve got to throw the dice one final time…
5. Weigh-up the impact of limited feature additions
We usually urge against this. Hard. The whole purpose of an MVP is to prove a business case exists for your product. It delivers the heart and soul of what you’re trying to build. If it fails to find a market the addition of extra features, prettier UI, share features, Siri features, push notifications or gamification won’t shift the balance of opinion.
You can’t polish a turd.
But you can waste a bunch of time (and money) trying.
Sometimes a feature will help turn things round. Sometimes it’ll make a real difference. More often than not it won’t.
If you’re thinking of adding a feature to save your MVP, try to assess whether it will actually change your fortunes. Talk to your customers, your users, a random collection of smartphone wielding strangers… anything…
If they all happen to say that your app needs to play a jaunty tune while you try to enter your email address then that very well might be the solution to all your problems.
If they all suggest random changes, then it’s time to move on and find something new to build.
6. Leave them wanting more
Just like this post. Because it is little more than a content MVP.
That’s why there is no point 7.
This is an MVP. If it works we’ll add another point. Maybe.
Thom Gibbons is CEO of Apptaura.
