What is an MVP and How Do You Build It?

As the market seems to be exposed to change at an accelerating pace, it is getting more important for businesses to be able to adjust quickly. There is talk of a “Darwinian business climate” in which the businesses who are most adaptive to change survive, not the smartest or strongest. At the same time, the use of agile development processes and the building of MVPs is growing in popularity - specifically within tech, but also in other products, departments, organisations and even life situations. For example, in my role as an IT consultant and freelancer, I implemented the agile way of working in an editorial department consisting of journalists. Me, myself, have not experienced better approaches to excel in this new business climate than this - especially compared to the traditional methods and the so-called waterfall approach. I am a huge fan and promotor of agile product development in general and formulating and building MVPs in particular. Therefore, in this blog article, I aim to explain the philosophy behind MVPs and how to work with it practically.

The philosophy which lead up to the MVP is based on the four cornerstones in agile software development, which are:

Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan

Source: The Agile manifesto (agilemanifesto.org)

Read more about agile software development and the Agile manifesto in the above link.

What is an MVP?

The goal of an MVP is to get proof of concept and feedback from real users of your product as early as possible. The great thing about this approach is that, by doing so, you minimize both time and cost. Furthermore, what I love about MVPs is that you get to be creative. The MVP does not need to be a fully functional product. It could mimic a product, but with real customers. What is important is the real customers. An MVP is basically the simplest version of your product that produces real value to the users.

One example of such an MVP I read about is someone who wanted to start a shoe store. However, to get proof of concept and feedback early, he built a basic website, photographed a pair of shoes in a physical store and put them up on his site. When he received an order, he simply purchased the shoes in the store and sent them himself to the customer. He lost money on every sale he made, but he realized that the concept worked. This example is Nick Swinmurn who built Zappos, which was later acquired by Amazon for USD 1.2 billion.

Another example, from my own experience, is that I worked with savings accounts at a Swedish bank. I came up with the hypothesis that a niched savings account for your savings buffer could increase our current customers’ engagement while also attracting new ones. Instead of releasing a whole new savings product and investing hundreds of thousands of SEK in development, we built a small buffer calculator in the official website in which the customer needed to put in some data themselves. If this was popular, the idea was to build a nisched buffer savings account with these calculations and more advanced features integrated in the logged-in mode, without manual data input. We released an MVP, which took approximately two days to build, but I finished my assignment before we could truly evaluate this idea. It would take some time to get proof of concept for this MVP since the marketing strategy was to get customers organically via SEO and Google had not indexed the site. I hope that my predecessor picked it up where I left it. Either way, you can check it out here: The SBAB buffer calculator

“If you are not embarrassed by your first product, you launched too late.” Reid Hoffman

Here I am posting boxes to our customers from my tea brand, Téamo. We started out with an MVP and have worked with continuous development of our product in our free time. Check it out here: Téamo.se

The point is to release quickly and if you are going to fail, also to fail quickly, or pivot in another direction. Regardless, you want that realization as early as possible and to kill your darlings before they become a burden. I would say that working with MVPs mimics the scientific method in which you try to prove or reject a hypothesis in order to come closer to the truth. The more data you collect, the more you can refine your understanding. To reject a hypothesis, or to “fail”, is extremely important and valuable. I believe that to dare to try something out and learn from previous tries is the approach with the highest ultimate success rate. I try to work systematically with this approach both in my work and personal life. I can also state from experience that when I look for someone to hire, already in the advert I state that having had personal projects or side-businesses is very meritorious, regardless of the results from those projects. As an example, check out this job advertisement that I have written: Job advertisement - Developer to startup

Image source: https://www.netsolutions.com/insights/how-to-build-an-mvp-minimum-viable-product-a-step-by-step-guide/

How do you build an MVP?

The Agile manifesto and agile product development is a philosophy or even a religion to some people. So, how do you go from a philosophy and turn that into action? Here I have outlined the concrete steps towards the realization of an MVP, complete with examples and tools.

The product development cycle and process:

Market research
Ideation and value formulation
Map out user flows
Prioritize MVP features
Define KPIs
Launch MVP

...and then you iterate. Here are these steps in more detail:

Market research

How:

Everything should start with research and getting to know the market and customer. Answer the questions: what do the customers want, who is the target audience, what substitute and complementary products exist, what competitors exist, what are the changes in the market, environment and even from the government? If it is an IT product, what platform(s), i.e web, mobile app or software and what marketing channel(s) are used by the target audience and so forth?
You could try to “be the customer” yourself and solve the customer problem on your own, which will give you a lot of insights. You should also try the competitors’ products.
You could read up on market reports, customer research, experts’ blogs, media coverage, listen to podcasts and so on.
You can use statistical data from governments or look into search behaviour and SEO, for example. I use the SAAS product Mangools for this purpose.

