The Product Model Has a Discovery Problem

There is something about the Product Operating Model that has bothered me for a long time, and I think I am finally getting closer to what it is.

It is not discovery itself. Quite the opposite. I have spent a large part of my professional life doing exactly the work the Product Model now talks so much about: observing people, interviewing, testing assumptions, working with analytics, facilitating workshops, synthesizing messy information, framing problems, prototyping ideas and continuously trying to understand whether we are solving something worth solving.

My problem is what happens when that work is described through a model that appears to have been formed in a discovery vacuum.

If your organization has product managers, engineers and designers who are primarily visual or graphical designers, somebody has to take responsibility for understanding users, investigating problems and figuring out what is worth building. Product management stepping into that space makes complete sense.

The problem starts when that particular organizational reality becomes a universal model and is exported into places where discovery was already a mature design and research discipline.

The Product Model makes perfect sense in a discovery vacuum. The problem is assuming the vacuum exists everywhere.

Where the Product Model comes from matters

Marty Cagan has never claimed that he invented product discovery. In fact, he has explicitly written that the concept existed long before he started using the term. But his earlier writing was very clear about where he believed responsibility sat: in 2008 he described product discovery as the primary responsibility of the product manager, carried out together with UX and engineering.

And Transformed gives an important clue about the organizational baseline behind the model. It describes designers in many companies before transformation as having a much smaller range of skills and being "usually graphic or visual designers." The Product Model then asks those designers to grow into a broader product-design role.

In the Scandinavian product environments I know, the history looks different. UX and digital design have long drawn from interaction design, HCI, human factors, participatory design, behavioral research and ethnographic methods. This is not just recent industry fashion. Aarhus University traces its interdisciplinary HCI tradition back to the 1970s and early 1980s, including user-centered systems development and participatory design long before the current Product Model vocabulary existed.

Many of the product designers I know are not particularly interested in being visual designers at all. Their expertise is understanding behavior, facilitating, interviewing, observing, synthesizing qualitative evidence, running usability studies and turning a complicated human situation into something a product team can act on.

For years, these people have been fighting not to be treated as pixel pushers.

The argument was precisely: bring us in before somebody decides what to build.

And that is why it feels strange when discovery now arrives back into the organization packaged primarily as a product-management capability.

Management discovered discovery

There is a slightly absurd situation I increasingly see.

A designer or researcher may have spent fifteen years working with Design Thinking, Double Diamond, continuous discovery, behavioral observation, usability studies, analytics, interviews, contextual inquiry and research synthesis. They may have studied HCI or human factors, followed Nielsen Norman Group for years, taken certifications and spent thousands of hours observing real people using real systems.

But none of that necessarily had one canonical management book attached to it.

Then somebody reads Inspired, Empowered and Transformed, and suddenly the organization has discovered discovery.

That is actually one of Cagan's great achievements. He has systematized a lot of good product practice into language that management can understand.

But packaging knowledge also affects who gets associated with it.

If management learns about discovery through books written primarily for product leaders and product managers, it is very easy for discovery to become mentally attached to the PM role. The organization doesn't necessarily look around and say: Wait. Do we already have people who are specialists in this?

Instead, the PM is sometimes left with the impression that discovery is something product management has now brought into the company.

Management finally found a book explaining why discovery matters. Great. Just don't confuse discovering the vocabulary with discovering the profession.

So who are the discovery people?

This creates a strange role problem in both directions.

I have seen experienced product designers pushed toward Product Manager roles because the organization notices that they are doing strategy, discovery, prioritization and problem framing and concludes that this must mean they are becoming product managers.

But they may not want to become product managers.

They may not want ownership of budgets, commercial targets, stakeholder politics and roadmaps. They want to become exceptionally good at understanding people, behavior, problems and opportunities.

At the same time, the opposite movement happens. PMs learn the methods of discovery and understandably start using them. That is good. PMs should talk to customers and participate deeply in discovery.

But participation and professional depth are not the same thing.

Research has depth. Interviewing has depth. Ethnography has depth. Behavioral science has depth. Qualitative synthesis has depth. Just like software architecture has depth.

If I sit in architecture meetings for two years, I may become much better at understanding architecture. I still wouldn't assume I should overrule a senior engineer on a difficult architectural question.

Why should research be different?

Shared discovery does not mean interchangeable expertise.

Talking to users is not the same as knowing how to research

This distinction becomes important because research often looks deceptively simple from the outside.

Two people sitting together talking does not look like a particularly complicated professional technique. But the difference between a useful interview and an interview that mostly confirms the interviewer's assumptions can be enormous.

Ask, "Would this feature make your job easier?" and somebody may happily say yes.

Great. Positive signal.

Except the question already contains the proposed solution, suggests that it should make their work easier and invites agreement. An experienced researcher will immediately become suspicious of what that answer actually tells us.

Observation can be even harder.

Most people are surprisingly uncomfortable simply sitting quietly and watching another person work. Silence becomes awkward, so they fill it. They explain something. Ask another question. Suggest an answer. Demonstrate that they understand.

And every time the observer does that, they risk changing what they are observing.

Sometimes the professional skill is knowing when to shut up, stay curious and eventually ask the apparently stupid question: Why did you do that? Why did you open that system? What are you looking for? What happens if you don't do this?

These things sound trivial until you have watched somebody unintentionally bias an entire interview.

That does not mean PMs cannot become excellent researchers. Of course they can.

It means reading that interviews are important does not automatically give you the methodological depth required to judge whether the research is good.

And then comes mandate

