Pm Idea To Plan

Idea → Plan (PM Creation Orchestrator) Skill

How this skill behaves (read first)

This is the front door for taking a raw idea to a build-ready plan, and the PM twin of ux-design-from-scratch. Where pm-product-review orchestrates the validation direction (generative → audit), this skill orchestrates the compositional direction (generative → generative): it sequences the PM scope ladder — problem → discovery → users → riskiest-assumption test → prioritization → spec → metrics — pulling in each skill as the work needs it, then hands the result to pm-product-review for validation.

It is the executable form of the compositional orchestration section (§9) of docs/orchestration-policy.md, applied to PM. Its whole job is to avoid the failure this skill was created to fix: a plan that is overdeveloped as a PRD and underdeveloped as a de-risked product bet — a polished spec resting on an unexamined market and an untested willingness-to-pay. The spec is the last rung, not the first, and it never runs before the evidence rungs beneath it.

The one rule that makes this skill earn its place: evidence before spec. Claude's default, asked to "take me from idea to plan," rushes to a plausible-looking PRD — requirements, stories, metrics — built on an unvalidated problem and zero adoption evidence. That document looks complete, which is exactly why it's dangerous: teams build from it. This orchestrator forces the problem, the discovery evidence, and the riskiest-assumption test to come first, and keeps the spec proportionate instead of letting it swallow the plan.

When NOT to use this skill:

• One named artifact — "write me a PRD", "frame this problem", "build a prioritization matrix". Let that skill trigger directly. Explicit scope overrides orchestration.
• The strategy / launch arc — vision & strategy, competitive analysis, roadmap, GTM, launch experiments. That is a different compositional arc (pm-vision-strategy, pm-competitive-analysis, pm-roadmap, pm-gtm-plan, pm-experimentation-ab, pm-analytics). This skill stops at a validated, build-ready plan; offer to continue into the strategy arc rather than producing it here.

Step 0 — Establish the context profile (once)

Infer from what the user gave you; ask only the one or two questions that materially change what runs. State the assumptions you're proceeding with, then build in order. Persist this for the rest of the session — don't re-ask.

• The idea, in one line — what's being proposed, for whom. Restating this back is also the first integrity check (if it can only be stated as a solution, the problem isn't framed yet).
• Stakes & reversibility of the build decision — a cheap, reversible experiment needs far less evidence than an expensive, hard-to-undo bet. This sets how much discovery and testing rigor is warranted (over-testing a reversible call is as wrong as under-testing a big one).
• Stage — is the problem still unproven (does anyone care?), is the solution the open question (can they use it / will they switch?), or is it viability/scale (will they pay, does it hold up)? This points each rung at the right depth.
• Market maturity — is this a crowded category? If yes, the riskiest assumption is almost never "can we build it" — it's switching cost and adoption (why leave the incumbent?). Flag this early; it changes which assumption gets tested first and makes pm-competitive-analysis a live offer.
• Evidence already in hand — existing research, data, or customer contact. Don't re-run discovery the user has already done; build on it.

Step 1 — Compose the ladder, gating at each rung

