Stage-Gate Process for Initiatives

Source: Confluence - Product Development Process

This document defines the Stage-Gate process for Initiatives at Path2Response. It is based on the Robert Cooper Stage-Gate Process, modified for agile development.

Scope: This process applies only to Initiatives. Non-Initiatives and Operational work follow streamlined processes.

Overview

The Stage-Gate process provides structure and governance for strategic projects. It ensures:

Validated ideas — Problems are verified before solutions are built
Executive alignment — Leadership approves progression at each gate
Resource commitment — Development capacity is reserved for approved work
Kill decisions — Projects can be stopped at any gate (explicit “No Go”)
Accountability — Clear ownership at each stage

Process Diagram

┌─────────────────┐
│  INTAKE/TRIAGE  │  All requests enter PROD. COO evaluates Initiative vs Non-Initiative.
└────────┬────────┘
         │
         ▼
┌─────────────────────────────────────────────────────────────────────────────────────┐
│ STAGE 1: IDEATION                                                                   │
│ Lead: COO (Product Owner)                                                           │
│ PM: Gather requirements, research market, draft business case, success metrics      │
│ Dev: CONSULTED for early technical feasibility                                      │
│ Requester: ACTIVE - validates problem, provides context                             │
└────────┬────────────────────────────────────────────────────────────────────────────┘
         │
         ▼
   ╔═════════════════════════════════════════════════════════════════════════════════╗
   ║ GATE 1: Ideation → Planning                                                     ║
   ║ Decision: Executive Team (CEO, COO, CFO, CRO, CTO) — CEO has ultimate say       ║
   ║ Required: Problem validated, high-level ROI, success metrics, resource estimate ║
   ║ Go if: Positive ROI potential, aligns with strategy, resources likely available ║
   ╚═════════╤═══════════════════════════════════════════════════════════════════════╝
             │
             ▼
┌─────────────────────────────────────────────────────────────────────────────────────┐
│ STAGE 2: PLANNING                                                                   │
│ Lead: Product Management                                                            │
│ PM: User stories, competitive review, MVP scope, prioritize features, GTM outline   │
│ Dev: CONSULTED early, ACTIVE later — estimate, commit to timeline                   │
│ Requester: REVIEW concept, APPROVE MVP scope                                        │
└────────┬────────────────────────────────────────────────────────────────────────────┘
         │
         ▼
   ╔═════════════════════════════════════════════════════════════════════════════════╗
   ║ GATE 2: Planning → Development  ★★★ CRITICAL PROD→PATH HANDOFF ★★★              ║
   ║ Decision: Executive Team — Dev team presents                                    ║
   ║ Required: MVP scope, PATH Epic Requirements met, dev estimate & commitment      ║
   ║ Go if: Technical feasibility confirmed, stakeholders aligned, budget approved   ║
   ║ Action: Convert PROD → PATH                                                     ║
   ╚═════════╤═══════════════════════════════════════════════════════════════════════╝
             │
             ▼
┌─────────────────────────────────────────────────────────────────────────────────────┐
│ STAGE 3: DEVELOPMENT                                                                │
│ Lead: Development Lead                                                              │
│ PM: SUPPORT — answer questions, adjust scope, prepare for launch                    │
│ Dev: ACTIVE — build, test, deploy                                                   │
│ Requester: INFORMED — updates, demo reviews                                         │
└────────┬────────────────────────────────────────────────────────────────────────────┘
         │
         ▼
   ╔═════════════════════════════════════════════════════════════════════════════════╗
   ║ GATE 3: Development → Testing                                                   ║
   ║ Decision: Executive Team — Dev team presents                                    ║
   ║ Required: Product built & tested, stakeholder acceptance, deployment plan       ║
   ║ Go if: Acceptance criteria met, ready for pilot                                 ║
   ╚═════════╤═══════════════════════════════════════════════════════════════════════╝
             │
             ▼
