7 Reasons Why Your MVP may Never Launch

Since we launched in 2015, my co-founding team and I have had the opportunity to help build over 50 MVPs.

From first-time founders with early-stage startups to seasoned entrepreneurs with multiple projects under their belts, all in a variety of regions across the globe.

Despite the differences in size, location and resources, we’ve noticed that a lot of them made similar mistakes along the way.

And while many of the hurdles you will encounter when building an MVP will be specific to you, some are common and easy to avoid.

So I sat down with my co-founding team, to combine our 25+ years of experience in building tech startups to identify those common hurdles.

The result is a list of 7 mistakes you should avoid before you take your first step to introduce a new product to the market.

1. Focusing on the “Minimum” More Than the “Viable”

The purpose of an MVP is not to launch a product before it’s ready. However, many startups will launch a seemingly half-built product into the market, labelling it an MVP.

This is a catastrophic mistake that results in a garbage product with an awful user experience.

Remember the purpose of building an MVP is to test if your product is viable using as few features as possible.

Any product you launch into the world still needs to be technically excellent, with a user experience that will keep people coming back for more.

In other words, what’s the simplest way to collect the maximum amount of validated learnings from users while still delivering a high-value experience?

Don’t fall into the trap of building a dozen half-assed features, when what you really need is two kick-ass features.

2. Feature Creep a.k.a “Kitchen Sink Syndrome”

Feature creep is another dangerous trap many entrepreneurs fall into when building an MVP.

This is where the number of features you plan to build spirals out of control. In other words, you throw everything into it, including the kitchen sink!

Feature creep can occur for a variety of reasons. Maybe your competitor has a certain feature, so you feel like you must build it.

Or perhaps you just “have to” build that cool feature – even though it isn’t necessary to prove your value at the MVP stage.

Feature creep is dangerous. It not only increases your costs but also your time to market.

A good example of this comes from Instagram’s first iteration, Burbn.

Whiskey enthusiast and founder Kevin Systrom designed the app for fellow whiskey lovers to share their experiences.

The app was rich with features, such as the ability to check in and rank whiskey spots.

However, many users found the app confusing and adoption was low.

Even Systrom himself commented that the app felt “cluttered and overrun with features.”

There was one feature, however, that every user adored. The ability to share photos easily with friends.

So Systrom made a tough decision:

“We went out on a limb, and basically cut everything in the Burbn app except for its photo, comment, and like capabilities. What remained was Instagram.”

Systrom listened to the market and built an app with the features needed to show off his value proposition.

So, focus on the value, the problem your users have and build an MVP with the fewest features possible to show them that your solution is the best on the market for them.

3. Sacrificing Security & Privacy for a Shorter Time to Market

This point is often the result of focusing on the “minimum” and not the “viable” but is important to mention in and of itself.

Yes, speed is important when it comes to building an MVP (as I will cover in just a moment).

However, you can’t skimp on things like privacy and security in your race to the market.

Aside from the obvious moral and ethical issues, it could kill your product, and possibly your startup.

Never put your customers at risk – no matter how small that risk may seem.

Ensure your MVP is secure and you’ve taken every precaution to protect your users’ privacy before you launch it.

4. Moving Too Slowly

As I mentioned in point #3, speed and a short time to market are vital when building an MVP.

The longer it takes you to get to market, the higher the chance that your competitors will beat you to the punch.

But speed doesn’t just matter when launching your MVP – but when iterating as well.

It’s important to take advantage of your agility and ability to pivot quickly as an early-stage startup.

It’s something serial entrepreneur Yaron Samid faced first hand when building his fintech startup, BillGuard.

I recently had the opportunity to sit down with him to discuss his startup journey. In the conversation, he shared how the ability to pivot was central to his success.

His platform was initially designed to be a “set & forget” app that notified fraudulent transactions on your credit card statement.

However, with an MVP out in the world, Yaron and his team quickly saw that adoption was low and the CPA was too high.

So they pivoted to a B2B model, attempting to sell their anti-fraud technology to the banks.

However, as a young startup, they didn’t have the runway for the long sales cycle that comes with selling to large banks.

So they had to pivot again:

“After two years of investing in a B2B marketing and sales team, with pilots in major banks, we made one of the hardest decisions we had to make.

To pivot back to a consumer app.

This meant letting go of some amazing talent we had brought in to sell to banks.

They just weren’t the right fit for a consumer business model. It was heartbreaking.

This time, instead of a security company, we built a personal finance company.

We completely redesigned the product. It was no longer a “set & forget” website. It was now a mobile app that would help you identify ways to save money and protect you from fraud.

That worked very very well.

It grew very quickly.”

Yaron took his MVP to the market quickly with a single value proposition in mind, then capitalised on his ability to be agile and pivot to solve the problem his users faced.

