Since the success of the lean startup, most people in the start-up world and beyond are familiar with the concept of a minimum viable product (MVP).

However, it seems, in a lot of cases, teams miss the point of an MVP. There is a whole lot of subjectivity in the viable part. Viable for what? For who? Who gets to define this? More importantly it is far too easy to try to cram one more feature in, leading to a half-baked product that doesn’t fully know what it’s purpose is.

Working with a number of startups over the past few years, I’ve seen this happen time and time again.

It’s an easy trap to fall into, I’ve been guilty of this too. You have your big ideas of how you’re going to make your users life much better. You get excited, carried away and don’t want to miss a single opportunity to achieve the success you and your team deserve.

Here’s how it usually goes

We visualise this bright future where our product is perfect and everybody loves it and work backwards from there. Identifying every last product feature that our customers are going to need.

We know that we need to ship quickly, so we take all these features and implement the minimum viable version of this.

Stop there, this isn’t going to work out.

It’s easy to try to do everything, but you’re going to burn out trying and probably end up with a bloated product that doesn’t know what it is.

But my product needs to have all these features

Every feature represents an opportunity for your customers to love your product right?

No. No, it doesn’t.

This is usually a symptom of having a product that lacks focus.

We’ll just work extra hard to get it all done

It is very likely that this will hurt you in the long run. There is a limit to productivity that you can’t get around by sleeping under your desk.

Design and development teams only have so much capacity, you have to spend it wisely. Otherwise, you will end up with a half-baked product that people tell you sounds interesting. But nobody wants to use.

The more you build now, the more you have to maintain in the future. Each feature will expand and multiply, new feature sets will be needed.

If you try to do everything it is much harder to know what to measure. Or where to direct your focus.

How should I do it then?

A better approach is to take a step back. Identify the core problem you are trying to solve, be certain it is a real problem. It takes huge courage to take this position, to say no to influential stakeholders — but it will pay off in the long run.

What challenge does your product help customers overcome?

What is the one thing you can do to make your users life better? Find that thing, and go all in.

Slice feature set vertically rather than horizontally. Figure out the smallest way you can solve the struggle.

Speak to customers or potential ones. Listen deeply. If you notice someone getting animated around a problem — you are on to something. This is something that they care enough about to want to change.

Cut your scope, cut your feature set. Be brutal.

Put all your efforts into that one thing, make sure you solve that problem in the leanest, most compelling way you can. This might not be a single thing, it can be multiple features — but you should be solving one pain, one struggle.

Build lean, ship often

“No business plan survives its first contact with customers.” — Steve_Blank.

Get your product in front of potential customers as soon as possible. Before you are fully comfortable sharing it.

In most cases, an MVP should take max 3 months, ideally less. The sooner you get a version out in front of people, the sooner you can validate your assumptions.

Build in flexibility, delete code often.

Don’t solve commoditised problems. Open source projects and third-party services exist to solve so many of the problems that modern businesses face. Make sure you find out if a solution exists to your problem before you start re-implementing something. Save your time to focus on the core value.

Measure it

Now you have identified the big problem you are solving, it’s going to be so much easier to measure. You have a North Star to follow, something you can judge success against. With this narrow focus, you can start experimenting and improving.

Keep shipping, keep measuring

Working this way you will identify early when you are on to something, and when you need to pivot. You can avoid chasing sunk costs in features that no-one wanted.

Repeat to fade

Just because you have nailed this main issue, doesn’t mean you should stop there. You will unlock greater potential after nailing the first problem. Once Uber had an infrastructure network in place from its main ride-hailing app, it was able to move into food delivery. This has become one of the most profitable parts of the business.

Experiment. Test hypotheses. Go again.