Chosen Methodology — Hybrid Definition and Derived Steps#

SUPERSESSION NOTICE: This document SUPERSEDES stage-chain-matrix.md as the operative pipeline definition. stage-chain-matrix.md remains the generic artifact/standard survey it was derived from; this document is the stage-chain-matrix re-cut through the lens of methodology-ranking.md's per-stage fitness evidence, with explicit methodology ownership assigned per stage and justified cell-by-cell.

STATUS: RECOMMENDATION PENDING OWNER SIGN-OFF. Nothing below is an adopted decision. It is the researched hybrid recommendation, derived strictly from the two cited source documents, for the owner to approve, amend, or reject — including the one genuinely-tied stage surfaced in Section 3, which requires an explicit owner call before the pipeline can be finalized.

---

1. Why a hybrid, not a single methodology#

methodology-ranking.md View 1 and View 2 both independently converge on the same finding: no single candidate methodology wins across all stages ("the winner changes at every stage" — ranking.md §3, line 59). A hybrid is therefore not a stylistic choice but the ranking's own conclusion. This document operationalizes that conclusion into a buildable pipeline.

---

2. Hybrid definition — cell-by-cell justification#

Each stage below names the stage-chain-matrix stage (Stage 0–6), maps it to the ranking's corresponding View-2 row, and names the adopted methodology/artifact with the exact ranking evidence that justifies the pick.

Weight-driven framing used throughout: where a row has one clear High, it is adopted outright (Stages 0, 3, 4, 5, 6). Where thoroughness vs speed conflict within one High-scoring row (Stage 2), the ranking's own §4 resolution (two depths) is carried forward verbatim rather than re-derived. Where two methodologies tie at High with no ranking-supplied tiebreaker (Stage 1), the tie is surfaced, not silently broken — see §3.

---

3. Stage 1 tie — explicit owner decision required#

The tie: ranking.md §3 row 1 (Discovery/problem-framing) scores both Lean/Customer-Development and Continuous-discovery/JTBD as High, with no finer-grained (e.g. decimal) distinction supplied anywhere in the ranking document. Per the task's instruction, a genuine tie on a stage's weighted score is not for this document to silently resolve by picking a favorite.

What is NOT in question: both methodologies' artifacts (Lean Canvas and JTBD job-statement / Opportunity-Solution Tree) are structurally compatible, not mutually exclusive outputs — stage-chain-matrix.md Stage 1 already lists both in the same cell ("Customer-Development hypothesis set and/or JTBD core-functional-job statement where validation is in scope"). So the recommended default in §2 above is to run both artifacts together rather than choose.

What IS still an open owner decision: ranking.md §2 View 1 ranks Continuous discovery/JTBD #1 overall and Lean/CustDev #2 overall, but that is a whole-methodology ranking (includes criteria Stage 1 alone doesn't exercise, e.g. ongoing weekly cadence vs one-time canvas), not a per-stage tiebreaker — using it to break the Stage-1 tie would be importing a different evidence base than the one that produced the tie. Two real options exist and the ranking cannot itself arbitrate between them:

• Option A — combine (recommended default, already reflected in §2): Stage 1 always produces BOTH a Lean Canvas AND a JTBD core-job statement / lightweight Opportunity-Solution Tree root. Rationale: zero ranking-evidence conflict (both artifacts can exist on the same stage without contradicting each other), costs only marginal extra AI-generation time, consistent with stage-chain-matrix's own precedent.
• Option B — pick one as primary, demote the other to optional: if the owner wants Stage 1 output minimized for raw speed (owner's stated #1 criterion, weight 0.30), run Lean Canvas only for the "thin slice" depth and defer JTBD/continuous-discovery artifacts to a later, optional re-validation loop (consistent with Torres's own framing that the opportunity tree "refreshes" rather than gates — stage-chain-matrix.md "Ordering disagreements" §1). This trades some faithfulness-to-need depth for speed at Stage 1 specifically.

