Deployment is mistaken for readiness
The software can be released technically, but communication, data, support, access, documentation, and recovery responsibilities are unresolved.
04 · Delivery stage
Launch & Support
Prepare release, ownership, observation, recovery, documentation, and feedback so a product can continue beyond deployment.
The context
What this stage helps the team resolve.
Launch is a change in responsibility, not the end of delivery. A dependable release considers who is affected, how the change is introduced, which signals matter, how issues are handled, and how product and technical learning return to the plan.
Signals lack meaning
Analytics, logs, and alerts exist without agreed questions, thresholds, owners, or a path from evidence to action.
Knowledge leaves at handoff
The people responsible after launch do not have the context, access, runbooks, or decision history needed to operate and improve the product.
What the work considers
Keep product, delivery, and ownership connected.
Activities are selected for the project's current questions and risk. A useful process is structured, but never busy for its own sake.
01
Release readiness
Review product behaviour, quality evidence, migration, communication, access, dependencies, and known limitations.
02
Deployment and recovery
Prepare a repeatable release path with proportionate rollback, backup, reconciliation, and incident considerations.
03
Support and ownership
Define systems in scope, contacts, priorities, response responsibilities, maintenance, credentials, and escalation routes.
04
Learning after launch
Connect feedback, product signals, operational issues, and technical health to a visible improvement backlog.
Potential outputs
Leave the next decision easier to make.
Outputs are agreed around the work and may be lightweight or detailed. Their value comes from supporting action, review, and shared understanding.
- 01Release-readiness decision and open-action view
- 02Deployment, migration, and recovery plan
- 03Operational runbook and access map
- 04Support scope and responsibility model
- 05Post-launch feedback and improvement rhythm
Working agreement
Make inputs, evidence, and boundaries explicit.
The stage works best when the right context is available and the team agrees how useful progress will be judged.
What we need to understand
- Release scope, users, dependencies, and communication needs
- Quality evidence and known limitations
- Environment, data, access, migration, and recovery context
- Business and technical support owners
Evidence of useful progress
- Release decisions and unresolved actions have owners
- Support contacts can access useful diagnostic context
- Critical recovery and communication paths are understood
- Product and operational feedback can influence future priorities
Important boundary
Support scope, response expectations, and availability need explicit agreement. A maintenance arrangement should not be assumed to provide continuous monitoring or guaranteed response unless those responsibilities are defined.
Stage rhythm
A visible path through the work.
The sequence is adapted to the engagement while preserving clear decisions, review points, and responsibilities.
Assess readiness
Review product, technical, data, operational, communication, and ownership conditions against the planned release.
Prepare the change
Complete release actions, validate access and procedures, communicate responsibilities, and make limitations visible.
Release and observe
Introduce the change through the agreed path, watch meaningful signals, and respond to material issues.
Learn and improve
Review feedback, incidents, usage, maintenance needs, and technical health to shape the next priority.
Process questions
Useful details to clarify.
What belongs in a launch checklist?+
It should reflect the product and may cover acceptance, access, data, deployment, dependencies, communication, documentation, monitoring, support, recovery, and open risks.
Can a release be staged?+
Yes. Feature controls, limited audiences, parallel operation, or phased migration may reduce risk when they fit the product and can be operated clearly.
What does continued support include?+
It depends on the agreement. Work may include defect investigation, maintenance, operational assistance, small improvements, dependency care, or planning for larger changes.
How is post-launch feedback prioritised?+
Feedback is assessed against user and business impact, frequency, risk, evidence, effort, dependencies, and the product's agreed direction.
Start a conversation
Need help with launch and support?
Tell us where the work stands, what needs to change, and what is currently unclear. We can help identify a sensible next step.