Tools:

You could for example use: Mangools, Google trends and search the web in general.

Ideation and value formulation

How:

Answer the question: From the user’s perspective, what is the problem you are trying to solve with this product? Try to sympathize and form an understanding of the forces that are driving the needs of the users. “Customer obsession” is a frequently used term, which I try to practice a lot. Also, if there are more people involved in the product development than yourself, make sure to establish “the WHY” with everyone involved early on.
Here you can start formulating a concept, an elevator pitch and a long-term vision for the product.
I would also recommend stating a hypothesis in this step, which you later try to prove or reject with real data.
You could also create a first visual presentation in the form of a quick hand-drawn sketch or prototype.
It could also be good to have the constraints in mind of the product. For example, it could be technical, compliance or branding (I write more about this in the next paragraph).

Tools:

A pitch deck could for example be made in: Google slides or Powerpoint and the rest in text documents. I usually use Google docs, but there are many alternatives.

Map out user flows

How:

Draw a first high-level customer journey with different user flows in a diagram in draw.io or a similar program.
Here you can start formulating a concept, an elevator pitch and a long-term vision for the product.
When designing the user flows, you can work with design thinking and customer research. For example in the form of focus groups, Google forms and such to find out more about your customer, their needs and behaviours.

Tools:

These are just example of suitable tools: Draw.io, Swimlanes.io, Google forms, Wireframe.cc and Lucidchart.

Prioritize MVP features

How:

With an MVP, you can always assume that time is the most limiting factor. However, both the time frame, budget and even scope should be as small as possible. The scope is what you usually can and should compromise the most with.
It is essential to decide and, if you are more than one person, agree on what are and what are not MVP features for your product. There are usually always stakeholders with an interest in your product and who want to add more to the scope. However, the non-MVP features are gathered in a backlog for later implementation and to which you can refer when the stakeholders wonder where their favourite feature disappeared to. With a backlog, you can reduce the scope of the MVP for practical purposes without people feeling that they have not been listened to or that their particular idea was not great. You need to scale down in order to be able to focus and deliver anything at all and that is what an MVP and a backlog will help you achieve. Therefore, tell your stakeholders that some features are non-MVP and will be placed in the backlog to be prioritized for later implementation.
Start building a product backlog of the non-MVP features. It could be good to include the following in your backlog: feature description, risk, business value, dependencies, size and date (when applicable). Dependencies could include who needs to be involved in the development. The size is how big of a workload it is (in my opinion, it is enough with a very rough estimate - for example in t-shirt sizes of small, medium and large). From my experience, I have seen a general division among those who think size estimations is beneficial versus unbeneficial to include. However, try to refrain from turning it into project management - with MVPs, nothing is written in stone, everything can and should be questioned and it is a continuous and never-ending work in progress.

Tools:

These are just example of suitable tools: Trello, Jira, Basecamp and Asana.

Define KPIs

How:

Who should measure what, how, how often and why?
Define points of reference. It could be historical reference points such as internal or external data points of previous launches of other or similar products. It could also be extrapolated data points and assumptions of future growth of the product. It can be good to separate what figures you would want in a dream scenario and what are realistic, as these can differ a lot. Read my previous article on Data-driven decision making for inspiration.

Tools:

You might be able to follow up on the KPIs in these tools: Google analytics, Amplitude, Kibana and Splunk.

Launch MVP

How:

Run tests before release. It can be good to release to friends and family in the first iteration. This in order to find improvements which are “low-hanging fruits” and obvious flaws, which easily can be corrected before any form of marketing campaign is kick-started.
Even with the marketing efforts following the external launch, start small and evaluate what works. Marketing is an extremely important and often overlooked step of product development and should be included from the start. Nobody is going to be able to find your product if you do not reach them and nothing “sells itself if no one sees it” from the start.

Finally, iterate your way forward in small feedback cycles with frequent and many releases. By developing, measuring and learning, you are working with continuous improvements following the product roadmap towards the product vision.

Image source: https://www.netsolutions.com/insights/how-to-build-an-mvp-minimum-viable-product-a-step-by-step-guide/

To keep in mind in a technical MVP

As the agile product development cycle can be applied not only in tech product development, it is not explicitly mentioned how the IT development and design work could be carried out. However, as I work within tech and it is the most common application, I would like to state a few things about that as well:

Development and design

How:

Break down the product in smaller pieces and define user stories and tickets (the smallest piece of a development task). Then you start coding, and you can go about this one ticket at a time, if you want. The design usually starts with designing one view (a snapshot of the user journey) at a time. As an example, one could start with coding and designing the first interaction with the customer, or the most important interaction with the customer.

