I have been familiar with the MVP concept for years. You may be thinking of some well-known definitions of the concept, such as the Microsoft Most Valuable Professional program, which I am sure some of us have wanted to be a part of in the past, or the NBA’s Most Valuable Player of the regular season. In this case, however, I want to change your mind for a few minutes and take your product mindset to the stage and embrace the Minimum Viable Product.

I remember thinking about this concept, founded by Eric Ries in 2009, as the smallest possible experiment to test a specific hypothesis, or the minimum version of a product that allows a team to collect the maximum amount of validated learning about customers with the least amount of effort.

You may agree with me and the authors that no minimum product or even viability analysis is required at this time, so what the hell are we doing here? this took me several years to realise, so let’s speed up the wheel of time to the present moment.

IKEA Values

Joining IKEA was one of the biggest steps of my career, not because of the great company it is today, but because of the values it represents. A message that Peter Kamprad, son of founder Ingvar Kamprad, said some time ago and that still resonates with me:

Any outside company can copy IKEA as a company whenever they want but it will be impossible for them to copy its values.

Traveling to Älmhult in the early months and discovering how Ingvar founded IKEA reminded me of the concept we defined, do you remember it? yes, it is MVP. If you have not read Ingvar’s biography and how he founded IKEA, or even visited Älmhult, I can only recommend it. It is definitely worth it.

In his early years, Ingvar started selling almost everything, from Christmas cards to nylon stockings. Translated to the essence of this article, he started an amazing product discovery journey from several key resources (e.g. Christmas cards, pens or seeds) and a unique selling point, himself. It sounds funny to think about what would have become of IKEA if that journey had stopped at nylon stockings. Would we have gotten to say pens in our core?

Based on the original definition of MVP, we could say that Ingvar launched his first MVP. However, this is where I realized that I was confusing product with experimentation, and that this led me to understand experimentation in the wrong way. This evolution came from Marty Cagan, where he associated these first exercises as “MVP tests” as an essential part of product discovery to achieve the desired product-market fit. So did Ingvar ever achieve product market fit? No, I don’t think so.

Ballpoint pen for granted — An example of a ballpoint pen for granted by IKEA Museum

Over the next five years, Ingvar continued his “MVP tests” and concluded that the most cost-effective distribution was through pens that clearly represented a target persona, such as newsagents, watchmakers, pen shops, bookstores and rural stores. His communication channel was based on small brochures, sales letters and price lists. Can you imagine what would have happened if someone had told him he had only one option or to limit himself to talk with the local newspaper in the area?

Finally, he defined a cost structure and a revenue stream to be profitable. Surely Ingvar was not aware that he was going through each of the necessary stages of what we now call a business model canvas, but did he really need one? His vision and clear product strategy were more important than the process or form it actually took.

Going back to our story, he wanted to sell pens for 3.95 kronor, but delivery took 4 kronor, which meant a loss of 5 öre. This learning by doing, accepting risks even with financial losses, becomes a crucial part of the current IKEA values that we have today.

Inspired

The second big move in my career was reading Marty Cagan and SVPG (Silicon Valley Product Group) trilogy. Inspired, Empowered and Transformed not only helped me to validate many of the hypotheses I had gathered over the past few years, but also transformed me into a product engineer, which will discuss later. A great price to pay for such a transformation, don’t you think?

The first step I took was to learn about product risk. It sounds strange, doesn’t it? how could an engineer start focusing on risk taxonomies instead of digital product development? but as I said, this was also a transformation process to become a product engineer. This leap into the void was just another proof of that change.

“Assessing the product risks is the first thing we do when we’re trying to discover a solution worth building.” Marty Cagan.

In particular, we adopted a risk taxonomy created by IDEO, popularised as part of the design thinking methodology, and based on the following three risks:

Desirability (whether customer will choose and use or product)
Viability (whether our solution works for our business; it also implies compliance risks, go-to-market risks, ethical risks, brand risks among others).
Feasibility (whether our engineers can build what we need with the boundaries we have)

It was slightly different from the four big risks that SVPG proposed and evangelise in different forums, but there is an exact match between them in who is responsible for each risk.

Product managers are responsible of the viability and outcomes.
Product designers are responsible of the desirability and experience.
Product engineers are responsible of the feasibility and delivery.

If you’re a Product owner, I encourage you to read the following articles (e.g. Good Product Manager / Bad Product Manager or Two in a Box PM) just to understand my vision while writing this article.

