Hybrid Methodology — Recommendation (pending owner sign-off)#
STATUS: This is a RECOMMENDATION, not an adopted decision. Nothing here is final until the owner signs off. Inputs: methodology-ranking.md, chosen-methodology-steps.md.
1. The recommended hybrid — and the case for it#
| Stage | Adopted approach/artifact |
|---|---|
| 0. Raw input | Direct elicitation/transcription, no methodology imposed |
| 1. Business model & problem framing | Lean Canvas / Customer Development + JTBD/Opportunity-Solution Tree, run together (working default — see §4a) |
| 2. Requirements (use-cases/user-stories) | Two-depth split: Heavy RE standards (IEEE 29148 / Volere) for full-spec; Agile stories/INVEST/BDD for thin-slice |
| 3. UX (flows, journeys, IA) | Design Thinking / Double Diamond (Discover/Define) |
| 4. UI / design requirements | Design Thinking / Double Diamond (Ideate/Prototype/Test → Develop/Deliver) |
| 5. Frontend spec | Lightweight tech-spec stack: Atomic Design + Storybook + Design Tokens |
| 6. Backend spec | Lightweight tech-spec stack: C4 + OpenAPI + ERD + ADR |
This hybrid is the direct case for the owner's stated goal — fast delivery, an ideal app that works exactly as the user wants, and maximum thoroughness of working-out: at the front stages (0-1, 3-4) speed and user-fit pull the same direction, so the pipeline runs the fastest, most user-validated methods there (Lean/JTBD, Double Diamond), while at the stages where correctness compounds downstream and is cheap to get right now (Requirements, Backend spec), it switches to the heavier, traceable artifacts (RE standards, C4/OpenAPI/ADR) — so thoroughness is spent only where it pays off, not spread evenly across the whole pipeline.
2. Evidence caveat (read this before trusting the ranking)#
There is no objective single-winner benchmark for software methodologies — rigorous head-to-head studies are scarce and context-dependent. This ranking is therefore CRITERIA-BASED and EVIDENCE-TIERED: each score is tagged Tier A (peer-reviewed/large-N), Tier B (industry reports), or Tier C (practitioner consensus). The two most-cited numbers in this space are cited AND contested here: the Standish CHAOS report (self-selected samples, shifting definition of "success") and Boehm's 100x cost-of-change figure (revised down in 2001 and further challenged by modern CI/CD practice). Treat the per-stage view as more reliable than any single overall number.
3. Speed vs. thoroughness — the core tension, and how the hybrid resolves it#
The owner's two top-line goals genuinely conflict, not just rhetorically: at discovery and UX, heavy upfront elicitation (RE-standards-style) risks fully specifying the wrong product before any real user contact — the opposite of "exactly as the user wants." At requirements and backend-spec, the direction flips — these are the stages with a measurable completeness test (29148's quality grid, Volere's fit criteria, C4/OpenAPI's machine-checkability), and the classic cost-of-change argument for paying up front, while weaker than the 100x folklore suggests, still holds for a smaller but real margin. The hybrid resolves this per stage rather than by averaging:
- Stage 0-1 (discovery): fast, lean, validation-first — speed and faithfulness-to-need dominate.
- Stage 2 (requirements): two configurable depths — thin-slice for speed, full-spec where thoroughness pays.
- Stage 3-4 (UX/UI): fast, iterative, user-tested — design-process lineage, no RE-standard rigor imposed.
- Stage 5-6 (frontend/backend spec): thorough, traceable, machine-checkable — the lightweight tech-spec stack, chosen for correctness-compounds-downstream reasons, not for speed.
4. Open decisions for the owner (nothing is decided)#
4a. Tied stage: Step 1 discovery (business model / problem framing)#
chosen-methodology-steps.md §3 surfaces a genuine tie at Step 1: Lean/Customer-Development and Continuous-discovery/JTBD both score High with no ranking-supplied tiebreaker.
- Option A (combine Lean + JTBD) — current working default: every Step 1 pass produces both a Lean Canvas and a JTBD core-job statement / lightweight Opportunity-Solution Tree root. No evidence conflict, marginal extra AI-generation cost.
- Option B (Lean Canvas only, defer JTBD): minimizes Step 1 for raw speed; JTBD/continuous-discovery deferred to an optional later re-validation loop. Trades some faithfulness-to-need depth for speed at this one stage.
4b. Reopened form question: representation FORM (parked earlier, now resumes conditioned on this hybrid)#
representation-recommendation.md left 5 questions open; they resume here:
- Authoring surface — schema-first structured fields, or free text the AI structures behind the scenes?
- Gate strictness — hard-block advancing until completeness is met, or allow advancing with flagged gaps?
- v1 scope — full chain (stages 0-6) first, or prove the mechanic on front stages (0-2) before extending?
- Build vs assemble — custom app, or assemble on existing tools (structured docs/Notion/Linear) plus an AI layer?
- Runtime/scope — internal/single-user only? persistence and where the source-of-truth lives?
5. What happens on sign-off#
Once the owner picks the Step-1 tie option (§4a) and the representation-form direction (§4b), the derived steps in chosen-methodology-steps.md become the working process, and we move to defining the per-stage schemas/templates.