Tools:

For the break-down of the work, you could use the tools I mentioned earlier: Trello, Jira, Basecamp and Asana. Design tools could be: Figma, Sketch and Invision and development tools could be too many and too complex to describe in this article. However, as an example of a small web development project, I use Sublime for coding, Postman for experimenting with API integrations and Github for pushing my code to production and Gandi for web hosting.

In your product development, you might have some tangible constraints, which are good to be aware of. This is not just applicable for MVPs, but for all technical product development. Either way, as with everything else when working agile, you should try to challenge and question these whenever possible. These could be, for example:

Technical constraints:

What is technically possible and feasible?

For example, what is the technical stack you might already have and the upcoming choices of technical stack?

What data do you have and can you obtain?

Also, what can and should we build ourselves and what integrations with other systems/programs/apps/APIs do we already have or should have?

Compliance constraints:

What legal constraints do we have?

For example, all digital products are somewhat constrained by GDPR in these times. Companies’ cookie and privacy policies are literally everywhere on the web. For example, if you are to collect personal information, the first thing in the data collecting flow needs to be a customer consent to using their personal data. This is something to keep in mind which might limit the product and the artistic freedom.

Branding constraints:

If the product should or should not convey or send a message, it could influence the whole product design. Therefore, when applicable, you need to include such things as:

The profile of the company

The marketing campaigns of the product

Cultural, moral and ethical aspects of the product

Benefits of MVPs

Now we have gone through what an MVP is, how to build it and what to keep in mind when developing a technical MVP. To summarize, some of the benefits from building an MVP, rather than following the traditional approach, are the following:

It is the quickest and cheapest way of turning ideas into products and to get proof of concept. The top reason why startups fail is "no market need", according to this report by CB Insights. Hence, you would want to get proof of concept as early as possible.
If you are going to fail, it forces you to fail quicker than you would have with other approaches. A consequence of the point I made above is that you get enough information to know whether or not to NOT keep developing the product. As I stated before - this is just as important a result, since it frees up time and money to work with more promising products without having spent too much on one which will not live up to your expectations or hopes. This concept is called “fail quickly”, which I wrote more about previously in this article.
It forces you to focus on and deliver the core functionality first (nothing more, nothing less).
You get access to data from REAL customers (cannot stress this enough).
You get access to data EARLY, which enables you to work data, test and hypothesis driven.
You come in contact with customers and can ask for feedback early in order to obtain customer-driven development. You might even obtain truly engaged and invested customers in your early adopters.
You are forced to formulate a target group and market. The target group should never be ‘everyone’. It is usually better to start with a small and niched target group since that usually makes the MVP scope smaller as well. The more customers you are trying to solve a problem for, the bigger the scope usually gets.
You do not only receive feedback early from customers, but also from your co-workers, which could accelerate your work.
You find out which marketing strategies work for your product and your target audience.

Final statement

As I stated in the beginning, I am an IT consultant and freelancer and work mainly as a product owner/manager. In addition to this, I have projects and side-business as well. In all of my work, I try to formulate MVPs and work data, test and hypothesis driven. I have seen amazing results from this approach both business and organization wise. Products get better and people also seem to prefer to work in this way. All-in-all, a win-win. However, and as is so important, I believe everything could and should be questioned so if a better approach comes along, I would be thrilled to try that out. Although, right now, it seems to be the best product development process and I would sincerely recommend it.

As a final statement, I would also like to address how you can apply the MVP thinking in real life situations. Me and my partner formulated a hypothesis that we would like to have a car in particular situations. We started renting those little electric Aimo cars, which are available in Stockholm. Since that was really smooth and the hypothetical statement was proved to be correct, the use cases that we first saw expanded and we started thinking about buying our own car instead. We discussed which price interval was reasonable for us. We could have spent all of our money on a really nice car, but we were not sure if it was worth it. Therefore, we found the cheapest, easiest and closest car we could find. We bought it for SEK 10 000 from a family friend. Now that we have tested it out and proved the hypothesis that we like to own our own car, we are planning to buy a newer car. We are prepared to spend more time researching what car we want, pay a higher price on the actual car and also spend more time taking care of the car because we now know that it solves a lot of our problems. The general approach should be that the more money and/or time you are going to spend, the more proof you should want backing up that investment. The easiest way to get proof of concept is to try it out for real, but on a small scale and then iterate. This is the MVP explained.

Good luck with your MVPs out there and let me know if you have any questions! Feel free to send me an e-mail at: anna@annaleijon.com :)

/Anna