Product Development Template
A board that starts before engineering does. Discovery findings become cards, and a feature doesn't reach general availability until support's part is done too.
Product, design, engineering and support cards move through the same four stages. A feature doesn't clear the gate until support's card is done too, not just engineering's.
Why most product templates stop covering the whole product
A feature's real lifecycle starts before anyone writes code and doesn't end when engineering calls it shipped. Most templates only track the middle of that, which is why the board and the actual product lifecycle drift apart within a quarter.
Discovery isn't on the board at all. Research and interview findings live in a deck that gets presented once and then referenced from memory, so by the time engineering sees the work, the reasoning behind it looks unmotivated.
Design and engineering keep separate boards. A card is "done" on one and unstarted on the other, and status meetings exist mainly to reconcile two versions of the same piece of work instead of actually moving it forward.
Beta feedback and GA readiness aren't tracked as work. A feature reaches 100% of users before support has a runbook for the tickets it's about to generate, because nothing on the board represented that as a thing to finish.
The template gets confused with a sprint board. A pure engineering board tracks tickets inside a build cycle, which is a real and useful thing, but it isn't the same problem as tracking a feature from an unclear user complaint through to a support team that can actually handle what it generates.
The common thread is scope: most product templates are really engineering templates wearing a different label, tracking the part of the lifecycle that produces code and leaving the parts before and after it to whatever happens to be lying around: a deck, a spreadsheet, nothing at all.
The structure, and why each part is there
Research and interview findings become cards, not a separate deck referenced once at kickoff and then forgotten by the time build starts, so the reasoning behind a feature is still checkable months later.
A card moves through the same discovery, design, build and beta stages regardless of whether product, design, engineering or support currently owns it: one place status lives, instead of four.
A cap on how much is in active development at once, so half-built features don't pile up waiting on whatever's next in line. It's a simple rule that pays off specifically here, where "just start the next one while we wait on review" is exactly how a team ends up with five features at 80% and none of them shipped.
A feature doesn't move to general availability until specific criteria, a support runbook, docs, are also marked done as their own cards, not just engineering's part of the work.
As sprints complete during the build phase, the forecast for when a feature clears build updates itself, rather than staying pinned to the estimate from kickoff.
The wiki holds why a feature was scoped the way it was, with page history, and any line of the spec can become a task if it turns out to need one during build or after launch. Six months on, that history is the difference between "we don't remember why we cut that" and an actual answer.
What a feature's path through the board looks like
An onboarding drop-off shows up first as a pattern in support tickets, then as a card in discovery once someone runs a handful of user interviews to confirm it's real and not a one-off complaint. Design picks up the discovery card and turns it into wireframes for a new flow. The card moves, but the discovery notes stay attached, so nobody's re-explaining the problem three weeks later. Build splits it into backend and frontend cards, both inside the column cap of four, and the forecast for when they'll clear build shifts slightly each sprint based on how the team's actually moving, not the estimate from the kickoff call. Before the feature can leave beta, two cards have to close: the engineering work, and a support runbook for the ticket types this flow is expected to generate. Only once both are done does the feature move to general availability, not when engineering finishes, which is a different, earlier moment.
How to use it
- 01Turn discovery findings into cards before design starts. Give design something concrete to react to, rather than a verbal brief that gets reinterpreted along the way.
- 02Cap the build column low. Low enough that the team finishes a feature before starting the next one while three others sit half-built.
- 03Write GA gate criteria per feature as their own cards. Support runbook, docs, rollout plan, so "engineering's done" and "ready for GA" stop being treated as the same milestone.
- 04Watch the build forecast, recalculated from velocity, rather than the original estimate from three sprints back that nobody's revisited since.
- 05Keep the decision log current. Why v1 was scoped narrow, why a feature was cut, so the next person doesn't relitigate a call that was already made for a reason.
- 06Let support see the board before beta, not at GA. A runbook written after the feature ships is written under pressure; one written during beta is written with time to actually think it through.
The discovery-to-GA flow isn't proprietary. You could run it in any tool with shared columns and a WIP limit. It's written down here because the GA gate is the piece most product boards skip, which is exactly how support ends up surprised by a launch nobody warned them was coming.
- Discovery belongs on the board as cards, not in a deck referenced once and then forgotten
- Engineering finishing a feature and a feature being ready for GA are different things, so track them as separate gates
- The build forecast should move with velocity, not stay pinned to the estimate from kickoff
Common questions
No. This one is scoped for the whole product lifecycle, discovery through general availability, across product, design, engineering and support. A pure engineering sprint board is narrower and doesn't carry discovery or the GA gate. This template is closest in spirit to launch planning, but covers building the thing rather than the go-to-market push around it.
To clear the GA gate on this board, yes. If there's no runbook card marked done, the feature stays at beta on this board rather than moving to general availability. That's deliberate, not a bug in the template.
The GA gate criteria still apply. A support runbook and docs still need their own cards marked done before the feature moves to general availability, whether or not there was a formal beta window in between.
The card simply doesn't move to design. A discovery card can close as "not pursuing," with the reasoning written into its wiki page, which turns out to be a genuinely useful record the next time someone proposes something similar and nobody quite remembers why it didn't happen before.
Yes. All templates are included on the Free plan, which covers up to five users and two projects and does not expire. A larger cross-functional team needs a paid plan for the extra seats, not for the template. See pricing.
Related pages
See it on your own work.
A workspace your whole company will actually use is 60 seconds away. No card, no risk, nothing to install.
14-day full-access trial · sample project included · no card required