Ai Pdlc Navigator

AI-PDLC Adoption Anti-Patterns

v1, opinionated. These are the failure modes we think most commonly stall AI-assisted PDLC adoption. We're less sure about some than others. If your experience says one of these is wrong or incomplete, file a PR.

Each entry names the anti-pattern, explains why we think it matters, suggests an alternative, and points at where on the maturity model grid it typically shows up.

---

1. AI writes code without an approved design artifact

Why we think this. The whole lifecycle — Discover through Design — exists to answer "are we building the right thing, in the right shape?" before Build begins. When AI makes code cheap, the temptation is to skip that work. You get code that compiles and tests pass, but nothing upstream validated that this is what the user needs, fits the architecture, or meets NFRs. The bug isn't in the code; it's in the decision to build this code.

What to do instead.

• Require a linked design artifact in any PR template.
• Let AI draft the design artifact too — that moves the problem upstream, not around it.
• Treat a merged PR with no design artifact as a process defect, not a speed win.

Where this shows up. L1+ × single-role for Developer. Teams feel productive on the Y axis and never notice they're at L0 on the X axis.

---

2. One prompt plays multiple roles

Why we think this. The role model encodes an important truth: different roles optimize for different things. A Developer optimizes for code; a Security reviewer optimizes for what the code shouldn't do; a PO optimizes for user value. One prompt that "writes the story and implements it and reviews it" collapses these tensions — which means the code gets written without them. You lose the value of having multiple perspectives even though a human team of one could never do that either.

What to do instead.

• One agent card per role. Let them hand artifacts off.
• If you must combine roles, name it: "this is a solo-founder flow" — so you know what you're trading.

Where this shows up. L1-L2 × cross-phase, especially on small teams where role boundaries were fuzzy before AI.

---

3. No human on the Definition of Done

Why we think this. Every artifact in this repo has — or soon will have — a Definition of Done. The DoD exists so the next role can trust the artifact as input. If AI both produces the artifact and decides it's done, you've lost the whole point of the handoff gate. The next phase's AI teammate will consume garbage and produce garbage-squared.

What to do instead.

• Keep a human audit at phase boundaries at minimum, even at L3 within a phase.
• The exit checklists are the minimum-viable version of this.

Where this shows up. L3 × any coverage. The faster you go, the more this hurts.

---

4. Autonomy set by vibes, not by blast radius

Why we think this. "We let AI do X because it felt safe" is how teams wake up to an incident. The question isn't "does it feel safe" — it's "what happens if this goes wrong and we don't notice?" That question has a real answer that can be written down. The HITL framework walks through how.

What to do instead.

• For each workflow you're about to push up the autonomy axis, answer the HITL framework questions in writing.
• Document the decision; it's an artifact too.

Where this shows up. Any L2-L3 move, especially on customer-facing or regulated surfaces.

---

5. Agent cards written before artifact docs exist

Why we think this. An agent card's inputs and outputs are artifacts. If the artifact docs don't describe what the artifact is, what it contains, and what "done" means, the agent card is fiction. You'll end up with an agent that produces something, but you can't verify it matches what the role is meant to produce.

What to do instead.

• Treat artifact docs as the contract. Agent cards are the implementation.
• If an artifact doc is missing or vague, fix it before writing the agent card.

Where this shows up. Early adoption — the most tempting time to skip this.

---

6. Skipping Discover because AI makes Build cheap

Why we think this. Build being cheap doesn't make Build correct. The Discover phase exists to answer whether the problem is real and whether you're the right team to solve it. Skipping it produces elegant solutions to problems nobody has — now faster than ever.

What to do instead.

• Let AI accelerate Discover (market scans, persona synthesis, ROI drafts). Don't skip it.
• Keep the Discover exit gate honest. "We're already building it" is not a gate criterion.

Where this shows up. When Build autonomy outpaces Discover investment.

---

7. Treating AI output as source of truth rather than draft

Why we think this. When humans copy AI output into a system of record without a review pass, errors compound silently. The system of record is trusted; the AI was guessing. The downstream consumer has no way to tell them apart.

What to do instead.

• Every AI output lands with a provenance marker (commit message, doc footer) at minimum.
• A human review step is required to promote AI output to "source of truth" status — until your DoD is precise enough that the review is mechanical.

Where this shows up. L1-L2 × any coverage, especially in docs and data workflows.

---

8. Letting AI choose tools without governance

Why we think this. The Tools section of each role exists because where an artifact lives matters. If every AI teammate picks a different place to write the same artifact, you get tool sprawl, duplicate sources of truth, and a security team that can't tell what's where.

What to do instead.

• Pick the tools per role before enabling the agent.
• If an agent wants a new tool, treat it as a governance request, not a config flag.

Where this shows up. Cross-phase coverage, when multiple agents need to share state.

---

9. No escalation triggers — AI runs until something breaks

Why we think this. L3 autonomy without named escalation triggers isn't autonomy — it's a production incident waiting for a trigger you haven't written down. The agent will hit edge cases; the question is whether it knows to stop.

What to do instead.

• List escalation triggers in the agent card before enabling L3.
• "Confidence below threshold" is not a trigger. "Regulated data touched," "production DB migration proposed," "customer-facing copy generated" are triggers.

Where this shows up. Any L3 × anything.

---

10. Uniform autonomy across roles (chasing symmetry on the grid)

Why we think this. The grid invites teams to read "L2 across all roles" as the target. It isn't. Different roles have different risk profiles — a Developer at L2 with a human code reviewer is different from a Security reviewer at L2 signing off on controls. Forcing symmetry means over-trusting one role or under-using another.

What to do instead.

• Set the autonomy target per role, not per team.
• Revisit quarterly. Some roles will move faster than others; that's success, not inconsistency.

Where this shows up. Teams trying to "roll out AI" as a single program.

---

11. Measuring velocity instead of leverage

Why we think this. "We ship faster" is true and insufficient. The value of AI in the PDLC isn't more of the same — it's being able to do things that were uneconomic before (thorough Discover, comprehensive threat modeling, writing the docs before the code, keeping the ADR current). If you're only measuring velocity, you'll de-prioritize the leverage.

What to do instead.

• Add at least one leverage metric: "Discover artifacts per initiative," "threat models per service," "ADRs per quarter."
• Watch those move alongside velocity.

Where this shows up. Teams reporting wins to leadership.

---

12. Treating AI adoption as a tool rollout, not a culture change

Why we think this. Rolling out AI with the same playbook as a new CI system (pilot → train → enable) misses that the work itself changes. Role boundaries shift, what "done" means shifts, what a reviewer's job is shifts. The tool works; the team doesn't use it well.

What to do instead.

• Read the role docs with your team and ask "what changes for me?"
• Retros should include "did AI change how we worked this sprint?" as a standing question.

Where this shows up. Month two of any adoption — the tool works, the culture hasn't caught up.

Formats — Bridging Named Docs and Shareable Bundles

Teams arrive at this handbook with their own document formats and leave wanting to share their work with others. This doc answers both:

1. Inbound — if you already have a PRFAQ, PRD, or other named format, which handbook artifacts does it cover? 2. Outbound — what's the recipe for a zip-and-share bundle at common handoff moments? 3. Bundle conventions — what a shareable bundle contains beyond the artifacts themselves.

v1, opinionated. These mappings are a starting point. If a format you use isn't here or you disagree with a mapping, file a PR.

---

1. Inbound — named format → handbook artifact mapping

Each row shows what the named format typically covers fully, what it covers partially, and what a team would still need to generate to reach a complete handbook artifact set for Discover and Define.

PRFAQ (press release + FAQ)

• Fully covers: opportunity brief, vision statement, outcome hypothesis.
• Partially covers: validated problem statement, business case, user personas (implicit in the customer voice).
• Typically missing: ROI model, market analysis report, feasibility memo, stakeholder map.

PRD (product requirements document)

• Fully covers: requirements document.
• Partially covers: MVP scope statement, NFR document, testable acceptance criteria, KPI definitions.
• Typically missing: outcome hypothesis, product roadmap, effort estimates, dependency list.

6-pager / executive memo

• Fully covers: opportunity brief, strategic alignment statement.
• Partially covers: business case, ROI model, competitive landscape report.
• Typically missing: validated problem statement, user personas, feasibility memo.

Lean canvas / business model canvas

• Fully covers: opportunity sizing.
• Partially covers: business case, user personas, pricing benchmark report.
• Typically missing: vision statement, outcome hypothesis, validated problem statement, ROI model.

Opportunity canvas / Jobs-to-be-Done statement

• Fully covers: outcome hypothesis, validated problem statement (hypothesized form).
• Partially covers: opportunity brief, user personas.
• Typically missing: business case, vision statement, ROI model.

Wireframes / design mocks

• Fully covers: visual design mockups.
• Partially covers: IA spec, interactive prototype, design specification.
• Typically missing: journey map / service blueprint, usability findings, accessibility design report.

User story map

• Fully covers: product roadmap.
• Partially covers: MVP scope statement, the backlog entries consumed in Plan.
• Typically missing: testable acceptance criteria, NFR document, effort estimates.

ADR / RFC

