If you ask me what I believe about product management, the honest answer is that most of it is downstream of two bodies of work. Marty Cagan and the Silicon Valley Product Group's product operating model — the argument, made across Inspired, Empowered, and most directly in Transformed, that the way strong product companies work is a coherent system rather than a set of ceremonies. And Teresa Torres's Continuous Discovery Habits, which takes the fuzziest part of that system and makes it a practice you can actually schedule.
I'm not going to pretend to improve on either. What I can offer is what happens when you try to install them in a company that didn't grow up that way — which, in enterprise software, is nearly every company. The frameworks are not the hard part. The hard part is that both of them are, underneath the diagrams, a demand that decision rights move.
What the operating model actually asks for
Strip the model down and it makes three demands.
Teams get problems, not feature lists. Cagan's line about missionaries rather than mercenaries gets quoted so often it's gone soft, but the operational content is sharp: if the team's input is a prioritized list of things to build, no amount of autonomy language changes what they are. A team that cannot alter what gets built in response to what it learns is a delivery team. That's a legitimate thing to be. It is not an empowered product team, and calling it one mostly teaches people that leadership words don't mean anything.
The four risks get addressed before the build, not after. Value, usability, feasibility, viability. The insight that took me longest to internalize is that viability is the one enterprise organizations skip. Value and usability get attention because designers and PMs care about them; feasibility gets attention because engineers will simply refuse. Viability — will this work for the business, can we sell it, price it, support it, defend it — tends to get deferred to a go-to-market conversation that happens after the thing exists. That's how you get technically excellent products nobody will pay for.
Leadership owes the team context, not answers. Vision and strategy are the leader's job. Solutions are the team's. Most organizations that fail at this fail in one of two directions: leaders who hand down solutions, or leaders who hand down nothing and call it trust.
What continuous discovery actually asks for
Torres's contribution, for me, is the word continuous. Discovery as a phase is a thing you finish. Discovery as a habit is a thing you maintain, and the difference shows up in the calendar: a weekly touchpoint with a customer, run by the trio building the product — product manager, designer, engineer — not by a research team who deliver findings to them.
That detail about who does the interviewing is not a logistics preference. It is the whole mechanism. Insight that arrives as a document gets read; insight that arrives as a customer struggling in front of you while you're the one who built the thing gets acted on. When engineers hear the problem directly, the design conversation starts in a different place.
The opportunity solution tree does the other half of the work. Start from a desired outcome, map the opportunity space you heard in interviews, put candidate solutions under specific opportunities, and test the assumptions underneath. Its real function is discipline: it makes it structurally awkward to justify a solution that isn't attached to an opportunity that isn't attached to an outcome. Most bad roadmaps would not survive being drawn this way.
Empowerment without context isn't trust. It's abandonment with better branding.
Where I've watched this go wrong
Years ago I took over a group of data products at an engineering-led company. The engineering talent was genuinely excellent. The problem was that excellence was aimed by internal conviction — technically impressive software solving problems customers turned out not to be willing to pay to have solved. Nobody was being lazy. The organization simply had no mechanism for a customer's reality to change what got built.
What worked wasn't announcing an operating model. It was making one trio — PM, designer, engineer — run customer conversations together, weekly, and then giving that trio the authority to reprioritize their own roadmap based on what they heard. The authority part is what made it real. The first time a team kills a nearly-built feature because of what four customers told them, and leadership backs them publicly, discovery stops being a reporting exercise. Growth followed, and the reprioritized roadmap looked meaningfully different from the one we'd inherited — but the durable change was that the argument in the room shifted from who was most senior to what we'd heard.
The failure mode I see more often is the opposite: the ceremony installs and the power doesn't. Teams hold weekly interviews, produce a tidy opportunity tree, and then build the roadmap that was already committed to a customer in a sales cycle nine months ago. Discovery theater is worse than no discovery, because it consumes real hours and produces a false sense that the organization is listening. If you want a diagnostic, it's this: name a decision that changed in the last quarter because of something a team learned in an interview. If you can't, you don't have continuous discovery. You have a recurring meeting.
Where I'd push on the canon
Weekly is a target, not a virtue. In enterprise B2B, the person who uses your product and the person who buys it are different people, and access to both is mediated by account teams with their own incentives. Insisting on a literal weekly interview when the cycle genuinely doesn't support it teaches teams that the practice is unrealistic. What I hold teams to is the property behind the cadence: no more than a couple of weeks between a team member and a real user, whatever form that takes — a scheduled interview, a support call listened to live, a session watching someone work. Fetishize the contact, not the calendar invite.
Prototyping got cheap, and that changes the sequence. Both frameworks were written when building something real was the expensive step, which is why they invest so heavily in deciding what to build before you build it. When a working prototype takes an afternoon, the prototype becomes a discovery instrument rather than the output of discovery. On the AI platform work I do now, the fastest way to learn what a capability needs to be is frequently to ship a deliberately small version of it into a real workflow and read what breaks. That isn't a license to skip discovery — you still need the outcome and the opportunity named first, or you're just producing demos. But "build the small real thing to find the gaps" now belongs in the discovery toolkit alongside the interview, and neither book quite says that.
Not every team should be empowered yet. This is the unpopular one. Empowerment assumes a team that can hold a problem, and some teams — new, thin on product judgment, missing a designer — can't yet. Handing them a problem and walking away produces failure they'll reasonably read as a betrayal. The honest move is to name where a team is, be more directive than the model likes for a while, and be explicit that it's temporary and what would change it. Pretending a team is empowered is not kinder than telling them the truth.
What's left when you take the frameworks away
Both bodies of work point at the same underlying thing, which is that good product organizations have a short, unbroken path between a customer's actual problem and a decision about what to build. Everything else — the trio, the tree, the touchpoints, the four risks — is machinery for keeping that path short and keeping it honest.
When I evaluate a product organization, mine included, that's the question I'm actually asking. How many translations sit between a user's difficulty and the person who can change the roadmap? Every one of them is a place where the signal gets rounded off toward what the organization already wanted to do. The frameworks are good because they remove translations. Adopting their vocabulary while leaving the translations in place is how a company gets to say it's product-led while shipping exactly what it would have shipped anyway.