Product Process

Overview

Not all work requires the same level of product process. A user-requested button change and a new product initiative are fundamentally different in risk, effort, and organisational impact. Applying the same process to both either buries small work in unnecessary overhead or under-prepares large work for the scrutiny it deserves.

This document defines three tiers of product work, each with proportionate process, artefacts, and decision authority. The tiers are guidelines, not rigid boxes PMs use judgment to assign work to a tier, and can escalate or de-escalate as understanding develops.

For a quick-reference version of this guide, see the Product Process Cheatsheet.

---

Tier Classification

	Tier 1: Feature	Tier 2: Enhancement	Tier 3: Initiative
Scope	A single feature, fix, or improvement within an existing product area	A new module, workflow, or significant extension to an existing product area	A new product, major pivot, or cross-cutting capability affecting multiple areas
Typical effort	1-3 days	1-4 sprints	Multiple sprints, potentially a quarter or more
Risk	Low; contained within known patterns	Medium; new UX flows, new integrations, or new data models	High: new market, new users, significant investment, strategic commitment
Examples	User-requested feature, UI improvement, config option, single API endpoint, bug-driven enhancement	New onboarding flow, reporting module, integration with external service, new user role/permissions model	New product line, platform migration, entering a new market segment, major architectural change with product implications
Discovery	Minimal: conversation with user/stakeholder	Moderate: user conversations, competitor scan, lightweight prototyping	Substantial: user research, market analysis, competitive landscape, prototyping, stakeholder alignment
Go/no-go authority	PM	PM + Head of Product (CTO if 4+ sprints)	Head of Product + CTO/executive leadership

For guidance on what artefacts each tier requires, see the Artefact Requirements Cheatsheet.

---

Design Approach

There is no full-time designer in the team structure. Design is handled through a combination of:

• Design system created and maintained by a freelance designer or AI-generated, providing consistent components, patterns, and styles. This is the foundation that makes the other approaches viable.
• PM-led design PM produces wireframes or mockups using AI tools or lightweight design tools (Figma, Whimsical) for Tier 1 and Tier 2 work.
• Dev-led design Dev builds directly from the design system with AI assistance, particularly for Tier 1 work where the UI pattern is established.
• Designer engaged for Tier 3 work or Tier 2 work with significant UX complexity. Produces high-fidelity designs and, where needed, interactive prototypes.
• AI-assisted design AI generates UI concepts, layout options, and component compositions from descriptions. Useful across all tiers as a starting point for PM or dev to refine.

The design system is the force multiplier. Without it, every piece of work requires bespoke design decisions. With it, most Tier 1 and Tier 2 work can be designed by the PM or dev using established patterns.

A note on prototypes vs wireframes: AI tooling has made interactive prototypes increasingly easy and cheap to create, and they are powerful tools for user validation letting real users try a flow and provide feedback. However, they can be counterproductive as a build artefact. Engineers can get stuck trying to precisely recreate a prototype rather than building the right solution using established patterns and the design system. The sweet spot for most build handoffs is AI-generated wireframes — clear enough to communicate intent, loose enough that the engineer applies the design system and their own judgment. Use interactive prototypes for user testing and validation; use wireframes and design system references for the build.

---

Tier 1: Feature

When to Use

A known problem with a clear solution within an existing product area. Typically originates from user feedback, support requests, or PM observation. The shape of the solution is largely understood before work begins.

Process

Request/observation → PM writes ticket → Refinement → Build → Release

There is no separate discovery phase. The PM’s conversation with the user or stakeholder is the discovery.

Steps

1. Capture (PM)

PM has a conversation with the user, stakeholder, or reviews the support data. PM writes a ticket containing:

• Problem: What’s the user problem or need? (2–3 sentences)
• Solution direction: What are we going to do about it? (2–3 sentences, not a spec)
• Success criteria: How do we know it worked? (1–3 measurable or observable outcomes)
• Constraints: Anything the dev needs to know (timeline, technical boundaries, dependencies)

This is a couple of paragraphs, not a document. If it takes more than 15 minutes to write, the work is probably Tier 2.

2. Refinement (Squad)

The ticket enters normal refinement (see Engineering Process, Section 4). PM presents the problem, squad discusses the approach, QA raises testability and edge cases. Output: agreed approach, rough size, acceptance criteria.

3. Design (PM or Dev)

