--- title: "Product Launch Plan: Coordinating Five Teams | Orangescrum" description: "How to run a product launch across engineering, marketing, support, and sales. The launch programme, the readiness gates, the risks." canonical: https://www.orangescrum.com/use-cases/product-launch --- # Product Launch Plan: Coordinating Five Teams | Orangescrum > For the complete documentation index, see [llms.txt](https://www.orangescrum.com/llms.txt). [Home](/) / [Use cases](/use-cases) / Product launch Use case # A Product Launch Where _Support Is Not Surprised_ The engineering work is rarely what sinks a launch. It is that marketing needed screenshots two weeks ago and support found out on the day. Available in[Cloud](/pricing "Cloud - included")[Self-Hosted](/self-hosted "Self-Hosted - included")Open Source [Start Free Trial →](/sign-up?utm_source=website&utm_medium=feature&utm_content=usecase_product-launch)[Book a Demo](https://calendly.com/orangescrum) Release management and risk management are Self-Hosted only · Unlimited users on every plan ## The scenario A significant release ships in six weeks. Engineering has it in their sprint board. Marketing has a launch plan in a document. Support has heard about it. Sales will find out from a customer. Each group is competent and each is working from a different picture. A launch programme puts the five workstreams in one place with one date, so the dependency between them is visible before it becomes a crisis. Runs Per release Typical lead time 4 to 12 weeks Start from Agile plus a launch project Owner Product manager or launch lead Who is involved ## Who is _involved_ Five workstreams, one date. Every one of them has a dependency on another. | Role | What they own | What they see in Orangescrum | | Product manager | Scope, the launch date, and the go or no go call | The programme view across all five workstreams | | Engineering lead | The build, the release, and the rollback plan | The sprint board and the release checklist | | QA lead | Test coverage and the quality gate before release | Test runs against the release, and open defects | | Marketing | Positioning, assets, and the announcement | The launch project and the date the assets are needed by | | Support lead | Documentation, training, and readiness on day one | The feature list and what the likely question volume will be | | Sales | Customer messaging and the pricing conversation | The launch date and the enablement material | The workflow ## Nine steps to _launch day_ The readiness gate is the step most teams skip, and it is the one that saves the launch. 1. 1 ### Group the workstreams under one programme Engineering, marketing, support, sales enablement, and legal each keep their own project. A programme sits above them so one person can see all five against the same date. - Do not force marketing onto the engineering board, and do not force engineering onto a marketing plan - The programme is where the cross workstream dependency lives Carried by[Program management](/program-management-software)[All in one dashboard](/all-in-one-project-management-dashboard) 2. 2 ### Fix the date and work backwards Put the launch date on a timeline, then place the dependencies behind it. Screenshots need a stable build. Support docs need final copy. Sales enablement needs the pricing decision. Each of those has a date, and it is earlier than people think. Carried by[Gantt chart](/gantt-chart) 3. 3 ### Freeze scope at a stated point Name the date after which nothing new gets in. Without it, engineering is still building on launch week and marketing is writing about a feature that changed on Tuesday. Carried by[Agile project management](/agile-project-management) 4. 4 ### Build the readiness checklist One checklist covering every workstream. Docs written, support trained, pricing published, monitoring in place, rollback tested, legal signed off. Each item has an owner and a hard due date before the launch. Carried by[Checklists](/checklists) 5. 5 ### Run the quality gate before you commit to the date Test the release properly and count the open defects by severity. The go or no go decision needs a number, not a feeling, and the number is how many high severity defects are still open. Carried by[Test case management](/test-case-management)[Bug and issue tracking](/bug-and-issue-tracking) 6. 6 ### Log the risks, with owners A dependency on a third party, a key person on holiday in launch week, an untested migration. Write them down with an owner and a mitigation. Self-hosted teams have a risk register with a risk matrix for exactly this. - Risk management is available in the Self-Hosted edition - Cloud teams can track the same risks as tasks with an owner and a due date Carried by[Risk management](/risk-management) 7. 7 ### Track the release itself Which build, which items are in it, and what happens if it has to be rolled back. Release management, with releases that carry the work items they contain, is available in the Self-Hosted edition. Carried by[Release management](/release-management)[Jenkins integration](/integrations/jenkins) 8. 8 ### Hold a go or no go with the checklist on screen Thirty minutes, the day before. Walk the readiness checklist, read the open defect count, and make the call. A launch delayed by two days on the basis of a checklist is far cheaper than one that goes out and gets pulled. Carried by[Checklists](/checklists) 9. 9 ### Run a launch week war room, then a retro Keep a single project for launch week issues so problems have one queue rather than four channels. Within two weeks, hold a retro on the process rather than the product. Carried by[Ticketing](/ticketing-software)[Reports and analytics](/project-reports-analytics) Set it up ## Build it _on Monday morning_ About two hours for the first launch, and much less after that. 1. 1Create a launch project per workstreamEngineering usually already has one. Add marketing, support, sales enablement, and legal, using the Simple or Kanban template for each. 2. 2Group them under a programmeSo one person can see all of them against the same date without opening five projects. 3. 3Put the date on the timeline and work backwardsAdd the milestones each workstream depends on, and be honest about how early screenshots and docs are really needed. 4. 4Write the readiness checklistEvery workstream contributes three to five items. Make it a reusable checklist group so the next launch starts from it. 5. 5Agree the go or no go ruleWrite down what would stop the launch, in advance, in numbers. It is much easier to agree that before you are two days out. 6. 6Book the war room and the retroBoth in the calendar, before launch week starts. Teams that need a formal risk register, a release record, or CI status on the work item should look at the self-hosted edition, which includes risk management and release management. The result ## What good _looks like_ Support is ready on day one They knew the feature list six weeks out and their documentation was on the readiness checklist. Marketing had a stable build in time Because the screenshot dependency was on the timeline, not in someone's head. The go or no go took thirty minutes It was a checklist and a defect count rather than a debate about how everyone feels. Nothing was a surprise Risks were written down with owners weeks earlier, so the ones that happened had a plan. Launch week issues had one queue Problems were triaged rather than spread across four chat channels. The next launch is easier The readiness checklist is reusable, and the retro fixed the one thing that actually hurt. Watch out ## Where this _usually goes wrong_ Marketing finds out late Assets are rushed in the final week and the announcement is weaker than the product. ✓ One programme with one date, so every workstream sees the same plan. No scope freeze Engineering is still adding features while marketing writes about the old ones. ✓ A stated freeze date, agreed at the start, on the timeline. Go or no go by vibe Nobody wants to be the one to delay, so a shaky release ships. ✓ Agree the numeric rule weeks early, when it is not personal. Support trained after launch Day one question volume overwhelms a team that has not seen the feature. ✓ Support readiness is a checklist item with a due date before launch. Risks in someone's head The known dependency on a third party is the thing that breaks, and there was no plan. ✓ Write risks down with an owner. Self-hosted teams get a proper risk register. No retro on the process The same coordination failure repeats every launch. ✓ A retro within two weeks, about the process rather than the product. Features used ## Everything this _runs on_ Release management and risk management are available in the Self-Hosted edition. The rest is in both Cloud and Self-Hosted. [Program managementFive workstreams, one view](/program-management-software)[Gantt chartWork backwards from launch day](/gantt-chart)[ChecklistsThe readiness gate, with owners](/checklists)[Test case managementThe quality number behind go or no go](/test-case-management)[Bug and issue trackingOpen defects by severity, before you decide](/bug-and-issue-tracking)[Release managementReleases and rollback, in Self-Hosted](/release-management)[Risk managementA risk register and matrix, in Self-Hosted](/risk-management)[All in one dashboardThe single view for the launch lead](/all-in-one-project-management-dashboard) Frequently asked questions ## Product launch _FAQ_ Should everything go into one project? No. Give each workstream its own project so the team can work the way it prefers, and group them under a programme so the launch lead sees all of them against the same date. When should the scope freeze be? Far enough before launch that marketing can write about something stable, which in practice is usually two to three weeks out. The exact date matters less than agreeing one and holding it. How do we make the go or no go objective? Agree the rule in advance and in numbers, such as no open critical defects and no more than three open high severity ones. Writing it down weeks early is what stops the decision being about who is most confident. Does Orangescrum handle releases and rollback? Release management, where a release record carries the work items it contains, is available in the Self-Hosted edition. The self-hosted edition also has a Jenkins integration so build status appears on the work item. Can we keep a risk register? Risk management with a risk register and risk matrix is available in the Self-Hosted edition. Cloud teams can track the same risks as tasks with an owner and a mitigation date, which is less formal but works. Does Orangescrum deploy the software? No. It does not do deployments or feature flags. It tracks the work, the readiness, and the release record. The self-hosted Jenkins integration surfaces build status on the item, but the pipeline stays yours. Can sales and support see the launch plan? Yes. Every plan includes unlimited users, so there is no reason to exclude them. Roles control what each group can see. How far ahead should we start? Four weeks for a small release, and eight to twelve for a significant one. The limiting factor is almost never engineering, it is support documentation and marketing assets. ## Run your next launch from one plan Five workstreams, one date, and a readiness checklist everyone can see. [Start Free Trial →](/sign-up?utm_source=website&utm_medium=feature&utm_content=usecase_product-launch_cta)[Book a Demo](https://calendly.com/orangescrum) ## Related use cases [Sprint planningThe engineering workstream](/use-cases/sprint-planning)[Campaign launchThe marketing workstream](/use-cases/campaign-launch)[Incident managementFor when launch week goes wrong](/use-cases/incident-management)[Agile Scrum templateWhere the build work lives](/project-templates/agile-scrum) [See all use cases →](/use-cases)