Adopting a Tiramisu Mindset to Build Your Next Product

The Tiramisu is one of the most famous Italian desserts around the world. Walk into an Italian restaurant, and more likely than not they offer it. Travel throughout Italy, and you can find it everywhere. Originally from the north-east region of Veneto (where Venice is located), the Tiramisu has become eponymous with Italian dessert. And if you Google it, you can find a variety of recipes to make your own.

Yet, making a good Tiramisu is not an easy task. There are three main ingredients in a Tiramisu: espresso coffee, mascarpone cheese, and ladyfinger biscuits. These three ingredients need to be in balance for the Tiramisu to come out good. If you put in too much coffee, too much cheese, or too many biscuits, you may end up with a dessert that resembles a Tiramisu but in fact is too soggy, too mushy, or too dry.

When I look at the Product Manager/Product Owner role, I find that a similar balance exists. The Product Owner has three main responsibilities, which I define as:

1. Understand the customer, the problem, the market
2. Drive product development and build the solution with the Development Team
3. Measure the outcomes and validate the solution to the problem

In working with teams around the world, I have often seen that only one of these areas is kept in focus, while the others are barely touched. Often, Product Owners spend some time understanding the customers, and then quickly jump to a solution and focus on building it. Measuring the outcomes comes at the end of the development process, and often as an after-thought rather than being an integral part of the process.

Yes, the team may try to learn about Scrum and do “Agile”. But when the three responsibilities are not kept in balance, Scrum becomes just a method to execute the work, and the team focuses on the execution part. It may build the product in Sprints, but the overall product development looks like a long cycle before it’s validated in the market.

Adopting a Tiramisu mindset helps to build products in rapid iterations, maintaining the focus on what customers need, and measuring outcomes along the way, as the product gets built. 

In this article, I’d like to answer a few questions that came up when I presented the topic to the Scrum Alliance community. These points are useful in thinking about how to support a Tiramisu mindset and avoid falling into the “build trap” of focusing on execution alone.

How can we get a Product Management and Innovation Assessment?

Change and improvement often starts from awareness, about the skills and knowledge that we don’t have, and about the desire to develop them. There are many ways to develop awareness, including reading articles in this community, participating in conferences, reading books on the topic, and more.

One valuable method is to use an assessment tool that can quickly help you understand key areas where you may not have the full skill set and that you may want to develop further.

We have built a Product Management and Innovation Assessment tool for this purpose; it's available through Comparative Agility. This assessment can be used by individual Product Owners, by teams, or by the larger organization, and it provides insights on which areas you may focus on as you develop your expertise in Product Management and in driving Product Innovation.

In a tech-strong world, how come you still chose to create a journey map on a wall? With our new reality of working from home, how would you run these workshops virtually... with no sticky notes, no paper, no pens and no walls?

Whenever I can, I prefer to use sticky notes and whiteboards to generate ideas and collaborate with others, rather than writing on a computer. My house is full of sticky notes and multiple whiteboards for this reason. They help me visualize things better.

However, the world is quickly changing. Even before the Covid-19 pandemic, teams were already starting to go remote - if not being remote altogether. The recent months have just put more pressure on everybody to figure out how to work collaboratively even when we are socially distanced.

Many tools exist to support this way of working, and one of my favorites is Miro. It’s a virtual whiteboard where you can create stickies and frameworks of all kinds, while collaborating with team members around the world. I’ve used it for product planning, for ideation sessions, and for running training classes with my students, with people simultaneously working together from the USA, from Germany, from Pakistan, and from Columbia. 

There are many other tools like it (Mural, Span Workspace, Google Jamboard, etc.) and everyone has their personal preference. In the end, it’s about creating a space when team members come together and share ideas.

With going remote, the business has been forced to utilize more technology. How do we deal with the gap? Sometimes they are hesitant to learn new Agile tools like Mural / Azure DevOps / JIRA?

In situations like these I often go back to the basics. In this case, the agile value of “Individuals and interactions over processes and tools”. Tools are great, and certainly they help solve many problems - especially in letting us feel connected even when we are physically separated from each other. At the end of the day, it’s not about the tool itself, it’s about fostering a culture of collaboration and communication between the individuals that work together.

Let’s take an example. Sometimes I hear teams become restricted by Jira. Everything is in Jira. All the details should be written in the User Stories. People are criticized for not being specific enough. If it’s not in Jira, it won’t get done. And so on. The “tool” becomes the controller of the team.

Every tool has its pros and cons, and Jira is no different. While powerful and simple enough to use, it forces teams to think within its constructs and allows (like most tools) little flexibility. For example, it forces teams to look at work as tasks that individuals need to complete, rather than creating a sense of team and self-organization that empowers team members to work together.

