Product Development Lifecycle (DSBL)

Commit to dates only for work in front of you through four distinct phases

Annie Pearl
Behind the scenes of Calendly's rapid growth

Product Development Lifecycle (DSBL)

"We've gotten a lot better at making the commitments around the work that's right in front of us versus making a commitment around a project six months out when we haven't even done enough discovery, enough design and ideation to have a real clear understanding of estimation." - Annie Pearl

What It Is

The Product Development Lifecycle is a four-phase framework that structures how product work progresses from problem identification to market delivery. The key insight is that you should only commit to dates and deliverables for the phase directly in front of you—not for distant phases where too much is unknown.

This solves the common problem of teams promising delivery dates for features that haven't been designed or scoped, leading to missed deadlines and frustrated stakeholders. By breaking work into clear phases with explicit gates, teams can make realistic commitments while maintaining transparency about what's known vs. unknown.

How It Works

The four phases are:

1. Discovery

  • Research the problem space through user interviews, data analysis, and market research
  • Understand customer needs and pain points
  • Deliverable: Clear understanding of the problem worth solving (or not)
  • You CAN commit to a timeframe for completing discovery research

2. Solutioning

  • Generate and evaluate multiple solution approaches
  • Conduct user testing to validate concepts
  • Land on a specific solution direction
  • Deliverable: Validated solution design ready for estimation
  • You CAN commit to completing solutioning after discovery is done

3. Build

  • Engineering estimation and sprint planning
  • Technical implementation
  • Deliverable: Working product/feature
  • You CAN commit to delivery dates once solutioning is complete

4. Launch, Measure, Iterate

  • Release to users
  • Measure against success criteria
  • Iterate based on real-world feedback
  • Deliverable: Validated learning and ongoing improvements

How to Apply It

  1. Map your roadmap items to phases - Identify which phase each initiative is currently in
  2. Only commit dates for current phase - When asked "when will X ship?", commit only to the next phase milestone
  3. Gate transitions between phases - Require explicit go/no-go decisions before advancing
  4. Set expectations with stakeholders - Explain that delivery estimates become possible only after solutioning
  5. Use phase-appropriate templates - Different documentation for discovery vs. build phases

Example conversation:

  • "When will feature X ship?"
  • "We're in discovery now, which will complete end of Q1. If we decide to move forward, we'll have a delivery estimate after solutioning in early Q2."

When to Use It

  • When planning quarterly or annual roadmaps
  • When communicating timelines to stakeholders (sales, leadership, marketing)
  • When structuring product team workflows
  • When teams are frequently missing delivery estimates

Especially valuable when:

  • Estimates are being demanded before designs exist
  • Teams are being held to dates committed too early
  • There's confusion about what "on the roadmap" actually means

Source

  • Guest: Annie Pearl
  • Episode: "Behind the scenes of Calendly's rapid growth"
  • Key Discussion: (00:37:05) - Explaining the four phases and commitment approach
  • YouTube: Watch on YouTube

Related Frameworks

Back to Execution