Creating a product from scratch is not a simple job. The amount of work to be done seems endless, and time is always limited. To be competitive, you don't need to be perfect, but you do need to be fast. It is therefore necessary to launch a product as soon as it is able to perform the primary function for which it was designed. This stripped-down product is called an MVP (Minimum Viable Product). But how do you create an MVP?
Our first experience creating an MVP was at a small startup. When we started there was nothing but an idea. Within a few months, we managed along with the rest of the team to turn that idea into an MVP. This is the process we followed:
Let's go over what each phase is for and how you can create an MVP.
The first logical step in creating an MVP is to know the user for whom we are making it and in particular the problem that our product will help solve. It's then important to start with one or more clearly articulated hypotheses that can later be tested. To give things some structure and make sure all our hypotheses were consistent, we used this formula:
I think [the user] experiences [fatigue/annoyance] when doing/because of [task to be done/responsibility]. Lean Customer Development , Cindy Alvarez
In fact it is important to consider the human dimension of the user and try to solve a problem that creates a real disadvantage. The myth of the user who takes rational decisions has been away for a long time and today we know with certainty that most of the decisions are taken for reasons that are anything but rational or emotional if you are a good sales specialist. (To explore this topic further we recommend Daniel Kahneman's book - Slow and Fast Thinking, which won the Nobel Prize in economics for demonstrating our ineptitude at making rational decisions). Now that we have our hypotheses, it's time to put them to the test.
The most efficient and least expensive way to put our hypotheses to the test is to test them on real (or potential) users with some user interviews. Since at this point we don't have a product yet, all we have to do is talk to the user, to understand if the hypotheses we have formulated actually match reality.
Asking targeted questions on a specific topic seems easier than it is. We will have to use some tricks in order to avoid polite answers or outright lies that our users will more or less consciously feed us. In addition, we will have to pay attention to our biases and how they affect the way we ask questions and interpret answers.
For tips and in-depth examples on the topic, I recommend reading Lean Customer Development by Cindy Alvarez. Below are some guidelines to remember at every interview:
It is best, if possible, to record the interviews in order to have a source untainted by interpretations of what the user told us. It may be possible to develop new hypotheses later, and revise the interviews in light of the new hypothesis.
Once we've collected enough data to confirm that the assumptions made are real problems of real users, it's time to work on the added value our product can bring. To do this a very useful tool is the Value Proposition Canvas theorized by Alex Osterwalder.
In practice, this means describing our user in terms of the activities they have to perform (jobs), the hardships or annoyances associated with performing these activities (pains), and the benefits or satisfactions they derive from these same activities (gains). Similarly, we will look at the product we have to offer in terms of solutions that help the user to perform these activities (products or solutions), "painkillers" (pain reliever) that allow the user to remove or at least reduce the discomfort related to the activities to be performed and profit or advantage generators (gain creators) that would make the experience even more satisfying.
At this point we have defined a particular problem, a specific user and a competitive advantage given by our solution. To complete our strategy we are now going to track the dependencies and main cash inflows and outflows of our product: an analysis of the market and partners involved, main activities and resources needed to create the product, revenue sources and costs, distribution channels and customer service strategy.
Also in this case we can take advantage of a tool created by Osterwalder that replaces the traditional business models and is better suited to a newborn reality and with still many doubts to clarify: the Business Model Canvas.
This plan will need to be updated as the assumptions are validated and will serve as a support for deciding what features to include when creating the MVP.
Once we've defined our strategy, it's time to make a plan to execute it. The common mistake at this stage is getting lost in detailed descriptions of goals and anchoring ourselves to fixed deadlines. We need to keep in mind that this process will not be linear, but iterative. Our beautiful plan as we visualize it now, will eventually arrive distorted by the unforeseen events we will inevitably encounter along the way. It is best, therefore, to prioritize a few important goals that we absolutely want to stick to.
Be careful not to confuse undetailed with generic. Although lacking in detail, the objectives must be clear and specific. Defining user stories will give stakeholders a specific idea of what will be developed, but without too much detail on the technical aspect or functioning of the product. This will avoid false expectations and allow the responsible teams to work freely on the solution. As much as it is better to avoid tying yourself to deadlines as much as possible, it is natural and necessary that a deadline for the creation and launch of the product must be set. Therefore, it is better to prefer flexible deadlines, such as a quarter rather than a specific date. On the one hand, to allow other teams to organize their work, and on the other, because a little pressure is essential to achieve good results and remain productive.
A roadmap is an ideal tool both for communicating externally with stakeholders and for keeping the development team aware of their progress. The important thing here, too, is to keep an overview and avoid details. A roadmap should be a tool that helps everyone understand where we are and what we are doing, not a monster of a document that the product manager spends hours updating!
Now that we have a strategy and a plan of action, all that remains is to execute it. Development and planning are actually two sides of the same coin and they influence each other. As stated in the Agile Manifesto: to create a great product it is important to respond to a change more than to follow a plan.
There are several methods inspired by the agile philosophy to manage the actual product development and interaction with developers, the best known of which are Scrum and Kanban.
During the product development phase, user stories will be used as the basis for software creation. With the goal to be achieved clearly specified, designers and programmers will be able to fully leverage their skills to provide the best design and technical solution respectively. To allow these teams to work freely, it is important not to create expectations about appearance or technical details at the planning stage.
On the other hand, it's useful to plan for regular stakeholder feedback on the work you've done, so that you can quickly correct any errors or clarify misunderstandings, and avoid finding yourself with nasty surprises at launch.
The best way to do this is to plan from the outset a series of regular meetings to present your work, clarify doubts and gather feedback. The most effective way to communicate during these meetings is through visuals, either of the finished product or, if this is not yet available, a mock-up.
Finally! In all likelihood there will be something missing on the eve of launch. Something that is not exactly as it should be. If this doesn't compromise the functionality of the product beyond repair, it's best not to delay the launch. There will always be something to improve. After all, we're talking about a minimum viable product. It's more important to launch the MVP in the market and have the users tell us what works and what's missing than to waste valuable time perfecting something that maybe the users don't care about.
A good launch doesn't have to be sensational. Especially if it's the first version or it's a particularly innovative product, it may be a good idea to opt for a soft launch to a limited number of users. This will give time to gather feedback and improve the product before making it available to a wider audience.
Whatever type of launch you plan, it's important to have a defined plan of the goals to be achieved, how the results will be measured, and who is responsible for each goal.
In reality, creating an MVP is not such a linear process. New information and discoveries you make along the way go on to affect or even upset the original plan, and it takes many iterations before you reach your desired outcome. Keeping an open mind is key to not getting discouraged and succeeding in creating a successful MVP.
