Using Product Management

Overview

Product management as standing ownership is not writing a PRD, running a backlog, or attending the standup. It is holding a falsifiable bet about what is worth building, for whom, and why — then proving across many sessions whether that bet paid off — without losing continuity, rubber-stamping every request, or taking an irreversible step a human should have gated. A skillpack is stateless guidance; ownership is inherently stateful. The hard part is therefore continuity, decision provenance, and an authority boundary — not PM trivia.

Three distinct jobs get conflated, and this pack draws the line hard because the failure modes differ:

• Product — what / why / for-whom / did-it-work. Decide the bet and its falsifiable success criteria; specify it; verify value actually landed. This pack.
• Program — delivered-predictably. Sequence and deliver the committed bet: flow, forecast, WSJF, scope control, coordination, RAID, benefits tracking. /program-management.
• Engineering — build-it. Architecture, implementation planning, code. /solution-architect, /axiom-planning, and the language-engineering packs.

The seam that defines this pack, stated once and load-bearing everywhere:

Product decides the bet + the falsifiable success criteria → program sequences and delivers it (flow, forecast, WSJF, coordination) → product validates that value landed.

Owning a product means running an operating loop every session — RESUME → ORIENT → DECIDE → DISPATCH → ACCEPT → CHECKPOINT — against a git-versioned product workspace (default docs/product/, configurable) with five standing artifacts: vision.md (purpose, who it serves, what it refuses to be, and the explicit authority grant), roadmap.md (Now/Next/Later bets as intent; sequencing handed to program-management), decisions/ (append-only Product Decision Records: context → options → call → rationale → reversal trigger), current-state.md (the resume brief), and metrics.md (north-star + guardrail, each with a falsifiable target). The tactical backlog stays in the product's existing issue / case-management system via a thin adapter — workspace files reference tracker IDs, they never duplicate the backlog. The loop, the artifact schemas, and the authority boundary are specified in the two spine sheets; this router names them and routes you there.

The most common product failure is the build trap: mistaking shipping features for delivering value. A team can ship the whole roadmap, close every ticket, and move no metric anyone cared about — because success was defined as output, the bet was never falsifiable, and nobody validated that value landed. This pack exists to make the bet explicit, the success criteria falsifiable, the decisions provenanced, and the validation real.