Stage-Chain Matrix — Idea → Full Project Documentation#

Synthesizes methodology-landscape.md into a canonical pipeline mapped onto our 7 target stages (Stage 0 raw input → Stage 6 backend spec). Every artifact/standard cited below is pulled directly from the landscape survey; nothing here is invented. Confidence markers (🧩/🤔) are carried over from the source document where a claim leans on secondary grounding.

Main matrix#

Stage 0 — Raw input: gap-filling questions#

1. "Is this a brand-new idea with no current process, or are you describing something your team/users already do today?" — determines Entry Point A vs B (see below).
2. "Who told you this is a problem — a specific customer complaint, a metric, or your own hypothesis?" — surfaces whether Stage 1's Customer-Development "fact vs opinion" gate can even be attempted yet.
3. "Is there an existing document (deck, brief, SOP, ticket) describing this, or is it only in your head right now?" — determines whether Stage 0 output is a transcription task or a structured-elicitation task.
4. "What triggered this now — a deadline, a competitor, an internal pain point?" — needed later to populate the Vision document's "business opportunity/problem statement."

Stage 1 — Business model & problem framing: gap-filling questions#

1. "Who exactly is the customer segment — can you name 2-3 real people or companies, not just 'users'?" (Lean Canvas/BMC Customer Segments block; also personas precondition).
2. "What do they do today without your product — what's the current workaround?" (Lean Canvas Problem block; also JTBD "job" framing).
3. "Who are ALL the actors — not just the end user, but any external system, admin role, or third party that interacts with this?" (RUP Actors completeness: "no leftover unnamed 'the user'").
4. "How will this make money, or is monetization out of scope for this phase?" (BMC/Lean Canvas Revenue Streams — if "out of scope," flag the canvas as partial, not failed).
5. "Have you validated this with any real customer conversation, or is this still a hypothesis?" (Customer Development discovery/validation gate — distinguishes 💭/🤔 from 🧩 status of the problem framing).

Stage 2 — Use-cases / user-stories: gap-filling questions#

1. "For this story, what's the role, the goal, and the benefit — can you fill in 'As a ___, I want ___, so that ___'?" (Connextra template minimum).
2. "Is this story small enough to build in one sprint, and can you tell me how we'd test it's done?" (INVEST: Small + Testable; also Acceptance Criteria).
3. "What happens when this goes wrong — any alternate or exception flow?" (RUP use-case spec: flow of events needs extension points, not just the happy path).
4. "Are there non-functional expectations here — performance, security, compliance — that don't belong inside one story?" (Supplementary spec / FURPS+ global requirements).
5. "Where does this story sit in the overall user journey — early exploration, core task, or edge case?" (Jeff Patton story-map backbone placement).

Stage 3 — UX (flows, journeys, IA): gap-filling questions#

1. "Walk me through this step by step as the user would experience it — what do they see, do, think, and feel at each point?" (Empathy Map / Journey Map Says/Does/Thinks/Feels quadrants).
2. "Where does this flow start and where does it end — what's the entry point and the goal-completion screen?" (User Flow completeness: every primary task needs entry-to-goal coverage).
3. "Are there decision points or branches where the user could go two different ways?" (User Flow branch points).
4. "What's the single business outcome this whole flow is meant to move — can you state it at the root?" (Opportunity-Solution Tree root outcome, if continuous discovery applies).
5. "Is this the first pass at the journey, or do we already have interview evidence backing each pain point?" (distinguishes a 🤔 hypothesized journey from a 🧩 evidence-backed one).

Stage 4 — UI / design requirements: gap-filling questions#

1. "Do we need pixel-accurate layout yet, or is a rough structural sketch enough for this review?" (lo-fi vs hi-fi fidelity decision).
2. "Does this screen reuse an existing component/token, or does it need something new in the design system?" (Design System/Token completeness — avoid ad hoc one-off values).
3. "Has this been shown to a real user yet, or is it still internal-only?" (Double Diamond Deliver gate: "small-scale tested, refined, validated").
4. "What are the usability targets here — load time, error tolerance, accessibility level — stated as something testable?" (Supplementary spec Usability category needs measurable targets, not adjectives).

Stage 5 — Frontend spec: gap-filling questions#

1. "What are every state this component can be in — default, hover, active, disabled, loading, error — have we listed them all?" (Storybook story-set completeness).
2. "Is this a new atom/molecule, or does it already exist at a different level in the design system?" (Atomic Design decomposition level).
3. "Which design tokens does this component consume — or does it hardcode a color/spacing value?" (Design Token completeness: no ad hoc values).
4. "Does this component's behavior depend on data/state from the backend, and has that contract been defined yet?" (flags a Stage 5/6 dependency gap before frontend spec is declared done).

Stage 6 — Backend spec: gap-filling questions#

1. "Is this decision architecturally significant — does it affect structure, a non-functional characteristic, a dependency, or an interface?" (ADR trigger test, Nygard).
2. "What are the entities involved, their attributes, and how do they relate — and at what level, conceptual or down to physical columns?" (ERD input/level).
3. "What's the full set of operations, request/response shapes, and auth scheme this API needs to expose?" (OpenAPI contract-first completeness).
4. "Is this a new deployable unit (service/container), or does it live inside an existing one?" (C4 Container-level scoping).
5. "What performance, reliability, or supportability targets apply here, stated as measurable numbers?" (remaining Supplementary-spec FURPS+ categories).

Ordering disagreements#