This document does not pick between A and B on the owner's behalf. §4 below proceeds using Option A (combine) as the working default so the step sequence is concrete, but Step 1's gap-questions explicitly carry a flag for the owner to confirm or override this before the pipeline runs for real.

---

4. Derived steps — full ordered sequence#

Step 0 — Raw input capture#

• (a) Name: Raw input capture.
• (b) Requirements: Whatever the user already has — notes, a verbal brief, an existing SOP/process doc, a deck, a ticket. No structured format required.
• (c) Preconditions: None (pipeline entry point). Completeness check to exit: a problem, a rough target user, and (if describing an existing process) the process's current steps are nameable — per stage-chain-matrix.md Stage 0 exit criteria.
• (d) Result/artifact: A captured problem/opportunity statement or process description, in whatever form the source gave it.
• (e) Gap-filling questions (≥3):
  1. "Is this a brand-new idea with no current process, or are you describing something your team/users already do today?" — determines which entry point (§5) applies.
  2. "Who told you this is a problem — a specific customer complaint, a metric, or your own hypothesis?" — surfaces whether Step 1's fact-vs-opinion gate can 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 Step 0's output is transcription or structured elicitation.
  4. "What triggered this now — a deadline, a competitor, an internal pain point?" — needed to populate the Step 1 Vision/problem statement.

Step 1 — Business model & problem framing (+ actors/personas)#

• (a) Name: Business model & problem framing.
• (b) Requirements: Step 0 output (problem/opportunity statement or process description).
• (c) Preconditions: Step 0 complete per its exit criteria. Completeness check to enter: a problem, rough target user, and trigger are nameable.
• (d) Result/artifact: A Lean Canvas (idea-stage) or Business Model Canvas (existing-process-stage — see §5 entry-point rules) + a Vision statement + an actor list + personas (flagged 🤔 if not research-backed) + a JTBD core-functional-job statement / lightweight Opportunity-Solution Tree root, per the §3 Option-A default (pending owner confirmation of §3).
• (e) Gap-filling questions (≥3):
  1. "Who exactly is the customer segment — can you name 2-3 real people or companies, not just 'users'?"
  2. "What do they do today without your product — what's the current workaround?"
  3. "Who are ALL the actors — not just the end user, but any external system, admin role, or third party that interacts with this?"
  4. "Have you validated this with any real customer conversation, or is this still a hypothesis?" — distinguishes 💭/🤔 from 🧩 status.
  5. (§3 tie-flag) "For Stage 1, do you want both a Lean Canvas AND a JTBD/opportunity-tree pass every time (Option A, default), or should we run Lean Canvas only for speed and treat JTBD as an optional later loop (Option B)?" — must be answered once, up front, before the pipeline is finalized.

Step 2 — Use-cases / user-stories (Requirements)#

• (a) Name: Requirements capture (use-cases + stories, two-depth).
• (b) Requirements: Step 1 Vision + actor list + personas.
• (c) Preconditions: Step 1 complete — canvas fully populated, every actor named, personas grounded (or flagged 🤔). Owner has also selected a depth for this stage: "thin slice" (MVP-fast) or "full spec" (thoroughness-ceiling) — this selection is itself a gap-fill question, not an assumption.
• (d) Result/artifact: Depending on selected depth — thin slice: Connextra-template user stories + INVEST check + acceptance criteria + a Jeff Patton story-map backbone; full spec: RUP use-case model + per-case use-case specifications (flow of events, pre/postconditions) + Supplementary specification (FURPS+ NFRs) scored against IEEE 29148 / Volere snow-card completeness.
• (e) Gap-filling questions (≥3):
  1. "Do you want the fast thin-slice pass (stories + acceptance criteria, enough to build an MVP) or the full-spec pass (complete use-case model + NFR spec) for this stage — or full-spec only for the parts that are architecturally risky?" — the depth-selection question, mandatory before proceeding.
  2. "For this story/use-case, what's the role, the goal, and the benefit — can you fill in 'As a ___, I want ___, so that ___'?"
  3. "What happens when this goes wrong — any alternate or exception flow?"
  4. "Are there non-functional expectations here — performance, security, compliance — that don't belong inside one story?"
  5. "Where does this sit in the overall user journey — early exploration, core task, or edge case?"

