Most Scrum teams aren't ready for a discussion about product discovery

The mission of our team is to help agile software development teams building the right things from an entrepreneurial perspective. Our background is not in “product management”, but in start-ups.

While there is a big overlap between the two, my experience with full-fledged product discovery is pretty limited. I’ve been helping teams in bigger companies adopt discovery for a year now.

This is not much, but I’ve conducted over 50 interviews, too. This gave me the opportunity to study many teams with an outside perspective. Many of them appreciated this outside perspective, as they’ve been caught up in the daily routine.

Yes, you got it right, we do discovery interviews about discovery – Meta, right?

You might think, why this story is relevant to you? Our first goal was to introduce a continuous discovery approach into companies, so they figure out the right things to build. But we learned this might not be the best first step.

If you want to introduce discovery in your company, you might get a better perspective what you should focus on.

Do teams need help in prioritising the right features or gather data to make an informed decision?

We started with the research goal of how product teams are prioritising what to build today. Our hypothesis was, that they had no data to make informed decisions.

Our research has confirmed our hypothesis. The problem is, that we formulated a hypothesis prone to confirmation bias. Product owners didn’t have any data to prioritise right, but it wasn’t a concern to them.

Their #1 problem is stakeholder management.

Their de facto job is gathering the needs and wants of different stakeholders. Then they have to build consensus between them and map that consensus to the backlog.

The product owners have little say in the discussion about what to build.

What is their goal?

Glad we realised quite fast, that we were asking the wrong question.

So we shifted our research focus to the goal of the team. Our next hypothesis was: We can show teams that they can improve what to build to have a bigger impact on their goal. But asking for their goals was pretty hard.

We tried different framings:

• What is the current goal your team tries to accomplish?
• What does success look like for your team?
• How is your performance assessed by management?

We struggled to start a valuable discussion with these questions.

Turns out, most companies neither have a good strategy nor good goals defined. The team's performance was assessed on velocity of features shipped and a subjective assessment of how good the product was. When the business metrics like revenue over all teams weren’t healthy, pressure increased to ship more or better features.

So, we shifted our research to defining strategy and goals to have a basis for product management.

Helping the teams define their goals

Research goal #3: How are companies defining their strategy and goals?

This question is a tough nut to crack. Our network consists mostly of individual contributor (IC) but not product leaders. Yet, most of this process happens on the leadership level. Talking to the IC level was still helpful.

The product teams had little say in the strategy.

The leadership communicated mainly features to build as the result of the strategy. And they didn’t ask for any input. Speaking to leaders, there was often no problem-awareness.

Problem-awareness is necessary for us to help these teams. So, our research shifted another time.

Symptoms of missing strategy

Helping teams with strategy is such an unspecific and broad promise.

So we need to understand the problems a missing strategy causes. One obvious to us is missing focus in your work, so you can outperform the competitors in the market you choose. But this seems to be non-obvious to these teams and their leaders.

Researching the different symptoms and connecting the dots is what I focus on right now.

We already observed some. Increased pressure on development teams because the business goals aren’t met. Uncertainty how to improve business performance in the next quarter. Implementation of features for just one customer.

I’m pretty excited how the more complete picture will look like.

Conclusions

We are really peeling layers of an onion here with our discovery work.

One approach would be to focus on the teams, who already want to implement discovery. We found some and are working with them. Even if they’re lacking a strategy, discovery helps them to ask the right question and establishing strategic thinking.

But we don’t double down on them because we intend to transform how our industry works.

My team is part of a software service provider. We are developing software agile for our clients and help them adopt an agile mindset. We want to serve them even better by help them to adapt the product mindset.

What is your experience in establishing strategic thinking? Where are you in your journey? Would love to grab a coffee.