From Design Thinking to MVP

Story Map

Design Thinking and then what?

Our Agile Coach Markus Güntert has already facilitated many Design Thinking workshops. In the process, he has come across a very exciting insight: Every design thinking project, no matter how inspiring, comes to an end at some point. But how does it actually continue afterwards?

Because "afterwards" the process is often no longer so clear. Unfortunately, in practice this often leads to these ideas being literally talked to death by an organization.

Enthusiastic users may already be asking: "When will this be available? Within the organization, however, the discourse revolves around the doubters, who tend to treat new ideas with skepticism. What risks are associated with them? What could go wrong during implementation? Couldn't it be a huge bad investment? Isn't the entire reputation of the company at stake?

What is the Story Map?

Teams tend to think in terms of grand visions - the "six-lane highway." However, to quickly test whether an idea will work, a clever "dirt road" is often all that is needed. The story map helps the team determine the field path - the MVP - for the product idea.

With the MVP in place, the team is able to launch and test the product. From there, they prioritize specifically when to invest in which parts of the product.

Getting started with the project

Before the teamwork starts, our Agile Coach Markus Güntert clarifies the expectations of the team members. 

The team dynamics

The team dynamics during the workshop are also influenced by the different expectations of the team members. For Markus, hierarchies are recognizable, which can be explained based on the different positions and experiences of the team members.

The better Markus as a coach knows the different expectations, the sooner he can intervene in a moderating way if necessary.

The product idea

In the video, team member Ida introduces the idea. This is what the team will work with in the workshop. The other team members Robin and Yannick share their impressions of the idea.

All team members can share their understanding of the idea at the beginning. This is done one after the other, without lengthy discussions.

Working on the backbone

The team now begins to define the backbone of the idea using the Story Map Canvas.

The creation of the backbone

The team starts with the backbone of the idea. Here, the idea is described chronologically from the user's point of view. The team gathers possible components that make up the backbone of the idea.

The backbone should primarily capture components that are critical effort drivers. Aspects of the backbone that cannot be clarified in the team are not discussed, but are recorded as a work order.

Discussions about the backbone

The team discusses individual components of the backbone and completes this part of the story map. The canvas for the story map suggests that the backbone consists of 7 components. There can also be a few more or fewer if it makes sense in terms of content.

Reflection of the backbone

The team reflects on the extent to which the backbone captures the idea as a whole. New suggestions are discussed. The story map is not meant to represent all the details of an idea, such as the masthead on a website. It is about the essential components of the future product.

Formulation of the expansion stages of the product idea

The team begins to formulate the further expansion stages of the individual components. This makes it clear where the journey can go after the MVP.

The team discusses each component of the backbone in turn with regard to its possible expansion stages. This is how prioritization emerges. Different team members bring different demands to the expansion stages. The team can decide together which components it will expand more or less extensively during the MVP phase.

Challenges in teamwork

In the development of an MVP, there are recurring requests from individual team members. The story map helps to address these requests constructively.

Dealing with management expectations

Team member Robin expresses how he envisions the future product. His wish reflects his personal preference. This is a difficult moment in teamwork.

In prioritizing the idea, it always happens that team members want to prioritize along their preferences. Prioritization along the customer perspective should be better based on user data. Expansion stages of the idea that are not yet important are placed in an idea parking lot. This makes it easier for the team to return to the expansion stages that are important now.

Technological possibilities

The team revels in new technological possibilities. In the process, it loses sight of the fact that many functions are also provisionally possible without elaborate technologies In the prioritization of the idea, it always comes to the fact that we can often think features smaller - in terms of the MVP.

 

Edge Cases and Happy Cases

The team gets into a discussion about so-called edge cases - these are possible, but unlikely, cases that can occur when using the product.

Edge cases are often a vehicle for the team to express legitimate concerns. However, with an eye toward later implementation, the team should ultimately focus on happy cases - examples where the idea works smoothly for the customer. The team finds its focus on the components it wants to implement as early as possible.

 

Prioritization and re-prioritization

The team continues to prioritize along the possible expansion stages. The team will not avoid re-prioritizing as needed later in the implementation process.

Commitment with respect to priorities is a snapshot. Priorities need to be adjusted as new insights become available. When prioritizing features, it helps to think about what kind of users would already be using the first version of a new product - the early adopters.

The "Robin Effect"

The idea becomes more concrete. The team now understands what discussion it needs to have in the story map. This is particularly evident in how team member Robin now intuitively tries to keep the MVP as small as possible.

Working with the story map often leads in a short time to a change of perspective forced by the method. Team members become more oriented towards what is possible in a short time (MVP).

 

Reflection and check-out

Markus summarizes the result of the teamwork once again. A joint reflection follows. The summary of the idea gives all team members the opportunity to clarify misunderstandings. All end up with a common understanding of the idea.

Team members reflect on the teamwork and the core content outcomes. And show gratitude.

 

The Canvas of the Story Map (A0)

Click here to download 📄 the Story Map Canvas.