Building an MVP: cost & process
In the article, A Minimum Viable Product Is Not a Product, It’s a Process, it describes what the process of building an MVP may look like. I want to point how this process applies when you outsource development before hiring an onsite team.
When you come up with an idea for a product and want to go to market, you may think the following: “I’ll build an MVP if customers like it — I will continue to develop the product to enhance it with solid features” That is right, this is what an MVP is. But… there are a lot of small details too.
Budget planning
If you search for an agency to outsource an MVP development, this presumes you have a budget to spend. It is very important to understand the total of your possible expenses.
The first project is built based on your initial assumption. You may perform an investigation and gather some thoughts from potential users. In general, you think you have found a problem you can solve better than an existing tool does.
At this point, we build the first version of the app. It is important to do it quickly: 2–4 months depending on the complexity of your product.
Great if it takes less than 30% of your budget to reach the point where you have something to show to the customers. This is just the beginning of building a product.
After collecting feedback and measurements, we will dive into the next iteration. We update the initial assumptions and fix them according to the received information from early users. Possible directions to take are tuning existing features or building new core features. It all depends on how close to reality you were with your initial idea.
You have to be ready to continue tuning the MVP to fit market needs in a few more iterations than you planned.
FFF: Fixed budget and time, Flexible scope
When you start with an MVP, setting expectations that are coherent with the real-world is key.
There’s a myth that goes like this: we can launch on time, on budget, and on scope. It almost never happens and when it does, quality often suffers. Fix Time and Budget, Flex Scope
That said, our approach is to fit within budget, time and objectives. An MVP should solve the problem and can lack features that could be postponed until later. We tend to carefully select what to include in the MVP in order to stay within the deadline and budget.
Imagine a military operation. Your group has to be at point A to meet another group for a resource exchange. They rely on you and following the operation, depend on the resources you have to deliver. You have to be there at a specified time. There is only 1 hour to transfer resources; if you are late by 45 min — operation failed.
You run 5 vehicles and in the middle of the road, one brakes down. You have to decide quickly; move the resources from the broken vehicle to another, try to repair it or just leave the vehicle on the road and move on. When time is critical, as in most cases, you have to move on. In a similar way, you have to be ready to cut or rethink a feature even it is 80% ready.
Set priorities
It happens all the time — we start to think feature A should be in the MVP. Maybe put down on paper all the planned features so as to have a complete picture of your plan. Cut by half and prioritize what is left. Come back to this list once a new idea pops into your mind.
Trust
Our nontechnical clients are heroes. They trust us, a team that they never meet to work on their project. In a current and well-connected world, it is a little bit easier but the uncertainty at the start eliminates this advantage.
Building trust between the client and the contractor is a long process and both sides have to be strong enough to reach that point. It goes through a set of miscommunications, overnight requests, team configuration changes, iterations of small failures and successes. Not to mention how important it is to choose the people you will enjoy working together and eventually trust to take care of your product. My advice is simple: talk, see and analyze facts over emotions and listen to your intuition.
To summarize, the main idea of the article is to think about building an MVP as a process of building a product to find what your product is. You’ll face challenges from different sides: clients, developers, yourself, and partners. Those challenges are part of the process, few of them could be fixed with a budget but most will require your strength, flexibility and patience. Keep going and good luck, you are the hero!
