Minimize the Distance Between the Maker and the User - Part 2

• an Interview with Marcus Castenfors on Holistic Product Discovery, Part Two

This is the second half of our interview with Marcus Castenfors, product leadership coach, and founder. In this part, we are covering the importance of prototyping, aligning the three important dimensions of business value, user value, and feasibility, and expanding our framework to foresee risks. You’ll also hear about what Spotify did in this respect, and what Marcus recommends to companies starting out with holistic product discovery.

Airtime: During your webinar, you also stressed the importance of continuous discovery and delivery, especially the continuous delivery of prototypes. How can you make sure that this continuous prototyping doesn’t take up too many resources? Can you provide a real-life example where this continuous prototyping mechanism led to a major successful discovery?

MC: Yes. In terms of resources, I think it’s important that the team works on it together. This doesn’t mean that everyone needs to work on it [in parallel], but it should be transparent what’s going on. What is the continuous learning that’s happening in the team? What are we learning?

You should have a product trio. Teresa Torres talks about the product trio where you have somebody who focuses on the business side of things, on the customer side of things, and on feasibility. That could be the product manager, a designer, and an engineer who does discovery together, right? But it doesn’t mean that the trio is a silo and that the other engineers and the rest of the team don’t know what’s going on. You want to bring everybody together, but sometimes, the designer might do research, and keeps people in the loop. It’s transparent what’s going on, what the team is learning about.

In terms of continuous prototyping, the prototype should be your number one artifact to capture learning.

Because documentation is problematic, because we as humans love to touch and feel stuff, right? Documentation is not very engaging, prototypes are far more engaging. I argue that prototypes are the best way to capture learnings and to keep them updated in an iterative and incremental way.

A case study for that. In Hapkey, the startup we talked about earlier, we’ve been doing continuous prototyping for a few months now, doing customer research every week on prospects. We have a hypothesis of a customer segment and we show a prototype every time we talk to customers. We also show a website of the competition because we’re testing the solution fit with the value proposition of the product.

We take the landing page of the product and compare it and contrast it with the competition and how they explain their product. We’ve been iterating the landing page as a prototype. So we’ve created this fake landing page and we’ve been iterating how we talk about the product, the features that we put on the product, or the features that we visualize on the landing page. And we’ve been learning a lot.

The landing page prototype has been a way to capture learnings from previous interviews.

After each interview, we talk about what we learned and how we should iterate the landing page. Then we do another round of interviews.

Airtime: If I hear you correctly, then there’s no need to align the prototyping with the research because it’s one cycle. You start with the research activity, and you end up with a new prototype, then you just repeat until the iterations are enough.

MC: Yeah. Research is amazing, but research should lead to action. That’s the most important thing. And the action that I talk about is prototyping. Obviously, you need some kind of documentation of the insights, so you don’t lose track of the research. If you don’t document, you could end up in a situation where you lose the signal as you progress. So it’s important to isolate the key insights from the research but you need to emphasize doing, acting, working with prototypes, working with the team.

Airtime: You stress the importance of powerful questions in the three areas of user value, business value, and feasibility. What is your general practice to make sure that all three are aligned and have equal importance?

MC: It goes back to what we talked about earlier, making sure that you have these competencies in your team. That you have people who come from three different perspectives, who have three different angles when it comes to product development. It could be a designer, a product manager, and an engineering lead. You can see it as a core principle when you’re talking about product discovery or delivery, that you have this balanced approach. You should have these three qualities in harmony. It could be as simple as putting it up on a Miro board or visual that you referenced during a workshop, that we should have these three perspectives. If you don’t have these competencies in your team, you can role-play. So I have the customer hat on, or I have the business hat on, or I have the feasibility hat on. We can debate and argue with healthy friction between these three perspectives.

It’s not all fun and games because if we just focus on user value, we might not capture business value. And if we just focus on technology or feasibility, we forget about user and business value. So yeah, it’s about having that balanced approach.

