02 | Before you start building

Introduction

In this chapter, we will begin a journey in which we will talk about the process of creation and implementation of an MVP, sharing various thoughts on this topic along the way. Also in this chapter, we will answer the question – of how not to make a false start with the MVP implementation. We will present software creators’ most common pitfalls and prejudices that may result in omitting important steps in creating an MVP scope. We will also explain how to resist temptation in the initial stages of working with an MVP.

Stop and think

Forgotten prospects

Which came first – the problem or the solution? – A question worth analyzing by theorists of digital product evolution.

In all seriousness, the answer to this question can often impact how creators think about developing an MVP at the beginning. Creating a strategy for implementing a new product differs significantly when we start with a solution in our mind, rather than the point where the genesis of our invention is a problem. 

The first perspective is associated with certain risks that may arise from an excessive focus on building the MVP scope based on the solution.

1. The first risk is losing sight of the user, which may seem cliche, but unfortunately, this mistake repeats over and over again in the early stages of creating new digital products. The creator, enchanted with the vision of the development of fancy features, does not ask himself whether there is a real target group for which the solution will be so helpful that they will want to pay for it.
So they start the process of building an MVP with the conviction that the solution itself is so attractive that there will certainly be consumers willing to pay for it

… it sounds quite absurd, but unfortunately, it happens quite often.

2. The second lost perspective, resulting from “falling in love” with the solution that may be overshadowed, is the perspective of the broadly understood market (history of competition successes and failures). In this scenario, the software’s creator, convinced of his solution’s effectiveness, does not conduct a thorough analysis of brands with a similar scope of activity and their historical relationships with users. This approach lacks conclusions from examining the correlation between:
– the range of solutions offered by the competition,
– user satisfaction,
– and the company’s financial success.

So we fell in love with the solution … we don’t see the real needs of the user sufficiently and we superficially look at how the competition has been doing so far – as a result, we create an MVP range, the implementation of which will not give real value to users …

…what can we do to prevent this?

“Love the problem, not the solution”

The solution to this problem seems simple… but is it?

As it turns out – not entirely. 

The phrase “love the problem, not the solution” is echoed in many texts about digital solution design and innovation, but the number of startups sprouting from the love to the solution, disconnected from user needs and the market situation, is not decreasing.

So what does “love the problem, not the solution” really mean?

If we were to list the elements contributing to the success of brands in different industries over the years, we could divide them into:

• specific factors related to industry and product characteristics
• universal success factors, independent of industry characteristics

The second group would most likely include the following factor – “consumer orientation”.

But after all, there are so many great frameworks to collect user feedback and so many great activities that companies are implementing to please their consumers – does that mean that all these companies have success in their pockets? Probably not…

The problem with loving a problem is the lack of regularity. Like many love relationships, this one also requires commitment and systematic nurturing. Many innovators either don’t focus on the problem from the beginning or they “burn out” during development and fall in love with other areas along the way – solutions, features, the pursuit of measurable results, scaling strategies, popularity, etc …. they do not care about the relationship with the problem and they do not delve into its essence.

So let’s pause for a moment… what does this mean for us when we are at the beginning of our journey and just starting to define the scope of the MVP? 

This means that the starting point in thinking about MVP should be a real problem, defined by a real group of consumers or resulting from the observation of a real group of users. We should remember at this point that the relationship with the problem does not end, on the contrary – it is just foreplay, the beginning of a long and intense relationship, the search for which we will deal throughout all phases of digital product development by cultivating a close relationship with the target group based on honest feedback and iterative testing of new solutions.

What benefits can you gain by staying focused on the real problems of future users?

• you save money by adjusting the solution to the real needs of future users – you avoid a false start caused by a wrong business idea
• build users’ trust in your brand – by engaging them from the very beginning in jointly shaping the product
• from the beginning, you build a product development culture in which the context of functioning and user needs is at the center

How are the problems solved by competition?