The landscape doc surfaces three real tensions between a linear staged pipeline (our tool's backbone) and the methodologies it draws from:

• Continuous-discovery loops vs. staged chaining. Teresa Torres's Opportunity-Solution Tree is explicitly "NOT a one-time completion gate" — the opportunity space refreshes every 3-4 customer interviews, and a tree's life only ends when the root outcome changes. This conflicts with a Stage 1→2→3 waterfall where each stage closes before the next opens. Accommodation: treat Stage 1-3 as a loop that can re-run against a fixed Stage 0 root outcome; the pipeline's "exit gate" for Stage 1/3 is not "never revisit" but "sufficient to start Stage 2/4," and a later discovery cycle can re-open an earlier stage's artifact (Vision, persona, journey map) without restarting the whole chain from Stage 0.
• Design Thinking / Double Diamond diverge-converge vs. linear stage gates. Both are explicitly non-linear — d.school says "start wherever you'd like," and the Double Diamond's own site notes "no idea is ever finished," allowing cycling back from Deliver to Discover. Our Stage 3 (UX) and Stage 4 (UI) map onto Define→Develop and Prototype/Test→Deliver respectively, which is a reasonable staged cut, but a literal reading of the methodology would let Stage 4 feedback reopen Stage 3. Accommodation: the pipeline enforces forward gates for document generation (you need a UX output to start UI), but the AI's gap-detection at Stage 4 is explicitly allowed to generate "revise Stage 3" questions when prototype testing (Stage 4 Test) invalidates a flow — modeled as a soft backward edge, not a hard restart.
• Lean "test before build" vs. upfront full spec (RUP/ISO 29148/Volere). Eric Ries's Build-Measure-Learn treats any output that doesn't produce "validated learning" as waste, favoring an MVP before a full use-case/requirements spec exists; RUP/ISO 29148/Volere assume requirements are elicited and documented in reasonably full form (per FURPS+/snow-card coverage) before detailed design. Accommodation: the tool supports two configurable depths per stage — a "thin slice" pass (Lean Canvas + one journey + one use case, enough to build and test an MVP) and a "full spec" pass (complete use-case model, full Supplementary spec) — with the same Stage 0-6 ordering but different completeness thresholds per pass; Volere itself models this compatibly, since its own philosophy is "start testing requirements as soon as you start writing them" and its spec-level completeness is explicitly iterative, not all-or-nothing.

Two entry points#

(a) Bare idea — full path, Stage 0 → Stage 6#

1. Stage 0: User states a raw idea with no existing process ("I want an app that helps freelancers track invoices"). Gap-fill: customer segment, problem evidence, trigger (see Stage 0 questions above).
2. Stage 1: AI drafts a Lean Canvas (idea-stage tool, per Maurya's "founders who have not found their customer yet") rather than a Business Model Canvas, plus a Vision document and an initial actor list (freelancer, client, payment processor). Personas are gap-filled from the user's stated target segment, flagged 🤔 until real research backs them.
3. Stage 2: AI converts Lean Canvas Problem/Solution blocks into a first story map (Patton) backbone, generates Connextra-template stories, runs INVEST, and asks acceptance-criteria gap-questions per story.
4. Stage 3: AI builds a journey map and user flows from the story map, applying Double Diamond Discover/Define since no empathy data exists yet — gap-fill forces at least a lightweight empathize pass (even 1-2 assumed interviews, explicitly flagged 🤔) before Define.
5. Stage 4: Lo-fi wireframes first (cheap, disposable per Design Thinking Prototype), then hi-fi only once the flow is validated — design system choices are gap-filled against "is there an existing design system or do we start fresh."
6. Stage 5 & 6 run in parallel off Stage 4/Stage 2 respectively: Frontend spec consumes hi-fi wireframes + tokens; Backend spec consumes use-case specs + data entities named during Stage 1-2 gap-fill. Nothing here is auto-skippable for a bare idea — every stage starts empty and must be gap-filled from scratch.

(b) Already-worked-out business process — partial path, enters mid-chain#

1. Stage 0: User supplies an existing SOP/process document (e.g., "here's how we currently approve expense reports manually"). This already IS a structured input, so Stage 0 is a transcription/ingestion step, not elicitation.
2. Stage 1 — largely auto-skippable: Business model and problem framing often already exist implicitly (the process's purpose, its stakeholders) — AI drafts the Vision and actor list directly from the process description instead of asking discovery questions, and Business Model Canvas (not Lean Canvas) is the better fit since this is "an existing business model to document," per the landscape's own Input distinction between BMC and Lean Canvas. Gap-fill is narrower: only missing actors (e.g., an approver role never mentioned) or an unstated revenue/cost link need asking.
3. Stage 2 — partially auto-fillable: Existing process steps map almost directly onto a RUP use-case model (each process step → a use-case flow of events) rather than needing invented user stories from scratch. Gap-fill targets what the process document never specifies: exception flows, SLAs, and non-functional constraints (RUP Supplementary spec) — these are the classic gaps a written SOP omits.
4. Stage 3 onward — same as path (a): Once use cases exist, UX/UI/Frontend/Backend stages proceed identically regardless of entry point, because they require experience design work (flows, screens, components, system design) that a business-process description does not already contain. The only remaining shortcut: if the process already names specific data entities/fields, Stage 6's ERD gap-fill starts from those fields instead of asking "what entities exist" from zero.

What must still be gap-filled even with a worked-out process: personas (a process description names roles, not motivations/behaviors), journey-level emotional/pain-point data (Empathy Maps), any UI/visual direction (processes are typically UI-agnostic), and all Stage 5/6 technical-spec artifacts (C4, OpenAPI, ERD, ADRs) — none of these are derivable from a business-process document alone.