My name's Paolo Lacche and in this article, I’ll discuss product discovery, what it means for a company, and how to tackle it at scale.

Product discovery is a very hot topic right now, in my view, together with OKRs and product metrics. It's one of the top three trends in product management. In this article, I’ll walk you through managing product discovery in theory versus reality, the decision-makers involved and understanding the dynamics at every level, and finally the metrics you can employ during the process.

Instead of treating it as the next buzzword, let's start by looking into it as something to be taken seriously, and what it actually means for an organization.

What is product discovery good for?

I'm sharing with you the feedback I've collected over the past few years working with several product teams in different types of organizations about product discovery.

We all know this is something we need to build great products people love. But I hope from this line, you start getting a sense of the complexity of the matter, which is actually tackling multiple problems within a company.

I'm sure you'll recognize some of these challenges.

Scaling product discovery

The goal of this article is not to go through product discovery methodologies, but rather to give you a direction of how to successfully set up product discovery at a company level at scale.

Especially focusing on these three areas, which in my experience, are the most overlooked by product leaders and company co-founders when dealing with product discovery.

Managing product discovery always makes sense in theory...

Let's start with the theory. What is there?

Ideal dual track agile

We've all seen this one, it's a neat, simple picture, you have a track for discovery, a track for delivery.

But how do you make that happen?

Without even considering the fact there's another dimension of complexity, I'm not going to encompass in this article, which is doing OKRs properly. Even if it's a very risky assumption, I will actually take for granted that you already do that part.

Product managers ideal focus

Another slide is about actually getting the expectation on what should be the outcome of establishing product discovery at a company. We all see this, we're all familiar with this one.

But are we actually expecting product managers to spend 80% of their time or the majority of their time in discovery?

Probably in an ideal world, but having coached 100s of product people in my career, I know they usually spend 150% of their time on product delivery, plus 70% of their time on meetings and Excel spreadsheets.

We're already above the 200% line and whatever is left is then used to be talking to customers and perhaps sleeping.

The question is, what's the real expectation not just the ideal one, and how do we trade this off?

Managing product discovery: theory vs. reality

The discovery flow

Let's start tackling the real world versus the ideal world starting with the flow. As I mentioned, product discovery is not something we need to do locally for a team, but we need to establish locally and globally at a company level.

The only way to do that properly is to start with designing our discovery flow.

Now, this is a very simple one in this example, but it's already something you start using. I'll give you a couple of hints on that.

What’s upstream?

The first one is, you need to consider what's upstream from this flow. This is, for instance, flowing which ideas or product ideas, which is not uncommon at all, are actually informing the discovery flow.

And of course, once again, keep in mind upstream from ideas we have, of course, objectives and OKRs.

What's the problem with that?

There are essentially three problems.

The first one is the real flows look, unfortunately, like this one.

Somebody has a brilliant idea, usually a feature, they go directly into building it, planning is done on the go and of course, plan expectations are never actually met.

Design usually comes at half of the way, where you see there ‘build more’ and only after you ship something, finally, you start seeing how users behave compared to that feature.

Most of the time, unfortunately, teams discover users didn't need that feature at all. That's the first problem we have.

Input and output

Two more are actually about the input and output of the discovery flow. So I start tackling the big elephant in the room, which is ideas.

I have nothing against the word ideas. It's a word I'm going to keep using during this article. But we need to make crystal clear what that means in the context of discovery.

We need to make that explicit and that word has only two possible meanings in this context; problems or solutions. We either work on problems, or we work on solutions.

The output of your discovery flow is valid problems and valid solutions.

That's the second thing to make explicit.

Not a linear process

The third problem with it is that unfortunately, this is not a linear process. It's not as simple as starting with a problem, validating it, creating a solution for the problem, validating it, awesome, let's plan it and build it.

Unfortunately, you need to do usually multiple iterations on product discovery, for instance, in terms of A/B testing for a solution, or user interviews, in order to refine your problems and solutions until you're able to make a decision on that, and decide if you want to build that solution or not.

Product discovery = decision making

This brings me to the second part of this article, which is about the decision-making mechanisms that happen in product discovery.

The decision-making ecosystem

Let's start to see the actors of the decision-making.

You

PMs in the first place, for sure. Unfortunately, in some cases, they even misuse their position in order to just make direct calls based on their opinions on what we should build in the product.

Stakeholder management

If we zoom out from the PMs, there's another set of folks. Usually, this is called stakeholder management.

I don't like the wording for exactly this context because for product discovery, these people are actually people working with you in a capacity of a different business function, and helping to build you a great product because they have also collected great ideas on the product itself.

Rather than stakeholder management here, the focus should be on orchestrating the decision-making across all these ecosystems.

If you look at this image, as a single product team, it's usually already a pain to orchestrate it at this level for a single product team. What I'm discussing in this article is actually to make it happen even on a larger scale.

How do we do that?

Stakeholders in the discovery loop

So let's get back to the flow. This is a more abstract picture, but essentially depicting the same concept of the discovery flow I shared before.

I put stakeholder there in the beginning, as you can see, stakeholders and objectives are upstream from ideas.

