I remember listening to a guy who was handling growth at Square (founded in 2009, current valuation $5B, public company). He was so detailed about how their potential customers should come to them, through which channels and how they would use the product, and why would they bring more clients – I was astonished. I was listening to him and thinking, “This dude went really deep!” It was clear to me that the company grew fast due to this detailed planning and perfect execution.
So before spending a dime on building a product, startup founders and company managers responsible for side projects should go deep, too, test the waters. This process relates to any type of product – hardware, software, website, mobile app, chatbot, anything.
There are several steps to it:
- Defining a market niche and your ideal customers
- Identifying the problem your potential clients have
- Validating your assumptions with potential clients
- Outlining the solution based on validated assumptions (a software product, mobile app, or a website)
- Defining and building a minimum viable product (MVP)
- Launching an MVP and validating it by testing it with early clients
- Adjusting the product based on the customers’ feedback and launching it
- Scaling the product while keep collecting customers’ feedback and improving the product
I assume you know how to deal with the first four steps using different tools and methodologies (and if not – let me know, I’ll write about them, too), so let’s focus on step #5 – how to develop a minimum viable product – and go really deep.
How to create a minimum viable product
Even though it’s just a step in the process, this step has its own steps too. Here they are:
- Define your MVP
- Find a top-level dev team who have built similar products before
- Prepare the specifications
- Finalize the scope and MVP development cost with your dev team
- Build and launch your MVP
You might think that’s a lot to deal with, and you’re right. However, if you do it right from the start, it will change your life and the course of your company growth for the better. The main reason startups fail isn’t because of the high competition or a high level of uncertainty – they fail simply because they don’t do the homework and build products very few people need. There is no magic, just a set of actions you should complete when developing a product. Some steps could be flexible and different, but for most businesses, these are the basic ones. Let’s go through them one by one.
Define your MVP
As Wikipedia says, an MVP is:
A product with just enough features to gather validated learning about the product and its continued development. Gathering insights from an MVP is often less expensive than developing a product with more features, which increase costs and risk if the product fails, for example, due to incorrect assumptions. The term was coined and defined by Frank Robinson, and popularized by Steve Blank, and Eric Ries. It may also involve carrying out market analysis beforehand.
This is a very generic definition, as you can see. It’s made that way so it will fit anything. An MVP could be just a landing page for one company, but it might not be enough for another. For example, for DevTeamSpace, it was exactly one landing page with a specific text explaining our unique approach to solve our potential clients’ problems. It was enough to validate the business assumptions and get our first clients. Once we got a client, a big part of the product was introduced by our unique process, not the software product itself. After that, it evolved and has been changed many times, growing it to an automated AI-enhanced software dev platform.
For another product, let’s say for a mobile app whose intent is to measure blood pressure, heart beat, sleep cycles, etc., and provide some healthcare recommendations, a landing page wouldn’t be enough. It would certainly be enough to validate some assumptions and get some people in the door, but you wouldn’t be able to serve them without somehow allowing them to measure certain health parameters via their own phones. That means that this MVP should be in the form of a mobile app with the most important features.
See it? It really depends what your MVP should be, and that’s why it’s so important to define what it is. If you only need a landing page to start serving clients – great. You almost don’t need to spend any resources to get started!
It’s good if you can put your MVP definition on half a page. I gave a good example of a product definition in one of our previous articles here
Find a top-level dev team who have built similar products before
For example, you want to launch a mobile app and you have defined your MVP as mobile app with a certain minimal set of the most important features. Now it’s time to hire developers who will bring your MVP live.
Simply put, it’s hard to find expert developers who have built similar custom projects before and are great at communicating with clients. And most people try to save money by going with a general dev services provider, crossing their fingers and praying that everything will be fine. Very often, it’s not going to be fine. If your dev team doesn’t have the relevant expertise, they will either screw up your project, or delay it, or leave a ton of bugs in it, or will do everything well, but spend much more of your resources and time.
However, one of the benefits of launching an MVP is launching it fast, so you can validate your product assumptions with real clients and adjust if necessary. Obviously, an expert dev team with relevant experience will build it as quickly as possible and with the highest quality, not because they are awesome, but because they have built something similar before. Yes, this dev team might have a higher price than a general dev shop, but if you don’t do it right from the start, it can cost you much more money and time down the road. Often people end up shutting down their products completely because of the mistakes they have made at the MVP level.
Btw, if you don’t know where to start looking for a top dev team with relevant experience, ask us about the community of top dev teams at DevTeamSpace by submitting your project.
Prepare the specifications
This is such an important topic that I have already published an article about it – 6 Tips on How to Write a Good Project Specification (with Examples). Here I will only say briefly that if you spend just a bit more time on specifications at the start, it can drastically increase your chances of success. As Abraham Lincoln said:
Give me six hours to chop down a tree and I will spend the first four sharpening the axe.
Finalize the scope and MVP development cost with your dev team
Once you have the specs ready, ask your dev team to prepare a detailed estimated and a timeline. You need this not only to understand the budget of your project, but to make sure that you and your dev team are on the same page, and it’s clear to both of you how your MVP will become a reality and how soon. Here is what the scope could look like:
And here is what the timeline could look like:
About the cost. There is no average cost to develop a minimum viable product. Very often, people shop around and ask:
“how much does it cost to make an MVP?”
As you can imagine, the most popular answer they hear is:
“Oh, it depends on your product features.”
Tough, there is a difference in MVP development pricing. You can pay on time and material basis (hourly rates, no solid deadlines or final scope), or lock the price. The latest one is reasonable – you know that you will not spend any more than that. However, it will also mean that the scope is locked and you can’t adjust it during the process. It works well when you know exactly what should be done, but it doesn’t work when you have uncertainties.
I recommend you lock in the price and define the scope as clearly as you can. It will minimize the risks and increase your chance of a successful MVP launch.
Build and launch your MVP
Now, once the MVP is defined, you’ve found the best dev partner you can, and the scope is clear, you are ready to start. There are several things to pay attention to:
- Oversee the process, but don’t micromanage.
- Make sure you keep track of any roadblocks and avoid any delays in the process by providing all necessary information to your dev team during the dev process.
Some clients want to text/talk directly to developers every day, or like two times per week, each time for 1-2 hours. This doesn’t make any sense. Firstly, you disrupt the process with your talks. and the devs spend less time programming. Secondly, you end up paying for talks, not the actual work. To solve this, at DevTeamSpace we provide every client with short daily updates on a special dashboard and over email. These updates are written by developers and automatically sent to the client at the same time each day. Updates contain information on what has been done during the day, what roadblocks appeared (if any), the overall project progress, and whether we are still on track to meet the deadline.
As for the roadblocks – simply make sure you watch for them, and when something is needed from your side, provide it to your dev team asap. I mean really ASAP, within 1 or 2 hours, so you don’t interrupt the dev process. If there is a roadblock on the dev team side, don’t wait until they will figure things out on their own. Offer them your help in the form of a conference call and discuss the problem and potential solutions. This is called team work and usually allows you to resolve any roadblocks really fast.
Once everything is ready, make sure you test everything before the launch. Don’t leave anything to chance. Ask your devs to test it, and relentlessly test everything yourself. It doesn’t mean you’re doing their job, it actually means you’re doing your job as the product owner. Once everything is nailed, launch it, but don’t rush. You should add a couple days more testing rather than launch an MVP with major bugs.
Now you are ready; now you have a plan to act on and build an outstanding MVP for your product. The system described above is equal for startup founders and for product managers in large companies. Your only job is to execute it well.
If this article has been helpful, feel free to share it with your friends and colleagues on social media and via email!