Skip to content

Lifecycle

Where is my project, and what happens next? This page is the delivery workflow itself: the statuses a project moves through and the work that happens in each. The gates between the phase groups live on their own page, Gates and Approvals; how widely the feature is switched on lives in Release Phases.

The statuses are conventions you implement in whichever issue tracker your team uses (Linear, Jira, Shortcut, GitHub Projects, Asana, etc.). The names are what matter, not the tool.


Product delivery flows through 3 phase groups with 3 gates:

Shape (Backlog → Shaping) → Shaping CheckpointBuild (Readying for Build → Building → In Preview) → Launch Readiness CheckGo to Market (Ready for GTM → GTM Launch Planning → Ready for Launch → Launched) → Launch Retro Check

Projects can also be Cancelled, moved by PM or GTM Lead via agreement with Product.


StatusPhase GroupWho Moves Project HereWhat’s Happening
BacklogShapeTriaging ideas, evaluating priority
ShapingShapeProduct ManagerWriting RFC, technical feasibility
Readying for BuildBuildTech Lead / Project LeadSpecs written, engineering scopes effort
BuildingBuildTech Lead / Project LeadActive development, deployed behind flag
In PreviewBuildTech Lead / Project LeadSoft-launch with trusted customers (Private Preview)
Ready for GTMGo to MarketGTM LeadPreview successful, ready for launch planning
GTM Launch PlanningGo to MarketGTM LeadDocs, training, launch materials in progress (Public Preview)
Ready for LaunchGo to MarketGTM LeadAll launch assets complete, awaiting release date
LaunchedGo to MarketGTM LeadLive to all customers (GA), tracking adoption
CancelledProduct Manager / GTM LeadStopped, won’t be completed

Every product decision traces back to evidence. The discipline is picking the highest-leverage work for the current strategy.

  • Validate the problem before committing engineering time
  • Tag the persona: User, Admin, or Sponsor
  • Apply Signal → Standard → Speed to pick the right path (Quick Win / Lightweight / Full Spec)
  • Vision check: does this move a named outcome and its Signal? (Where one number captures the whole product, that Signal is the single headline metric.)

Backlog:

  • Talk to customers (3+ minimum); see Discovery
  • Gather evidence (pain points, workarounds, urgency)
  • Assess impact (how many customers, what magnitude?)
  • Collect usage data and feedback patterns

Shaping:

  • Write the RFC; use the RFC Template
  • Score with RICE
  • Get technical feasibility from engineering
  • Review with Sales, Marketing, Product, Engineering

Exit: the Shaping Checkpoint.


Build: Readying for Build → Building → In Preview

Section titled “Build: Readying for Build → Building → In Preview”

The product is one thing. Our three product principles are engineering standards, not aspirations. If you can’t measure it, don’t ship it.

  • The RFC is the single living document: approved at the end of Shape, updated through delivery as decisions land
  • Product principles applied as design and engineering standards, not post-hoc review criteria
  • Instrumentation wired up before preview: events defined, dashboards built, guardrail metrics identified

Readying for Build:

  • Update the RFC with the agreed approach as design and engineering land decisions
  • Hold project kick-off
  • Set up the project in your tracker with milestones (see Project Standards)
  • Engineering creates build tickets and estimates

“Ready to Build” is a conversation, not a formal gate. PM and Tech Lead confirm specs are clear and engineering is ready to start. No sign-off ceremony needed, just mutual confidence.

Building:

  • Engineering builds feature behind flag (flag OFF); see Release Phases
  • Weekly progress check-ins
  • Create demo artefacts (short recorded walkthroughs)
  • Train support team
  • Set up metrics and monitoring
  • Outcome UAT in a production-like environment: validate the user’s job end-to-end (job × surface), independent of unit tests (see Agentic Delivery)

In Preview:

  • Enable flag for 5-10 trusted customer accounts (Private Preview)
  • Gather feedback from preview customers
  • Fix critical bugs
  • Monitor production stability
  • Summarise Private Preview results
  • RFC (delivery document)
  • Instrumentation: events + dashboards covering all RFC success metrics
  • Architecture Decision Records (ADRs) for irreversible decisions
  • Changelog Draft

Exit: the Launch Readiness Check.


Go to Market: Ready for GTM → GTM Launch Planning → Ready for Launch → Launched

Section titled “Go to Market: Ready for GTM → GTM Launch Planning → Ready for Launch → Launched”

Shipping is the beginning, not the end. A feature nobody uses isn’t a success, it’s an unanswered question. Getting from “we built it” to “customers use it” takes deliberate effort.

  • Changelog entry for UX changes, support notification for everything
  • GTM Lead owns transitions from Ready for GTM onward
  • Structured post-launch reviews at three intervals:
    • 2 weeks: Early signal. Is it being used? Any red flags?
    • 30 days: Trend check. On track? Feedback patterns?
    • 60–90 days: Full review. Data meets decision

Ready for GTM → GTM Launch Planning:

  • Widen the flag to the Public Preview cohort (see Release Phases)
  • Write customer documentation
  • Write release notes and changelog
  • Train Sales team (positioning, value), for higher-stakes launches
  • Train Support team (functionality)
  • Prepare launch materials (blog, email, social), for higher-stakes launches
  • Execute launch activities
  • Get GA sign-off

Ready for Launch → Launched:

  • Publish announcement and release notes
  • Enable feature for broader rollout (gradual % or full)
  • Monitor adoption metrics
  • Respond to customer feedback
  • Track self-onboarding conversion
  • Measure sales enablement impact
  • Launch materials (scaled to the stakes of the launch)
  • Post-Launch Review at 2wk/30d/60-90d intervals
  • Changelog updates

Exit: the Launch Retro Check, run through the post-launch reviews.