This is where the Product Trio stops being quite as balanced as the drawing suggests.

The PM usually enters discovery carrying something the other disciplines do not carry in exactly the same way: a business mandate.

There are targets, stakeholders, deadlines, commercial expectations, investments and commitments. Leadership expects movement. Somebody is responsible for making the product succeed as a business.

That is a legitimate and necessary role.

But mandate creates direction.

If I have spent months aligning leadership around an opportunity, secured investment and committed to an outcome, I am not psychologically neutral when evidence starts suggesting that the original assumption might be wrong.

Nobody is.

Confirmation bias, motivated reasoning, anchoring and escalation of commitment do not suddenly disappear because we call what we are doing discovery.

Designers are biased too. We become attached to concepts and can overvalue experience quality. Engineers have their own biases around architecture, technical risk and maintainability. Researchers have biases.

The diversity of those perspectives is part of the value of having different disciplines in the first place.

The problem is that everyone may have bias, while not everyone has the same authority to act on it.

Everyone has biases. Mandate gives one person's biases more organizational power.

Knowing enough to participate is not knowing enough to judge

There is another uncomfortable layer here.

The useful part of the Dunning–Kruger effect is not the internet version where stupid people think they are geniuses. It is the much simpler observation that limited competence in a domain can also limit your ability to accurately evaluate your own competence within that domain.

You don’t know what you don’t know.

A PM learns about interviews, hypotheses, experiments, prototypes and validation. Excellent. They are now much better equipped to participate in discovery.

But they may still not have enough methodological depth to recognize weaknesses in their own research.

The evidence has not necessarily won.

The mandate may simply have won.

The dangerous combination

The fox guarding the henhouse

This is why I keep coming back to a slightly unfair analogy: the fox guarding the henhouse.

I am not suggesting PMs are foxes and researchers are chickens. The point is structural.

If you are responsible for protecting the budget, the deadline, the stakeholder commitment and the commercial outcome, should you also be the primary authority deciding whether the evidence is strong enough to stop all of them?

Because the path of least resistance is always available.

Every one of those statements can be completely rational. Every one can be said by a smart person acting in good faith.

And they all point in the same direction:

Keep going.

If “keep going” is also the direction your mandate is pushing you, no conscious manipulation is necessary. Human bias can do the rest.

The trio needs different people

This is also why I do not think the goal should be three interchangeable product generalists.

The differences are useful.

Product management tends to reward decisiveness, commercial understanding, stakeholder navigation and the ability to create movement. Engineering rewards analytical depth, precision and technical skepticism. Research and design often require people who can tolerate ambiguity for longer, stay curious, observe before acting and resist converging simply because everybody would feel more comfortable if a decision were made.

Those working styles can irritate each other.

Good.

Sometimes that friction is exactly what protects the product.

The researcher saying “we don’t know enough yet” and the engineer saying “this is more complicated than it appears” are not necessarily obstacles to progress. They may be doing precisely what the trio exists to do.

Trust is what keeps mandate from becoming hierarchy

For this to work, the team needs something more fundamental than another process.

Trust.

Real trust is being capable of saying: I don’t understand this deeply enough to overrule you.

Design has to be able to say that to engineering. Engineering has to say it to design. Product has to say it to both.

In a high-trust team, a PM hearing a researcher push back hard can think: There is probably something here I don’t understand yet.

In a low-trust team, the same conversation becomes: I understand your concern, but I am accountable for the outcome.

And mandate wins.

That is why companies can adopt all the language of empowered teams while continuing to behave exactly as they did before. If they still reward control, certainty, micromanagement and the ability to push decisions through the hierarchy, adding product vocabulary does not magically produce trust.

You just end up with old behavior using newer words.

AI makes this more important, not less

AI is now making the boundaries between professions much easier to cross. I can generate code. A PM can build an interface. An engineer can create an interview guide. A designer can make a financial model.

That is mostly a good thing.

But access to another profession’s tools is not the same thing as acquiring its judgment.

AI can make biased research questions look professional, unsupported product thinking look like a finished application and terrible architecture execute successfully enough to impress somebody in a demo.

The output can look competent long before the person has enough experience to judge the output.

So I am not particularly worried about people crossing professional boundaries.

I am worried about crossing those boundaries while retaining the authority to overrule the specialists who live there.

And yes, I have skin in this game

There is an obvious criticism of everything I have just written.

I am a designer who has spent a large part of my career doing discovery.

Of course there is a danger that this sounds territorial: The PMs are taking our work. Give it back.

That is not what I want.

If a PM is better at discovery than I am, they should lead it. If an engineer understands a particular user problem better than the designer, listen to the engineer. Titles should not protect mediocre expertise.

And I do not particularly want the PM mandate either.

That is actually part of my point.

There are people who want to spend their careers becoming extremely good at discovering problems, understanding behavior and turning evidence into product direction without also becoming responsible for budgets, commercial targets, stakeholder management and roadmaps.

They should not have to become Product Managers simply to retain influence over discovery.

Maybe some of my irritation is territorial. Watching organizations suddenly recognize work you have been doing for decades because it has now been packaged through another discipline can be frustrating.

Being biased does not automatically make the observation wrong. It means I need to be clear about what I am defending.

I am not defending a title.

I am defending discovery as a professional capability in its own right.

And I think we should be careful not to erase the people who already specialize in it simply because management finally found a model that explains why their work matters.

An empowered product team should not be built around the person with the broadest mandate. It should be built around different expertise, with enough trust to know when your own mandate needs to get out of the way.