.png)
Following our webinar with Marcus Castenfors, we did a follow-up interview with him about his holistic approach to product discovery. We talk about how to implement holistic product discovery in a new team or organization, that “fuzzy, warm feeling” of engagement it brings to everyone in the product team, and the way it can help mitigate your biggest risks. We also hear examples from his career, the early days of Spotify’s product discovery, and the benefits of continuously interacting with customers.
We’re publishing this interview in two easy-to-digest chapters for you. This is part one of our conversation.
Airtime: Thank you very much for taking the time for this interview. Can you please introduce yourself in a few sentences to the readers of our blog?
Marcus Castenfors: Absolutely. My name is Marcus Castenfors and I’m based in Sweden. I’m a product leadership coach and I work mainly with product managers, Chief Product Officers, and C-level executives on how to create effective products, making sure that it’s something that customers want, it’s something that’s feasible to build, and something that creates business value for the company. And that relates to product discovery, strategy, vision, alignment between teams, and many other facets.
Airtime: Sounds like a holistic picture. You’re also a co-founder of a startup called Hapkey. What is that company focusing on?
MC: Hapkey focuses on continuously improving teams through feedback. It’s a survey tool for team managers to understand the current pain points that the team is facing and to create action plans, so that action is happening based on insights and data. It’s something that we’ve been working on for the past three years on the side of my consulting business. So I kind of eat my own ”dog food”. I apply my toolbox of product discovery techniques to a real startup case.
42% of products fail because they don’t meet a real market need.
Airtime: In the webinar that you did with us, you started out by saying that 42% of startups fail because they don’t meet a real market need and that also half of all functionalities developed are hardly ever used. In your opinion, does this mean that even successful companies finance unused development with a handful of functionalities that are really spot on?
MC: Yes. The statistic is real not just in a startup sense, but also in an enterprise and corporate sense. There’s so much waste out there in terms of product development. And why is that the case? It’s because you’re not focusing on the right insights. What I tend to see across the globe when it comes to product development teams is that they’re mainly focusing on the features, the output, and the typical scenario is that someone above (could be a C-level or director or manager) says that “we need to do this”. And they don’t even add the “because…” They say, this is my idea, let’s just build it. And there’s hardly any insight into why that’s something useful to build.
The most successful product teams that I’ve worked with care deeply about insight, understanding customers, users, and what’s important for the business. That leads to experiments on what we think could create value for users, customers, and the business. So it’s a completely different mindset. And I see this as a clash between traditional ways of organizing or directing companies versus more modern approaches that have the mindset that everything is a hypothesis, even strategies. You need to treat everything as an experiment, and you need to collect a lot of insights in order to validate or invalidate your assumptions.
Airtime: The way you describe it brings to mind some “authoritarian gut feeling”. You say management has a hunch based on their experience, and then they just push it through. How can an organization’s culture move from A to B, from authoritarianism to insights and hypotheses?
MC: It comes from leadership. That leadership needs to have some kind of epiphany that the stuff that they’re doing right now is not creating the impact that they want. There needs to be this catalyst moment. Maybe they’re struggling, and in a way of addressing the struggle, they look at a different way of working.
A different way of working is to empower teams instead of making the decisions up top in the organization.
How to drive that change? One best practice is to start with something small. We worked with an organization about three or four years ago that wanted to drive this change. A big multinational business-to-business company. We started with one team, by understanding the team’s context right now.
The team’s context at that moment was a relay race. They had a business goal or something like that. Maybe it wasn’t even a goal that came from above. Then the product manager did some discovery around that [goal], wrote a one-pager brief, and handed over the brief to a product owner who worked with the [developer] team. The product owner created a backlog of different things to focus on and handed it over to the team. The team wrote code and was totally shielded from insights and customers, working in sprints. So that was the context that the team was in.
We tried to change that. We first recommended that the team should meet customers on a regular basis, talk to [these customers], understand their pain points and their problems, and by doing this remove the silos within the team. We planned things together. We had a joint six-week rhythm for the entire team. We planned at the beginning of that six-week rhythm what to focus on, what we wanted to learn in terms of discovery, and what we wanted to build in terms of delivery. Everybody had a joint focus from the onset of that six-week period. And the whole team was part of customer research.
The first planning cycle that we had was a bit awkward. Engineers asked the question “Why do I need to talk to customers?” because they have never done that before. “What’s the value of talking to customers?” they said. Then at each new six-week cycle, there were more smiles in the room, and more engagement, because people started to understand. “Oh wow, the customers are struggling with this, we need to work on this.”
That’s a story of change that started with one team and then that one team led to another team that led to another team, and then the whole product organization worked in this kind of fashion, of breaking down the silos and working collaboratively, working with insights. As a result, they became more data-driven and insight-driven. So that’s, I believe, a successful case study of driving change.
Airtime: Excellent. The changes didn’t only happen on the organizational level, but each person newly facing the customers had a fuzzy warm feeling as the whole thing progressed to understanding customers’ needs better.
MC: Exactly. And speaking of the fuzzy warm feeling, I was in a workshop yesterday with a client. They’re a large B2B organization as well. In a meeting with all the product managers in that organization, they invited a store manager. (They work with stores as well.) Part of that meeting was to interview that store manager to understand their pain points. Also part of that journey is to visit that store. So, everybody, all the product managers have the opportunity to go to this store, to interview customers, to talk to store managers, and people working in the store. This is the second time they’ve experimented with this kind of tactic of bringing in the store manager to the current ways of working.
A product manager said in the meeting that it’s amazing to have that opportunity to find out what happens on a day-to-day basis in that store. And it brings that fuzzy warm feeling that the stuff that you’re creating is creating value for someone else. That is a fundamental aspect that you want to foster in a leadership situation when you’re working on your product. To minimize the distance between the maker and the user, as Henrik Kniberg would put it.
Typically, there’s a large gap between the maker who’s making things (whether that’s design or user research, or engineering) and the user who is actually using the stuff that comes out.
If you can just minimize that gap, you will see amazing results in my experience, and create that fuzzy, warm feeling in the team, also called engagement. It’s engagement that you feel connected to the stuff you’re creating, I think chemically it’s called oxytocin. Oxytocin is a chemical in your brain that you get when you collaborate with people, when you feel belonging to people, and so on. It’s about increasing oxytocin, and you can do that by minimizing the gap between the maker and the end user.
Airtime: Excellent tagline for selling the idea. Get, get your natural high up!
MC: It’s a natural high, yes, absolutely. And so many people in the business world are not exposed to that because they just focus on their own thing and focus on their own team and then forget about what happens outside the team.
Airtime: You also placed a lot of emphasis on the importance of the team, different viewpoints, and bouncing ideas off each other. Can you describe a high-performing team that you worked with? What were the key qualities that made it work very well?
MC: A high-performing team is a team [where] they have each other’s backs, they take care of each other, and they care about each other. It’s a team that’s been working together for quite a while. So they understand the quirks, idiosyncrasies, and competencies of the other teammates. And they’re willing to take risks together because product development is risky.
It’s a risky endeavor because we don’t know what’s gonna happen when we produce these features or launch these designs for users and customers. Sometimes you need to take risks and in order to take risks, you need to ensure that you have a team that takes care of each other. Google did a study five, six, or seven years ago on high-performing teams. They, I think, collected data from 300 teams. And the research question was, what makes a high-performing team high-performing? What are the tenets related to that? They did interviews, sent out surveys, and they discovered that
the number one factor that makes a high-performing team high-performing is psychological safety.
That you’re willing to take risks together. You are able to talk about the uncomfortable truths.
But another core aspect related to that is that it’s a happy team. Not happy in the smiley sense, although I think it’s a good KPI, laughs are a good KPI in the team. But happy in a way that they feel their stuff is adding value. They feel like they’re respected in the team, they are happy that they have a good manager or leader, and many other aspects of what happy means to each of them. I believe happy teams lead to positive results. If you’re engaged, if you’re happy, you will do good work.
Airtime: It is interesting how many KPIs or OKRs are connected to tangible performance and unconnected to these soft states of being.
MC: Absolutely. Two colleagues of mine, Jan Grape and Matthias Skarin, they talk about the metaphor of the engine and the steering wheel. In an organization, you have a steering wheel that defines the direction of the business, where we are going. Are we going to Budapest, or are we going to London as a business? Now that’s the vision and the strategy for the company.
And then you have the engine. What’s the health of the engine? That relates to defects in digital products, time-to-market, and aspects of the products, but also if your teams are happy and engaged. Because people are the engine of the organization, especially in [the field of] digital products. Leaders sometimes forget about the engine and focus far more on the steering wheel. Where are we going as a business? What’s our strategy? What’s our vision? What’s our OKR? I think it’s very healthy to think equally about the engine, if it’s working well, and if it’s not working well, how we’re going to address that.
This was the first chapter of our two-part interview with Marcus. We’ll be publishing the second half of our conversation shortly, so don’t forget to follow us on Medium to get notified when it is out. Take care!
Copyright © 2024 Airtime UX GmbH