For UI work: PM sketches the approach using the design system — a wireframe, an annotated screenshot, or a verbal description referencing existing patterns. For many Tier 1 items, the dev builds directly from the design system with no separate design artefact needed.

4. Technical Design Review (Dev → Lead Dev)

Per the standard process (Engineering Process, Section 6). For straightforward Tier 1 items, this may be a 2-minute Slack exchange.

5. Build and Release

Standard development and release process.

Artefacts

Artefact	Owner	Required?
Ticket (problem, solution direction, success criteria, constraints)	PM	Yes
Wireframe or design reference	PM or Dev	Only if UI work with non-obvious layout
Acceptance criteria	PM + QA	Yes (captured on ticket at refinement)
ADR	Dev	Only if a significant technical decision is made

Go/No-Go

PM decides. No approval needed beyond normal backlog prioritisation. PM uses judgment on whether it’s worth doing and where it sits in priority. If there’s a priority conflict, Head of Product arbitrates per normal process.

AI Usage

• PM uses AI to draft the ticket from raw inputs (user conversation notes, support ticket content)
• Dev uses AI for implementation plan pressure-testing and code generation
• QA uses AI for test scenario generation

---

Tier 2: Enhancement

When to Use

A significant extension or new capability within an existing product area. More than a single feature but not a new product. Involves new UX flows, new data models, new integrations, or meaningful changes to how users interact with the product. The solution shape isn’t fully clear at the outset and needs some exploration.

This is the most common tier for planned roadmap work.

Process

Discovery → PRD → Design → Go/No-Go → Refinement (multiple sessions) → Build → Release

Steps

1. Discovery (PM, with support)

Proportionate exploration before committing to build. The goal is to develop enough confidence that the solution direction is right without over-investing in analysis.

Activities (PM selects what’s appropriate, not all required):

• User conversations — conversations with several target users, ideally with different contexts and perspectives. Enough to validate that the problem is real and not just one person’s view. Not a formal research study — structured conversations with specific questions.
• Competitor scan — how do competitors or adjacent products handle this? What can we learn, borrow, or deliberately avoid? AI-assisted analysis of competitor products and publicly available information.
• Technical feasibility check — Lead Dev provides an early read on approach, major risks, and rough effort. This is a conversation, not a formal assessment.
• Data review — what does existing analytics data tell us about the problem? PM — Analytics & Experimentation supports with data pulls and analysis.
• Stakeholder input — if the enhancement affects other business areas (sales, support, operations), gather their requirements and constraints early.

Output: PM has enough understanding to write a confident PRD. If discovery reveals the work is bigger or riskier than expected, PM escalates the tier classification to Tier 3.

2. PRD (PM)

A structured document that serves as the single source of truth for what’s being built and why. Not a novel but a focused document that a dev can read in 15 minutes and understand the full picture.

PRD structure:

• Problem statement: What user or business problem are we solving? Why now? Supported by evidence from discovery (user quotes, data, competitive pressure).
• Goal and success metrics: What outcome are we targeting? How will we measure it? Specific, measurable, time-bound where possible.
• User stories / jobs to be done: Who is the user? What are they trying to accomplish? What does the workflow look like from their perspective?
• Scope: What’s in. What’s explicitly out. What’s deferred to a future iteration.
• Solution overview: High-level description of the approach. Not implementation detail; enough for a dev to understand the shape and for a stakeholder to understand what they’re getting.
• Design: Wireframes, mockups, or prototypes. For Tier 2, this is typically low-to-medium fidelity; enough to communicate the UX flow and key screens, not pixel-perfect. PM produces these using the design system and AI tools, or collaborates with a freelance designer for complex UX. AI-generated wireframes are the sweet spot for build handoffs; clear enough to communicate intent, loose enough for the engineer to apply the design system. Interactive prototypes are valuable for user validation but should not be the primary build artefact (see Design Approach above).
• Dependencies and risks: What could go wrong? What do we depend on? What assumptions are we making?
• Phasing (if applicable): If the work spans multiple sprints, how is it broken into shippable increments? Each phase should deliver user value, not just technical progress.

3. Design (PM, with designer or AI support)

For Tier 2, design runs in parallel with PRD creation, not as a separate phase after it.