Step 3 — UX (flows, journeys, information architecture)#

• (a) Name: UX discovery/definition.
• (b) Requirements: Step 2 use-cases/stories + Step 1 personas.
• (c) Preconditions: Step 2 complete to the selected depth (every story passes INVEST or is split; use-case model internally consistent with no orphan actors).
• (d) Result/artifact: Empathy maps, customer/user journey maps, user flows (entry-to-goal with branches), Double Diamond Discover/Define problem statement.
• (e) Gap-filling questions (≥3):
  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?"
  2. "Where does this flow start and where does it end — what's the entry point and the goal-completion screen?"
  3. "Are there decision points or branches where the user could go two different ways?"
  4. "Is this the first pass at the journey, or do we already have interview evidence backing each pain point?" — distinguishes 🤔 hypothesized from 🧩 evidence-backed.

Step 4 — UI / design requirements#

• (a) Name: UI design (wireframes → prototypes → design system).
• (b) Requirements: Step 3 flows/journeys/IA + problem statement.
• (c) Preconditions: Step 3 Define exit — problem statement specific/actionable/user-centered; every primary task has a complete user flow.
• (d) Result/artifact: Lo-fi wireframes → hi-fi wireframes/prototypes (user-tested per Double Diamond Deliver), design system + design tokens (DTCG format, $value+$type minimum), updated Supplementary-spec Usability entries.
• (e) Gap-filling questions (≥3):
  1. "Do we need pixel-accurate layout yet, or is a rough structural sketch enough for this review?"
  2. "Does this screen reuse an existing component/token, or does it need something new in the design system?"
  3. "Has this been shown to a real user yet, or is it still internal-only?" — Double Diamond Deliver gate.
  4. "What are the usability targets here — load time, error tolerance, accessibility level — stated as something testable?"

Step 5 — Frontend spec#

• (a) Name: Frontend component specification.
• (b) Requirements: Step 4 hi-fi wireframes/prototypes + design system/tokens.
• (c) Preconditions: Step 4 hi-fi artifacts user-tested; token set satisfies current screens without ad hoc one-off values.
• (d) Result/artifact: Atomic Design decomposition (atoms/molecules/organisms/templates/pages) realized as Storybook story sets per component with auto-generated docs, each traceable to design-system tokens.
• (e) Gap-filling questions (≥3):
  1. "What are every state this component can be in — default, hover, active, disabled, loading, error — have we listed them all?"
  2. "Is this a new atom/molecule, or does it already exist at a different level in the design system?"
  3. "Which design tokens does this component consume — or does it hardcode a color/spacing value?"
  4. "Does this component's behavior depend on data/state from the backend, and has that contract been defined yet?" — flags a Step 5/6 dependency gap.

Step 6 — Backend spec#

• (a) Name: Backend architecture & API specification.
• (b) Requirements: Step 2 use-case specs/NFRs + Step 1 actors/domain entities. (Runs in parallel with Steps 4–5, not after them — both Step 5 and Step 6 depend on Step 2/Step 1, not on each other.)
• (c) Preconditions: Step 2 complete to selected depth, with entities and NFR categories named; Step 1 actor list finalized.
• (d) Result/artifact: C4 model diagrams (Context, Container, optional Component/Code), OpenAPI/Swagger API contracts, ERD (conceptual → logical → physical), ADRs for every architecturally-significant decision, remaining Supplementary-spec NFR categories (Reliability, Performance, Supportability).
• (e) Gap-filling questions (≥3):
  1. "Is this decision architecturally significant — does it affect structure, a non-functional characteristic, a dependency, or an interface?" — ADR trigger test.
  2. "What are the entities involved, their attributes, and how do they relate — and at what level, conceptual or down to physical columns?"
  3. "What's the full set of operations, request/response shapes, and auth scheme this API needs to expose?"
  4. "Is this a new deployable unit (service/container), or does it live inside an existing one?"
  5. "What performance, reliability, or supportability targets apply here, stated as measurable numbers?"

