The product development lifecycle in one place - a practical guide
A walkthrough of the full lifecycle - idea, spec, plan, build, review, ship, learn - with the handoffs where teams lose context, and how to run each stage so the next one inherits everything.
May 1, 2026 · 4 min read · Kash Gohil
The product development lifecycle - idea to spec to plan to build to ship to learning - fails at the handoffs, not the stages. Every team ideates, plans, and ships somehow; what separates smooth teams from chaotic ones is whether each stage inherits the context of the one before it, or starts an archaeology dig. This guide walks the lifecycle stage by stage, with the handoff each one owes the next.
Stage 1: Idea → Decision
Ideas are cheap and plentiful; the stage's job is deciding which ones deserve a spec. Keep a visible-but-separate ideas pool (not in your backlog), and promote an idea only when someone can write one paragraph: the problem, who has it, and why now.
The handoff owed: a decision with a reason - including "no, because." Teams that skip recording the nos re-argue them quarterly.
Stage 2: Decision → Spec
The spec (or RFC) turns "we should" into "here's precisely what" - reviewable before the expensive part starts. This stage has the best-documented playbook of the lifecycle, so we wrote it up separately: how to write an RFC that actually gets read, template included. The short version: state the problem, propose concretely, name the alternatives, set a decision date, get explicit sign-off.
The handoff owed: an approved spec structured so it can be decomposed - which is the difference between a spec that becomes work and a spec that becomes a PDF.
Stage 3: Spec → Plan
Decompose the approved spec into issues sized for one reviewable change each, grouped as a project, each issue tracing back to the section it implements. This is where scope becomes visible: if the spec decomposes into forty issues and you expected twelve, better to learn now.
The handoff owed: a plan whose items reference their why. An issue that can't answer "which part of the spec is this?" will drift, and its drift is invisible.
Stage 4: Plan → Build
The build stage runs on small branches, fast trustworthy CI, and review that doesn't queue. The process failure that hurts most here isn't slow coding - it's the loop back: discoveries during building that quietly change scope without updating the spec or the plan. When reality diverges from the spec, the spec gets a one-line amendment, not a shrug.
This is also the stage where agent teammates contribute most - and they sharpen the handoff discipline, because an agent's output is only as good as the issue and spec behind it.
The handoff owed: merged changes that closed their issues automatically - status that maintains itself - so "what's done?" is never a meeting question.
Stage 5: Build → Ship
Shipping should be the boring stage: the pipeline that tested every change also packages and deploys it, gated by the same required checks, with a human hand on the final lever. If releases are exciting, the excitement is deferred risk from earlier stages - untested paths, unreviewed scope, manual steps.
The handoff owed: a deployed change traceable to its issues and spec - because stage 6 is about to ask "did it work?", and that question needs to know what "work" meant.
Stage 6: Ship → Learning
Close the largest loop: did the shipped thing solve the problem from stage 1? A short delta note ("what we built, how it differs from the spec, what surprised us") written the week after shipping, plus a check on whatever signal the spec said would define success. Feed what you learn back into the ideas pool, and the lifecycle is a cycle instead of a line.
Why do the handoffs fail in a normal stack?
Count the tools in the walkthrough above: ideas in one place, specs in a docs app, plans in a tracker, code and CI on a platform, conversation in chat, learnings back in docs. Six stages, five tools, and every handoff is a manual copy between systems - which is why each stage so often starts by reconstructing what the last one knew. The stitched stack can run this lifecycle with discipline (every practice above works anywhere), but the discipline is constant because the structure fights it - the argument we laid out in why we built Rezee.
One workspace changes the default: in Rezee, the spec in Ideate & Design becomes the issues in Plan & Track, which close from Code & Ship, with status flowing back into the document and the discussion attached rather than adjacent - the handoffs are the data model, so context arrives without being carried.
FAQ
What are the stages of the product development lifecycle?
Six, in practice: idea capture and decision, specification, planning and decomposition, building with review, shipping through CI/CD, and post-ship learning that feeds back into ideas. Names vary by team; the handoffs between them are where the failure modes live.
How is this different from agile or Scrum?
Orthogonal. Agile prescribes cadence and ceremonies for stages 3-5; this guide is about what each stage passes to the next, which matters identically in Scrum, Kanban, or no-method-at-all. Most "agile isn't working" complaints are actually handoff failures wearing a methodology costume.
How long should each stage take?
For a small team's typical feature: days in specification, an afternoon in decomposition, one to three weeks building, minutes shipping. Warning signs are ratio-shaped - specs that take longer than building, or shipping that takes longer than either.
Can a small team skip stages?
Skip ceremony, never handoffs. A two-person team's "spec" can be five paragraphs and its "plan" six issues - but work that starts without a written why and ends without a what changed pays for the shortcut with interest, usually within a quarter.