• AI-generated wireframes for all new screens and flows; enough to communicate layout, information hierarchy, and interaction patterns. This is the primary build handoff artefact.
• Medium-fidelity mockups for key screens where visual design matters (user-facing, high-traffic, or complex interactions). Using the design system components.
• Interactive prototype for user validation when the UX flow is complex enough that static screens don’t communicate it (e.g., multi-step wizard, drag-and-drop interaction). AI tooling makes these increasingly cheap to produce. However, prototypes are a validation tool, not a build specification; engineers should ideally build from wireframes and the design system, not attempt to precisely recreate a prototype.

For straightforward enhancements where the UX follows established patterns, annotated wireframes referencing existing design system components are sufficient.

4. Go/No-Go (PM + Head of Product)

PM presents the PRD to Head of Product. The decision is:

• Go: proceed to refinement and build.
• Go with changes: adjust scope, phasing, or approach and proceed.
• Defer: valid idea, wrong time. Returns to backlog with context preserved.
• Kill: not worth doing. Document why so the decision isn’t revisited without new information.

This is a conversation, not a presentation. 30 minutes. Head of Product is assessing: Is this the right problem? Is the evidence sufficient? Is the scope appropriate? Does it fit the roadmap? Are the risks acceptable?

For enhancements estimated at 4 or more sprints, or with significant cost or strategic implications, Head of Product involves the CTO. PM should flag this in advance if they think it’s needed.

5. Refinement (Squad, multiple sessions)

The PRD and designs are the input to refinement. Because Tier 2 work spans multiple sprints, it’s broken down across multiple refinement sessions:

• First session: PM walks through the PRD. Squad asks questions, challenges assumptions, identifies technical risks. High-level breakdown into phases or major components.
• Subsequent sessions: Refine individual phases/components into sprint-ready items. Standard refinement process applies (problem, approach, acceptance criteria, rough size).

Lead Dev ensures the technical approach across the full enhancement is coherent; individual items shouldn’t be refined in isolation without understanding the whole.

6. Build and Release

Standard development and release process, with phased delivery behind feature flags where applicable. Each phase is releasable independently.

PM reviews progress at each sprint demo against the PRD goals. Scope adjustments happen through conversation between PM and Lead Dev during the sprint, with Head of Product consulted for significant changes.

Artefacts

Artefact	Owner	Required?
Discovery notes (user conversations, competitor scan, data)	PM	Yes (can be informal; doc, notes, Slack summary)
PRD	PM	Yes
Wireframes / mockups	PM (or freelance designer)	Yes for UI work (primary build handoff artefact)
Interactive prototype	PM / designer	For user validation of complex UX (not a build artefact)
Sprint-level tickets (broken down from PRD)	PM + Lead Dev + QA at refinement	Yes
ADRs	Dev	For significant technical decisions within the build

AI Usage

• Discovery: AI-assisted competitor analysis, customer feedback synthesis, data analysis
• PRD: AI drafts initial PRD from discovery notes, user conversations, and PM’s direction. PM reviews, refines, and owns the output.
• Design: AI generates UI concepts and layout options from descriptions. PM or dev refines using the design system.
• Refinement: AI-generated test scenarios, preliminary technical assessments, acceptance criteria drafts
• Build: Standard AI-assisted development (code generation, test writing, code review)

---

Tier 3: Initiative

When to Use

A major new product, a significant strategic bet, or a cross-cutting change that affects multiple product areas, requires substantial investment, and carries meaningful risk if it fails. The problem space is not fully understood and requires deliberate investigation before committing resources.

Tier 3 work typically originates from product strategy, leadership direction, or a market opportunity that requires validation.

Strategic alignment check: Before any serious work begins on a Tier 3 initiative - even framing - the idea must be discussed with the CTO to confirm strategic alignment. This applies regardless of where the idea originates, including from PMs or developers internally. This is a quick conversation, not a formal meeting. The purpose is to catch misalignment early: a PM shouldn’t spend two weeks on discovery for an initiative if the executive team has already decided to acquire a company that solves the same problem, or if it conflicts with a strategic direction the PM isn’t aware of.

Process

Framing → Discovery → One-Pager → Executive Go/No-Go → PRD → Design → Refinement → Build → Release

Steps

1. Framing (PM + Head of Product)

Before discovery begins, the initiative needs a clear frame. Head of Product and PM (typically the Discovery PM, or the squad PM if the initiative maps to their area) define:

• The hypothesis: What do we believe is true about the market, the user need, or the opportunity?
• The questions discovery must answer: What don’t we know that we need to know before committing?
• The investment boundary for discovery: How much time/effort is proportionate before the go/no-go decision? (e.g., “2 weeks of PM time, 5 user interviews, a competitor analysis, and a technical feasibility spike”)
• Who needs to be involved: Which parts of the business are affected? (sales, support, operations, legal, finance)