Airtime: I really like the idea of role-playing. I used to be a salesperson in investment banking and we did it a lot to explore and grow empathy. Do you do this regularly in your projects, placing everyone in different seats?

MC: I definitely do that in training. When I run product discovery training we try out different perspectives and that works well. We’re quite good at role-playing as humans, and that brings up additional insights.

Airtime: You also said that highlighting risks around these three factors is half the challenge of product discovery. Can you tell me how you do pre-mortems to ask the right questions and find out about these risks?

MC: Yes, pre-mortems. I got inspired by Shreyas Doshi who was one of the first product managers at Stripe. He’s a great person to follow on Twitter and LinkedIn because he writes about this stuff all the time. Pre-mortem is basically flipping the notion of post-mortem. Post-mortem is something that you do when something bad has happened. It could be an incident or a project that didn’t meet expectations. You typically facilitate a workshop with a cross-functional team to learn from past mistakes, like a retrospective.

Pre-mortem is about anticipating what could go wrong, what are the key risks with the project at hand or the problem to solve that has been defined.

You can role-play in a sense of what could go wrong. Think about what the feasibility risks are, what could go wrong in terms of the technology, and what could go wrong in terms of not addressing user value, and from the business side of things.

When you think many steps ahead about what could go wrong, that workshop or that meeting will lead to insights on what to discover first. You want to tackle the highest-risk items first and use product discovery techniques to do so. These could be user research, talking to stakeholders, and understanding the strategy, or from a feasibility angle, maybe you need to do quick feasibility studies. It could be a technical spike just to test some technology or integration that’s really important to this project.

If you watched the TV series ‘The Playlist’ about Spotify, it’s quite interesting to think about how they tackled risk.

Spotify in the beginning wanted to address the problem of Pirate Bay.

Pirate Bay was the norm in the mid-2000s, where you downloaded music for free. But there were quite a lot of problems relating to downloading music for free from Pirate Bay because you needed to find the song, you needed to download it, you needed to put it on your computer, categorize it somehow, and then you had to use Napster or some other audio software to listen to the song. Sometimes you got a virus, sometimes it was poor quality. So Spotify’s idea of the value proposition was to create a tool that was free, that had an amazing library, and that provided a better experience than Pirate Bay.

And they had this maniacal focus on one feasibility aspect, which was buffering. When you click on a song, it should play instantly on your PC or Mac. That was the key risk that they tackled initially. How do we eliminate buffering, so it feels instant? From a business value perspective, there was a lot of risk related to record labels. From a user value perspective, the risk was if users were willing to move from Pirate Bay to Spotify. What’s the value that Spotify is bringing in contrast to Pirate Bay — they were tackling risks in this way.

So user value, business value, and feasibility could be a helpful way to categorize product risks. And you could use this risk mapping technique that I referenced in the webinar to categorize what’s the highest risk and how much knowledge we have on the risk. Then you can flip each post-it to understand what you need to discover. It could be anything and everything. It could be super straightforward like talking to a stakeholder or doing something simple with the technology. What’s riskiest with the technology? Or what’s riskiest with feasibility?

‍Airtime: Thank you Marcus. My last question for you. If you had to recommend one or two key things to teams who want to implement holistic product discovery, but haven’t yet, what would they be?

MC: The number one thing would be to use the framework that we reference. The framework is holistic in the sense that we think about the stages or modes that you go through to understand the problem and to define the solution, as well as the three aspects of user value, business value, and feasibility. And what we mean when we talk about the framework is that you don’t need to fill in all the blanks. There are 12 fields in the framework, but you should see it as a guiding light or a mental model of what you should focus on in product discovery.

You do product discovery already, but what techniques are you using? There might be some gaps in what you’re doing. Use the framework with your team to assess your current toolbox.

The second recommendation is to try the risk mapping technique because that could be a great start to kick off product discovery. What are the highest risks right now? And what should we do to learn?

Airtime: Thank you very much for your time, Marcus. This talk has been really enlightening.

MC: Thank you so much for the opportunity!

‍