Lifecycle · Phase 5 of 8
Build keeps delivery focused on what was agreed. 38 governed templates help teams manage scope changes clearly, so decisions stay visible and the work remains aligned throughout delivery.
Build is where the agreed product takes shape. The team tracks what is being delivered against what was defined, identifies blockers early and records any trade-offs or changes along the way. The aim is to keep delivery aligned, so changes to scope are deliberate decisions rather than gradual drift.
During Build, the team needs to stay clear on:
Gensudo includes 38 Build templates across the five product roles, with the Product Owner leading this phase with 13 templates. The Creative Director follows with 8, reflecting the growing focus on execution and brand delivery. Key documents include User Stories, Brand Guidelines and Tone of Voice Guidelines, helping teams keep delivery aligned with what was agreed. Gensudo’s kanban, timeline, calendar and flow views also make progress easy to track, while sign-off guidance remains built into each document so approvals do not get lost during delivery.
Treat user stories as working documents, not archived specs. When reality diverges from a story, update the story — the alternative is a backlog that describes a product nobody is building.
Regularly compare what exists to what the PRD promised. Gaps found weekly are course corrections; gaps found at launch are incidents.
Name blockers early and visibly. A blocker raised in week two is a scheduling conversation; the same blocker discovered in week ten is a crisis.
Every cut, substitution and deferral gets an owner and a written reason. This is the difference between a scoped release and a shrunk one.
Launch preparation isn't a phase you enter; it's work you begin during build. The checklist assembled now is the go decision made calm later.
Because build is where the product quietly stops matching its specification — unless someone keeps score. Build documents aren't bureaucracy; they're the mechanism that turns scope changes into decisions with owners and reasons, instead of drift discovered at launch. That's why the phase still carries 38 governed templates even though most of the team's energy is in delivery.
You don't stop scope changing — you stop it changing silently. Keep user stories current with reality, compare built-versus-defined on a regular rhythm, and insist that every addition, cut or substitution is recorded with an owner and a reason. Scope that changes through documented decisions is management; scope that changes through accumulation is creep.
Divergence is normal — the failure is leaving it unrecorded. When build reveals something the definition didn't anticipate, the team decides deliberately: change the spec, change the build, or accept and document the gap. Whichever way it goes, the specification should end the phase describing the product that actually exists, because launch and everything after depend on it.
Of the 38 Build-phase templates, 13 belong to the Product Owner — the role that sits closest to the backlog, where delivery honesty is won or lost day by day. The Product Owner keeps stories current, mediates between the specification and the sprint, and makes sure trade-offs are surfaced as decisions rather than absorbed as drift.
Build keeps faith with the specification — so if the spec itself is ambiguous, that's a Define-phase problem wearing a Build-phase costume.
Revisit the Define phase →The product exists. Now readiness gets confirmed — function by function — before anyone says go.
Go to the Launch phase →Keep stories, specifications and creative direction aligned throughout delivery, with kanban, timeline, calendar and flow views all in one workspace.