Walk the ladder in order. At each rung classify the skill as core (apply now) / offer (name, don't auto-build) / skip (owned elsewhere or already done) — don't apply every skill at full depth by default (that's the creation-side bandwagon).

Child skills are named by their installable skill name. Compose one only if it's installed; if a named skill isn't present, apply that rung's intent inline with its core best practice and note the gap rather than blocking.

Rung 1 — Frame the problem · pm-problem-statement (core, first)

Pin the problem as a gap with evidence, separated from symptom and solution (problem + consequence + goal). Nothing downstream is trustworthy until this holds. If the user can't supply evidence, proceed but mark the problem as an unvalidated assumption to be retired in Rung 3 — don't paper over it.

Rung 2 — De-risk with discovery · pm-discovery (core — do NOT skip to the spec)

This is the rung the PRD-rushing default drops, and dropping it is exactly what produces a strong spec on a weak bet. Discovery establishes who actually adopts, how it fits their current workflow, whether they'd switch, and whether they'd pay — the evidence the plan stands on. Keep it proportionate to the Step 0 stakes (lightweight continuous contact for a reversible call; a deeper study for a big irreversible one), but always run it before the spec. In a crowded market, this is where switching-cost evidence comes from.

Rung 3 — Define the users · pm-personas-jtbd (core)

Ground the target users in the discovery evidence — jobs-to-be-done and real frustrations, every detail earning a decision. No demographic fiction. This rung consumes Rung 2's output; if discovery was skipped, personas are guesses and should be labelled as such.

Rung 4 — Test the riskiest assumption · pm-assumption-testing (core — and foreground it)

Surface the leap-of-faith belief — the one that, if false, sinks the idea — phrase it falsifiably, and design the cheapest test that answers it, with pre-set success criteria. Foreground the viability/desirability test, do not bury it under the spec. In most idea→plan cases the riskiest belief is "the people we're targeting will actually adopt this and pay/switch" — so a painted-door, concierge, or pre-sell test that checks real behavior before a line of code usually belongs here as an explicit build/no-build gate. A plan that frames this test as a buried sub-section of the PRD has failed this rung.

Rung 5 — Prioritize what to build first · pm-prioritization (core)

Decide the first slice with a method that traces to the strategy/outcome and exposes trade-offs, not fake-precise scores. Prioritization comes after the riskiest assumption is named — you prioritize against validated risk, not against a wish list.

Rung 6 — Write the plan · pm-product-spec (core, last — and proportionate)

Only now write the spec/PRD, and keep it proportionate to the evidence beneath it. Every requirement testable, full flows (not happy paths), explicit scope-out, a dependencies/constraints/assumptions section, and each assumption traced back to whether it's been tested (Rung 4) or is still open. The spec's job is to carry forward the evidence and the open risks, not to paper over them with polished requirements. pm-user-story is owned by this rung (defer to it).

Rung 7 — Define success · pm-okrs-kpis (offer → core if metrics carry weight)

pm-product-spec already contains a success-metrics section; pull in pm-okrs-kpis when the plan needs first-class outcome metrics — outcomes with baseline/target + guardrails, not vanity counts. Offer it; make it core when the user asked for success metrics or when the spec's metrics need real rigor.

Consistency rule: decisions propagate up the ladder. The problem framed in Rung 1, the evidence from Rung 2, and the validated/open assumptions from Rung 4 are reused by every rung above — don't re-litigate them inside the spec. This is the whole point of building idea-up.

Step 2 — Validate via product-review

When the plan exists, hand it to pm-product-review (if installed), which applies the audit policy: it auto-runs pm-assumption-rigor-audit (the always-relevant lens — was the riskiest assumption targeted, falsifiable, matched to a right-fidelity method with pre-set criteria?), and routes by artifact type — spec → pm-spec-quality-audit, metrics → pm-okr-metric-validity-audit, prioritization → pm-prioritization-rigor-audit, with pm-decision-quality-audit offered for the build/no-build call. It returns one prioritized, de-duplicated report — not one per audit. Resolve any findings back toward the Step 0 decision. If pm-product-review isn't installed, run whichever audit skills are present directly, or self-review against the policy.

Step 3 — Offer the strategy / launch arc (don't auto-run it)

A validated plan is the handoff point, not the finish line. Once the plan passes review, offer to continue into the strategy arc rather than producing it unprompted: product vision & strategy (pm-vision-strategy), competitive analysis (pm-competitive-analysis — make this a strong offer in a crowded market, since switching cost is a strategic question this arc owns), roadmap (pm-roadmap), go-to-market (pm-gtm-plan), and launch experiments + analytics (pm-experimentation-ab, pm-analytics). Naming the next arc is the service; auto-generating it is the bandwagon.

Common do/don't patterns

Relationship to the policy

This skill is the compositional-orchestration section (§9) of docs/orchestration-policy.md in executable form for PM work. Its validation twin is pm-product-review; its UX counterpart is ux-design-from-scratch. If this skill and the policy ever diverge, the policy governs — update this skill to match it.

Source lessons (Uxcel)

This is an orchestrator — most of its substance lives in the skills it composes (see the source lessons in pm-problem-statement, pm-discovery, pm-personas-jtbd, pm-assumption-testing, pm-prioritization, pm-product-spec, pm-okrs-kpis). The staging itself — idea → plan, with evidence and definition before build — is grounded in:

• Product Development Lifecycle
• Product Development Stages
• Product Definition