Table of contents
- 1. Overconfidence
- Lessons learned
- 2. Poor user experience
- Lessons learned
- 3. Wrong customer in mind
- Lessons learned
- 4. No clear vision of end product
- Lessons learned
- 5. Building a minimum non-viable product
- Lessons learned
- 6. Not making an MVP small enough
- Lessons learned
7. Thinking there’s no competition for your product- Lessons learned
- Nothing is ever what it seems to be
Building an MVP is hard. A lot of factors can get in the way: founder’s perfectionism, a team’s lack of experience in lean development, fear to underdeliver, overconfidence, unrealistic expectations.
What’s more, not everyone understands what an MVP is and how it should be treated.
We interviewed 9 tech startup founders and chose 7 most dangerous mistakes tech teams suffer from.
1. Overconfidence
Overconfidence looks a lot like superbia (the Christian sin of pride) and is probably one of the most dangerous sins startups face.
Disregard to potential technical challenges will lead to a late release which means burning recklessly fast through the runway without tangible results.
Mika Koskiola, CTO of Proximi.io, and his team experienced this pitfall early on. They are working on an SDK that allows developers to build in location-based features into their apps.
Creating such a complex software development kit was bound to be a hard challenge for the whole team. But even though Proximi.io developers had the skill and experience they still encountered a lot of unexpected bumps along the road.
The first big challenge was the team’s overconfidence. It took Proximi.io half a year to build an MVP. Almost twice as long as they initially thought!
The second one was scalability. Proximi.io started as an in-house solution, for use in internal projects only. The team finished the first proof-of-concept version in just a few weeks. But once the company started working on the commercial version they found out just how clumsy and unscalable it was.
Setting up new customers had to be done by hand and took forever. The demand quickly outgrew the modest capabilities of admins to onboard new people by hand. Something had to be done, and quick!
Dealing with these challenges combined meant they were desperately slow. It took Mika 6 months to polish the internal version of the platform. But the team had to pour in another 6 months into the product to build a commercial SDK ready for consumers.
If I’m being realistic I would say estimates for MVP development had to be doubled.
We even had to cut some features and not only because of the time pressure but also for the sake of focus. We needed to narrow our focus to manage the timeline.
Lessons learned
- give yourself twice as much time as you think you need to build an MVP;
- cut features, not corners, when leveraging MVP development services for startups.
2. Poor user experience
Luuva Oy is a Finnish team of stock market experts and developers who are looking to change the way people interact with the stock market and decide what to buy and what to sell.
Stonder app allows users to share their opinion whether the stock of a company will grow or decline.
But even though Luuva Oy built Stonder based on the knowledge of 3 stock market experts, it still suffered from lack of foresight into what users expect from the app and how they are going to interact with it.
The first MVP was buggy and suffered from poor user experience. For example, users could see the all-time rating of any company but weren't able to find out where public opinion is going right now. Realising their mistake Luuva Oy introduced a new parameter, The Sentiment, to counter that. Now it acts like a thermometer that shows which way general opinion is going – down or up.
The app now displays both all-time ratings and the current dynamics of public opinion and helps investors decide how to act on this permanently fickle market.
Lessons learned
- invest in usability and user experience and test how users interact with your product;
- couple good ideas with an excellent execution, don’t let bugs ruin your customers’ day.
3. Wrong customer in mind
When you make a mistake who your customers really are you can’t tailor your product to give them the best value.
This is what happened with Husky Marketing Planner, a Belgian startup.
Today Husky is a SaaS platform that helps marketers manage projects they are involved in.
But when they only started Husky was a very narrow tool that allowed non-marketers create their own marketing plans just by answering a few questions.
Husky’s team biggest challenge was the wrong user base. Because of how hard they had to pivot they needed to rebuild the whole backend from scratch.
We started on the wrong foot. We had a different customer in mind. In the beginning we thought we needed to create a tool which would help people to write their own marketing plans. Especially for people who didn’t have marketing experience.
But when we created our first product we noticed that our users were more interested in secondary elements of the solution instead of the main module (marketing plan builder) – they actively used tasks, campaign planning, budgets, and other modules and the core functionality was pretty much ignored.
Switching to a new pricing model was bad news. Because of the way Husky was built the team had to completely rewrite the platform. Instead of keeping plans targeted at individuals they had to switch to pricing based on the number of users per organization.
The new paradigm required an overhaul of system architecture.
Lessons learned
- Do extensive research to fully understand your customers and their exact needs.
- Leverage startup consulting services for additional market and audience research.
4. No clear vision of end product
Marina Ahoy is a software solution that allows port owners and harbormasters automate booking and easily monitor what ships are at sea and what are docked.
Initially Marina Ahoy was just a journaling app that helped harbormasters see what ships are at sea and what are at the marina but the startup quickly realized that it was not exactly what people will pay for.
Our idea was interesting but vague. As we collected more data it turned out that different countries had different approaches to the problem we tried to solve. We also realized the problem itself was too small for an MVP.
We had to evolve to a point where most ports would want to use us. It took a lot of leg work. Some ports are so overbooked they are ready to pay just to know who's at sea and who's parked. Others need a report creating tool. Others still want to sell port services remotely to people at sea. We had to evolve to cover all this functionality and provide value to the majority of our leads.
Hectic development haunted the startup for the major part of their existence. In an effort to onboard new ports they constantly tweak and add features growing the existing functionality further and further.
For harbormasters Marina Ahoy now offers paperless journaling, automated booking, and various quality of life features. For yacht owners they developed Android and iOS Apps that customers can use to book services or purchase docking rights.
Lessons learned
- Examine the market and its pains to build exactly what your customers need.
5. Building a minimum non-viable product
There are a lot of ways to screw up an MVP. One of them is misunderstanding of what your customers want.
This happened to Chris and his team. Scrap Connection, the scrap marketplace they built, tried to solve the fundamental problem of establishing trust between the seller and the buyer. And they failed.
It turns out our first MVP wasn’t a minimum viable product at all. It wasn’t viable.
We created an auction-based marketplace where sellers could list their offers and buyers could publicly bid on what they want. The auction was time-restricted and the best bid won.
This scheme didn’t work for us. And there are several reasons to that. There were too much transparency, buyers don’t like bidding, the auction was too public and that intimidated both types of participants.
On the one hand, buyers are always looking for new suppliers in order to avoid tying themselves up to a single source of raw materials. And sellers need to diversify their trading network, too. They can’t rely on a few steady customers since if anything funny happens like an abrupt lack of funds or dwindling demand they’ll be left out in the cold.
Only a few years later and after 2 major iterations Scrap Connection managed to come closer to building a better marketplace for scrap sellers and recyclers.
Lessons learned
- Instead of building solely on your vision concentrate on the underlying problem and user feedback.
6. Not making an MVP small enough
Some solutions are just born big.
This was the case with Skillific, a smart HR platform that uses big data algorithms to find suitable candidates for IT companies.
Their problem was in the whole essence of MVP. To become truly viable as in "minimum viable product" Skillific had to build their solution far bigger than any startup following lean ideas would be comfortable with.
They just had to.
Potential customers expected immediate value from the prototype when all Skillific could offer was a concept. This lack of immediate real results got potential leads confused and frustrated. They saw new and interested candidates in the system and wanted to contact them right away.
I thought that I could go to the customers and show what it does and they would really like it. With this validation we then would go to investors, ask for money, and improve our product further.
But the actual situation was more complex than that. We couldn’t show our leads a prototype because it never had enough functionality to become valuable to the customers.
The biggest challenge of Skillific was the small data set they had to use for their MVP.
This data wasn't actionable!
And absence of data then led to absence of real value to the customer. This meant that limited access to real data diminished the value of the product early on.
In this situation Skillific had to continue development for two long years before it was rich enough in data and features to raise customer interest again.
Lessons learned
- People need actionable data from the start. They need to see how your product can benefit them right now. To make money you need a product that actually works and gives value based on immediate customer needs.
7. Thinking there’s no competition for your product
Skillific is an awesome team, but we just had to add another deadly sin from them!
We thought there was no competition. Turned out we weren’t unique, we just did the same thing but with a twist.
Don’t fool yourself thinking there’s no-one out there doing what you are doing right now. Even if you can’t find anyone it doesn’t mean there are no companies that want to build the same thing you are building.
Lessons learned
- Be honest with yourself about the uniqueness of your product.
- Look closer. There may be companies that want to expand into your niche or have already done that and failed. Learn from their experience.
- Ask yourself why there’s no competition if it’s really the case. Is it a good thing? Does this market have any potential for growth?
- Run the numbers. And then run them again. Is there some hidden cost you don’t take into consideration? Or a huge challenge noone can overcome?
Nothing is ever what it seems to be
So here's the summary:
- The majority of startups make a pivot somewhere during the MVP phase and as a result end up building at least two MVPs.
- Most startup founders dramatically underestimate the time it takes to build a working MVP. A lot of founders we talked to thought their MVP would take twice as fast to build as it actually took. And half of them had to rebuild an MVP from scratch because it wasn’t really viable.
- Even when the startup team has a lot of experts with deep industry knowledge they are not guaranteed to find a perfect product/market fit and are likely to still pivot somewhere along the way.
- Another big trend we’ve noticed is that most startup founders underestimate the complexity of technical and business challenges and focus on the big picture instead, not taking seriously all the multiple nuances and details during app development for startups that may stall the project.
- Teams build their products on what they have experience with, not necessarily on the technology stack that scales or works best for their product.
