The principle of building a software product is simple: take the most important features, build, release, succeed. However, choosing these features becomes a stumbling block for many aspiring startupers. Read on to find out how to avoid their mistakes and how to use the correct approach for building your MVP, both in theory and in practice (examples ahead!)..
The top five reasons for startup failure are:
We didn’t just make up these reasons. They were defined after research conducted by CB Insights. After studying 101 failed startups - and, according to their numbers, 70% of startups do fail - they concluded that these were the most common reasons for failure.
As seen from the above chart, it is essential to be sure of the following:
- The market needs the product and there are potential customers for it - this includes choosing the right functionality, marketing strategy etc.
- You have enough money to release the starting set of features and cover unexpected expenses that might - and will - show up during the product’s coming to the market
- You have found the right executor for your ideas - a software team that treats your success as its own
In this article, we will offer advice on:
- Market research
- Choosing the right features and the right way of implementing them
- How the Pareto Principle (aka 80/20 rule) applies to software development and why “buy a feature” product technique is seldom selected by the forward-thinking start-uppers
1. Do Your Homework - Conduct Research!
It is fairly easy to compare your future software product with a donut. Everybody seems to like those sweet snacks you seem to have enough money and opportunity to bake and sell them in your neighborhood.
To begin with, you bake them without all the fancy toppings, chocolate fillings and other fancy extras that you’ve seen in the best cafeterias of your town.
If there are enough hungry people in your neighborhood, you will get a regular flow of customers.
But what if donuts are not just a trend? Do you have friends that adore donuts? Really? Are those friends some sloppy cops from 80’s movies?
What will your future product bring to the table? Will it be in demand?
Let us step away from this bakery madness and call the things what they are.
Your product has to fit the market needs. It has to solve at least one of the end customer’s problems. Your customer must be willing to pay for your product.
Try to get actionable feedback from the users ASAP
To do this quickly, you need to put a real prototype - paper or digital - in the hands of users to learn what the next steps should be.
Do your homework - conduct research.
It is common for startup owners to overlook this research into customer needs, market, demographics and so on.
Some product owners don’t even ask themselves two fundamental questions:
- 1. Why is this product special?
- 2. How will it solve the customer’s problem?
A good way to start is by conducting an early competitor analysis of a similar product on the market. More or less similar competitors will be out there even if the product is unique.
If all the features are already on the market - what is the point of making a clone?
If there is no competitor research, it is like entering a battlefield with your eyes blindfolded.
Remember Google Glass, the futuristic gadget that was supposed to bring us one step closer to the high-tech utopia? And if you do, when was the last time you saw a person wearing one in public? We thought so.
Only after investing , Google found out that their product solved exactly 0 problems of their target audience. Aside from the occasional use in a few medical practices, the Glass never gained the intended popularity. Even worse, the dissatisfied “explorers” (the first few people who bought the first version of the product) eagerly shared their experience with thousands of their social media followers.
The product has failed, although Google gained quite a bit of technological know-how as a consolation prize.
A summary of what you need to do before entering the market with your MVP:
- Make sure your product serves a segment of its audience
- Address at least one problem of that audience
- Get the money for an easy and quick build
- Conduct competitor research to make sure your product is as unique as you think it is
2. The Pareto Principle and Techniques of Choosing MVP Features
You have to enter the market with a minimal set of functions that users are going to utilize.
Initially, in MVP period you have to build 80% of all the basic functions for 20% of your budget. If this rule sounds familiar, perhaps you are acquainted with the Pareto Principle. It has plenty of applications in lots of industries, including IT.
Read this article on how we use this law and dodge Murphy’s law at our software company.
Now, let’s look at how we can approach the MVP application in the same way.
It all comes down to selecting the most beneficial functions that take the least amount of effort to build and implement.
As for selecting the right MVP features, there are many ways to assess which functions are needed, which are nice-to-have, and which are an absolute no-no for the first release.
One of the most common assessment approaches, as ProductPlan states, is the Value vs. Complexity Quadrant.
It is fairly simple and many product (and project) managers go through this assessment instinctively.
It is also easy to understand - MVP needs high business value produced by low effort. High value for high level of effort is for the future. It goes without saying that low business value for high effort is a no-no. The estimation of effort and value is up to product owner and business analysts.
80 percent of functions for 20 of effort, if you will.
A (Totally Real) Example
Suppose, Monica has a small, but thriving chain of pizzerias. She decides to build an app that would allow users to order food from her restaurants, and will start with an MVP.
The features that came to her mind were as follows:
- Personal cabinet, where a user can place orders quickly without having to reenter the information.
- Menu with descriptions of various pizzas, sauces, drinks etc.
- Delivery tracking, that would let people see the current location of their order on the map.
- Chat with customer service, to help address any concerns regarding the order.
- In-app payments
- Social network for pizza lovers.
- Integration with the ERP systemc that Monica’s company uses to process orders.
She gets together with the development team she has hired for the project and go over the project idea picking the features based on the Value vs Complexity Quadrant.
Personal cabinet as Monica envisions it is quite simple. However, it doesn’t provide much business value either. Bottom left.
Menu is of paramount importance and is relatively simple. Upper left.
Delivery tracking is hard to make good and it is not something that her typical customers want that much. Bottom right.
Chat with customer service is pretty straightforward to develop and can be helpful. Bottom left.
In-app payments can be implemented by integrating existing third-party solutions like Stripe or Braintree. They are also important for the good overall user experience, so they go to the upper left section.
Social network would be time-consuming to build and the business value it presents is unclear at best. Bottom right.
Integrating the ERP would be complicated, but it is important to quickly process and deliver the orders. Upper right.
It seems like there would be three “must have” features for Monica’s MVP: Menu, In-app payments and ERP integration.
If you are not a fan of all these charts, weighted scoring is your model. You just figure out a scoring method for the value of features, give every function a numerical value and count the total score.
The higher the score of the function, the more you need it. Those with the highest scores should be included in the MVP selection.
Now let’s imagine that Monica and her team have decided to apply the weighted scoring method for the same features.
|Chat with customer service||3|
|Integration with the ERP system||5|
Her budget allows her to implement the three points that give the most business value: Menu, In-app payments, and Integration with the ERP.
3. A Good Software Company is Interested in Your Success
So here are the graphs we promised you. Don’t worry, there is an explanation to them!
W2 (Wi on the initial graph) is the amount of money the product owner has for a software team at the beginning of the development
W1 (W0 on the initial graph) is the amount of money left when the product enters the market (has to be a little higher than on the initial graph)
T1 is the time of the first release
T2 is the time when money returns to W2 level
T+ (needs to be added at the end of stress time) is the time when the product starts to bring a profit
The client shows up with a certain amount of money. As an independent contractor, the software company should do its job as it was planned initially - present an MVP version of the software - and the success is assured.
Well, not quite. The perfect scenario of a product launch looks like this:
Monica’s idea was viable and she did good job doing marketing research. So did the software development team. The MVP is now out there, gathering feedback and earning its first money.
By the way, experienced analysts in our software team discuss not just business requirements and rules but also come down to the functional level of analysis - that way we get a more in-depth picture.
It is not just about WHICH functions you select for the MVP - it is also about HOW these functions will be implemented.
Only a few people use the app at first, to the dismay of Monica (stress time on the graph). Doubts start creeping up on her, she isn’t sure about her decision to make an app. But soon the app starts showing a profit, usually this stress time vanishes as well.
The greater the number of popular and frequently used features implemented, the faster the cash will start to return to the product owner. Hence, stress time will be reduced.
The goal of a competent software team is to make a product that minimizes the time between T1 and T2. The time before T1 should also not take an eternity as it is important to get on the market quickly and within budget.
Not so perfect scenario
Sometimes though, startups go bust.
That could happen for zillions of reasons. The graph shows a scenario when the startup ran out of cash. For example, the product owner might stop believing in the product and end the operation long before the money ends.
Also, if business requirements were defined wrongly in the beginning, there will be no green line or arrival of cash flow.
Choosing the wrong features and the wrong team are also in the Top 3 reasons for the failure of startups, remember?
After studying the market selecting the right features for the MVP so you don't run out of cash quickly, make sure the software team you’ve chosen to work with is competent.
The Pareto Principle is applicable to selecting MVP features. Choose the ones that would cover 80% of the functionality and make them for 20% of your budget.
That way you will save money for future software modification.
At the same time, remember that V stands for Viable in MVP, so do not enter the market if you have some half-baked useless product your target audience doesn’t need in the end.
An idea, no matter how bright, is nothing without proper business management.