┌─────────────────────────────────────────────────────────────────────────────────────┐
│ STAGE 4: TESTING                                                                    │
│ Lead: Product Management                                                            │
│ PM: Manage pilot, collect feedback, analyze results, iterate                        │
│ Dev: SUPPORT — bug fixes, improvements, model tuning                                │
│ Requester: PARTICIPATE in pilot, provide feedback                                   │
└────────┬────────────────────────────────────────────────────────────────────────────┘
         │
         ▼
   ╔═════════════════════════════════════════════════════════════════════════════════╗
   ║ GATE 4: Testing → Launch                                                        ║
   ║ Decision: Executive Team                                                        ║
   ║ Required: Pilot results, performance data, operational readiness, GTM plan      ║
   ║ Go if: Pilot success, positive feedback, business case still valid              ║
   ╚═════════╤═══════════════════════════════════════════════════════════════════════╝
             │
             ▼
┌─────────────────────────────────────────────────────────────────────────────────────┐
│ STAGE 5: LAUNCH                                                                     │
│ Lead: Product Management                                                            │
│ PM: Execute GTM, sales training, marketing collateral, monitor metrics              │
│ Dev: SUPPORT — ensure stability, monitor performance                                │
└────────┬────────────────────────────────────────────────────────────────────────────┘
         │
         ▼
   ╔═════════════════════════════════════════════════════════════════════════════════╗
   ║ GATE 5: Launch → Review                                                         ║
   ║ Decision: Executive Team                                                        ║
   ║ Required: Launch complete, metrics tracking, lessons learned                    ║
   ║ Go if: Launch successful, metrics meet targets, operations stable               ║
   ╚═════════╤═══════════════════════════════════════════════════════════════════════╝
             │
             ▼
┌─────────────────────────────────────────────────────────────────────────────────────┐
│ STAGE 6: REVIEW                                                                     │
│ Lead: Product Management                                                            │
│ PM: Analyze metrics vs targets, document lessons learned, prepare closure report    │
│ Dev: CONSULTED — input on technical lessons learned                                 │
│ Action: Close Initiative in JPD after quarterly review                              │
└─────────────────────────────────────────────────────────────────────────────────────┘

Stage Details

Stage 1: Ideation

Purpose: Validate the problem and build the business case.

Lead: COO (Product Owner)

Activities:

Gather requirements from requester
Research market opportunity
Draft business case with ROI estimate
Define success metrics
Identify resource requirements (high-level)
Assess technical feasibility (consult with Development)

Deliverables for Gate 1:

Problem statement (validated with requester)
High-level ROI estimate
Success metrics definition
Resource estimate (people, time, money)

Duration: ~1 sprint

Gate 1: Ideation → Planning

Decision Makers: Executive Team (CEO, COO, CFO, CRO, CTO)

Go Criteria:

Problem is validated and worth solving
Positive ROI potential
Aligns with company strategy
Resources are likely available

No-Go Criteria:

Problem not validated
ROI doesn’t justify investment
Doesn’t align with strategy
Resources not available

Outcomes:

Go — Proceed to Stage 2 (Planning)
No-Go — Stop work, document decision
Hold — Wait for conditions to change (e.g., Q3 budget)

Stage 2: Planning

Purpose: Define what will be built and how.

Lead: Product Management

Activities:

Write detailed user stories from persona perspectives
Conduct competitive review
Define MVP scope and feature prioritization
Work with Development on technical approach
Get Development estimates and timeline commitment
Outline go-to-market strategy
Validate MVP scope with requester

Deliverables for Gate 2:

MVP scope definition
PATH Epic meeting all PATH Epic Requirements:
1. The “Why?” — Problem from persona’s perspective
2. Acceptance Criteria — Clear, testable, binary
3. Source of Truth — Where data comes from
4. Impact Analysis — Effects on other systems
5. Priority & Stakeholders — Business value, who accepts
6. Release Parameters — Patch ASAP or standard release
Development estimate and timeline
GTM outline

Duration: ~2-3 sprints

Gate 2: Planning → Development (Critical Handoff)

Decision Makers: Executive Team — Development team presents

This is the critical PROD → PATH handoff point.

Go Criteria:

MVP scope is defined and approved
PATH Epic Requirements are met
Development has estimated and committed to timeline
Technical feasibility is confirmed
Stakeholders are aligned
Budget is approved

No-Go Criteria:

Requirements unclear or incomplete
Technical feasibility not confirmed
Stakeholders not aligned
Budget not available

Action on Go: Convert PROD Epic to PATH Epic (or create PATH child issues)

Stage 3: Development

Purpose: Build the product.

Lead: Development Lead

Activities:

