Product management frameworks that actually hold up: Cagan, Torres, Norman and the discipline's real foundations

Product management is a young discipline wearing borrowed vocabulary from engineering, design and general management, and much of what makes it confusing is that the people who built it were often solving a specific organisational problem rather than writing a textbook. Marty Cagan watched teams inside Netscape, eBay and HP get handed roadmaps instead of problems, and spent years afterward documenting what the alternative actually looks like in practice. Teresa Torres watched product teams treat customer research as an occasional event rather than a habit. Don Norman gave the field a vocabulary for why some products feel broken even when every feature technically works. This guide takes the discipline's genuinely load-bearing frameworks, one at a time, with a worked scenario and an honest account of where each one breaks down.

Empowered teams and discovery over delivery

Cagan's central distinction, developed across decades inside and around Silicon Valley product organisations, is between a feature team that receives a prioritised backlog and executes it, and an empowered team that receives a business problem and is trusted to discover the right solution itself. The structural difference is not effort or talent; it is where the judgement about what to build actually sits.

A worked scenario: a company's churn is rising in a specific customer segment. A feature team's response is to look at the support queue for the most requested fixes and schedule them. An empowered team's response is to talk to churned and at-risk customers directly, form a hypothesis about the actual driver (often not the most-requested feature at all), and test a narrower intervention before committing engineering time to a broad fix. The empowered team may ship less in the same quarter and still solve more of the actual problem.

Where it fails: empowerment requires an organisation willing to tolerate a team discovering the "wrong" answer to a stakeholder's assumption, which is a genuine cultural cost many companies are not actually prepared to pay despite saying they want empowered teams. Cagan has been candid in later writing that most companies that adopt the vocabulary of empowerment do not restructure the actual decision rights that make it real.

Continuous discovery habits

Torres's framework replaces the discrete research sprint, a dedicated multi-week phase before a big redesign, with a standing weekly habit of short customer conversations that never stops, regardless of what's currently being built. The underlying claim is that opportunity awareness decays quickly; a team's mental model of its customers goes stale within weeks, not quarters, and periodic research just means the team is stale for the interval between sprints.

A worked scenario: a product team building a new onboarding flow runs quarterly usability studies before major releases. Under continuous discovery, the same team instead runs three fifteen-minute calls every week with recent signups, regardless of whether onboarding is the current focus, so that when priorities shift the team already has a current, not stale, picture of where the actual friction sits.

Where it fails: continuous discovery assumes a customer base willing and available for frequent short conversations, which is a much easier assumption for a consumer product with a large user base than for an enterprise product with a handful of accounts, each conversation requiring account-management coordination and carrying real relationship risk if handled clumsily.

Escaping the build trap

Perri's diagnosis is that many product organisations measure exactly the wrong thing: output (features shipped, velocity, story points) rather than outcome (whether the shipped work moved a metric that matters to the customer or the business). The build trap is dangerous precisely because it is invisible from inside a busy team; velocity looks healthy, the roadmap looks full, and nobody notices that none of it is changing the numbers that were supposed to justify the work.

A worked scenario: a team ships twelve features in a quarter, hits every sprint commitment, and retention is flat. Under output measurement, the quarter reads as a success. Perri's framework asks a different question at the retro: which of the twelve features moved retention, and if none did, what does that say about how the roadmap got built in the first place, likely from a stakeholder wishlist rather than a validated problem.

Where it fails: outcome measurement requires outcomes that are genuinely measurable on a reasonable timeline, which is straightforward for a fast-moving consumer product and much harder for enterprise software where the relevant outcome (a customer's business result) may lag the shipped feature by quarters, making the output-versus-outcome distinction correct in principle and difficult to operationalise in practice.

Affordances and feedback

Norman's foundational design research, developed across his career including time at Apple, established the vocabulary that every product designer now uses whether or not they know the source: an affordance is what an object's design signals it can do, and feedback is what confirms to the user what just happened after they act. A door with a flat plate signals push; a door with a handle signals pull; a door with a handle that actually needs pushing is what Norman calls a design failure people blame on themselves rather than the door.

A worked scenario: a save button that gives no visual confirmation after being clicked produces users who click it repeatedly, unsure whether the action registered, then worry the extra clicks caused duplicate saves. The fix Norman's framework prescribes is not a better button; it is immediate, unambiguous feedback that the action was received and completed, which removes the uncertainty at its source rather than adding instructions to compensate for it.

Where it fails: affordance design assumes a physical or visual vocabulary the user already shares, which breaks down across genuinely novel interaction patterns (a new gesture, a new interface paradigm) where no existing convention exists to signal correctly; in those cases, the framework correctly identifies that a problem exists but offers less guidance on what the new affordance should look like.

Positioning before building

Dunford's contribution sits earlier in the process than the frameworks above: before deciding what to build, decide who you are being compared against and which specific attributes make you the obvious choice for the customer holding that comparison in mind. Positioning done properly changes the roadmap, not just the marketing copy, because a team that knows precisely who it serves makes sharper trade-offs than one still trying to be broadly appealing.

A worked scenario: a project management tool competing against generic spreadsheets for a specific vertical (construction site management, say) makes very different roadmap decisions once positioned against that specific alternative than a team still positioning itself as "better than Asana," because the features that beat a spreadsheet for a site manager are not the same features that beat a competing project tool.

Where it fails: positioning requires genuine category discipline, saying no to adjacent segments that would dilute the position, which is a difficult commercial call for a growth-stage company under revenue pressure to say yes to any customer willing to pay, even one outside the chosen position.

Badass users and skill over satisfaction

Sierra's framework, developed from years of working with technical audiences on tools like Java and later on game design, argues that satisfaction is a weak predictor of retention and that skill is a strong one. A user who has become genuinely capable with a tool, able to produce results they are proud of, has a switching cost that a merely satisfied user doesn't: leaving means losing accumulated competence, not just finding an equally pleasant alternative.

A worked scenario: two onboarding flows for the same software product. One optimises purely for ease, hiding complexity so the new user never feels friction. The other deliberately teaches a few slightly harder but more powerful capabilities early, accepting a rougher first session in exchange for a user who becomes visibly more capable within the first week. Sierra's framework predicts the second cohort retains better, because their growing skill becomes a reason to stay that pure ease never creates.

Where it fails: skill-building onboarding requires a product with genuine depth to grow into; applied to a simple utility with no real skill ceiling, the framework has nothing to build toward, and the ease-first approach is correctly the better design for that category of product.

Discovery, design and positioning are not competing layers

The most common mistake in applying these frameworks is treating them as alternatives to choose between. Cagan and Torres answer which problem to solve and how to keep discovering it; Norman answers how the chosen solution should behave once built; Dunford answers how the product should be understood relative to the alternatives customers are actually weighing. A team using only the design layer builds something usable that solves the wrong problem. A team using only the discovery layer finds the right problem and ships something confusing. All three layers are addressing different failure modes, not competing for the same job.

---

The Product Leader category collects these frameworks, and others including Julie Zhuo, Ken Kocienda and Kathy Sierra, as downloadable .md files for Claude, ChatGPT or any LLM. If you're heading into a specific high-stakes product or strategy call rather than building general fluency, Decision Brief is a $79 tool built to structure that decision before the meeting.