So, launch your MVP as quickly as possible (while avoiding point #1), learn from the feedback of your users and implement the changes that will improve their experience.

5. Building for Everyone

Your product should be designed to solve the problem of a specific user. In other words, your goal isn’t to please everyone.

If your value proposition is trying to solve all the problems for the whole world, you risk it being irrelevant for each person.

This will ultimately result in a bad user experience and a product with little to no adoption.

Instead, your value proposition should be tailored to a smaller group of users who face a specific problem.

This is the best way to gather targeted, high-quality feedback that will accurately inform your product roadmap moving forward (your marketing person will thank you too.)

A prime example of this is Facebook.

Today Facebook is the most active social media platform in the world, boasting around 2.9 billion monthly active users.

But when it launched in 2004 its initial audience was exclusively Harvard students.

Only when Facebook had gathered enough feedback from that initial group of users did they decide to grow their audience. And even then it was only to Yale and Stanford.

It wasn’t until 2006 that Facebook opened its membership to non-students.

And they’re not the only famous startup to launch small. Take Slack as another example.

The first iteration of Slack was built to solve a very specific problem – the need for a centralised SaaS hub for team communication and file sharing –built for internal use only. It was only after it gained traction among the team that they expanded their audience to other companies.

So, build your MVP with a specific group of users in mind and launch solely for them.

Gather their feedback, iterate your product and grow your audience gradually.

6. Not Working With the Right Team

People are, arguably, the most important aspect of your startup. And having the wrong people building your MVP can be a fatal mistake for your startup.

By this I mean, advisors, mentors and, if you’re not a technical founder, technical stakeholders.

My co-founder, Daniel, has written an extensive guide on finding the right person to help you build your MVP, but essentially you have three viable options:

1. Find a CTO or technical co-founder

2. Bring on a team of freelance developers

3. Work with a software development company.

Finding a CTO/technical co-founder is by far the most idyllic choice. Having that senior technical talent by your side will pay dividends in the long run.

However, the issue here is that finding the right CTO/technical co-founder is extremely difficult – especially in an ecosystem where there is a huge shortage of developers.

You not only have to find a CTO with the right combination of hard and soft skills for the job, but you also have to convince them to take a bet on your very young startup.

It’s the reason so many entrepreneurs are turning to the other two options on the list, freelance developers or a software development company.

They all allow you to build your MVP while retaining a short time to market without committing to the huge cost of a full-time CTO.

More than this, finding a CTO is often much easier when you have an MVP in the market and have started gaining traction.

It’s something Nelly Yusupova, a CTO and startup advisor with nearly 20 years of experience in the tech industry, touched on in a recent conversation we had.

She told me that:

“Launching your early MVP and gaining traction will really help you attract a technical co-founder because you’ve taken the risk out of that opportunity for them.”

Let’s say you hire an agency and they start to build your MVP with a three to five-month timeline.

Parallel to that, you’re going to start looking for that technical co-founder or CTO.

You’re going to start joining tech communities and building your network. Start to talk to people.

And, hopefully, by the time you start having those conversations your MVP is going to have enough traction that it will be a no-brainer for the tech co-founder or CTO to at least consider you.”

Finding a technical co-founder is something that myself and my founding team faced before we came together to launch Altar.

In fact, it was one of the reasons we built Altar, to begin with.

We all struggled to onboard technical co-founders in our previous startups. So, we created Altar to fill the gap in the market and help entrepreneurs build high-quality MVPs within a short time to market.

All of this to say, whichever option you choose to help you build your startup, they must be able to produce high-quality code and architecture that follows the industry best practices.

At Altar, we’ve worked with entrepreneurs who built their MVP with the wrong team before coming to us.

In the worst cases we’ve seen, the code was so poor that we’ve had no choice but to scrap the codebase and start from scratch. Something not every startup can afford to do.

7. Ignoring User Feedback

This may seem obvious, but when your users start giving you feedback, listen to it.

This often happens when founders are too focused on the solution they want to build, as opposed to the problem they want to solve.

Not listening to user feedback will result in you developing a product that nobody wants. This will lead to low adoption rates, barely any traction and it won’t be long before your startup reaches the end of the road.

Always remember the why behind building an MVP – to test if the solution you have in mind will actually solve the problem for your target users.

The only way to know the results of that test is to listen to the people who are using your MVP.

Wrapping Up

These are just a handful of the common mistakes people make when building an MVP.

The truth is, there are many hurdles to building an MVP, many of which are case-specific.

So, my advice to avoid mistakes is to:

• Define and narrow down your value proposition – What is the problem you intend to solve? And how? Why is this a 10x better way to solve than anything else out there?

• Build small, but at a high standard – Choose the minimum features possible – while maintaining a meaningful product but also make sure they’re built to a high quality with security and privacy at the core.

• Only build features that test your value proposition – anything else can wait until you know that people want your product.

• Don’t take so long to build that you miss your shot – Neither your competitors nor the market will wait for you.

• Surround yourself with the best talent you can find – Whether they’re in-house or a third party, make sure you’re working with professionals who know their onions.

• Listen to User Feedback – Remember, your goal is to solve their problem better than anyone else on the market – without them your product can’t succeed.

Thanks for reading.

Also published here