Sprint planning and execution
Implementation and code review
Testing and quality assurance
Stakeholder demos
Deployment to staging/production

Product Management Role: SUPPORT

Answer questions about requirements
Adjust scope if needed (with stakeholder approval)
Prepare for launch (GTM activities)

Requester Role: INFORMED

Receive updates
Attend demo reviews

Duration: ~2-6+ sprints (varies by scope)

Gate 3: Development → Testing

Decision Makers: Executive Team — Development team presents

Go Criteria:

Product is built and passes internal testing
Acceptance criteria are met
Stakeholder has accepted the work
Deployment plan is established

No-Go Criteria:

Acceptance criteria not met
Critical defects remain
Stakeholder hasn’t accepted

Stage 4: Testing

Purpose: Validate with real users in controlled environment.

Lead: Product Management

Activities:

Manage pilot program
Collect feedback from pilot users
Analyze results against success metrics
Iterate based on feedback
Document issues and improvements

Development Role: SUPPORT

Fix bugs discovered in pilot
Implement priority improvements
Tune models (Data Science)

Requester Role: PARTICIPATE

Use the product in pilot
Provide feedback

Duration: ~1-4 sprints

Gate 4: Testing → Launch

Decision Makers: Executive Team

Go Criteria:

Pilot results are positive
Performance data meets targets
Operational readiness confirmed
GTM plan is complete
Business case still valid

No-Go Criteria:

Pilot results are negative
Performance doesn’t meet targets
Operations not ready
Business case no longer valid

Stage 5: Launch

Purpose: Bring the product to market.

Lead: Product Management

Activities:

Execute go-to-market plan
Sales training
Marketing collateral creation
Internal training
Client communications
Monitor launch metrics

Development Role: SUPPORT

Ensure system stability
Monitor performance
Address critical issues

Duration: ~1-2 sprints

Gate 5: Launch → Review

Decision Makers: Executive Team

Go Criteria:

Launch is complete
Metrics tracking is in place
Initial lessons learned documented

Stage 6: Review

Purpose: Evaluate success and capture learnings.

Lead: Product Management

Activities:

Analyze metrics vs original targets
Document lessons learned (what worked, what didn’t)
Prepare closure report
Present to Executive Team

Development Role: CONSULTED

Input on technical lessons learned

Action: Close Initiative in Jira Product Discovery (JPD) after quarterly review

Duration: ~4-6 sprints post-launch (ongoing measurement)

Preventing “Into the Wash”

The process includes explicit mechanisms to prevent requests from disappearing:

Mechanism	Description
JPD Tracking	Every Initiative tracked with current stage visible
Monthly Exec Review	Status, next gate target, blockers reported
Duration Red Flags	Escalation if stage exceeds expected duration
Explicit Decisions	Cannot advance without documented gate approval
Requester Sign-off	Original requester validates at Gates 1 and 2
Kill Explicitly	Requires formal “No Go” decision (not silent death)

Expected Stage Durations

Stage	Expected Duration	Red Flag
Stage 1: Ideation	~1 sprint	> 2 sprints
Stage 2: Planning	~2-3 sprints	> 4 sprints
Stage 3: Development	Varies	Per estimate + 50%
Stage 4: Testing	~1-4 sprints	> 6 sprints
Stage 5: Launch	~1-2 sprints	> 3 sprints
Stage 6: Review	~4-6 sprints	Ongoing

RACI by Stage

Stage	Product Management	Development	Requester	Executives
Ideation	Responsible	Consulted	Accountable	Informed
Gate 1	Informed	Informed	Consulted	Accountable
Planning	Responsible	Consulted → Active	Consulted	Informed
Gate 2	Consulted	Responsible	Consulted	Accountable
Development	Support	Responsible	Informed	Informed
Gate 3	Consulted	Responsible	Consulted	Accountable
Testing	Responsible	Support	Active	Informed
Gate 4	Consulted	Consulted	Consulted	Accountable
Launch	Responsible	Support	Informed	Informed
Gate 5	Consulted	Consulted	Consulted	Accountable
Review	Responsible	Consulted	Informed	Accountable

Work Classification Guide — When to use Stage-Gate vs streamlined process
PROD-PATH Process — How PROD and PATH interact
PATH Epic Requirements — What “ready for development” means

Keyboard shortcuts

Path2Response Product Management Knowledge Base