/super-product-owner

name: super-product-owner
description: "Complete Product Owner / Product Manager capability — a wiki-style knowledge map of product practice in active software development: the role and its boundaries, strategy cascade (vision → OKRs → roadmap → backlog), continuous discovery, backlog craft (epics, INVEST stories, acceptance criteria), prioritization frameworks (RICE, MoSCoW, Kano, WSJF), sprint delivery, metrics (North Star, AARRR), stakeholder management, and anti-patterns. The PO/PM owns what gets built, in what order, and why — including the end-to-end user flows and user journeys. Use when scoping a product or feature, decomposing an idea into outcomes/epics/stories, prioritizing a backlog, defining an MVP, mapping user journeys, measuring success, or saying no to a stakeholder. Pairs with super-ui-ux-design, which owns how each screen looks and behaves."

🧭 The Full Schemata of Product Owner / Product Manager

(in Active Software Development)

> Same format as the UI/UX schemata: a wiki of linked nodes with Mermaid diagrams. Build the schema, then go get it broken by real stakeholders, real engineers, and real users. > > Internal links like [Prioritization](#-node-5--prioritization-the-core-craft) jump between nodes. Mermaid renders in Obsidian, GitHub, and Notion.

---

🌉 Bridge — Where This Skill Sits (Read First)

This is the **upstream half** of a two-skill pair. The `super-ui-ux-design` schemata governs *how the product looks, feels, and converts*; this one governs *what gets built, in what order, and why* — the decisions that exist before a single screen is sketched. On a real build you wear both hats in sequence: the PO/PM hat chooses the outcome, the slice, and the order; the design hat shapes its surface. When the question is scope, priority, or value, you are here. When the question is the interface, go there. The two documents deliberately rhyme — same wiki-of-nodes format, same constructivist spine — because they are one schema with two layers: Kano's basics mirror the UX Hierarchy of Needs, discovery's ~5-user tests are Node 5 of the UI/UX schemata, and "outcome over output" is the product-level twin of "aesthetics is a multiplier, not a substitute."

One boundary deserves stating up front because teams get it wrong constantly: **the Product Owner / Product Manager is responsible for User Flows and User Journeys as well.** The end-to-end journey — how a user discovers the product, enters it, moves through each core task, hits the moments of value, and comes back — is product territory, not a design afterthought: the journey *encodes what the product is*. The PO/PM owns that the steps exist, connect, and serve the outcome (journey maps, flow definitions, the path through every capability in [Node 0](#-node-0--what-is-this-role-actually)'s scope); the designer, through `super-ui-ux-design`, owns how each step on that path looks and behaves. A beautiful screen inside a broken journey is a well-decorated dead end — and that failure belongs to the PO, not the designer.

With that frame set, build the schema below.

---

🗺️ The Master Map

mindmap
  root((PRODUCT<br/>OWNER / MANAGER))
    The Role
      Value maximizer
      Decision owner
      PO vs PM vs PjM
      Desirable · Viable · Feasible
    Strategy Layer
      Vision
      Product Strategy
      Roadmap
      OKRs
    Discovery
      User research
      JTBD
      Opportunity Solution Tree
      Assumption testing
      MVP & prototypes
    Delivery
      Backlog management
      User stories & epics
      Sprint events
      Definition of Ready / Done
      Working with engineers
    Prioritization
      RICE / ICE
      MoSCoW
      Kano
      WSJF
      Value vs Effort
    Measurement
      North Star Metric
      AARRR funnel
      Leading vs lagging
      Retention & churn
    People Layer
      Stakeholder management
      Saying no
      Communication
      Anti-patterns

---

🎯 Node 0 — What Is This Role, Actually?

**One-line definition:** The Product Owner/Manager is accountable for **maximizing the value** the product delivers, by deciding **what gets built, in what order, and why**, and by being able to defend that "why" with evidence.

Notice what's *not* in the definition: writing code, managing people, drawing UI, running ceremonies. The role owns **decisions and outcomes**, not execution.

The cleanest mental anchor comes from Marty Cagan (*Inspired*): your job is to discover a product that is simultaneously:

flowchart TD
    V[VALUABLE & VIABLE 💼<br/>Users will choose it,<br/>and it works as a business:<br/>revenue, cost, legal, brand] --> P((The product<br/>worth building))
    D[DESIRABLE ❤️<br/>Users actually want it<br/>and can use it] --> P
    F[FEASIBLE 🔧<br/>Engineers can build it<br/>with the time, tech,<br/>and skills available] --> P
    P --> O[Shipped OUTCOME,<br/>not just output]

Miss any leg and you get a classic failure:

| Missing leg | What you ship | |---|---| | Desirability | A technically impressive product nobody asked for | | Viability | A beloved product that bleeds money or breaks the law | | Feasibility | A beautiful roadmap that never ships |

> 💡 **Output vs outcome** is the single most important distinction in this entire document. *Output* = features shipped. *Outcome* = behavior changed, problem solved, metric moved. Teams that measure themselves by output become [feature factories](#-node-9--anti-patterns-how-this-role-goes-wrong). Everything below exists to keep you on the outcome side.

**See also:** [Strategy cascade](#-node-2--the-strategy-cascade), [Metrics](#-node-7--measurement-how-you-know-it-worked)

---

🪪 Node 1 — PO vs PM vs Everyone Else

The titles are messy in the real world. Here's the schema to untangle them.

Product Owner (Scrum's definition)

A **role defined by the Scrum Guide**: one person accountable for maximizing product value, primarily through managing the Product Backlog