This prevents discovery from becoming open-ended exploration. The frame keeps it focused and time-boxed.

2. Discovery (PM-led, cross-functional input)

Thorough investigation proportionate to the scale of the initiative. This is real work, not a formality.

Activities (PM leads, involves others as needed):

• User research structured interviews with target users. Broader and deeper than Tier 2: aim for sufficient coverage across different segments, use cases, and levels of sophistication to have confidence in the findings. Document findings, not just impressions.
• Market analysis market size, growth trends, existing solutions, white space. AI-assisted research supplemented by PM judgment. For initiatives entering a new market, this is essential.
• Competitive landscape detailed analysis of competitors, their positioning, strengths, weaknesses, pricing. Not just “who else does this” but “why would a user choose us over them?”
• Technical feasibility Lead Dev and/or Staff Engineer conduct a deeper assessment than the quick conversation in Tier 2. This may involve a time-boxed spike (1–2 sprints max) to prove out a key technical risk. Output: feasibility assessment with identified risks, rough architecture direction, and high-confidence effort range.
• Business model / commercial viability if the initiative has revenue implications, work with the relevant business stakeholders to model the opportunity. What does success look like commercially? What investment is required? What’s the payback period?
• Stakeholder requirements structured input from affected business areas. Not informal conversations; documented requirements and constraints that feed into the PRD.
• Prototyping for initiatives with significant UX uncertainty, build a throwaway prototype to test concepts with users. This is a learning tool, not a deliverable. A freelance designer or a dev building quickly with AI; the output is user feedback, not code.

Output: PM has validated (or invalidated) the hypothesis, answered the discovery questions, and has enough evidence to make a credible case for investment.

If discovery invalidates the hypothesis, the initiative is killed with documented reasoning. This is a successful outcome - discovering a bad bet before committing resources is valuable.

3. One-Pager (PM)

A single-page executive summary designed for leadership consumption. This is the artefact that answers “what the hell are you guys working on?” and, for go/no-go decisions, “should we commit to this?”

One-pager structure:

• Title and one-sentence summary: What is this, in plain language?
• Problem: What user or market problem have we identified? Supported by evidence (user quotes, data, market analysis).
• Opportunity: Why is this worth pursuing? What’s the size of the prize? What happens if we don’t do it?
• Proposed solution: What are we going to build, at a high level? Not technical detail; a description a non-technical executive can understand.
• Key assumptions: What are we betting on? What must be true for this to succeed?
• Key decisions required: What do we need leadership to decide? (Budget, headcount, timeline, strategic trade-offs)
• Risks: What could go wrong? What’s our mitigation?
• Investment required: How much effort (sprints, people), how much cost (external resources, infrastructure), what’s the timeline?
• Success metrics: How will we know this worked? Specific, measurable outcomes with timeframes.

The one-pager is not a summary of the PRD. It’s written for a different audience (leadership, not the squad) and serves a different purpose (investment decision, not build specification). It’s written before or in parallel with the PRD, not after.

4. Executive Go/No-Go (Head of Product + CTO/Executive Leadership)

Head of Product presents the one-pager to the appropriate decision-makers. The level of the audience depends on the scale of investment:

Investment Scale	Decision Forum
4+ sprints of squad commitment	Head of Product + CTO
Cross-squad impact or new headcount	Head of Product + CTO + CEO/executive leadership
Requires capital investment	Board/investor visibility (CTO/CEO present)

The decision options are the same as Tier 2: go, go with changes, defer, kill. But the consequences are larger, so the scrutiny is greater.

If Go: Proceed to PRD and build. If Defer: Preserve all discovery artefacts. Document the deferral reason and conditions under which it should be reconsidered. If Kill: Document the reasoning. Share with the team so the learning isn’t lost.

5. PRD (PM)

Same structure as Tier 2, but with significantly more depth and rigour:

• Problem statement backed by user research data, not anecdote
• Goal and success metrics aligned with the one-pager commitments
• Detailed user stories / jobs to be done covering all user segments and scenarios identified in discovery
• Scope with explicit phasing - Tier 3 work must be delivered incrementally, not as a big bang. Define an MVP that delivers the core value, then subsequent increments that extend it. Each increment must be independently shippable (see Project Sizing Rules). If the initiative exceeds 4 sprints, the PRD must define increments of 1-4 sprints each with their own success criteria and go/no-go.
• Solution overview including key architectural decisions and technical approach (informed by the feasibility spike)
• Design a high-fidelity mockups and, where needed, interactive prototypes. For Tier 3, engage a freelance designer for the core UX flows. AI-generated concepts as a starting point, designer refines.
• Dependencies and risks with mitigation plans, not just a list
• Phasing with milestones independently shippable increments of 1-4 sprints each, with sprint-level milestones within each increment. Each increment maps to sprint planning and has a go/no-go at completion.

6. Design (Freelance Designer + PM + AI)

For Tier 3 initiatives:

• Freelance designer produces the design system extensions (if needed) and high-fidelity wireframes and mockups for all key screens and flows. Wireframes and design system references are the primary build handoff artefacts.
• Interactive prototypes for core workflows, used for user validation before build. Prototypes are powerful for testing concepts with real users but should not be treated as build specifications; engineers build from wireframes and the design system, not by recreating prototypes.
• Design review with PM, Lead Dev, and QA to confirm feasibility, testability, and alignment with the PRD
• Design assets handed off in a format devs can build from (Figma, design tokens, component specs)

7. Refinement and Build

Same as Tier 2 but over a longer duration. The Project Sizing Rules (above) apply; work over 4 sprints must be decomposed into independently shippable increments with their own go/no-go. Additional considerations:

• Kick-off session before the first refinement, PM presents the full PRD and designs to the squad. The squad asks questions, challenges assumptions, and builds shared understanding of the whole initiative before breaking it into sprint-level items.
• Every sprint produces tangible output a reviewable artefact that demonstrates progress toward the goal (see Project Sizing Rules). No invisible sprints.
• Increment reviews at the end of each independently shippable increment - PM, Lead Dev, and Head of Product assess progress against the one-pager goals. Is the initiative on track? Do metrics from early increments validate the hypothesis? Should scope be adjusted? Should we proceed to the next increment?
• Stakeholder updates at agreed intervals; Head of Product communicates progress to the executive audience that approved the initiative.

Artefacts

Artefact	Owner	Required?
Framing document (hypothesis, discovery questions, investment boundary)	PM + Head of Product	Yes
User research findings	PM	Yes
Market and competitive analysis	PM	Yes
Technical feasibility assessment	Lead Dev / Staff Engineer	Yes
Business model / commercial analysis	PM + business stakeholders	If revenue implications
Prototype (throwaway)	PM / Dev / Designer	If significant UX uncertainty
One-pager	PM	Yes
PRD (detailed)	PM	Yes
High-fidelity wireframes / mockups	Freelance designer	Yes (primary build handoff artefact)
Interactive prototypes	Freelance designer	For user validation of core workflows (not a build artefact)
Sprint-level tickets (broken down from PRD)	PM + Lead Dev + QA at refinement	Yes
ADRs	Dev / Staff Engineer	For significant technical decisions
Increment review notes	PM	Yes, at each increment go/no-go

AI Usage

• Discovery: AI-assisted market research, competitive analysis, customer feedback synthesis, user interview preparation and analysis
• Feasibility: AI-assisted codebase analysis for technical spike
• One-pager: AI drafts from discovery findings and PM direction. PM refines.
• PRD: AI drafts from discovery outputs, one-pager, and PM’s solution direction. PM reviews and owns.
• Design: AI generates UI concepts and layout options. Designer refines. AI produces variations for user testing.
• Prototyping: AI-assisted rapid prototype development for user concept testing
• Refinement and build: Standard AI-assisted processes across development lifecycle
• Stakeholder updates: AI drafts progress summaries from sprint data and milestone outcomes

---

Project Sizing Rules

These rules apply across all tiers and ensure that work remains incrementally deliverable, inspectable, and stoppable. For a quick-reference version, see the Project Sizing Cheatsheet.

Every sprint produces a tangible output. Any work spanning more than one sprint must have per-sprint milestones, and each milestone must produce a concrete, reviewable output that moves toward the goal. What counts as output varies:

• A working API endpoint demonstrated via Postman
• A data pipeline processing test data
• An architecture diagram and ADR for a foundational decision
• A spike report proving or disproving a technical approach
• A schema and migration running against test data
• Infrastructure provisioned and documented
• A UI flow (when it naturally exists at that point)