I often say to my teams, having the details written in Jira is great, but don’t forget to share and communicate with each other. As much as you can write details in a card, there is always something left out or a possibility for mis-interpretation. So creating the space for collaboration and alignment is essential. At that point, which tool you are using to save the details becomes irrelevant or a choice of convenience.

How important is it that the customer understands the agile mindset and process, in order to work with an agile team on an MVP?

I think it’s essential to have customers understand the agile mindset. It’s not about them becoming experts in Scrum. It’s about them supporting the team in the product development journey by being accessible and available, by providing frequent feedback, by allowing for plans to change.

The goal of adopting agile practices is to reduce risk, maximize the value of the product delivered, and reduce the time to market. What customer would not like any of these?

In order for the product team to be effective at achieving these objectives though, the customers play a key role. They provide context about the problem they need to solve and why that’s important. They provide feedback and validation along the way, to help the team steer the solution towards a product that works and solves the problem. And they understand that having an upfront plan with all the requirements fully scoped out may not be in the best interest of risk reduction or value delivery. Therefore, they support the team in creating plans and changing the plans at any time as they learn more.

Is there a limit to the number of MVPs you can have on a product?

The short answer is, there is no limit. You may have multiple hypotheses, and you may want to deliver different MVPs or different versions of your MVP to validate these hypotheses.

It comes down to the purpose of an MVP. I think of the MVP as a tool that Product Owners have at their disposal to quickly validate hypotheses and reduce the risk of building the wrong thing. At its essence, the MVP should help to validate (or maybe invalidate) a key hypothesis you are making about your solution, your customer behavior, or your market. You build a “minimum” product that you can put in market, in the hands of your customers, to test for “viability”.

Is this working? Would customers use it? Does it validate our hypothesis?

If it works, you move on to the next step. If it doesn’t, you may pivot, consider a different solution, and deliver another MVP to validate again your hypothesis until you find something that works.

One good tool to use is the MVP Canvas. The MVP Canvas helps to define the hypothesis and create alignment of the metrics to use to measure it.

A new project is created and the MVP is clear, but only the stories for the first one or two Sprints are created. The customer wants to know when the MVP will be ready. Is it good practice to dedicate the team to creating all the stories at high-level and provide a high-level estimation? How does the Tiramisu method help with release planning for those customers/managers that want a release plan and a forecast for what can be delivered when?

I think it comes down to the agile value of “Adapting to change over following a plan”. Having a plan is great, and in fact agile practices support many ways of planning, across a variety of horizons. While short-term plans can be quite detailed and specific (e.g. a Sprint Backlog for what the team is working on in this Sprint), longer-term plans are less specific because everyone understands that they may change as the team learns more and new ideas emerge for the product.

One way to address the planning of an MVP and create shared understanding with customers and stakeholders is to use a Product Journey Map. This is a great tool that helps the team plan an MVP and create transparency on what is in the MVP and what is not. And it allows for the team and its stakeholders to align on any changes.

Building a Product Journey Map is an exercise that can be done collaboratively to create shared understanding and transparency on the plan. To learn more about this tool, you can refer to this article and also download the PDF worksheet that guides you on the process.

The key to making a Product Journey Map workable is to avoid getting bogged down in too much detail upfront. I like to start doing it at the “Feature” level rather than using User Stories.

To answer the question about delivery date, you need to have an estimate of the amount of work, and a measure of velocity (how much work you can do in a given unit of time). So once you have built your Product Journey Map and identified your MVP, estimate the amount of work needed for it, and derive an estimated timeframe.

Everyone should understand that the estimated timeframe is exactly that, “estimated”. At this stage we can only guess when we’ll be able to deliver it, and things may change as we do the work. 

In order to create transparency with the stakeholders, you can use a Release Burndown tool, tracking the progress on your product at each Sprint and projecting out the time to completion. 

By having transparency at every stage of the project, you can have conversations with stakeholders when the plan does not align with the expectations. And at that point, you can discuss adjustments to the timeframe, to the scope of the project, or to the number of teams. The Product Journey Map is a great tool to support these conversations and create transparency on the plans.

Learn more from Valerio by watching his Scrum Alliance webinar Adopting a Tiramisu Mindset to Rapidly Build Products and Deliver Value.

Valerio Zanini is a Certified Scrum Trainer, a SAFe Program Consultant, and a Certified Product Innovation Trainer. He is passionate about creating products that customers love and developing the teams that make them a reality. He has two decades of product development experience in a variety of organizations. He is the author of Deliver Great Products That Customers Love and the founder of Spark Engine, a training, and certification program in Product Innovation.