Product Development Process

Ship the right thing, the right way, at the right cadence -- every sprint, every quarter.

Why This Matters

Owner: A broken dev process burns cash and kills morale. A smooth one compounds velocity quarter over quarter.
Dev: Clear process means fewer fire drills, less rework, and more time writing code that actually ships.
PM: You orchestrate the cycle. If Discovery is starved, you ship the wrong features. If Delivery stalls, you lose market windows.
Designer: Without a seat at the table early (Discovery), you end up painting lipstick on engineering decisions already made.

The Concept (Simple)

Think of product development like a restaurant kitchen:

Discovery -- The chef tastes ingredients, reads reviews, designs the new menu (research & ideation).
Design -- Recipes are written, plated mockups created (wireframes & prototypes).
Build -- The line cooks execute the recipes (engineering sprints).
Ship -- Plates go out to the dining room (release & deploy).
Measure -- The manager reads table feedback and adjusts (analytics & iteration).

The key insight: Discovery and Delivery run in parallel -- you are always researching next quarter's features while building this quarter's.

How It Works (Detailed)

The Development Cycle

 ┌─────────────────────────────────────────────────────────────────┐
 │                   CONTINUOUS PRODUCT CYCLE                      │
 │                                                                 │
 │   ┌───────────┐   ┌──────────┐   ┌─────────┐   ┌───────────┐  │
 │   │           │   │          │   │         │   │           │  │
 │   │ DISCOVER  ├──►│  DESIGN  ├──►│  BUILD  ├──►│   SHIP    │  │
 │   │           │   │          │   │         │   │           │  │
 │   └─────┬─────┘   └──────────┘   └─────────┘   └─────┬─────┘  │
 │         │                                             │        │
 │         │            ┌───────────┐                    │        │
 │         │            │           │                    │        │
 │         └────────────┤  MEASURE  ├◄───────────────────┘        │
 │                      │           │                             │
 │                      └───────────┘                             │
 └─────────────────────────────────────────────────────────────────┘

Phase Breakdown

Phase	Duration	Key Activities	Outputs	Who Leads
Discover	1-2 weeks	User interviews, data analysis, competitor audit, problem framing	Problem briefs, opportunity assessments	PM + Designer
Design	1-2 weeks	Wireframes, prototypes, usability tests, technical spikes	Validated mockups, tech feasibility docs	Designer + Dev
Build	1-2 sprints	Implementation, code review, unit/integration tests	Working software, test coverage	Dev lead
Ship	1-3 days	Feature flags, staged rollout, release notes	Live feature, monitoring dashboards	Dev + PM
Measure	Ongoing	Analytics review, user feedback, A/B test results	Impact report, iteration backlog	PM + Data

Dual-Track Agile

Traditional agile has one track: build and ship. Dual-track separates Discovery from Delivery so they run simultaneously.

 WEEK 1        WEEK 2        WEEK 3        WEEK 4        WEEK 5
 ─────────────────────────────────────────────────────────────────

 DISCOVERY TRACK (PM + Designer)
 ┌──────────┐  ┌──────────┐  ┌──────────┐  ┌──────────┐
 │ Research  │  │ Research  │  │ Research  │  │ Research  │
 │ Feature B │  │ Feature C │  │ Feature D │  │ Feature E │
 └──────────┘  └──────────┘  └──────────┘  └──────────┘

 DELIVERY TRACK (Dev + QA)
                ┌──────────┐  ┌──────────┐  ┌──────────┐
                │  Build   │  │  Build   │  │  Build   │
                │ Feature A │  │ Feature B │  │ Feature C │
                └──────────┘  └──────────┘  └──────────┘
                               ▲
                               │
                        Discovery output
                        feeds Delivery

The rule: Discovery should always be 1-2 sprints ahead of Delivery. If the gap closes, you are flying blind.

Sprint Planning for SaaS

A healthy SaaS sprint balances four buckets:

 ┌─────────────────────────────────────────────────┐
 │              SPRINT CAPACITY (100%)              │
 ├────────────────────┬────────────────────────────┤
 │  New Features      │         40-50%             │
 │  (roadmap work)    │  ████████████████████       │
 ├────────────────────┼────────────────────────────┤
 │  Tech Debt /       │         20-25%             │
 │  Infrastructure    │  ██████████                 │
 ├────────────────────┼────────────────────────────┤
 │  Bug Fixes         │         15-20%             │
 │                    │  ████████                   │
 ├────────────────────┼────────────────────────────┤
 │  Discovery /       │         10-15%             │
 │  Spikes            │  ██████                    │
 └────────────────────┴────────────────────────────┘

If you spend 100% on new features, tech debt will eat you alive within 12 months. See also: SaaS Metrics That Matter for how velocity connects to business outcomes.

Release Cadence Strategies