But what about data teams? There is a large community behind them. In this case, as with architecture, security or privacy teams, data teams should not be an exception. As experts in the field, they should empower a data analytics model based on insights, connect with other internal or external initiatives that enrich the proposed model, and help the product viability and its product manager in the product strategy decision-making process. Thus, Product managers are responsible for deciding how and when to rely on these resources.

An MVP is a good starting point but it does not define the path we take as a product team to get there. Whether you call it Minimum Viable Product, Minimum Feasible Experience or Minimum Lovable Product and go back to the origins of IKEA:

Take value risks and business risks as early as possible (let’s start selling pens again!).
Look for locality and effective collaboration that brings speed to your experiments (let’s find some manufacturers that bring us a cost-effective ratio to avoid losing money one more time).
Focus on solving user problems beyond features or roadmaps that come from external sources (listen, analyze and determine that pens are more needed and valuable than nylon stockings).

I only know one way to achieve this, be empowered.

Empowered

Some time ago, someone asked me why I chose to join a large company like IKEA, after spending my entire career in various technology startups. My answer at the time was quick and clear:

I believe in its mission and digital transformation and I want to be part of it.

Today I still believe in that change but I would definitely not have the same strategy without any doubt.

From my perspective, one of the biggest challenges for leaders of large companies is communication. As with product managers, it is not only about communicating a clear mission and vision, but also about getting your strategy accepted and adopted, no matter how many variations it may have. In other words, digital transformation to a product operating model starts with strong conviction, but continues with the transformation of the teams into empowered product teams.

Now it’s time to talk about engineering products, which, at least in my opinion, is the most realistic and least toxic definition of a10x engineer. These engineers have a number of differentiating characteristics:

Do not spend more hours than other engineers performing the same tasks.
Leverage all the resources around them in their constant quest for higher performance.
Do not limit themselves to technical areas but accept others such as privacy, security or sustainability as central point to their decision-making process.
Be present in a constant flow of innovation, diverging and converging ideas that they absorb in their constant and direct relationship with customers.
Be problem solvers, not feature implementers of stakeholders.

The only way to sustain the transformation of teams, maximise their performance, and even attract outside talent with the same skills is to ensure the following three factors: autonomy, empowerment, and innovation.

However, this journey brings with it a number of challenges that will test the resilience of the transformation process and the cohesion of the teams. The main goals of the next section is to briefly review into some examples in order to help these teams, from my personal perspective, identify and be prepared for these challenges.

Transformed

If you work in a large company, you may have heard about brand risk or even been involved in these assessments. Similarly, it is possible that under this pretext, some “MVP Tests” have been discarded under this pretext because of the high risk, creating a sense of frustration in the team because they did not even reach users for validation.

Is it possible that the brand could be a brake on the three factors mentioned? Yes, it potentially could be. Like any other type of risk, there are no green (yes) or red (no) lines; the vast majority of these risks fall between gray areas, subject to interpretation and decision by the relevant stakeholders.

On the brand aspect, I was once asked if there are any known metrics or if it is mainly an emotional factor. From my point of view, it is quite similar to sentiment analysis in that you can put numbers, assumptions and some kind of criteria behind it, but there will remain a significant amount of uncertainty to manage. Humans have been pretty bad at managing uncertainty since the beginning of time, so maybe it is time to consider that we can be equally bad at estimating brand risk.

Another important aspect to consider is the lack of alignment between the company’s values and its culture. We often come across sensational inspirational phrases in companies that are far from reflecting the culture of the company and the teams that make it up. It reminds me of the book The five dysfunctions of a team from Patrick Lencioni.

In this leadership fable, the main character encounters various pitfalls such as the lack of trust, fear of conflict, lack of commitment, avoidance of accountability or inattention to results. Sound familiar? These are some examples of values and culture misalignments.

Giving teams enough autonomy to identify the main problems to be solved, declaring common co-creation spaces where different hypotheses are validated and diverged, and converging on common solutions once reached our product market fit is achieved it are just some examples to help in this challenging task.

Conclusion

Moving a company into a product operating model is an amazing MVP, plenty of assumptions to ideate, risks to take and challenges to overcome. Why should product teams be different?

The MVP was originally published in Flat Pack Tech on Medium, where people are continuing the conversation by highlighting and responding to this story.

Newsfeed

News from Ingka Digital

Ingka's Flat Pack Tech at Medium.com