---

5. Dual entry points#

(a) Bare idea — enters at Step 0, full path Step 0 → Step 6#

Nothing is auto-skippable. Every step starts empty and must be gap-filled from scratch:

1. Step 0: raw idea stated, no existing process. Full gap-fill (all 4 questions).
2. Step 1: Lean Canvas (not BMC — Maurya's "founders who have not found their customer yet" applies), Vision doc, initial actor list, personas gap-filled and flagged 🤔 until research-backed, plus JTBD pass per §3 Option A default.
3. Step 2: story map backbone generated from Lean Canvas Problem/Solution blocks; Connextra stories + INVEST + acceptance-criteria gap-questions. Thin-slice depth is the natural default for a bare idea (nothing yet justifies full-spec cost) but the depth question is still asked explicitly, not assumed.
4. Step 3: journey map + user flows built from the story map; Double Diamond Discover/Define applied with an explicit gap-fill forcing at least a lightweight empathize pass (even 1-2 assumed interviews, flagged 🤔) before Define, since no empathy data exists yet.
5. Step 4: lo-fi wireframes first (cheap, disposable), hi-fi only once flow is validated; design-system choice (existing vs fresh) is gap-filled.
6. Steps 5 & 6 run in parallel, each off its own precondition (Step 4 for frontend, Step 2 for backend) — no shortcuts available for a bare idea.

(b) Already-worked-out business process — enters at Step 0 as ingestion, auto-skip rules apply from Step 1 onward#

1. Step 0: existing SOP/process document supplied — this is transcription/ingestion, not elicitation. Gap-fill narrows to clarifying ambiguous steps in the document, not asking "what is this" from zero.
2. Step 1 — largely auto-skippable: Business Model Canvas (not Lean Canvas — "an existing business model to document," per stage-chain-matrix's BMC-vs-Lean-Canvas input distinction) and the Vision/actor list are drafted directly from the process description. Gap-fill narrows to: missing actors never mentioned in the SOP, and an unstated revenue/cost link. JTBD pass (§3 Option A) is still run but anchored to the process's stated purpose rather than elicited from scratch.
3. Step 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), so this entry point naturally pulls toward the full-spec depth rather than thin-slice, since the raw material already resembles a use-case spec. Gap-fill targets what the SOP never specifies: exception flows, SLAs, non-functional constraints.
4. Step 3 onward — identical to path (a), no further auto-skip: UX/UI/Frontend/Backend stages require experience-design work (flows, screens, components, system design) that a business-process description does not already contain, so nothing here shortcuts. The one remaining shortcut: if the process document already names specific data entities/fields, Step 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 (applies regardless of entry point once past Step 2): personas (a process names roles, not motivations/behaviors), journey-level emotional/pain-point data (empathy maps), any UI/visual direction (processes are typically UI-agnostic), and all Step 5/6 technical-spec artifacts (C4, OpenAPI, ERD, ADRs) — none of these are derivable from a business-process document alone.

---

6. Summary of resolutions requiring no further owner input vs. one that does#

• Resolved by ranking evidence alone (no owner input needed): Steps 0, 3, 4, 5, 6 (sole High winner per stage, no tie) and Step 2's depth mechanism (ranking.md §4 pre-resolves speed-vs-thoroughness via the two-depth accommodation, though which depth to use per instance is still a per-use gap-fill question, not a methodology-selection question).
• Requires explicit owner sign-off before the pipeline is finalized: Step 1's Lean/CustDev vs Continuous-discovery/JTBD tie (§3) — this document proceeds on Option A (combine both) as its working default, but flags this as open, not decided.