Humanity would be so much richer if we could learn from the mistakes of others… we do some parts of it, but there is still room for improvement. Today we know that our empirical experiences have a stronger influence on decision-making than lessons learned from other people’s stories.

This does not mean that we should not analyze and be inspired by the successes of others, quoting after the classic “To win, you have to play”. Before you start working on defining the scope of your MVP, there are many things you can do to increase the probability of success. In all likelihood, what you will be trying to offer your future audience has already been implemented partly by someone else, and if your innovation is unique, there is bound to be a product/software based on similar consumer needs, motivations, and emotions.

Before we start thinking about the exact scope of the MVP, we should do our history lesson and broaden awareness of how our future user functions and what he struggles with.

Here are some examples of how we can do this:

• desktop research
• institutional knowledge research
• competition analysis (business, functional, technological)
• benchmarking
• all forms of direct contact with end-users (i.e. IDI interviews, focus groups, corridor research, diary research of existing solutions)
• historical analysis of companies whose operation is based on a similar model (even if they come from a different industry)

… and other forms of background data analysis can enrich the implementation strategy of our idea and help us better understand future users. ​​

Google, when it was creating the browser that we can use today, did not have many benchmarks. What allowed it to gradually expand the market and in the end dominate it was an observation of a hitherto familiar process – how do people search for information? How to most effectively transfer this knowledge to the interface? Of course, Google’s popularity is also due to its effective algorithm, which allows for precise and personalized search phrases based on historical browser sessions – but this was also a key user need that could be identified by analyzing competitors and talking to users.

Understanding the strengths and weaknesses of the competition game gives us another plane in the process of prioritizing the functions that the user may need the most, where consumers feel frustrated and satisfied when performing various activities.

At this stage, it is important to carefully observe the market, and users – there is no universal rule. Activities that will allow us to find the answer to the question – is the direction in which we are going right? – can take different forms, such as quantitative/qualitative research, and can come from different industries. It is important not to neglect to “nourish” the decision-making process with both types of insights. Both can bring value and both can prove crucial to answering the ultimate question – do users really need our product?

Does value to the business always = value to the user?

Does value for the user mean value for Business? … in the vast majority of cases the answer will be – yes. But does value for Business mean value for the user? … the answer here is unclear.

So what else can we do before we start creating the scope of our MVP? 

• we already know what problem our software is supposed to solve, 
• we also know how the competition is doing
• we already have interesting benchmarks

Well, we need to name a unique value proposition that we want to propose to future consumers. 

Why is it important?

Defining your unique value proposition is a synthesis of what we have learned so far. Naming the value that we want to stand out, which is the foundation of our business, is the basis innovators often forget or keep in mind, but never name outright. 

Naming this value increases awareness of the direction in which we want to develop our product and allows for easier assessment of the consistency of actions. Users can forgive the lack of additional features in the MVP, but not those that are supposed to be the key mechanism for solving their problem – it’s worth communicating effectively what our product stands out for.

Several frameworks make it easier to define your unique value proposition, such as The Business Model Canvas and its modified start-up alternative, Lean Canvas. Both frameworks allow you to define a unique value proposition, while not losing sight of the problem, competition, most important metrics, and other key parameters for business development.

There is no time to waste! Before you start defining the scope of your MVP, name your unique value proposition based on the problem of future users of your product and the solutions proposed by the competition. It will pay off!

Does the MVP need an MVP?

Problem/ solution fit loop

Does the MVP need an MVP? …  well, we won’t complicate it too much, but if you ask us – is it worth validating the MVP scope before implementing it? We will answer – yes, it’s worth it.

The beginning of building an MVP in practice means the beginning of higher expenses, so it is so important to optimize the offer to the needs of future users to the maximum extent possible. No exaggeration is healthy, which is why being sluggish at the stage of adjusting the offer to the needs is also not appropriate (we all know how the technology industry can dynamically change) – here is the same, like at any other stage, the top-down timeframe will help in effective management of progress.

