Sprint Zero: How We Kick Off Every Product We Build

The $50,000 Mistake I Made (So You Don't Have To)

Early in my career, I spent six weeks building a product feature that nobody wanted. The client signed off, the requirements were clear, and we delivered exactly what they asked for.

Then nobody used it.

The problem wasn't our execution — it was the assumptions we made before writing a single line of code. That's why we invented Sprint Zero.

Product planning whiteboard

What Is Sprint Zero?

Sprint Zero is the structured week before development begins. No code. No prototypes. Just answers to the questions that determine success or failure.

Sprint Zero outputs:

• Validated problem statement
• Technical architecture decisions
• Success metrics (not vanity metrics)
• Risk assessment and mitigation
• Week 1 development plan

Day 1: Problem Validation

The Five Whys (But Actually Rigorous)

Start with the stakeholder's problem statement, then ask "why" five times:

Now you're building something that solves the actual problem, not the symptom.

The "Not To Do" List

Equally important: Define what you won't build.

Prioritization matrix

Day 2: Technical Decisions

The Architecture Decision Record (ADR)

Document every significant technical decision:

# ADR-001: Data Storage Solution

## Context
We need to store sales data from multiple sources (CRM, spreadsheets, manual entry).

## Decision
Use PostgreSQL with TimescaleDB extension for time-series data.

## Alternatives Considered
- MongoDB: Worse for reporting queries
- Firebase: Too expensive at scale
- Raw Postgres without Timescale: Missing time-series optimizations

## Consequences
- Pros: Efficient time-series queries, familiar SQL
- Cons: Need Timescale expertise, more complex setup

## Status
Accepted

Tech Stack Freeze

No "let's try this cool new framework" during Sprint Zero. Pick boring, proven technology:

// Our default stack (proven across 50+ projects)
{
  "frontend": "Next.js 14 (App Router)",
  "styling": "Tailwind CSS + shadcn/ui",
  "backend": "Next.js API routes",
  "database": "PostgreSQL + Prisma",
  "auth": "NextAuth.js",
  "hosting": "Vercel"
}

Day 3: Success Metrics

Leading vs. Lagging Indicators

Most teams only track lagging indicators (what happened), not leading indicators (what will happen).

Instrumentation Requirements

Define what you need to measure before writing code:

// Every action that matters gets tracked
trackEvent('user_signed_up', {
  source: 'referral',
  plan: 'pro',
  time_to_value: 120 // seconds
})

trackEvent('feature_used', {
  feature: 'dashboard_export',
  user_segment: 'manager'
})

Day 4: Risk Assessment

The Risk Matrix

Risk assessment matrix

The "Break It" Session

Spend 2 hours intentionally trying to break your assumptions:

• "What if the CSV has 1M rows instead of 10K?"
• "What if the API goes down for 6 hours?"
• "What if users want hourly instead of daily updates?"

Day 5: The Development Plan

Week 1 Milestones

Definition of Done (DoD)

Every feature requires:

- [ ] Code reviewed by at least one engineer
- [ ] Unit tests for business logic
- [ ] Integration test for critical path
- [ ] Manual QA in staging
- [ ] Error tracking implemented (Sentry)
- [ ] Feature flag ready for gradual rollout
- [ ] Documentation updated
- [ ] Performance budget met (< 100ms p95)

The Sprint Zero Checklist

Before Sprint Zero

• Stakeholders committed to 1 week of availability
• All decision-makers in the room
• Whiteboard or digital equivalent ready
• Access to existing data/systems

During Sprint Zero

• Day 1: Problem validation complete
• Day 2: Technical decisions documented
• Day 3: Success metrics defined
• Day 4: Risks identified and mitigated
• Day 5: Development plan finalized

After Sprint Zero

• Stakeholder sign-off on all decisions
• ADRs committed to repository
• Tracking plan implemented
• Risk mitigation tickets created
• Development kickoff scheduled

Real Sprint Zero Output Example

Here's what we produced for a recent e-commerce personalization project:

Problem validated: Users abandon carts because recommendations feel generic Solution: Real-time collaborative filtering on product views

Technical decision: Use Redis for session tracking, Postgres for user history, Replicate for model inference

Success metric: 15% reduction in cart abandonment within 30 days

Risks mitigated: Model cold-start (fallback to popular items), Redis memory limits (TTL 1 hour)

Week 1 plan: Session tracking → Basic recommendations → A/B test framework

Why This Works

Before Sprint Zero (typical project):

• Requirements: Vague
• Tech stack: Undecided
• Metrics: None
• Risks: Unknown
• Success rate: 30%

After Sprint Zero:

• Requirements: Validated
• Tech stack: Documented
• Metrics: Tracked
• Risks: Mitigated
• Success rate: 80%

One week of planning saves months of rework. That's not an expense — that's the highest ROI activity in product development.

The best code is the code you never have to rewrite. Start with Sprint Zero.

Written by

Priya Shah