• Fully covers: An entry in architecture decision records, decision log from design reviews.
• Partially covers: architecture document (one decision's worth), build-vs-buy decision.
• Typically missing: The broader design package (API spec, data model, threat model).

OKRs / objectives document

• Fully covers: KPI definitions (lagging measures), approximations of the outcome hypothesis (leading).
• Partially covers: business case success framing, strategic alignment statement.
• Typically missing: Everything about how — requirements, scope, roadmap, plan, and the per-phase handoffs.

---

2. Outbound — bundle recipes (zip-and-share)

Named bundles for common handoff moments. Each recipe lists the artifacts to include, the intended reader, and a "ready to share" check. Bundles are generated by path 6 of the navigator skill or assembled manually.

Vision bundle

Intended reader: Executive sponsors deciding whether to fund further Discover.

• opportunity brief
• business case
• ROI model
• strategic alignment statement
• validated problem statement

Ready to share when: every artifact's Definition of Done is green and the business case references the ROI model by version.

Kickoff bundle

Intended reader: An incoming delivery team at Plan start.

• signed product charter
• product roadmap
• MVP scope statement
• KPI definitions
• testable acceptance criteria
• risk register
• dependency list

Ready to share when: the charter is signed, the MVP scope is stable, and KPIs are instrumented (or explicitly planned for instrumentation in Build).

Build-start bundle

Intended reader: Engineering, QA, and design partners starting Build.

• approved design package
• build-ready package
• API specification
• data model
• NFR document
• test plan
• feature flag plan
• telemetry plan

Ready to share when: the Design exit checklist passes.

Design-partner bundle

Intended reader: Early customers invited to co-create or validate.

• vision statement
• user personas
• interactive prototype
• journey map / service blueprint

Ready to share when: the prototype is shareable in the target environment and the vision is stable enough to survive customer feedback.

Launch-readiness bundle

Intended reader: Go/no-go reviewers at the Launch gate.

• launch-readiness assessment
• verified KPI telemetry
• approved known-issues & risk acceptance
• rollback safety sign-off
• go/no-go decision package

Ready to share when: the Verify exit checklist passes.

Board / investor bundle

Intended reader: Board or investor update. Use sparingly — high-stakes, high-visibility.

• board/investor launch narrative
• revenue report
• operational performance review
• updated roadmap

Ready to share when: metrics are current within the board's reporting window and the narrative references them by date.

---

3. Bundle conventions

Every shareable bundle — whether generated by the skill or hand-assembled — should include the artifacts plus:

• `README.md` manifest at the top level. One-line description per included file, grouped by phase. Name the bundle recipe used (e.g., "Vision bundle v1"). Name the source handbook (link to the repo) and the version or date.
• `traceability.md` linking each generated artifact back to the source document(s) it draws from. Makes review fast and surfaces gaps.
• Top-of-file pointer in every artifact back to the handbook, so a recipient can go deeper if they want the canonical definition.
• No deep-links into `phases/` paths from inside the bundle. Links inside the bundle are relative to the bundle root. External links go to the handbook.
• `_TBD: <note>_` placeholders wherever an artifact was generated from a seed doc that didn't cover that field — never silently invent. The manifest calls out which artifacts have material TBDs.

These rules let the bundle render standalone when zipped, so the recipient doesn't need access to the handbook to read the work.

HITL Framework — Drawing Your Own Line

There is no universally right answer to "how much autonomy should we give an AI teammate." The answer depends on your risk posture, your regulatory context, your blast radius, and your organization's maturity. This doc is a framework for making that decision consistently, not a recommendation of where to land.

Every agent card in this repo points here for its autonomy setting. Agent cards describe what an agent does; this doc describes how much your organization trusts it to do so.

The five axes

When deciding autonomy for a given workflow, score it on each axis. Higher scores push you toward lower autonomy (more human involvement).

1. Blast radius

Who or what is affected if this goes wrong?

• Low: only the AI teammate's own workspace; a draft file, a scratch branch.
• Medium: internal artifacts visible to the team; an updated backlog, a generated test.
• High: production systems, customer-facing surfaces, regulated data, financial commitments.

2. Reversibility

How hard is it to undo?

• Low (easy to reverse): git revert, delete a draft, re-run the workflow.
• Medium: requires a rollback script, a migration reversal, a comms correction.
• High (hard or impossible to reverse): money moved, customer emailed, data deleted, PII disclosed.

3. Regulated / audited

Is this work subject to external or internal compliance review?

• Low: not regulated, not audited.
• Medium: subject to internal audit but not external regulation (e.g., SOC2 controls).
• High: subject to external regulation with specific human-in-the-loop requirements (financial services, healthcare, aerospace).

4. Customer-facing

Can a customer see the output directly?

• Low: internal-only; customers never see this artifact.
• Medium: visible indirectly (e.g., influences a product decision).
• High: directly customer-facing — emails, generated content, pricing, UI copy.

5. Cost of a false positive / false negative

What does a mistake cost?

• Low: re-run the workflow, trivial cost.
• Medium: engineering time to diagnose and correct; possible minor customer impact.
• High: significant financial cost, customer loss, reputational damage, regulatory exposure.

The eight questions to ask

For each new AI-teammate deployment or autonomy change:

1. Blast radius: If this agent is wrong 5% of the time, what's the cumulative damage over a month? 2. Reversibility: What would the rollback procedure look like? Has anyone tested it? 3. Auditability: If a regulator asks "what did the AI do and why," can we answer in full? 4. Customer surface: Does this touch a customer-facing artifact? Under what circumstances? 5. Escalation: What conditions should end the agent's turn and require a human? Are those conditions precise enough to be tested? 6. Owner: Who is the named human accountable for this agent's scope and policy? (If the answer is "the team," it's no one.) 7. Review cadence: How often do we inspect a sample of the agent's output? What change in output triggers an unplanned review? 8. Exit ramp: If this doesn't work out, how fast can we revert to L0 or L1? What's the operational cost?

If you can answer all eight in writing, you have the basis for an informed autonomy decision. If you can't, you're not ready to make the move.

Worked archetypes

These are examples of how different organizations might land, not recommendations. Your team will land somewhere similar or different based on your specific context.

Archetype A: Regulated enterprise

Context: Financial services, healthcare, or similar. SOC2 + external regulator. Change management is a formal process. Auditability is non-negotiable.

• Most workflows stay at L1: AI drafts, human owns and signs.
• A narrow set of internal-only, low-blast-radius workflows may reach L2 (e.g., generating test data for non-prod environments).
• L3 is rare and reserved for workflows where the escalation triggers can be defined mechanically and tested. Autonomous dependency patching in non-prod might qualify.
• Customer-facing AI output is L0 or L1 with mandatory legal review.

Archetype B: Growth-stage startup

Context: Series B-C, shipping fast, limited internal audit function, competitive pressure on velocity.

• Most internal workflows reach L2 quickly: AI drafts and revises, humans audit at artifact-done time.
• Cross-phase handoffs reach L2 within a year — the exit checklists are the audit.
• L3 applies to narrow, well-instrumented workflows (dependency updates, documentation sync, test generation).
• Customer-facing AI output goes through L1 with human review before publish — not as a policy matter, as a brand-quality matter.

Archetype C: Internal-only tooling team

Context: Platform or developer-tools team building for internal consumers. No external regulator. Blast radius is usually bounded to engineering.

