super-product-owner

# 🧭 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

```mermaid
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:

```mermaid
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. Tactical center of gravity: backlog, sprint goals, acceptance, working with the dev team daily.

### Product Manager (the industry's definition)

A **job title defined by the market**: owns problem discovery, strategy, market understanding, pricing, positioning, and the roadmap. Strategic center of gravity: the *why* and *what next quarter/year*.

### How they relate in practice

```mermaid
flowchart LR
    subgraph Strategic["Strategic (months–years)"]
        PM[Product Manager hat<br/>vision, market, strategy,<br/>roadmap, pricing]
    end
    subgraph Tactical["Tactical (days–weeks)"]
        PO[Product Owner hat<br/>backlog, stories, refinement,<br/>sprint goals, acceptance]
    end
    PM <-->|"same person in most companies,<br/>two people in large/scaled orgs"| PO
```

Three common configurations:

1. **One person, both hats** (most startups and mid-size compa