Strategy	Cadence	Best For	Risk Level	Example
Continuous Deploy	Multiple/day	Infra-mature teams, B2B with feature flags	Low (with safeguards)	GitHub, Netflix
Weekly Release Train	Every Monday	Mid-stage SaaS, 5-20 devs	Medium	Basecamp-style
Bi-weekly Sprint Ship	Every 2 weeks	Early SaaS, small teams	Medium	Most startups
Monthly Release	End of month	Regulated industries, enterprise	Higher	Healthcare SaaS
Quarterly Big-Bang	Every quarter	Legacy or hardware-coupled	Highest	Avoid if possible

Recommendation for most SaaS: Start with bi-weekly, graduate to weekly, then continuous as your CI/CD pipeline matures.

Feature Flag Strategy

Feature flags decouple deployment from release:

 Code merged to main
        │
        ▼
 ┌──────────────┐     Flag OFF      ┌──────────────┐
 │   Deployed   ├───────────────────►│  Dark Launch │
 │   to Prod    │                    │  (internal)  │
 └──────┬───────┘                    └──────────────┘
        │
        │ Flag ON (10%)
        ▼
 ┌──────────────┐     Flag ON (50%)  ┌──────────────┐
 │  Beta Users  ├───────────────────►│  Staged      │
 │  (canary)    │                    │  Rollout     │
 └──────────────┘                    └──────┬───────┘
                                            │
                                     Flag ON (100%)
                                            ▼
                                     ┌──────────────┐
                                     │  GA Release  │
                                     └──────────────┘

In Practice

Example: Launching a "Team Dashboard" Feature

Week	Discovery Track	Delivery Track
1	Interview 8 customers about team reporting needs	Ship billing page redesign (prev. cycle)
2	Synthesize interviews, create problem brief	Bug fixes, tech debt sprint
3	Designer creates wireframes, run usability tests	Begin API endpoints for dashboard
4	Refine designs based on tests, write spec	Frontend build sprint 1
5	Start Discovery on next feature	Frontend build sprint 2 + integration
6	--	QA, staged rollout, measure

Common Mistakes

Mistake	Why It Hurts	Fix
Skipping Discovery	You build features nobody wants	Mandate 1 week of research per feature
No tech debt budget	Velocity degrades 10-20% per quarter	Reserve 20% of every sprint
Big-bang releases	Risk concentrates, rollback is painful	Use feature flags + staged rollout
Design as an afterthought	Rework doubles build time	Include Designer from Day 1 of Discovery
No Definition of Done	"Done" means different things to everyone	Use the checklist below

Definition of Done Checklist

 ┌─────────────────────────────────────────────────────┐
 │            ✅ DEFINITION OF DONE                     │
 ├─────────────────────────────────────────────────────┤
 │  [ ] Code reviewed and approved by 1+ peer          │
 │  [ ] Unit tests written (>80% coverage on new code) │
 │  [ ] Integration tests pass                         │
 │  [ ] No critical/high severity bugs open            │
 │  [ ] Feature flag configured                        │
 │  [ ] Analytics events instrumented                  │
 │  [ ] Error monitoring in place (Sentry, etc.)       │
 │  [ ] Documentation updated (API docs, changelog)    │
 │  [ ] PM has verified acceptance criteria             │
 │  [ ] Designer has verified visual fidelity           │
 │  [ ] Performance benchmarked (no >10% regression)   │
 │  [ ] Rollback plan documented                       │
 └─────────────────────────────────────────────────────┘

Key Takeaways

Discovery and Delivery run in parallel -- never let Delivery outpace Discovery.
Balance sprint capacity: 40-50% features, 20-25% tech debt, 15-20% bugs, 10-15% spikes.
Ship small, ship often -- bi-weekly minimum; graduate to continuous deployment.
Feature flags separate deploy from release -- deploy daily, release when ready.
A shared Definition of Done prevents "it works on my machine" syndrome.
Process should accelerate the team, not add bureaucracy. If a ceremony does not produce decisions, kill it.

Action Items

Owner: Review your current release cadence. If it is monthly or longer, challenge the team to move to bi-weekly within 90 days.
Dev: Implement feature flags if you do not have them. Start with a simple boolean per feature, graduate to a service like LaunchDarkly.
PM: Audit your Discovery pipeline. Are you at least 1 sprint ahead of Delivery? If not, block time for research this week.
Designer: Ensure you are embedded in Discovery, not just consulted during Build. Push for co-creation sessions with PM and engineering.

Next: Feature Prioritization -- deciding what to build is harder than building it.

Product Development Process ​

Why This Matters ​

The Concept (Simple) ​

How It Works (Detailed) ​

The Development Cycle ​

Phase Breakdown ​

Dual-Track Agile ​

Sprint Planning for SaaS ​

Release Cadence Strategies ​

Feature Flag Strategy ​

In Practice ​

Example: Launching a "Team Dashboard" Feature ​

Common Mistakes ​

Definition of Done Checklist ​

Key Takeaways ​

Action Items ​