Overview
A concrete product launch workflow example showing how a small SaaS team can coordinate product, marketing, support, and post-launch follow-up in Kanvly. The example walks through the team situation, board setup, live cards, notes, cadence, common mistakes, and measurement signals so the workflow feels concrete instead of generic.
The real workflow scenario
A product manager, designer, two engineers, one marketer, and a support lead are launching an account settings improvement requested by customers. Before the launch, product decisions live in a doc, support questions live in chat, and marketing keeps a separate launch checklist. The team needs one operating view before the release date gets close.
The point of this example is not to prescribe one universal process. It shows how small SaaS teams preparing a product or feature launch can turn a messy operating moment into a board, notes, and cadence that the team can actually use during a normal week.
- Finalize non-goals for the first release.
- Approve settings page copy and empty states.
- Prepare support answers for account owners.
- Create launch email and changelog notes.
- Measure activation after the first week.
The board setup
Start with the board flow Discovery -> Shaped -> Ready -> In progress -> Review -> Launch -> Learned. The lane names are intentionally plain because the first job of the board is shared readability, not process decoration.
Each card should answer owner, next action, status, and why the work matters. If a card needs more explanation than a title can hold, that context belongs in an attached note rather than a side conversation.
The notes and context to keep
The board shows motion, but the notes explain judgment. In this example, the durable context is: Customer evidence and why the team chose this scope. Launch positioning, screenshots, and known limitations. Support handoff notes with answers to predictable questions.
This is the difference between a task tracker and a workspace. A task tracker can say that something moved to review. A workspace should also make it clear what changed, who decided it, and what the next person needs to know before acting.
The weekly cadence
The cadence is deliberately lightweight: Monday readiness review for scope, risks, and owner clarity. Wednesday blocker sweep across product, marketing, and support. Friday post-launch cleanup with follow-up cards moved into Learned.
This rhythm keeps the system trustworthy without turning it into a ceremony-heavy process. The team should leave each review knowing which cards moved, which cards are blocked, and which notes were updated because a decision changed.
Mistakes to avoid
Most teams do not fail because the board has the wrong color or the wrong icon. They fail because the workflow slowly stops reflecting reality.
Use the first two weeks to remove friction rather than add fields. If people keep updating private lists, asking where context lives, or skipping the board during real work, the system is too far away from the actual operating habit.
- Treating launch day as the end of the workflow.
- Keeping support prep outside the same board.
- Moving every discovery note into execution instead of linking only the useful context.
How to know it is working
Good measurement should describe whether the workflow is becoming easier to trust. For this example, watch: Readiness blockers closed before launch. Support questions answered without escalation. Follow-up cards created from post-launch learning.
The strongest sign is behavioral. When the team opens the workspace first, trusts the board during review, and uses notes to preserve decisions, the workflow is doing its job.
- Pick one active workflow with real owners before changing the whole system.
- Create the first board with only the statuses the team can explain.
- Move live cards first and leave historical work behind until the new flow is trusted.
- Attach notes for decisions, briefs, support answers, or stakeholder context.
- Review blocked, stale, and ownerless cards on a predictable cadence.
- Turn repeated work into a template only after the team has used it once.