• L2 is the default after a short L1 warmup.
• L3 applies widely because blast radius is low and reversibility is high.
• The main risk is coverage — if AI teammates span too many workflows without coordination, tool sprawl and conflicting outputs emerge. Governance of tool choice (see anti-pattern #8) matters more than governance of autonomy.
• Customer-facing axis is mostly N/A.

What this framework deliberately doesn't say

• What autonomy you should pick. Not our call.
• Which artifacts are always L0. Varies by your context.
• How to enforce the policy. Your org's existing governance tools — change management, PR review, audit — are the enforcement layer. This framework is the decision layer.

Where this plugs in

• The maturity model describes the axes you move along.
• The anti-patterns describe failure modes at specific cells.
• The objection-handling doc shows how this framework answers common pushback.
• Agent cards reference this doc for their autonomy setting.

AI Maturity Assessment

A structured way to answer "how AI-mature are we?" The assessment uses two lenses:

1. Automation lens — per-phase automation coverage, labeled Sporadic / Isolated / Struggling / Scaling / Mature. Can be run org-wide (14 roles × 9 phases) or role-level (1 role × 9 phases). 2. Readiness lens — five organizational dimensions (Strategy & Governance, Data, Tech Infrastructure & Tools, Workforce & Skills, Culture), labeled on the same 5-tier scale. Org-level only.

Together they answer two different questions. Automation asks "how much of the work is AI-assisted today?" Readiness asks "is the org positioned for that automation to stick and scale?" A team can have high automation and low readiness (built it, but won't scale) or low automation and high readiness (ready to go, haven't shipped).

Label source. The 5-tier vocabulary (Sporadic, Isolated, Struggling, Scaling, Mature) and the five readiness dimensions come from an internal AWS maturity model developed by a partner team. This doc adopts them directly so customers see one consistent vocabulary across AWS materials.

This complements the maturity model. The maturity model is the tactical picker — for one workflow, it helps a team decide "what autonomy level × coverage should we aim for next?" This assessment is the strategic scorecard — it tells you where you are today across automation and readiness, so you can decide where to invest.

Why this matters

A mature AI-PDLC org has high automation across all roles and phases, backed by strategy, data, infrastructure, workforce, and culture that support it sticking. Not every role is necessarily performed by a person — some roles or role-tasks can be fully autonomous within named escalation triggers (see HITL framework). The observable results: cycle times drop (handoffs compress, reviews shorten) and ship velocity rises (more features through the pipeline per unit time, at the same or better quality).

This assessment doesn't measure cycle time or velocity directly — those are outcomes. It measures the drivers so you can diagnose why cycle times or velocity aren't improving.

Scope options

Org-level assessment

Walks all 14 roles across all 9 phases (automation lens) and all 5 readiness dimensions. Use this when:

• You're planning a program-level AI adoption push.
• You're reporting maturity to leadership.
• You want to spot cross-role gaps (e.g., "Build is Scaling but Verify is Sporadic, so fast code still waits at the gate") or automation/readiness mismatches.

Role-level assessment

Walks one role across all 9 phases (automation lens only; the readiness lens is org-wide and doesn't apply to a single role). Use this when:

• You're planning AI adoption for a specific role's team.
• You want to know where the biggest leverage is within one role's lifecycle.
• You're a role owner (Developer team lead, QA manager, etc.) preparing a pitch.

---

Lens 1 — Automation

Methodology — interview

Assessment runs as an interview, not a self-score questionnaire. For each activity, ask the user to describe how they currently do the work in their own words. State the score back for confirmation before moving on.

For each phase × role cell in scope, enumerate the activities, artifacts, and outcomes that role owns (A) or co-owns (R) in that phase. Source from:

• The role's RACI table in roles/<role>.md (primary and co-owned).
• The phase's exit checklist in phases/<N>-<slug>/README.md.
• The activity lines in AI-PDLC-linear-flow.md under that phase.

Example interview questions:

Capture the tools they name as they describe each activity — product names, not categories. Keep a running list; use it to build the Tools Used section of the report.

From the interview answer, derive two columns:

• Maturity — one of the 5-tier labels: Sporadic, Isolated, Struggling, Scaling, Mature.
• Approach — Assistive or Autonomous. Blank when Maturity is Sporadic.

Activity-level scoring:

Confirm the maturity before moving on: "Sounds like that's currently Scaling with Assistive approach — AI drafts the first pass, you edit, it's part of your routine. Correct?" Fix on disagreement. For ambiguity, prefer the more conservative label and note the uncertainty.

Batch only after the user demonstrates fluency. The skill can offer "if the next three are the same, say 'same,'" but only after the user has seen the pattern a few times.

Phase label rubric

Roll each phase up using the 5-tier scale based on the % of activities with any AI assistance (Assistive + Autonomous):

Ties break up: if a phase is on a boundary (e.g., 20% vs. 21%), weight Autonomous activities more heavily — they indicate deeper adoption.

Potential automation targets per phase

For each phase scored, after the activity table, add a Potential automation targets subsection. List 3-5 activities where AI could advance the maturity (Sporadic → Isolated/Scaling; Scaling Assistive → Mature Autonomous). For each target:

• Name the activity and its current Maturity/Approach.
• Describe how the automation would work in 1-2 sentences — the concrete mechanic, not the abstraction. "Claude Code watches Datadog against a 7-day baseline and posts an anomaly summary to the launch bridge every 5 minutes" beats "AI-assisted launch monitoring."
• Name what would move on the Maturity/Approach columns ("Scaling / Assistive → Mature / Autonomous").

Skip this subsection for phases where all activities are already Mature / Autonomous or where the role has zero activities in that phase.

Automation rollup — role-level

One table, nine rows:

Plus a short summary: strongest phase, weakest phase, cross-phase patterns (e.g., "Discover through Design is Scaling; Build through Operate is Isolated" — a common shape that tells you where to invest next).

Automation rollup — org-level

A matrix: 14 roles × 9 phases, cells = label. Plus:

• Per-phase label (weighted by activity count across roles) — the phase maturity.
• Per-role label (weighted by activity count across phases) — the role maturity.
• A summary with the top 3 leverage opportunities.

---

Lens 2 — Readiness (org-level only)

The readiness lens answers whether the org is positioned for its automation to stick and scale. Each dimension is scored on the same 5-tier scale. Score from the team's observed state — don't grade aspirationally.

Dimension 1 — Strategy & Governance

Dimension 2 — Data

Dimension 3 — Tech Infrastructure & Tools

Dimension 4 — Workforce & Skills

Dimension 5 — Culture

Readiness rollup

A single table:

Plus a short summary: the lowest-scoring dimension is usually the one that will drag the others back if left alone. Name it explicitly.

---

Cross-lens diagnosis

After scoring both lenses, look for mismatches:

Record the diagnosis in the report.

---

How this relates to the maturity model

The maturity model is a tactical picker — for one workflow, it helps a team decide "what autonomy level × coverage should we aim for next?" The 2D grid is about a workflow's current and target state.

The assessment is a strategic scorecard — it tells you where you are today across automation and readiness, so you can decide where to invest.

Loose mapping from an automation label to the maturity model grid:

• Sporadic → L0 regardless of coverage.
• Isolated → usually L1 × single-role.
• Struggling → L1-L2 × single-role or single-phase; rarely cross-phase.
• Scaling → L1-L2 × single-phase or cross-phase.
• Mature → L2-L3 × cross-phase or full lifecycle.

Use them together: the assessment tells you where you are; the maturity model helps you pick a reasonable next step for one workflow; anti-patterns tells you what to watch out for when you move.

---

What a Mature org looks like

• Most activities across most phases are AI-accelerated. Human attention concentrates at phase boundaries (exit checklists) and escalation triggers.
• Some roles or role-tasks are fully autonomous. Dependency patching, test generation, documentation sync, KPI monitoring, release-notes drafting, incident summarization — these lean autonomous in mature orgs.
• Strategy, data, infra, workforce, and culture all support it. No single dimension is dragging.
• Cycle times are compressed. Handoffs that took days now take minutes; reviews that took hours now take seconds. The exit checklists still gate quality, but the work to meet them is mostly automated.
• Feature ship velocity is maximized relative to the team's quality bar. More features through the pipeline at the same or better defect rate. Velocity is a symptom of maturity, not a score input — but a Mature org sees it reliably.

---

Running the assessment

The navigator skill path 7 orchestrates this interactively: collects scope, walks the activities, computes the labels, writes a report. You can also run it manually by following this doc.

Recording the assessment

Save the report(s) to ./artifacts/ in the user's project root (not this handbook repo).

Role-level scope

Write a per-role markdown artifact at ./artifacts/YYYY-MM-DD-<role-slug>-maturity.md — one file per role assessed. Using the handbook's role slug (developer, site-reliability-engineer, product-owner, etc.) keeps the filename stable across re-runs and makes diffs meaningful.

Each role artifact contains:

• Scope — role name and slug, date run.
• Lens 1 (Automation) — for each phase the role owns activities in:
• An activity table with columns: Activity | Artifact/Outcome | Maturity | Approach | Notes. Maturity is the 5-tier label (Sporadic/Isolated/Struggling/Scaling/Mature); Approach is Assistive or Autonomous (blank when Maturity is Sporadic). Notes cites the user's phrasing from the interview.
• A Potential automation targets subsection (see "Potential automation targets per phase" above).
• The phase label and a 1-2 sentence rationale.
• Rollup table — one row per phase. Columns: Phase / Activities / Sporadic / Isolated / Struggling / Scaling / Mature / Assistive (count) / Autonomous (count) / Label.
• Cross-phase pattern — strongest phase, weakest phase, observed pattern (e.g., "Discover through Design is Scaling; Build through Operate is Isolated").
• Top 3 leverage opportunities for this role, each grounded in a named activity or artifact.
• A concrete "next tier" picture for this role — what moving one label up would look like in practice.
• Tools used — a table of every product the user named during the interview, grouped by handbook capability category. Columns: Capability / Tool / Used for (list of activities in this assessment where the tool came up). This doubles as a mini tools inventory for this role; link to the full inventory if path 3 has been run.

If multiple roles are assessed in the same session, write one file per role. Do not combine them.

Org-level scope

Write:

• One per-role artifact at ./artifacts/YYYY-MM-DD-<role-slug>-maturity.md for each of the 14 roles — same shape as the role-level output above.
• A rollup artifact at ./artifacts/YYYY-MM-DD-org-maturity.md containing the 14×9 automation matrix, the 5-dimension readiness table, the cross-lens diagnosis, org-wide top 3 leverage opportunities, and the concrete Mature picture for the org. The rollup links to each per-role artifact.

This way a customer can share the Developer artifact with engineering leadership without also handing over the Product Sponsor assessment, while the rollup stays the single source of truth for the org view.

Re-running

Re-run quarterly or after a significant AI adoption push. Because filenames are role-slug-keyed, the newest run overwrites or sits alongside the previous one — diff against the previous file to track progress per role.

AI-PDLC Maturity Model — the tactical picker

A tool for self-locating one workflow on an AI-adoption curve. Two axes, sixteen cells. Your team can legitimately sit in different cells for different workflows — uniformity is not the goal, deliberate progress is.

Pair with the [Maturity Assessment](maturity-assessment.md) — the strategic scorecard. The assessment tells you where you are across the org (automation + readiness, 5-tier Sporadic → Mature). This model helps you decide where to aim next for a specific workflow. Use them together: the assessment diagnoses; this model picks the next move.

This is one of the adoption docs. Read it alongside anti-patterns, objection-handling, and the HITL framework.

Axis 1 — Autonomy (Y)

How much of the work AI does versus a human:

Moving up this axis is about trust and evidence, not about the model being smarter. You earn L2 from L1 by accumulating cases where the human's edits were trivial. You earn L3 from L2 by defining what "exception" means precisely enough that you're comfortable not reading every output.

Axis 2 — Coverage (X)

How much of the lifecycle your AI teammate covers:

Moving right is about workflow integration, not about replacing more people. The hardest step is usually single-role → single-phase: that's where you discover whether your artifact DoDs are precise enough to serve as inputs to the next role.

The grid

Each cell is a legitimate place to operate.

How to read this

• Your team is probably not in one cell. You might be L2 × single-role for code review and L0 × everywhere-else. That's fine. Pick the cell per workflow, not per team.
• Don't chase uniformity. Forcing every role to L2 at the same time guarantees some of them are there for the wrong reasons.
• Progress is cell-by-cell, not a tidal wave. One role moving from L1 to L2 is a real win. Don't discount it because the broader team is L1.

How to move up on the autonomy axis

• L0 → L1: pick one high-volume, low-blast-radius artifact in one role. Let AI draft it. Measure how often the human's edits are substantive.
• L1 → L2: when substantive edits are rare over a meaningful sample, shift the human from editor to auditor. Define what a failed audit looks like.
• L2 → L3: define escalation triggers — what conditions must end the agent's turn and pull a human in? Without precise triggers, L3 is irresponsible, not ambitious.

How to move right on the coverage axis

• Single-role → single-phase: make sure every artifact in that phase has a Definition of Done. Without one, downstream AI teammates can't know if their input is ready.
• Single-phase → cross-phase: wire up the next phase's exit checklist. The earlier phase's AI output feeds the next phase's AI input — but a human still gates the boundary.
• Cross-phase → full lifecycle: usually not necessary. Most teams find diminishing returns past two or three adjacent phases automated end-to-end.

Where to go next

• If a cell you want is blocked: read anti-patterns for the cell you're trying to leave.
• If an exec or IC is pushing back on the next move: objection-handling.
• If you're unsure what autonomy is allowed for a given artifact: hitl-framework.

Objection Handling

v1, opinionated. These are the objections we think most commonly come up when a team starts adopting AI in the PDLC. The response patterns are a starting point, not scripts. If your experience suggests a better response, file a PR.

Each entry names the objection as it's usually heard, identifies who tends to voice it, names the fear underneath, and offers a response grounded in this repo.

---

1. "AI will make our engineers worse at their job"

Voiced by: Senior ICs, engineering leaders. Fear underneath: Skill atrophy, a team that can't operate without the tool, reduced ability to onboard juniors.

Response. It's a real risk at L3 autonomy without the L2 audit step — when humans stop reading the output, they stop learning from it. This is the core reason the maturity model staggers L2 as its own tier. At L2, humans still audit; the job shifts from editing to judging. That keeps the skill alive in a different form.

The actual skill atrophy risk is when a team jumps L0 → L3. That's not AI adoption, that's abdication.

---

2. "We can't have AI touching production code"

Voiced by: Security, SRE, ops leadership. Fear underneath: An incident caused by an AI commit, with no human to hold accountable.

Response. Agreed — and that's not what this repo asks for. The HITL framework is explicit that blast radius and reversibility drive the autonomy decision. Production code changes are high blast radius and usually low reversibility. Those workflows stay at L0 or L1, and the agent cards list the scope boundaries.

The mistake would be reading L3 as "AI merges to main." It isn't. L3 is "AI runs the workflow within its defined scope and escalates on named triggers."

---

3. "Our regulator won't allow this"

Voiced by: Compliance, legal, heads of regulated business units. Fear underneath: Audit findings, fines, loss of operating license.

Response. Which parts won't they allow? This is usually a question about data flow, provenance, and human accountability — all of which the HITL framework treats as decision axes. Most regulators don't prohibit AI assistance; they require documented controls, human accountability, and auditability. Those are features of this approach, not obstacles to it.

Start with the regulator's specific constraints. Map them to the axes. Usually the answer isn't "no AI" — it's "AI at L1, with audit logs, in these named workflows."

---

4. "We tried an AI pilot; it didn't stick"

Voiced by: Leaders who've been through a failed pilot. Fear underneath: Wasted time, embarrassment, another pilot going the same way.

Response. Pilots usually fail for one of three reasons: (1) no clear role or artifact to own, (2) the team jumped to L3 on day one, (3) no measurement of whether the work improved. This repo addresses all three — the role cards give ownership, the maturity model enforces a staged path, and the exit checklists make "improved" concrete.

What matters: start at L1 in one role, pick something with a DoD, measure substantive edits over 4-6 weeks. That's a meaningful pilot.

---

5. "This just speeds up the wrong thing"

Voiced by: Product leaders, senior PMs. Fear underneath: Faster delivery of features nobody asked for, more tech debt, louder backlog without more value.

Response. Agreed — and that's why we don't start at Build. The Discover and Define phases are where AI can have the biggest leverage precisely because they were under-invested when humans did all the work. The leverage anti-pattern is #11 — don't just measure velocity.

If your team is only speeding up Build, you have a prioritization problem, not an AI problem. AI makes it more visible.

---

6. "Our team won't trust AI output"

Voiced by: Team leads, delivery managers. Fear underneath: Low adoption, duplicated work ("I'll check everything anyway"), silent abandonment.

Response. Trust is earned over cases, not declared. The maturity model is explicitly staged around this: at L1, nobody is asked to trust output; humans edit and own it. Trust builds when humans notice their edits are trivial. That's the L1 → L2 signal.

Trying to force trust through a policy doesn't work. Let people stay at L1 as long as they need to.

---

7. "We'd have to rewrite our PDLC"

Voiced by: Process owners, PMO, senior delivery leaders. Fear underneath: Massive change-management cost, consultants, a year of disruption.

Response. You don't. This repo is intentionally laid out as additions to what most teams already do — roles, phases, artifacts, DoDs. The agent cards bind to existing roles; the exit checklists add precision to handoffs that were already happening. If your current PDLC is close to what this repo describes, the delta is small.

Where it's larger, start with one phase. Don't rewrite. Instrument.

---

8. "We can't measure whether this is working"

Voiced by: Executives, finance, anyone asked to fund the effort. Fear underneath: Can't justify continued investment, can't course-correct, can't tell success from noise.

Response. Use the axes. Velocity is the obvious metric and usually the wrong one alone. Better:

• Substantive-edit rate on AI-drafted artifacts (falling = earned L2).
• Artifact coverage per phase (are all DoDs met at gate?).
• Escalation rate at L3 (falling over time = triggers are tight enough).
• Leverage metrics from anti-pattern #11.

None require new tooling — they derive from your existing artifact inventory.

---

9. "We're too small / too big for this"

Voiced by: Both small and large orgs, for opposite reasons. Fear underneath: (Small) this is over-engineered for us. (Large) this will never survive our complexity.

Response. The role and phase model is a description, not a prescription. Small teams collapse roles onto fewer people and skip phases that don't apply. Large teams add roles, split phases, and layer governance — the HITL framework accommodates more complex autonomy decisions.

The pattern is the same at both scales: named roles, artifacts with DoDs, staged autonomy. Implementation varies wildly.

---

10. "Who's accountable when the AI is wrong?"

Voiced by: Executives, legal, risk. Fear underneath: Diffused accountability, nobody to fire, inability to explain what happened to a regulator or a board.

Response. Accountability stays with the human who signs the artifact. At L1, that's the editor. At L2, that's the auditor. At L3, that's whoever defined the escalation triggers and the agent's scope. The agent cards and HITL framework are explicit that autonomy is a customer policy decision — meaning there is always a policy-owner, and that's your accountable human.

"The AI did it" is not a defensible answer. "A human approved scope X with triggers Y; the system operated within that scope and escalated when expected" is.

Adoption — Where to Start

You found this repo. Your team is considering (or actively deploying) AI teammates across your PDLC. This dir is for you.

The rest of the repo describes what an AI-powered product lifecycle looks like — 9 phases, 14 roles, their artifacts, and their handoffs. This dir answers how a customer team adopts it without the common failure modes.

The journey

1. Self-locate. Read the maturity model — a 2D grid of autonomy × coverage. Find the cell your team is in today. Pick the cell you want to be in. 2. Check the anti-patterns. Read anti-patterns for the cell you're leaving. Most adoption failures aren't from the destination being wrong; they're from skipping steps on the way. 3. Prepare for pushback. Read objection-handling. Whoever will resist this adoption move is on that list, and you'll want the response pattern ready before the conversation. 4. Set your autonomy policy. Read the HITL framework — a framework for deciding how much autonomy a given workflow should have, grounded in blast radius, reversibility, regulation, customer surface, and cost of mistakes. This is explicitly a framework, not a prescription. 5. Pick a phase and a role. Go to the phase list and role list. Pick one role in one phase as the starting point.

Measuring where you are today

The maturity model is the tactical picker — it helps you decide the next move for one workflow. The maturity assessment is the strategic scorecard — it tells you where you are across the org using two lenses: automation (per-phase AI coverage) and readiness (Strategy, Data, Infra, Workforce, Culture). Both use the shared 5-tier scale: Sporadic / Isolated / Struggling / Scaling / Mature. Run the assessment quarterly; use the model continuously as you plan workflow moves.

Bridging named formats in and out

If your team arrives with a PRFAQ, PRD, 6-pager, canvas, or other named format — or you want to assemble a shareable bundle at a handoff moment — see formats. It maps common inbound formats to handbook artifacts and defines named outbound bundle recipes (Vision, Kickoff, Build-start, Design-partner, Launch-readiness, Board/investor).

A note on voice

These docs are opinionated and labeled v1. Where we make a claim — especially in anti-patterns and objection-handling — we've tried to name why we think it. If your experience contradicts what's here, file a PR. That's the fastest way this gets better.

A note on what's not here

• Workshop kits. Not yet.
• A prescribed autonomy policy. Never. The line varies by customer; the HITL framework is how you find yours.
• Task-specific prompts. Not yet — on the roadmap.
• AWS-specific tooling. Intentionally tool-agnostic.

Architect in Discover

You are here to prevent a nice-sounding bet from being funded without a realistic technical cost attached. Discover is not the moment for architecture — it's the moment for directional feasibility and honest cost inputs so the business case doesn't rest on fantasy. Keep the read sharp, fast, and caveated; you'll have Define and Design to be precise.

What you do

• Technical cost & feasibility inputs — produce the ROI technical inputs that feed the BA's ROI model
• Contribute to the feasibility memo — flag the technical risks, unknowns, and cost drivers the business case must address
• Contribute to the strategic alignment statement — pressure-test fit with the enterprise technology strategy

Artifacts you own

• ROI technical inputs — order-of-magnitude build, run, and integration cost estimates with named assumptions

Artifacts you contribute to

• feasibility memo — owned by the Product Owner, you supply the technical risk and cost posture
• strategic alignment statement — owned by the Product Sponsor, you check fit with enterprise architecture standards

Outcomes you drive

You don't drive outcomes this phase — you input into the Sponsor's approved budget & investment commitment and Discover exit decision through cost credibility and risk flags.

Who you work with

• Product Owner — they need your honest feasibility read for the business case and feasibility memo
• Product Sponsor — they need your fit-with-strategy view for the portfolio decision
• Business Analyst — they plug your cost inputs into the ROI model; you need to know which scenarios they're pricing
• Security & Compliance — their regulatory and data-sensitivity flags may change your cost read materially

Handoff into Define

Your Discover inputs become the starting point for the real architectural work in Define — NFR definition, technical feasibility review, system-to-process mapping. The quality bar is that your cost estimates are honest enough that when Define sharpens them the ROI doesn't collapse. You're done when the Sponsor can fund the initiative knowing roughly what the run cost will look like, and you have a shortlist of the questions Define must answer.

business case

_Produced by: Business planning_

Business outcome supported: frame the opportunity, validate the problem, understand the market, and exit with a funded, strategically-aligned bet.

Primary owner: Product Owner

Stakeholders: Product Sponsor

What this is

The financial and strategic justification for investing in this initiative — what it will cost, what it will return, over what time horizon, and under what assumptions. This is the draft that becomes the approved business case in Define and the baseline every later phase measures actuals against.

Why it matters for the Product Owner

You co-author this with the Sponsor because it is the single document the org will use to decide whether to fund, pause, or kill the work. A sloppy business case gets picked apart in governance; a tight one buys you months of runway and credibility.

Definition of Done

• [ ] Executive summary names the bet and the ask in one paragraph.
• [ ] Benefits include explicit assumptions, not just headline numbers.
• [ ] Costs cover build, run, and opportunity over a 3-year horizon.
• [ ] NPV, payback, and at least one sensitivity range are computed.
• [ ] At least one re-forecast trigger is named.

What it contains

• Executive summary: the bet and the ask
• Strategic rationale and fit with portfolio priorities
• Target customer and expected adoption curve
• Revenue, cost-avoidance, or efficiency benefits with assumptions
• Build, run, and opportunity costs over a 3-year horizon
• NPV, payback period, and sensitivity ranges
• Key risks and what would cause a re-forecast

Inputs you rely on

• ROI model and ROI technical inputs
• Opportunity sizing and market analysis report
• Pricing benchmark report and competitive landscape report
• Feasibility memo for cost and risk posture
• Finance partner for method and corporate hurdle rates

Who consumes it

• Product Sponsor — ratifies it in Define and defends it in governance forums
• Business Analyst — traces benefits realization tracking back to these numbers throughout the lifecycle
• Architect — checks the cost assumptions against emerging technical choices in Design

Common pitfalls

• Precision theater — three-decimal-place forecasts built on two assumptions
• No sensitivity analysis, so one bad assumption invalidates the whole case silently
• Leaving out run-cost and the full ops burden — only counting build
• No named owner for tracking actuals vs. plan once the product ships

competitive landscape report

_Produced by: Competitor analysis_

Business outcome supported: frame the opportunity, validate the problem, understand the market, and exit with a funded, strategically-aligned bet.

Primary owner: Sales & Marketing

Stakeholders: _(none listed)_

What this is

A structured view of who else plays in or near the opportunity space — direct competitors, indirect substitutes, and the "good enough" status quo. It is how the org sees the table it is about to sit down at.

Why it matters for the Sales & Marketing owner

You produce this to protect pipeline and positioning before a single line of code is written. If a credible competitor already owns the category, your team should know before committing; if there is a clear position to take, your downstream messaging and pricing depend on it.

Definition of Done

• [ ] Direct competitor set lists product, pricing, target segments, and recent moves for each entry.
• [ ] At least one indirect substitute (including internal tools or spreadsheets) is named.
• [ ] Each competitor has strengths, weaknesses, and positioning recorded.
• [ ] At least one white-space opportunity is identified with defensibility rationale.
• [ ] Report carries a dated snapshot and source list.

What it contains

• Direct competitor set with product, pricing, target segments, and recent moves
• Indirect substitutes (including internal tools and spreadsheets)
• Strengths, weaknesses, and positioning of each
• Where customers are currently dissatisfied with the alternatives
• White-space opportunities and defensibility analysis
• Dated snapshot and sources so it can be refreshed cleanly

Inputs you rely on

• Win-loss data from sales if adjacent product exists
• Customer interviews from the BA's problem validation
• Analyst reports, review sites, public pricing pages
• Product teardown of top 2–3 competitors

Who consumes it

• Product Sponsor — uses it to test "is there room to play here?"
• Product Owner — uses white-space to shape MVP differentiation
• Business Analyst — feeds it into the business case and market analysis report
• Sales & Marketing (future) — evolves it into battlecards and launch positioning

Common pitfalls

• Feature-checklist battles that ignore customer jobs-to-be-done
• Ignoring the incumbent "spreadsheet + internal tool" — often the hardest competitor
• One-off snapshot with no refresh plan — competitors move in weeks
• Positioning in the gaps of competitors rather than the gaps in customer needs

data-sensitivity flag

_Produced by: Data sensitivity early read_

Business outcome supported: frame the opportunity, validate the problem, understand the market, and exit with a funded, strategically-aligned bet.

Primary owner: Security & Compliance

Stakeholders: _(none listed)_

What this is

An early, coarse read on the sensitivity of data the product will collect, process, store, or share. It flags the "this touches PHI" or "this handles payment data" reality before Architecture picks a stack that cannot support it.

Why it matters for the Security & Compliance owner

You produce this because data classification drives almost everything downstream — architecture, residency, retention, encryption, access, logging, and vendor choice. Missing a sensitivity tier in Discover silently constrains every subsequent decision in the wrong direction.

Definition of Done

• [ ] Expected data categories are enumerated (e.g., PII, PHI, PCI, credentials).
• [ ] Data subjects and their jurisdictions are named.
• [ ] Sources and sinks across the product boundary are listed.
• [ ] A preliminary classification tier is assigned against the org's scheme.
• [ ] At least one red-line category is stated.

What it contains

• Expected data categories (PII, PHI, PCI, financial, credentials, trade secrets)
• Data subjects and their jurisdictions
• Expected volume and velocity signals if known
• Sources and sinks (where data enters and exits the product boundary)
• Preliminary classification tier against the org's scheme
• Red lines (data categories the org has decided not to handle)

Inputs you rely on

• Opportunity brief and draft user journeys
• Regulatory risk flag for jurisdictional triggers
• Org data classification policy and tiering scheme
• Architect's early system-context sketch

Who consumes it

• Architect — uses it to rule candidate stacks and deployment models in or out
• Product Sponsor — sees the true regulatory gravity of the initiative
• Security & Compliance (future you) — promotes this into data inventory & classification and the privacy impact assessment in Define

Common pitfalls

• Assuming anonymized data is out-of-scope — re-identification risk is often underestimated
• Missing secondary data (logs, telemetry, support tickets) that may contain sensitive fields
• Inheriting stale classifications from a similar product without re-checking
• No red-line decisions, so the initiative drifts into regulated territory by accident

feasibility memo

_Produced by: Early feasibility / risk assessment_

Business outcome supported: frame the opportunity, validate the problem, understand the market, and exit with a funded, strategically-aligned bet.

Primary owner: Product Owner

Stakeholders: Architect, Product Sponsor

What this is

A short, honest read on whether the initiative is technically, operationally, legally, and commercially feasible before anyone commits serious money. It surfaces the "we cannot do this because…" constraints while they can still reshape scope cheaply.

Why it matters for the Product Owner

You produce this so the Sponsor is not asked to fund an initiative that the Architect already knows will collide with a data-residency rule or a capacity constraint. An early red flag here is worth ten late change requests.

Definition of Done

• [ ] Memo covers at least three feasibility dimensions (technical, operational, regulatory, commercial, or data).
• [ ] Each dimension carries a red/amber/green rating with supporting evidence.
• [ ] Known blockers include the conditions that would make them go-possible.
• [ ] At least one alternative (do-nothing, buy, partner, partial scope) is considered.
• [ ] Memo recommends next investigations to retire the biggest amber/red items.

What it contains

• Top 3–5 feasibility dimensions: technical, operational, regulatory, commercial, data
• Known blockers and the conditions under which they become go-possible
• Alternatives considered (do-nothing, buy, partner, partial scope)
• Red/amber/green rating per dimension with evidence
• Recommended next Discover investigations to retire the biggest amber/red items

Inputs you rely on

• Architect's early read on fit with current platform and patterns
• ROI technical inputs for cost-side constraints
• Regulatory risk flag and data-sensitivity flag
• Sponsor's portfolio view (is this a bet the org has appetite for?)

Who consumes it

• Product Sponsor — uses it to decide go / no-go / defer on further discovery spend
• Architect — carries amber items into Define's technical feasibility findings
• Business Analyst — drafts problem validation to specifically retire the risks flagged here

Common pitfalls

• Overconfident greens because no one wants to kill the idea early
• Missing the operational lane (support, ops, enablement cost) and only scoring build
• No retirement plan for amber items — they carry silently into Define as surprises
• Treating it as a one-time assessment instead of revisiting at each gate

initial project brief

_Produced by: Project initiation / pre-kickoff coordination_

Business outcome supported: frame the opportunity, validate the problem, understand the market, and exit with a funded, strategically-aligned bet.

Primary owner: Project Manager

Stakeholders: _(none listed)_

What this is

A one-page logistics brief that the PM uses to coordinate the Discover phase itself — who is doing what, when the gate review is, what risks are live, and what the team needs from the Sponsor. It is not the product brief; it is the project brief for the Discover phase.

Why it matters for the Project Manager

You produce this to run Discover like a project and not a set of disconnected artifacts drifting on their own timelines. It gives you a baseline to flag slippage early and a shared artifact to drive the pre-kickoff conversation.

Definition of Done

• [ ] Discover team members are named with their roles.
• [ ] Milestones and a stage-gate date are listed.
• [ ] Top 3-5 risks each have a named owner.
• [ ] Information and access needs from Sponsor, customers, or partners are specified.
• [ ] Budget and time box for the Discover phase are stated.

What it contains

• Named Discover team members and roles
• Discover milestones and the stage-gate date
• Working agreements and decision rights
• Top 3–5 risks with owners
• Information / access needs from Sponsor, customers, or partners
• Budget and time boxing for the Discover phase itself

Inputs you rely on

• Opportunity brief and Sponsor's framing
• Stakeholder map to know who needs what engagement
• Available capacity of Discover-phase contributors (BA, UI/UX, Architect, S&C)
• Portfolio calendar for competing commitments

Who consumes it

• Product Sponsor — uses it to know what to unblock and when to expect the gate
• Discover contributors — use it to plan their weeks and flag impediments
• Project Manager (future you) — evolves it into the Define-phase schedule draft

Common pitfalls

• Confusing it with the opportunity brief or charter — this is purely logistical
• Missing owners on risks, so risks drift
• No gate date, so Discover expands to fill the time
• Treating it as set-and-forget — update weekly as the phase evolves

market analysis report

_Produced by: Market & customer research_

Business outcome supported: frame the opportunity, validate the problem, understand the market, and exit with a funded, strategically-aligned bet.

Primary owner: Business Analyst

Stakeholders: _(none listed)_

What this is

A synthesis of market size, segmentation, trends, buyer behavior, and adjacent forces that affect whether the opportunity is real and growing. It is the evidence behind claims like "the market for X is growing 18% YoY" that show up in the business case.

Why it matters for the Business Analyst

You produce this so the organization is not investing on gut feel. The report is what you will point to when someone challenges the demand assumption in Define or when benefits start drifting in Operate and you need to recheck the market thesis.

Definition of Done

• [ ] TAM/SAM/SOM figures include methodology and sources, not just totals.
• [ ] Segments the product will and will not serve are named with rationale.
• [ ] Buyer, user, and economic-buyer roles are distinguished with jobs-to-be-done.
• [ ] At least one demand driver and one restraint are identified with direction and magnitude.
• [ ] Report carries a dated snapshot so it can be refreshed cleanly.

What it contains

• TAM / SAM / SOM with source-of-truth methodology, not back-of-envelope
• Segmentation and the segments you will and will not serve, with rationale
• Buyer / user / economic-buyer distinctions and their jobs-to-be-done
• Demand drivers and restraints, with direction and magnitude
• Adjacent and substitute solutions (including the "spreadsheet + intern" alternative)
• Geographies, channels, and regulatory windows worth noting

Inputs you rely on

• Primary interviews and surveys you ran during Discover
• Analyst reports, public filings, and industry data
• Support/VoC data if adjacent product already exists
• User personas work-in-progress for qualitative grounding

Who consumes it

• Product Sponsor — tests the "is this market worth playing in" question
• Product Owner — uses segmentation to sequence early adopter targets
• Sales & Marketing — feeds it into pricing benchmark and later GTM planning
• Business Analyst (future you) — references it during benefits-realization reviews

Common pitfalls

• Analyst-report pastiche with no original research to triangulate
• Single-point estimates where a range would be honest
• Segmenting by firmographics alone and missing behavioral segmentation
• No dated snapshot — markets move, and a 2-year-old report will mislead benefits tracking

opportunity brief

_Produced by: Ideation / opportunity framing_

Business outcome supported: frame the opportunity, validate the problem, understand the market, and exit with a funded, strategically-aligned bet.

Primary owner: Product Owner

Stakeholders: _(none listed)_

What this is

A short, one-to-two-page framing of an opportunity worth exploring — who the customer is, what is broken, why now, and the shape of the bet. It is the first durable artifact of the lifecycle and the seed every other Discover doc grows from.

Why it matters for the Product Owner

You write this to put a stake in the ground before the organization spins cycles on something unclear. It gives you a defensible frame when the Sponsor, Architect, and BA start pulling the opportunity in different directions, and it is the fastest way to decide whether to invest more discovery effort or pass.

Definition of Done

• [ ] One-sentence opportunity statement identifies customer, pain, and desired outcome.
• [ ] Current state and cost-of-inaction are named.
• [ ] At least one hypothesized customer segment is identified.
• [ ] "Why now" is grounded in a specific trigger (market, regulatory, or internal).
• [ ] At least one kill criterion is stated.

What it contains

• One-sentence opportunity statement (who, pain, desired outcome)
• Current state and the cost of doing nothing
• Hypothesized customer segments and primary personas
• "Why now" — market, regulatory, or internal triggers
• Rough size-of-prize and strategic fit
• Known unknowns and what would kill the idea
• Proposed next Discover activities and owners

Inputs you rely on

• Customer signals — support tickets, sales losses, field anecdotes, VoC
• Portfolio/strategy context from the Product Sponsor
• Market rumblings and competitive moves
• Internal capability or constraint triggers (tech debt, compliance deadlines)

Who consumes it

• Product Sponsor — uses it to decide whether to fund further Discover work
• Business Analyst — uses it as the starting scope for market analysis and problem validation
• UI/UX Designer and Architect — scan it to sense-check personas and feasibility before committing research time

Common pitfalls

• Writing a solution brief instead of an opportunity brief — you have jumped to "build X" without evidence of a problem
• Over-specifying the customer segment too early and locking out valid adjacencies
• No "kill criteria" — if nothing would stop the idea, nothing will validate it either
• Treating it as a one-shot doc; it should evolve as Discover evidence accumulates

opportunity sizing

_Produced by: Problem-opportunity analysis_

Business outcome supported: frame the opportunity, validate the problem, understand the market, and exit with a funded, strategically-aligned bet.

Primary owner: Business Analyst

Stakeholders: _(none listed)_

What this is

A quantified view of how much value the opportunity could generate if the validated problem were solved — expressed in revenue, cost avoided, hours reclaimed, or whatever currency the Sponsor cares about. It is the bridge between the market analysis and the financial case.

Why it matters for the Business Analyst

You produce this to replace hand-waving with a range. It is what differentiates opportunities that "feel big" from opportunities that are actually big enough to justify the investment, and it is the input the Sponsor will argue about in governance.

Definition of Done

• [ ] Target addressable population is quantified with the reach mechanism named.
• [ ] Per-unit value (revenue, hours saved, tickets deflected) is stated in the Sponsor's currency.
• [ ] Adoption and penetration assumptions cover a 3-year horizon.
• [ ] Best, expected, and worst case sizings are each shown with their drivers.
• [ ] At least one upside-gating dependency (capacity, enablement, regulatory) is listed.

What it contains

• Target addressable population and how you reach them
• Per-unit value (revenue per customer, hours saved per task, tickets deflected)
• Adoption and penetration assumptions over a 3-year horizon
• Best/expected/worst case sizings with explicit drivers
• Dependencies (capacity, enablement, regulatory approval) that gate the upside
• Comparison to a credible alternative use of the same investment

Inputs you rely on

• Market analysis report and validated problem statement
• User personas for volume and behavior assumptions
• Pricing benchmark report for per-unit value
• Finance-approved discount rates and adoption curve conventions

Who consumes it

• Business Analyst — feeds it into the ROI model and business case
• Product Sponsor — uses it to rank this opportunity against other portfolio bets
• Product Owner — uses it to prioritize which segments to sequence first

Common pitfalls

• Assuming 100% of the addressable market adopts — cut by reasonable penetration
• Double-counting benefits that overlap with an existing initiative
• Mixing one-time and recurring benefits without labeling
• No worst case, so the range looks like a forecast rather than a sizing

outcome hypothesis

_Produced by: Problem-solution fit hypothesis_

Business outcome supported: frame the opportunity, validate the problem, understand the market, and exit with a funded, strategically-aligned bet.

Primary owner: Product Owner

Stakeholders: _(none listed)_

What this is

A falsifiable statement of the form "we believe [persona] will [behavior change] because of [intervention], resulting in [measurable outcome]." It turns a vague "this should help" into something Discover and later phases can actually test.

Why it matters for the Product Owner

You produce this so every downstream experiment, MVP choice, and KPI has a clear target to validate against. Without a crisp hypothesis, teams ship features and then argue afterwards about whether they "worked" — which is exactly how sunk-cost builds happen.

Definition of Done

• [ ] Hypothesis names a target persona and their current behavior.
• [ ] The intervention (product capability or change) is specified.
• [ ] The expected behavior change is stated.
• [ ] A measurable outcome and success threshold are defined.
• [ ] Disconfirming evidence is described.

What it contains

• The target persona and their current behavior
• The intervention (the product capability or change)
• The expected behavior change
• The measurable outcome and threshold for success
• Leading indicators you can read before the outcome is knowable
• What disconfirming evidence would look like

Inputs you rely on

• Vision statement and opportunity brief
• Persona work in flight from the BA and UI/UX Designer
• Any baseline behavior data you already have (analytics, support trends)

Who consumes it

• Business Analyst — uses it to scope problem validation and select KPIs
• UI/UX Designer — tests it in user research and early concept work
• Product Sponsor — holds the team accountable to disconfirming evidence, not just supporting stories
• Downstream QA/Tester — traces acceptance criteria back to the outcomes that justified building

Common pitfalls

• Writing "users will love X" — not falsifiable, not an outcome
• Coupling multiple hypotheses in one statement so you can't tell which part failed
• Setting thresholds after the evidence comes in
• Treating it as static — revise as Discover learns, but version the changes

pricing benchmark report

_Produced by: Pricing research_

Business outcome supported: frame the opportunity, validate the problem, understand the market, and exit with a funded, strategically-aligned bet.

Primary owner: Sales & Marketing

Stakeholders: _(none listed)_

What this is

Comparative pricing data across competitors, substitutes, and adjacent markets, mapped against value delivered and buyer willingness-to-pay. It is how the team arrives at a defensible pricing hypothesis before Design-era commitments make it expensive to change.

Why it matters for the Sales & Marketing owner

You produce this so the org enters the opportunity with a pricing posture, not a shrug. Pricing set late and without evidence is the fastest way to destroy margin or leave money on the table; benchmarking early gives Finance and the Sponsor a basis to trust.

Definition of Done

• [ ] Competitor pricing shows list, discounted, and effective prices with sources and dates.
• [ ] Pricing models (per-seat, per-usage, tiered, outcome-based) and their prevalence are compared.
• [ ] At least one value-metric candidate is identified and tied to a customer outcome.
• [ ] Willingness-to-pay signals or price-sensitivity segmentation are recorded.
• [ ] Report ends with a recommended pricing hypothesis expressed as a range.

What it contains

• Competitor pricing: list, discounted, and effective, with sources and dates
• Pricing models (per-seat, per-usage, tiered, outcome-based) and their prevalence
• Value metric candidates and which one aligns with customer outcomes
• Willingness-to-pay signals from interviews or surveys
• Segmentation of price sensitivity by persona or industry
• Recommended pricing hypothesis with range, to be tested in later phases

Inputs you rely on

• Competitive landscape report
• User personas and validated problem statement for value framing
• Primary pricing interviews / van Westendorp-style surveys if feasible
• Finance guidance on margin floors and portfolio pricing norms

Who consumes it

• Business Analyst — plugs per-unit value assumptions into the ROI model
• Product Owner and Product Sponsor — use it to test commercial viability
• Sales & Marketing (future) — evolves it into the pricing & packaging plan at launch

Common pitfalls

• List prices mistaken for effective prices — discounting distorts everything
• Benchmarking against the wrong peer set (enterprise vs. SMB, different geographies)
• Ignoring packaging — price is interdependent with what's bundled
• Single-point recommendation with no range or sensitivity

regulatory risk flag

_Produced by: Initial regulatory landscape scan_

Business outcome supported: frame the opportunity, validate the problem, understand the market, and exit with a funded, strategically-aligned bet.

Primary owner: Security & Compliance

Stakeholders: _(none listed)_

What this is

A first-pass scan of the regulatory and legal landscape the opportunity will touch — data protection, industry-specific rules, export controls, accessibility mandates, and anything else that could block or reshape the work. It is a flag, not a full assessment; the goal is to surface known unknowns early.

Why it matters for the Security & Compliance owner

You produce this so the Sponsor does not fund an initiative that will collide with a regulator mid-Build. Flagging GDPR, HIPAA, PCI, SOX, or sector-specific regimes in Discover is cheap; discovering them in Verify is expensive and embarrassing.

Definition of Done

• [ ] Jurisdictions the product will reach are listed.
• [ ] Applicable regimes each carry a confidence rating (definitely, likely, possible).
• [ ] Data categories and triggers (PII, PHI, financial, children's data) are named.
• [ ] Industry-specific rules and certifications are recorded where relevant.
• [ ] Open questions requiring Define-phase legal review are logged.

What it contains

• Jurisdictions in scope (geographies the product will reach)
• Applicable regimes with initial confidence rating (definitely / likely / possible)
• Data categories and triggers (PII, PHI, financial, children's data)
• Industry-specific rules and certification requirements
• Known regulatory-change monitoring needs
• Open questions that need formal legal review in Define

Inputs you rely on

• Opportunity brief and market analysis report for geography and segment
• Data-sensitivity flag sibling scan
• Internal compliance register and prior initiatives in the same space
• Legal counsel for anything non-obvious

Who consumes it

• Product Sponsor — factors regulatory risk into go / no-go / defer
• Architect — shapes early feasibility conclusions and NFR candidates
• Security & Compliance (future you) — promotes flags into the applicable-regulations list in Define

Common pitfalls

• Treating "we don't process PII" as settled without checking the actual data flow
• Missing sub-regimes (state privacy laws, sector-specific data rules)
• Ignoring regulatory-change velocity in high-velocity regimes
• Confident greens with no basis — flag ambers liberally and resolve in Define

ROI model

_Produced by: Cost-benefit / ROI analysis_

Business outcome supported: frame the opportunity, validate the problem, understand the market, and exit with a funded, strategically-aligned bet.

Primary owner: Business Analyst

Stakeholders: _(none listed)_

What this is

The working spreadsheet (or equivalent) that computes NPV, IRR, and payback from the benefit and cost inputs. It is the engine behind the business case — the business case is the narrative; this is the math.

Why it matters for the Business Analyst

You own this model because every later phase will tug at its inputs as reality changes. A well-structured model — explicit assumptions, clean sensitivity levers, versioned snapshots — lets you update honestly; a spaghetti model quietly hides the fact that the business case no longer holds.

Definition of Done

• [ ] Cost inputs cover build, run, opportunity, and change-management lines.
• [ ] Benefit inputs separate incremental revenue, cost avoidance, and productivity gain.
• [ ] Adoption curve, discount rate, and time horizon assumptions are explicit.
• [ ] NPV, IRR, and payback are computed under expected, best, and worst cases.
• [ ] Sensitivity tornado covers the top 3-5 drivers.

What it contains

• Cost inputs: build (one-time), run (recurring), opportunity, and change-management
• Benefit inputs: incremental revenue, cost avoidance, productivity gain
• Adoption curve with explicit ramp assumptions
• Time horizon, discount rate, and terminal value policy
• Sensitivity tornado for top 3–5 drivers
• NPV, IRR, payback, and break-even under expected/best/worst cases

Inputs you rely on

• Opportunity sizing for benefit lines
• ROI technical inputs for build and run cost
• Pricing benchmark report for unit economics
• Finance-sanctioned discount rate and treatment of internal costs

Who consumes it

• Product Sponsor — uses it to defend funding in governance forums
• Product Owner — uses sensitivities to see which decisions actually move the needle
• Business Analyst (future you) — refines it in Design as updated ROI model and tracks actuals in Operate/Iterate

Common pitfalls

• Hard-coded numbers instead of input cells, so updates require archaeology
• Optimistic ramp curves with no basis in comparable launches
• Missing run-cost escalation (support, compliance, platform fees)
• No version control — "which version did the Sponsor approve?" becomes unanswerable

ROI technical inputs

_Produced by: Technical cost & feasibility inputs_

Business outcome supported: frame the opportunity, validate the problem, understand the market, and exit with a funded, strategically-aligned bet.

Primary owner: Architect

Stakeholders: _(none listed)_

What this is

The technical cost side of the ROI: rough-order-of-magnitude build effort, run cost, integration cost, and the cost of the non-functional commitments implied by the opportunity. This is what keeps the ROI model honest on the cost side.

Why it matters for the Architect

You own this because business-side estimators will otherwise assume build is cheap and run is free. Providing a grounded range early prevents the "we approved $2M and it will cost $6M" conversation in Build, and flags unaffordable NFRs before they get promised.

Definition of Done

• [ ] T-shirt build effort lists major cost drivers, not just a total.
• [ ] Run-cost model covers infrastructure, licenses, SRE, on-call, and compliance.
• [ ] Integration cost is estimated against named upstream/downstream systems.
• [ ] NFR-driven costs (availability, residency, recovery, scale) are called out.
• [ ] Technical risks that could move the number by >30% are listed.

What it contains

• T-shirt build effort and major cost drivers
• Run-cost model: infrastructure, licenses, SRE, on-call, compliance
• Integration cost with named upstream/downstream systems
• NFR-driven cost (availability, data residency, recovery, scale)
• Build-vs-buy candidates and their indicative pricing
• Key technical risks that could move the number by >30%

Inputs you rely on

• Opportunity brief and early scope shape
• Feasibility memo for the constraint landscape
• Platform team rate cards and current infra unit economics
• Vendor quotes or public pricing for likely buy candidates

Who consumes it

• Business Analyst — plugs cost lines into the ROI model and business case
• Product Sponsor — tests affordability against portfolio budget
• Architect (future you) — refines these numbers through technical feasibility findings and the design-era updated ROI model

Common pitfalls

• Engineer-hours only — missing run cost, compliance cost, and enablement cost
• Anchoring on the happy-path architecture and ignoring NFR-driven cost
• No range — ROM without bounds is treated as a commitment later
• Forgetting the "current platform cannot support this" case where the cost includes platform uplift

stakeholder map

_Produced by: Stakeholder identification & alignment_

Business outcome supported: frame the opportunity, validate the problem, understand the market, and exit with a funded, strategically-aligned bet.

Primary owner: Product Owner

Stakeholders: Product Sponsor

What this is

A named list of every person or group with influence over, interest in, or dependence on the initiative, classified by power, interest, and stance. It is the org chart the project will actually be run against — not the one on the HR site.

Why it matters for the Product Owner

You build this to find the people who can kill the initiative before they do it quietly, and to plan how often you will engage each group. Discovering a critical stakeholder in Define or Design is late; discovering them at launch is expensive.

Definition of Done

• [ ] Stakeholders are listed by name and role, not title alone.
• [ ] Each stakeholder is placed on the influence-vs-interest quadrant.
• [ ] Each has a current stance (champion, neutral, skeptic, blocker) with evidence.
• [ ] Decisions owned or veto rights held by each stakeholder are recorded.
• [ ] Engagement cadence and channel are specified for each stakeholder.

What it contains

• Named individuals and their roles (not just titles)
• Influence vs. interest quadrant placement
• Current stance (champion, neutral, skeptic, blocker) with evidence
• Decisions each stakeholder owns or veto-rights they hold
• Preferred engagement cadence and channel
• Known proxies when the real decision-maker is inaccessible

Inputs you rely on

• Opportunity brief and strategic alignment statement
• Sponsor's view of the political landscape
• Prior project histories with overlapping stakeholders
• Any regulator, partner, or customer advisory contacts already identified

Who consumes it

• Project Manager — uses it to build the stakeholder communication plan in Plan
• Product Sponsor — uses it to sequence exec conversations and unblock at steering
• Business Analyst — uses it to schedule interviews and workshops with the right attendees

Common pitfalls

• Titles without names — you will not know who to call
• Missing "silent blockers" like legal, procurement, or a parallel product team
• Static map — stances shift as scope emerges; re-score at each phase gate
• No plan for skeptics beyond "inform" — skeptics need engagement, not broadcasts

strategic alignment statement

_Produced by: Align to portfolio strategy_

Business outcome supported: frame the opportunity, validate the problem, understand the market, and exit with a funded, strategically-aligned bet.

Primary owner: Product Sponsor

Stakeholders: Architect

What this is

A short, explicit statement of how this initiative ladders up to corporate and portfolio strategy — which strategic bet it supports, which pillar it advances, and which trade-offs it is making against other bets. It is the Sponsor's answer to "why this, why now, why instead of something else."

Why it matters for the Product Sponsor

You produce this because portfolio coherence is what makes the difference between a strategy and a spreadsheet of initiatives. Initiatives without a clear strategic spine get deprioritized first in downturns, and they are the hardest to defend to the board.

Definition of Done

• [ ] Statement links explicitly to specific corporate strategy pillars or OKRs.
• [ ] The portfolio bet this initiative belongs to is named.
• [ ] What is being said "no" to by saying "yes" is explicitly recorded.
• [ ] Coherence with adjacent initiatives is marked (reinforces / neutral / conflicts).
• [ ] Re-evaluation triggers (strategic pivots, market shifts) are listed.

What it contains

• Explicit link to corporate strategy pillars or OKRs
• The portfolio bet this initiative belongs to
• What you are explicitly saying no to by saying yes to this
• Coherence with adjacent initiatives (reinforces / neutral / conflicts)
• Expected portfolio-level KPI contribution
• What would trigger re-evaluation (strategic pivots, market shifts)

Inputs you rely on

• Current corporate strategy and OKR cascade
• Portfolio roadmap and capital allocation view
• Architect's input on enterprise-fit and platform alignment
• Business case and opportunity sizing for quantified contribution

Who consumes it

• Product Sponsor peers and executive leadership — for alignment and air-cover
• Architect — uses it as the "why" behind NFR priorities and build-vs-buy posture
• Project Manager — references it when scope pressure tests strategic fit

Common pitfalls

• Generic alignment to every pillar — "supports growth and efficiency" means supports nothing
• Missing the anti-commitment — what this initiative displaces or defers
• No re-evaluation triggers, so the initiative coasts past a strategic pivot
• Written once and never refreshed when strategy changes

user personas

_Produced by: Persona / target user definition_

Business outcome supported: frame the opportunity, validate the problem, understand the market, and exit with a funded, strategically-aligned bet.

Primary owner: UI/UX Designer

Stakeholders: Business Analyst

What this is

Evidence-based archetypes of the people the product is for — their goals, contexts, constraints, and jobs-to-be-done. Personas are not marketing posters; they are working tools that shape what gets built, tested, and supported.

Why it matters for the UI/UX Designer

You own personas because they are how you force the team to design for a specific human instead of a generic "user." Good personas kill bad scope arguments fast: "would Marta, our on-call ops engineer, actually open this at 3am?"

Definition of Done

• [ ] Document contains 3-5 primary personas, not more.
• [ ] Each persona has a name, role, context, and the tools they currently use.
• [ ] Each persona lists jobs-to-be-done with frequency and criticality.
• [ ] Accessibility or assistive-technology considerations are captured per persona.
• [ ] At least one representative research quote grounds each persona.

What it contains

• 3–5 primary personas (more than that and none get used)
• Name, role, context, tools they currently use
• Jobs-to-be-done with frequency and criticality
• Goals, success measures in their own terms, pains, and workarounds
• Accessibility and assistive-technology considerations
• Representative quotes from the research that grounds the persona
• What would disqualify them as a target user

Inputs you rely on

• User interviews and contextual inquiry sessions
• Validated problem statement
• Market analysis report segmentation
• Existing support, CRM, and analytics data if adjacent product exists

Who consumes it

• Business Analyst — uses personas as the "who" in requirements and acceptance criteria
• Product Owner — prioritizes backlog against the primary persona's jobs
• QA/Tester — builds risk-based test coverage around the persona's top journeys
• Sales & Marketing — aligns messaging and segmentation to the same archetypes

Common pitfalls

• Demographic portraits with no behavior or jobs — cannot be used to decide anything
• Too many personas, so teams default back to "generic user"
• Built from team assumptions, not primary research
• Never revisited — personas drift from reality within a year of a live product

validated problem statement

_Produced by: User / problem validation_

Business outcome supported: frame the opportunity, validate the problem, understand the market, and exit with a funded, strategically-aligned bet.

Primary owner: Business Analyst

Stakeholders: UI/UX Designer

What this is

A crisp statement of the user problem, supported by enough primary evidence that the team can defend "this problem is real, painful, and unmet." It converts the opening hunch in the opportunity brief into something the org is willing to spend Define-phase money on.

Why it matters for the Business Analyst

You produce this because the organization's most expensive failure mode is building the right solution to the wrong problem. A validated problem statement is your evidence chain — it lets you say no to scope that does not serve a real job-to-be-done.

Definition of Done

• [ ] Statement expresses the problem in user language with direct quotes.
• [ ] Who has the problem, when, how often, and what it costs today are specified.
• [ ] Current workarounds or competing alternatives users rely on are recorded.
• [ ] Evidence base is quantified (interview count, survey n, data sources).
• [ ] Severity and frequency are scored across target personas, and out-of-scope problems are listed.

What it contains

• The problem in the user's language, with direct quotes
• Who has it, when, how often, and what it costs them today
• What users currently do instead (workarounds, competing products, resignation)
• Evidence base: number of interviews, survey n, data sources
• Severity and frequency scoring across target personas
• What problems are explicitly out of scope

Inputs you rely on

• Interview and diary-study data you and UI/UX ran
• User personas and the outcome hypothesis
• Market analysis report for context
• Support tickets, CRM losses, and internal stakeholder interviews if adjacent product exists

Who consumes it

• Product Owner — uses it as the anchor for MVP scope in Define
• UI/UX Designer — uses it to frame journey mapping and usability research
• Architect — uses it to avoid solutioning for problems users do not actually have

Common pitfalls

• Confirmation bias — interviewing only people who already like your idea
• Leading questions that produce the answer you wanted
• Too few interviews to see patterns (n<8 per segment is rarely enough)
• Writing the problem in solution language ("users need a dashboard") rather than outcome language ("users cannot tell when X is failing")

vision statement

_Produced by: Document product vision_

Business outcome supported: frame the opportunity, validate the problem, understand the market, and exit with a funded, strategically-aligned bet.

Primary owner: Product Owner

Stakeholders: _(none listed)_

What this is

A durable, emotionally resonant statement of what the product aspires to be and who it serves 3–5 years out. It is not a roadmap and not a slogan — it is the north star sentence people repeat back in meetings when scope arguments heat up.

Why it matters for the Product Owner

You use this to keep near-term backlog decisions coherent with a long-term direction, and to give Sponsor and stakeholders a shared "why" they can rally behind. A strong vision makes trade-off conversations shorter; a weak or missing one guarantees they recur forever.

Definition of Done

• [ ] Target user or customer is described in their own words.
• [ ] The future-state world with the product in it is depicted.
• [ ] At least one explicit anti-vision (what the product will not do) is stated.
• [ ] A strategic aspiration (market position, category, or scale) is named.
• [ ] Measurable signals that the vision is coming true are identified.

What it contains

• Target user or customer in their own words
• The future state their work looks like when the product exists
• What the product will categorically not do (anti-vision)
• The strategic aspiration (market position, category, scale)
• Measurable signals that the vision is coming true

Inputs you rely on

• Opportunity brief as framing
• Portfolio strategy and Sponsor's long-term bets
• Early customer conversations from the BA's problem validation
• Competitive and adjacent-market context

Who consumes it

• Product Sponsor — tests whether the vision ladders up to portfolio strategy
• Business Analyst and UI/UX Designer — use it to prioritize which personas and jobs-to-be-done to validate
• Every downstream role — uses it as tie-breaker when requirements or scope clash

Common pitfalls

• Generic "be the best X" statements that could describe any competitor
• Confusing vision with a dated roadmap milestone
• Writing it alone and skipping Sponsor alignment, so it quietly dies at the first exec review
• No anti-vision, so scope creep has nothing to push against

Business Analyst in Discover

You are the evidence function in Discover. While the PO frames the bet and the Sponsor lines up funding, you make sure the claims underneath have real data, real users, and a real market behind them. If Discover ships without your work, the stage-gate becomes a vibes check; with your work, it becomes a defensible investment decision.

What you do

• Market & customer research — publish the market analysis report
• User / problem validation — run the research, co-produce the validated problem statement with the UI/UX Designer
• Problem-opportunity analysis — size the prize in the opportunity sizing
• Cost-benefit / ROI analysis — build the ROI model that anchors the business case
• Feed personas work — contribute to user personas so the segments trace back to evidence

Artifacts you own

• market analysis report — external view of the space, trends, and competitive posture
• validated problem statement — the problem as real users describe it (co-owned with UI/UX Designer)
• opportunity sizing — TAM/SAM/SOM with assumptions named
• ROI model — the numbers the business case rests on

Artifacts you contribute to

• user personas — owned by the UI/UX Designer, you supply the segmentation and quantitative anchors

Outcomes you drive

You don't drive outcomes this phase — you input into the Sponsor's approved budget & investment commitment and Discover exit decision through the ROI model and validated problem evidence.

Who you work with

• UI/UX Designer — partner for user validation and personas; you bring the analytical frame, they bring the qualitative depth
• Product Owner — consumes your ROI model, opportunity sizing, and market read into the business case and vision
• Product Sponsor — scrutinizes your numbers in the stage-gate review; you need to know the corporate hurdle rates and portfolio lens
• Sales & Marketing — their competitive landscape and pricing benchmarks feed your market analysis and ROI model
• Architect — their technical cost inputs plug into your ROI model

Handoff into Define

Your Discover work becomes the floor for Define. The ROI model is refined into the ratified business case; the validated problem statement drives the requirements document; opportunity sizing feeds MVP scope decisions. The quality bar is traceability — every number sourced, every user quote tagged, every assumption flagged so sensitivity can be tested in Define. You're done when the Sponsor can defend your numbers without you in the room.

Customer Support / Success in Discover

You are off-stage in Discover. There are no customers yet, no tickets, no onboarding, and no renewal cycle. Your job this phase is to stay informed so the eventual support and success motion isn't designed in a vacuum later.

What you do

• Stay aware of the opportunity — skim the vision statement, user personas, and validated problem statement
• Notice the support shape — self-serve vs. high-touch, B2B vs. B2C, regulated vs. not — what you hear in Discover will determine the support process you'll model in Define

Artifacts you own

You don't own any artifacts this phase — you contribute to others' (see below).

Outcomes you drive

You don't drive outcomes this phase — you input into others'.

Who you work with

• UI/UX Designer — personas they define here become the customer segments you'll serve
• Sales & Marketing — their commercial model hints (pricing, packaging, GTM) shape what support looks like

Handoff into Define

Nothing you produce is a hard handoff into Define, but you own the support process model in Define, so you should arrive already knowing who the customer is and what the renewal/expansion motion is likely to look like. The quality bar is that when the support process conversation starts, you're not playing catch-up. You're done when you could describe the likely cost-to-serve shape of this initiative in a sentence.

Developer in Discover

You are not staffed on this initiative yet. Discover is about deciding whether to fund the work, not how to build it — any code or estimation would be premature. Your job this phase is to stay aware of what's being queued up, and to be available if the Architect needs a spike or a rough estimate to support the feasibility memo.

What you do

• Stay aware of the opportunity — skim the opportunity brief and vision statement if they cross your team's space
• Be reachable for the Architect — if a throwaway prototype or rough estimate would materially improve the feasibility memo or ROI technical inputs, you may be asked

Artifacts you own

You don't own any artifacts this phase — you contribute to others' (see below).

Artifacts you contribute to

• ROI technical inputs — owned by the Architect, you may supply a sanity-check estimate or quick spike if requested

Outcomes you drive

You don't drive outcomes this phase — you input into others'.

Who you work with

• Architect — your only real touchpoint in Discover; they may pull you in for a quick feasibility spike

Handoff into Define

Nothing you produce is a hard handoff into Define, but you should expect to be pulled in for estimation as soon as Define opens. The quality bar is awareness — when the team asks you to size work in Define, you already have enough context to do it well. You're done when you know what's coming and can start fast if Discover gets a go.

aligned leadership team

_Produced by: Sponsor/PO alignment facilitation_

Primary owner: Project Manager

What this is

The Product Sponsor and Product Owner have arrived at a shared view of the opportunity, the customer, and the bet they are being asked to make. This is not a document — it is a state of alignment that every downstream activity will reference.

Why it matters

Without early leadership alignment, Discover produces artifacts that contradict each other and Define inherits political disagreement dressed up as requirements. Aligning now saves weeks of re-litigation later.

What it contains

• Shared problem framing and success definition
• Agreed scope boundaries for the Discover phase
• Known disagreements captured and parked (not hidden)
• Who makes which call as the initiative progresses

Definition of Done

• [ ] Shared problem framing and success definition are recorded.
• [ ] Scope boundaries for the Discover phase are agreed.
• [ ] Known disagreements are captured and parked, not hidden.
• [ ] Decision rights are assigned for calls anticipated as the initiative progresses.

Entry criteria

• Opportunity brief and vision statement have been reviewed by both
• Stakeholder map identifies who else must be consulted

Exit signal

Sponsor and PO speak with one voice when briefing other stakeholders.

Supporting artifacts (this phase)

• opportunity brief
• vision statement
• outcome hypothesis
• business case
• stakeholder map
• feasibility memo
• market analysis report
• validated problem statement
• opportunity sizing
• ROI model
• user personas
• competitive landscape report
• pricing benchmark report
• ROI technical inputs
• regulatory risk flag
• data-sensitivity flag
• initial project brief
• strategic alignment statement

approved budget & investment commitment

_Produced by: Secure initiative funding_

Primary owner: Product Sponsor

What this is

The Product Sponsor has secured and communicated the initial funding envelope for the initiative, including headcount, infrastructure, and external spend.

Why it matters

Funding converts an idea into a project. Without it, teams cannot be staffed, vendors cannot be engaged, and the business case cannot be tested against reality.

What it contains

• Approved budget ceiling (operating + capital)
• Headcount allocation across roles and phases
• Funding horizon (how long runway lasts without re-approval)
• Re-approval triggers (variance thresholds, milestone gates)

Definition of Done

• [ ] An approved budget ceiling (operating plus capital) is recorded.
• [ ] Headcount allocation across roles and phases is specified.
• [ ] Funding horizon (runway before re-approval) is stated.
• [ ] Re-approval triggers (variance thresholds or milestone gates) are defined.

Entry criteria

• Business case quantifies expected return
• Feasibility memo identifies major cost drivers
• ROI model is credible to finance

Exit signal

Hiring requisitions open and procurement can be initiated.

Supporting artifacts (this phase)

• opportunity brief
• vision statement
• outcome hypothesis
• business case
• stakeholder map
• feasibility memo
• market analysis report
• validated problem statement
• opportunity sizing
• ROI model
• user personas
• competitive landscape report
• pricing benchmark report
• ROI technical inputs
• regulatory risk flag
• data-sensitivity flag
• initial project brief
• strategic alignment statement

Discover exit decision

_Produced by: Discover stage-gate review_

Primary owner: Product Sponsor

What this is

A formal go / no-go gate. The Sponsor decides whether the opportunity is worth defining in detail. Discover ends here; Define only begins with a go.

Why it matters

Gates force honest conversation about whether the evidence supports continuing. Skipping gates is how orgs build things no one asked for.

What it contains

• Go, no-go, or defer decision with recorded rationale
• Conditions attached to a 'go' (open risks to be addressed in Define)
• Next-cycle instructions if 'no-go' or 'defer'

Definition of Done

• [ ] Go/no-go/defer decision is recorded with named rationale.
• [ ] Conditions attached to a 'go' are listed and have owners.
• [ ] Next-cycle instructions exist if 'no-go' or 'defer'.

Entry criteria

• All Discover artifacts complete (vision, business case, ROI model, feasibility memo, validated problem, market analysis, personas, competitive and pricing views, regulatory and data-sensitivity flags)
• Leadership team aligned
• Funding committed or conditioned

Exit signal

Define kicks off, or the initiative returns to the opportunity backlog.

Supporting artifacts (this phase)

• opportunity brief
• vision statement
• outcome hypothesis
• business case
• stakeholder map
• feasibility memo
• market analysis report
• validated problem statement
• opportunity sizing
• ROI model
• user personas
• competitive landscape report
• pricing benchmark report
• ROI technical inputs
• regulatory risk flag
• data-sensitivity flag
• initial project brief
• strategic alignment statement

Product Owner in Discover

You are the single throat to choke for "is there a real product here?" Your job in Discover is to frame the opportunity crisply, articulate a vision worth rallying around, and assemble the evidence pack the Sponsor needs to fund it. Everything you produce this phase is draft — but each draft has to be tight enough that the stage-gate conversation is about strategy, not sloppiness.

What you do

• Ideation / opportunity framing — write the opportunity brief that gets this on the portfolio radar
• Document product vision — publish the vision statement the team will anchor to
• Problem-solution fit hypothesis — state the outcome hypothesis as a falsifiable bet
• Business planning — co-author the business case with the Sponsor
• Stakeholder identification & alignment — build the stakeholder map with the Sponsor
• Early feasibility / risk assessment — commission the feasibility memo with the Architect and Sponsor

Artifacts you own

• opportunity brief — the one-pager that gets this initiative considered
• vision statement — the north-star the team will still recognize a year from now
• outcome hypothesis — the testable bet about problem-solution fit
• business case — the financial and strategic justification (co-owned with the Sponsor)
• stakeholder map — who cares, who decides, who blocks (co-owned with the Sponsor)
• feasibility memo — the early read on whether this is buildable and at what cost (co-owned with Architect and Sponsor)

Outcomes you drive

You don't drive outcomes this phase — you input into others'. Your artifacts feed the Sponsor's approved budget & investment commitment and Discover exit decision.

Who you work with

• Product Sponsor — your primary partner; you need strategic framing, funding, and stakeholder access in return for a ratifiable business case
• Architect — you need early feasibility and cost reads; they need the problem shape and scale ambition
• Business Analyst — their market analysis, ROI model, and opportunity sizing feed your business case
• UI/UX Designer — their persona work and problem validation sharpen your vision
• Project Manager — they keep leadership aligned and the stage-gate on track

Handoff into Define

Every Discover artifact you own becomes an input to Define. The business case gets ratified; the vision anchors the product charter; the outcome hypothesis decomposes into KPIs and MVP scope. The quality bar is that every claim in your pack is sourced — numbers trace to the ROI model, user pain traces to the validated problem statement, risks trace to the feasibility memo. You're done when the Sponsor can sign the exit decision without caveats you can't answer.

Project Manager in Discover

You are here to make Discover actually happen as a coordinated phase instead of a scatter of 1:1 conversations. Before there's a team or a plan, there's a Sponsor, a PO, and a handful of experts trying to assemble a fundable bet — your job is to connect them, keep the stage-gate on the calendar, and produce a tidy pack that makes the go/no-go conversation substantive.

What you do

• Project initiation / pre-kickoff coordination — publish the initial project brief so everyone enters Discover with shared context
• Sponsor/PO alignment facilitation — run the sessions that produce an aligned leadership team before the stage-gate
• Help schedule expert contributions — BA research, Architect feasibility, Security flags — so nothing stalls the stage-gate
• Track the artifacts landing in the Discover pack and flag gaps before the Sponsor's review

Artifacts you own

• initial project brief — the pre-kickoff orientation doc that aligns the small working group

Outcomes you drive

• aligned leadership team — Sponsor and PO visibly on the same page on ambition, evidence, and risk before the stage-gate

Who you work with

• Product Sponsor — you keep their gate meeting set up with a clean pack; they give you the escalation path
• Product Owner — you help them drive the artifact pack to completion; they give you decisions on ambition and timeline
• Architect — you schedule their feasibility slots around the stage-gate
• Business Analyst — you sync with them on research timelines so the ROI model is ready when the business case needs it

Handoff into Define

Discover closes with a go/no-go; Define opens with a charter, schedule, and workshop cadence you will drive. The quality bar is that no one arrives at Define wondering who's in, what the scope of ambition is, or when the next decision is due. You're done when the Sponsor's stage-gate runs on time with a complete pack, and leadership leaves the meeting aligned instead of with homework.