The anti-pattern is an invisible sprint: “we wrote a lot of code but there’s nothing to show.” If the squad can’t point to a concrete output, the work wasn’t broken down well enough. This does not mean artificially creating a UI for something just to have a demo. It means there is always a tangible artefact that demonstrates progress.

Tier 2 and Tier 3 work must be broken into sprint-level phases at the PRD stage. The PRD defines the phases; refinement breaks phases into sprint-level items. If the PM can’t articulate sprint-level phases in the PRD, the work isn’t understood well enough to commit to.

Anything over 4 sprints must be decomposed into independently shippable increments of 1-4 sprints each. Each increment:

• Has its own success criteria
• Delivers value that is not dependent on subsequent increments being completed
• Has a go/no-go review at completion (“do we proceed to the next increment?”)
• Can be paused or killed without the previous increments being wasted

This creates natural off-ramps. If increment 1 ships and the metrics don’t support the hypothesis, you can stop without having wasted the entire investment. This requires genuine independence between increments - not just an arbitrary split at the 4-sprint mark. If the increments can’t function independently, the decomposition needs rethinking.

Summary:

Duration	Sizing Requirement
1-3 days	No special sizing rules (Tier 1)
1 sprint	No special sizing rules
2-4 sprints	Sprint-level milestones with tangible output each sprint. Phases defined in PRD.
4+ sprints	Decomposed into independently shippable increments of 1-4 sprints. Each increment has its own go/no-go.

---

Tier Assignment Guidelines

The PM assigns the tier when work enters the backlog. It’s a judgment call, not a formula, but these guidelines help:

Assign Tier 1 if:

• The solution is obvious or well-understood
• The work fits within 1-3 days
• It affects a single, contained area of the product
• The risk of getting it wrong is low (easily reversed or adjusted)
• No stakeholder alignment or executive visibility needed

Assign Tier 2 if:

• The solution requires some exploration or design
• The work spans multiple sprints
• It introduces new UX flows, data models, or integrations
• Users will notice and need to learn something new
• It requires Head of Product awareness and approval

Assign Tier 3 if:

• The problem space isn’t fully understood
• The work represents a significant strategic commitment
• It affects multiple product areas or requires new capabilities
• It requires new investment (headcount, infrastructure, external resources)
• It needs executive visibility and approval
• Getting it wrong is expensive (time, money, reputation, opportunity cost)

Escalation: If discovery at any tier reveals the work is bigger or riskier than initially classified, PM escalates the tier classification. A Tier 1 that turns out to need design exploration becomes a Tier 2. A Tier 2 that reveals a market question becomes a Tier 3. This is normal, not a failure.

De-escalation: A Tier 3 where discovery narrows the scope significantly might be re-classified as a Tier 2. This is also normal.

---

Summary: Artefacts by Tier

Artefact	Tier 1	Tier 2	Tier 3
Ticket (problem, solution, criteria)	✓	✓ (derived from PRD)	✓ (derived from PRD)
Discovery notes	—	✓ (lightweight)	✓ (structured)
User research	—	Conversations	Formal findings
Market/competitive analysis	—	Scan	Detailed analysis
Technical feasibility	At refinement	Lead Dev conversation	Spike + written assessment
One-pager	—	—	✓
PRD	—	✓	✓ (detailed)
Wireframes (build handoff)	If needed	✓	✓ (high fidelity)
Interactive prototype (validation only)	—	If complex UX	Core workflows
Business/commercial analysis	—	—	If revenue implications
Increment review notes	—	—	✓
ADRs	If significant	If significant	✓

---

Summary: Responsibilities by Tier

Activity	Tier 1	Tier 2	Tier 3
Discovery	PM (user conversation)	PM (conversations, competitor scan, data)	PM-led, cross-functional
Problem definition	PM (ticket)	PM (PRD)	PM (one-pager + PRD)
Design	PM/Dev (design system)	PM + AI (wireframes, mockups)	Freelance designer + AI
Technical assessment	Lead Dev (at refinement)	Lead Dev (conversation)	Lead Dev/Staff Eng (spike)
Go/no-go	PM	PM + Head of Product	Head of Product + CTO/exec
Refinement	Standard (1 session)	Multiple sessions	Kick-off + multiple sessions
Build	Standard	Standard, phased	Standard, phased with milestone reviews
Stakeholder comms	PM (via backlog visibility)	PM + Head of Product	Head of Product to exec audience