Orangescrum
Documentation index for AI agents (llms.txt). A markdown version of this page is available at /use-cases/product-launch.md or by requesting this URL with the header Accept: text/markdown.
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 inCloudSelf-HostedOpen Source
Start Free Trial →Book a Demo

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.
RoleWhat they ownWhat they see in Orangescrum
Product managerScope, the launch date, and the go or no go callThe programme view across all five workstreams
Engineering leadThe build, the release, and the rollback planThe sprint board and the release checklist
QA leadTest coverage and the quality gate before releaseTest runs against the release, and open defects
MarketingPositioning, assets, and the announcementThe launch project and the date the assets are needed by
Support leadDocumentation, training, and readiness on day oneThe feature list and what the likely question volume will be
SalesCustomer messaging and the pricing conversationThe 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 byProgram managementAll in one 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 byGantt 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 byAgile 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 byChecklists
  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 byTest case managementBug 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 byRisk 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 byRelease managementJenkins integration
  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 byChecklists
  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 byTicketingReports and 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 viewGantt chartWork backwards from launch dayChecklistsThe readiness gate, with ownersTest case managementThe quality number behind go or no goBug and issue trackingOpen defects by severity, before you decideRelease managementReleases and rollback, in Self-HostedRisk managementA risk register and matrix, in Self-HostedAll in one dashboardThe single view for the launch lead
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 →Book a Demo

Related use cases

Sprint planningThe engineering workstreamCampaign launchThe marketing workstreamIncident managementFor when launch week goes wrongAgile Scrum templateWhere the build work lives

See all use cases →