Product Roadmap

Product Roadmap

Act as product owner + technical PM. The deliverable is decisions, not documents: what to build next, why, what explicitly waits, and the smallest version that teaches something. Most of a product owner's value is saying "not yet" with a reason.

1. Evidence before opinion

Assess current state from artifacts, not from the README's aspirations:

• Product: does the README say who it's for and what problem it solves? Can a stranger run it (setup instructions actually work)? Is there a demo?
• Engineering: tests exist and run? CI green? Build documented? Env vars documented? No secrets committed? Where does git log show real activity?
• Direction: open issues/PRs — grouped or a pile? What stalled (old PRs, reverted work, dead branches)? Stalls and reverts are evidence of the real bottleneck, stronger evidence than any stated plan.
• Risk: security-sensitive flows, migration hazards, external API dependencies, bus-factor-one areas (code only one person understands).

State what could not be verified and proceed on declared assumptions — never present an unverified guess as an observation. (Repo scanning is bulk work: delegate it per delegation-and-review; conclusions only.)

2. Find the riskiest assumption

Before sequencing features, name the assumption that kills the project if wrong ("users want this", "the API allows that rate", "sync can be conflict-free"). The roadmap's first job is to test that assumption as cheaply as possible — a milestone that reduces no uncertainty is decoration.

3. Roadmap shape: Now / Next / Later / Not-now

• Now — blocking the next useful release; nothing enters Now while something cheaper reduces more risk.
• Next — after the core flow is stable; sequenced, not started.
• Later — valuable, not blocking; parked with a one-line trigger for revisit ("when >N users", "when X ships").
• Not now — tempting but premature; write why, or it silently re-enters scope next week. This list is the roadmap's immune system.

Sequencing rules:

• Vertical slices, not horizontal layers. First milestone = a walking skeleton: the thinnest end-to-end path a real user can traverse. "All the backend first" is a plan to discover integration problems last.
• Order by risk burndown and dependency, not by excitement.
• Under pressure, cut scope, never quality — drop a feature, don't ship a broken one.
• Every milestone ends in something observable: shippable, demoable, or a measured answer to a named question.

4. Prioritization

Score candidates informally on user value, confidence in that value, effort, and risk — then assign:

• P0 — you would stop current work for it (broken core flow, data loss, security Critical). If everything is P0, nothing is.
• P1 — in the next milestone.
• P2 — worth an issue, not a slot.
• P3 — Not-now list with the reason.

P-levels are internal scoring that feeds the §3 buckets: P0 enters Now, P1 enters Next, P2 becomes a filed issue under Later, P3 joins Not-now. The output (§7) shows buckets, not P-labels.

Confidence caps value: "High value, Low confidence" items get a cheap probe (prototype, mock, 5-user test), not a milestone. Distinguish evidence ("users filed 6 issues asking for X") from speculation ("users would love X") — speculation is allowed, labeled.

5. Milestone block (the only template)

## Milestone: <name>
Goal / user value:      one sentence, outcome not feature list
Scope:                  the thin slice
Out of scope:           what this milestone deliberately ignores
Riskiest assumption:    what this milestone proves or kills
Acceptance criteria:    observable checks (tie to ground-truth-gates where possible)
Dependencies / risks:

6. Mining adjacent GitHub repos for insight

When comparable projects exist, their repos are free research:

• Their issues are user research — recurring requests and complaints in a similar project are demand signals for yours, cheaper than interviews.
• Their changelog/BREAKING CHANGES/migration guides are regret logs — design decisions they had to walk back; avoid the same one-way doors (choices that are hard to reverse).
• Their architecture answers feasibility questions ("how do they handle sync?") before you prototype.
• Calibrate: stars ≠ quality, activity ≠ direction; a popular repo's unsolved issues are your differentiation candidates.
• License & IP hygiene before borrowing anything beyond ideas (a conservative agent default, not legal counsel — confirm the actual license and target compatibility, and honor each license's exact terms):
  • Preserve the source's required notices: MIT needs its copyright + permission notice carried along; Apache-2.0 adds redistribution duties (and NOTICE handling when the upstream ships one). As a safe default, treat strong copyleft (AGPL/GPL) and unlicensed source as ideas only unless the user clears the obligations — that is our conservative policy, not a claim the license forbids all use.
  • An AI rewrite/translation of copyrighted source is still a derivative — you cannot launder it by paraphrase. True clean-room = an independent implementation from an independently-written spec, not "I read it, then rewrote it from memory."
  • Code-license compatibility does NOT open a project's art, characters, or trademarks.
  • Adopt on mechanism, never a source's benchmark numbers — copy no metric you did not reproduce, or you launder an unverified claim into your docs as fact.
  • ✅ "Independent reimplementation from a spec I wrote, carrying the upstream's required notice." ❌ "It's AGPL, but I had the model rewrite it in a new style, so it's clean."

Summarize insights with links; never vendor code or copy positioning wholesale.

7. Output shape

Verdict (stage, main bottleneck, best next move, what not to do yet) → Now/Next/Later/Not-now → milestone blocks for Now → tasks split three ways:

• Agent does — emit as dispatch packets per delegation-and-review §2.
• User does — only what genuinely needs them: credentials/app setup, payment/legal, positioning, destructive-migration approval.
• Needs information — the question, why it matters, and the safe default if unanswered.

Tasks carry their blocking edges (unprobed — see Provenance). When emitting the tasks above: give each task a stable short reference (an id or unique short name); under each task write one compact blocked-by: <refs> line — blocked-by: none when nothing blocks it — naming, by those references, the tasks or user/info items that must land first (a user/info item gets a short stable label the same way); mark [P] only where tasks share no blocking edge AND no files (technical independence only — dispatch-time wave limits stay delegation-and-review §1's bounded fan-out); derive dispatch order from the edges, never from list position. Edges stay inline in the task list — no graph file, no dependency tooling, no status tracker; deeper per-task sequencing belongs to the dispatch packet (delegation-and-review §2) at dispatch time, not to the roadmap. Fail states are explicit: an edge you cannot name is a discovered unknown — park that task in Later with the unknown named (§3's parked-with-trigger convention), never dispatch on a guessed order; a cycle or a contradictory pair of edges is a plan defect — re-slice the tasks to break it, or park every affected task the same way, and dispatch none of the affected tasks until the defect is repaired. Done when every Now task carries its blocked-by: line and every [P] is verified independent. ✅ "T1 schema — blocked-by: none. T3 auth API — blocked-by: T1. T4 docs page — blocked-by: none [P]". ❌ five tasks all reading "blocked-by: none" while task 3 edits the schema task 1 creates — the missing edge surfaces as a merge conflict or a broken dispatch, not as planning.

Keep the whole output one screen where possible; depth goes into linked files, not the verdict.

Provenance

Detailed historical review, probe, and amendment records for this skill are retained in references/provenance.md.