Have you ever heard of a problem/solution fit loop? This is the name of the process whose goal is to achieve an almost perfectly tailored offer before we start building an MVP. The process can be linear, but it can also loop if you need to iterate to optimize the solution.

• At the beginning of our process, as we agreed earlier, we gain insights – we identify future recipients of our solution, determine their problems based on conversations with them, and research competitors – thanks to these activities, we obtain material from which we will sew our solution.

• In the next step, we synthesize the data that we obtained at an earlier stage and define a solution that will contain a unique value proposition for our target product.

• The third step … attention here … is not to build the MVP scope in this process, but to draft the offer in a descriptive form, which will allow potential stakeholders to easily familiarize themselves with the scope of the functionality of your tool. In this way, you gain tangible material with which you can arrange a few more meetings to discuss in more detail the adequacy of your solution to the expectations of future consumers.

If the draft of your offer meets with approval and general admiration … well, maybe it’s time to “cut out” the MVP from the draft of the offer and start building …  🙂

Summary

Accurately defining the scope of an MVP is crucial to the success of any digital project. Conducting research with users, and defining the goals and constraints of the project allows you to determine the key functionalities that are relevant to users and bring value to the business. In this way, the project can be implemented in an efficient and compliant manner, thus gaining the trust and loyalty of users and increasing the chances of the product’s success in the market.

Inaccurate MVP scoping can lead to serious time and cost issues. Creating functionality that users don’t need takes time and cost that could be better spent developing key functionality for users. Failure to accurately define the scope of the MVP can also lead to communication problems between the project team and users, which can result in incorrect assumptions about their needs and expectations.

We would like our message to resound bluntly – failure to validate the scope of the MVP in the context of the real market situation and the needs of the target audience leads, in most cases, to losing money and the end of the business.

Additional advice – how to effectively walk on a research balance beam?

“Surveys are like cryptocurrencies. A lot of people talk about them but very few actually know how to use them properly.” – Julian Della Mattia, UX Research Lead in Kiwi.com.

We will talk in more detail about how to research MVP at different stages in later chapters. Still, at the end of this one, we wanted the following message to be heard – research is an indispensable element of the decision-making process. 

As we wrote earlier, research may take various forms, but it is not about research for the sake of research – the variety of forms of obtaining information and the type of information is very important to enrich our decision-making process. There is no golden rule, but it is always good to be open-minded, explore different perspectives, and rely on both quantitative and qualitative data to see the fullest possible context – it is worth remembering that when deciding on the scope of MVPs, the richer, more thorough, and more diverse research, the greater the chance of making the right decisions.

It is also worth remembering the pitfalls of collecting data and relying on numbers due to our human nature.

From the prejudices that are worth remembering during the decision-making process, which modern psychology has described in more detail, I can recall – the observer-expectancy effect and automation bias. Both relate to perception biases when relying on numerical data.

The observer-expectation effect is a phenomenon that occurs in situations where the researcher makes a top-down assumption about the truth of the research thesis (before he or she begins the study). The result can be the creation of a questionnaire or research scenario that will lead to biased conclusions, or the misinterpretation of the reason for the relationship between the figures, in favor of the expected thesis. In short, if we expect a certain result, the research process will likely lead us to it.

Automation bias occurs in situations where a human’s opinion is in opposition to a machine’s calculations, in which case we as humans tend to favor decisions based on automatically calculated data. A classic example is the work of a pilot, where very often a decision is made based on the calculations of the onboard computer.

How does this relate to the world of building digital products? – Let’s remember that in our decision-making process, we often encounter various automatically generated numerical analyses (e.g., conversion funnel analysis), so it is always useful for the quantitative dimension that answers the question – “What?” to add a qualitative dimension that explains “why?”.

Basically, at this point some people might say – “ok, enough talk, let’s start building something … the product will not implement itself” … but we will say – “wait a minute, let’s practice our patience a little bit more. Let’s build an MVP wisely.”

But how to start building your MVP wisely? Check it out in our next chapter!