What we need to keep in mind here is there is a decision-making point at every step of the flow.

Initially, you need to decide and negotiate and agree on the objectives with your stakeholders.

  • You need to select those problems and those solutions which are promising and you want to go after and explore further.
  • You need to make a decision to understand whether the solution is ready to be built and even to decide which one to be first and to ship to users.

Decision-making and innovation capability

When we do that, as we mentioned before, the more people we involve in the company, the better it is. Why?

Simply because people generate more ideas.

So we tend to leverage the whole innovation capability of the whole company.

You can see that one, for instance, is just the VP of User Experience and that many as the few user researchers in a company. Some companies delegate the task of innovating and discovering to just that.

So you can see that one just as a CEO and a few executives, again, it's one or one plus many. If you look at the yellow footprint in this image, you can already understand that everyone is better.

How do you get to involve everyone?

Decision-making frameworks

You consider those stages in decision-making in the flow, and you make that explicit.

In this example, for instance, there's a simple decision-making framework which is actually reflecting pretty much my philosophy.

PM & team

I like to delegate to each and every product team rather than just to a few people, a few executives, a few researchers, doing experiments and researching and continuously discovering on their product area.

Give them some bandwidth to do so, give them some margins to do so, and give them even some decisional power for, for instance, discarding non-promising areas rather than taking small risks and building some features which are low budget without approval.

Area or Tribe

Then, of course, at the product area, or the tribe level, you can approve large initiatives that require multiple teams.

Company

Again, at the company level, you will confirm the budget for these product areas, and approve higher risk initiatives.

The decision-making framework, if you get one take away from this, is not just local, not just global, it goes throughout the whole organization, and it needs to be made explicit and it needs to be part of your discovery flow.

Decisions bypassing discovery

Let's tackle the last elephant in the room about discovery, which is there's not just the happy path.

There can come an executive or a business owner saying "Just fucking do it", and imposing or dictating to build something.

This is something that in the real world, we have to consider and we have to model into the discovery flow.

Who should fix this mess?

Managing the discovery flow

The person who will need to manage that is actually, in my view, a product leader.

So the product leader is not the person feeding most of the ideas for the product, as sometimes unfortunately it is meant for, but it's actually the person managing the discovery flow.

Again, what does managing mean? (And by the way, managing and setting up, of course, setting up as I'm discussing here). Managing especially means measuring, what we can measure in the discovery flow in order to measure it properly as product leaders.

Managing product discovery: from puppets to masters

This is an example of a super simple discovery flow.

Stakeholders’ SteveJobsness

I'll introduce the concept of what I call the SteveJobness of certain business owners and stakeholders.

We have the happy path on the upper side and then somebody can come and say, "Hey, this goes into JFDI. And let's do it without questioning if it brings value, which value it brings, if it fixes and actually solves a real problem, valid problem users have".

What I do here is I tag that item, I still build that item but I tag it with the Steve Jobs in the company who actually made that call.

Again, it goes into the bunch of greenlighted ideas and it's being planned.

So that at the end of it, we're going to end up with certain valid ideas that we build because of data we collected during discovery, certain ideas we discarded because of the data, and certain others that are part of the JFDI path.

Each one with the name of the business owner or the stakeholder that had the brilliant idea.

For me, when I think of managing this, it's extremely important as a product leader to understand what's the split of this.

This brings me to the first metric of product discovery flows; discovery versus JFDI.

Discovery vs. JFDI

This is an example of some real data anonymized from some of the product teams I was working with in the past.

You can see that actually starts from being pretty much the opposite of that 80/20 we saw in the reality, actually, less than 20% here is being through discovery.

But at least you measure that and you visualized that, and then you can make an effort, month after month to improve that.

Yes, unfortunately, it does take months to get this improvement. But you can see already here, there's a positive trend and we reached out to almost a 60/40 split of discovery versus JFDI.

This means more and more ideas are actually going in this case for this product team, for this organization, through the happy path.

The other side of the story

The second metric for product discovery flows is about looking at the end of the story.

Again, we have the happy path, we have the JFDI, and we plan certain ideas, but we know after shipping them, which one of those were actually successful, and which one of those are actually things users don't need.

We also know having tagged those ideas with the discovery data, or with the business owner and stakeholder, where do they actually come from?

All you need is two balls

Which brings me to the second metric of failed features versus successful features.


Failed features vs. successful features

Again, this is real data from some other teams I was working with in the past and what you can see here is:

  • The majority of the failed features come from the JFDI path. And
  • The majority of the successful features are those going through the happy path of discovery.

This is, at the same time making you understand that actually 20% of the calls made by executives, in this case, were real calls that had a business impact that users and customers are actually buying.

But also it gives you leverage and pushing how to say no if they tend to abuse the JFDI shortcut too much.

Recap: discovery at scale

When you want to establish discovery at scale for the whole company, you need to start from the floor, you need to start understanding that.

You need to step back as a product lead from being the decision-maker and actually wear the hat of being a decision-maker that needs to orchestrate decision making within this flow with all other stakeholders.

And you need to establish metrics for the discovery flow itself in order to manage it properly.


Thank you.