The feature is done and the launch is not, because six teams each thought somebody else was doing the enablement. Here is the model behind a launch tracker, the prompts to build it, and what it takes to run it.
Your private status link is on its way to your inbox.
A product launch tracker is four parts: a tier that decides how much launch a feature gets, a workstream per function with a named owner and its own readiness, exit criteria that are checkable rather than a feeling, and a go or no-go held on a date with the evidence attached. The part teams get wrong is the tier. Treating every feature as a full launch exhausts the company, and treating none of them as one means the big launch lands with nobody ready.
Launches
11
Launches this quarter
2
Tier one
1
At risk, go or no-go Thursday
6 days
Median slip, tier one
Segments GA, tier one, go or no-go on 11 Sep. One blended number for this launch reads 76% and looks fine. Split by workstream, sales enablement has no owner and twelve days to go.
You run product, product marketing or a launch function. Things ship and then nobody knows about them, or a big launch arrives and support has never seen the feature. What you want is one page per launch that says who is ready and who is not.
What happens between a feature being finished and a launch being ready.
Which decides how much launch this gets, and therefore which workstreams apply and how much each owes.
Product, docs, marketing, enablement, support, legal, each with a named owner rather than a function name.
Because a tracker only the launch owner can edit is just the launch owner chasing seven people on Slack.
Which makes it a measurement. Criteria marked met with no evidence get flagged, because those are the ones that are not.
Put them in one field and readiness becomes whatever the date needs it to be, discovered on launch day.
Including the no-goes. A launch function with no record of what it delayed relearns the same lesson every quarter.
A launch tracker is not a project plan with a launch date on it. It is four parts, and the first one prevents most of the pain.
How much launch this gets. A tier three feature note and a tier one launch need different work, and deciding that up front is what stops the company drowning in launches.
Product, docs, marketing, sales enablement, support, legal, each with a named owner and its own readiness rather than one blended percentage.
Per workstream, per tier. Not "docs are ready" but the specific pages that must exist, so readiness is a test rather than a mood.
A decision held on a date, with the readiness evidence attached and the outcome recorded, including the times you decided not to go.
These prompts start from a Helix project, which is what handles sign-in, credentials and hosting. Start with Helix
Paste these into Claude Code, Codex or Cursor in order. Each one leaves you with something that runs, so you can stop after any step.
Because not every feature deserves a press release.
In this Helix project, build me a product launch tracker.
A launch record: name, the feature or release it covers, the product area,
the target date, the launch tier, the launch owner, current status, and a
one-line description of what changes for the customer.
Tiers, and make this the first decision:
Tier one is a major launch. Press, analysts, a campaign, sales
enablement, a customer webinar.
Tier two is a significant feature. Release note, docs, an email, a sales
briefing.
Tier three is an incremental change. Release note and docs only.
The tier determines which workstreams apply and which exit criteria are
required, so let me define that mapping and change it.
Treating every feature as a tier one exhausts the company and people stop
reading launch emails. Treating none of them as one means the launch that
mattered lands with support seeing it for the first time in a ticket.
I sign in through Helix, so do not build a login page. Read the signed-in
user from the runtime. And do not put any key or connection string in the
code: if this needs to reach another system, tell me and I will create the
connection in my workspace.Worth knowing. Tiering first is the whole trick. Everything downstream, which workstreams apply and how much work each owes, falls out of one decision made at the start.
Because one overall percentage tells you nothing you can act on.
Now add workstreams, one per function involved: product, documentation,
marketing, sales enablement, support, legal and privacy, and anything else
I add later.
Each workstream on a launch has a named owner, a set of tasks derived from
the tier, its own readiness percentage, and a status the owner sets:
on track, at risk, or blocked.
Show readiness per workstream rather than one blended number. "Marketing
is 60%" tells you who to call. "The launch is 78% ready" tells you
nothing, and it is usually an average that hides one workstream at zero.
Roll up to a launch view: which workstreams are ready, which are at risk,
and specifically what is outstanding in each.
Let workstream owners update their own status without touching anyone
else's, because a launch tracker that only the launch owner can edit
becomes the launch owner chasing seven people on Slack, which is the
thing you were trying to replace.The difference between a readiness number and a guess.
Add exit criteria per workstream per tier, and make them checkable.
Not "docs are ready" but the specific thing: the three how-to pages are
published and linked from the release note. Not "sales is enabled" but
the briefing is delivered, the one-pager is in the portal, and the demo
environment has the feature switched on.
Each criterion is either met or not, with who confirmed it and when. The
workstream readiness percentage is then just the proportion met, which
makes it a measurement rather than an opinion.
Track the ship date and readiness as separate questions. If they are the
same field, readiness quietly becomes whatever the date needs it to be,
and you find out on launch day.
Flag any criterion marked met with no evidence and no date, because those
are the ones that turn out not to be met.Held on a date, with the evidence attached.
Last, the decision, and treat it as an event rather than an email thread.
A go or no-go on a date before the launch: it shows every workstream's
readiness, the outstanding criteria, the risks raised, and it records an
outcome. Go, go with a named exception, or no-go with a new date.
Record who decided and what they knew. A launch that goes with docs at
40% is sometimes the right call, and the useful thing is that somebody
chose it with the number in front of them rather than nobody noticing.
Keep the no-go decisions. The launches you delayed and why are the most
useful history a launch function has, and they are the ones that never
get written down.
Then report across launches: how many by tier per quarter, which
workstream is most often the one at risk, average slip by tier, and the
proportion that went with exceptions. If the same workstream is late
every time, that is a resourcing answer rather than a nagging problem.Worth knowing. Recording no-go decisions is the part everyone skips. A launch function with no record of what it delayed relearns the same lesson every quarter.
The step that turns a working prototype into something with your data in it.
Now connect it to the systems we actually run, so it works on real data
rather than the rows you seeded.
Anything in angle brackets is a placeholder. Swap it for whatever we use
instead, and have the app name the connection it wants rather than assume
a vendor, so changing my mind later is a config change and not a rewrite.
<Jira>. Read the epic behind the launch, so the product workstream's
readiness is the real state of the work rather than a typed percentage.
<Slack>. Give each launch a channel, and post the readiness summary before
the go or no-go rather than asking seven people.
<Notion>. Pull the launch brief, positioning and messaging, so the tracker
links to them rather than duplicating them.
<Salesforce>. Read which accounts asked for this, which is what turns a
launch email into a list of calls worth making.
<Google Calendar>. Hold the launch date and the go or no-go, so the date
lives in one place and moves in one place.
<Zendesk>. Confirm support macros and help centre articles exist, which is
the support workstream's exit criterion rather than a promise.
<Google Drive>. Track the enablement deck and one-pager as artefacts, so
'the briefing is delivered' has something attached to it.
<Amplitude>. Read adoption after launch, which is the only way to know
whether a tier one was worth being a tier one.
Only write where I have said to write. Everything else is read only.
Do not write a key, a token or a connection string anywhere in the code,
and do not ask me to paste one. Tell me which connections you need and I
will create each as an authentication in my Helix workspace. Reference
them by alias.Worth knowing. Every name in angle brackets is a placeholder for whatever you run. Helix holds the credential as a workspace authentication, so the app references an alias and never the secret itself.
The last step of every build: a URL, and the right people on it.
Deploy my app.Worth knowing. Your assistant runs helix deploy underneath and the app comes back as a URL. Unreleased features are in here by name, so set Access Control before sharing.
A launch touches every function, so the tracker reads readiness from where each function already works.
Jira
Read the epic behind the launch, so the product workstream's readiness is the real state of the work rather than a typed percentage.
Slack
Give each launch a channel, and post the readiness summary before the go or no-go rather than asking seven people.
Notion
Pull the launch brief, positioning and messaging, so the tracker links to them rather than duplicating them.
Salesforce
Read which accounts asked for this, which is what turns a launch email into a list of calls worth making.
Google Calendar
Hold the launch date and the go or no-go, so the date lives in one place and moves in one place.
Zendesk
Confirm support macros and help centre articles exist, which is the support workstream's exit criterion rather than a promise.
Google Drive
Track the enablement deck and one-pager as artefacts, so 'the briefing is delivered' has something attached to it.
Amplitude
Read adoption after launch, which is the only way to know whether a tier one was worth being a tier one.
Each line says whether the app reads, writes or both. Anything not described as writing should be read only.
Named systems are the ones most teams actually run, not a list of the only ones that work. Swap in whatever you use.
Each connection is an authentication in your Helix workspace, referenced by alias. The app names the connection it wants and never holds the credential, so nothing here ends up in your code and any of it can be rotated or revoked without a redeploy.
The build gets you a working tracker. It holds unreleased product plans and it is edited by seven functions, so it needs to be run properly.
AI Deployment
One command takes the app from your assistant to a live address, so the people who need it get a link rather than instructions for running it locally.
App Security
Unannounced launches with dates are one of the more sensitive things a company holds. SSO plus scoped access is what keeps the roadmap inside the roadmap.
App Security
Reading epics from the issue tracker and writing status back needs real access. Granting it to the app rather than pasting a key into it means it can be rotated or revoked without a redeploy.
App Registry
Every app carries a named owner and an entry IT can see, so the tool does not become nobody's problem when the person who built it changes role.
Cost Management
Per-app spend visibility, with budgets and caps, so an internal tool cannot quietly become a line item nobody can explain.
One record per launch that sets a tier, splits the work into a workstream per function with named owners and separate readiness, holds checkable exit criteria, and records a dated go or no-go decision.
Because a tier three feature note and a tier one launch need different work. Treating everything as a major launch exhausts the company and people stop reading launch emails; treating nothing as one means the launch that mattered lands with support unaware.
Because "the launch is 78% ready" is an average that usually hides one workstream at zero. "Marketing is 60%" tells you who to call, which is the only thing a readiness number is for.
That it can be checked by somebody other than the person who owns it. "Docs are ready" is a feeling. "The three how-to pages are published and linked from the release note" is a test with an answer.
Because the launches you delayed and why are the most useful history a launch function has, and they are the ones nobody writes down. Without them the same lesson gets relearned every quarter.
Yes. The prompts here are written for Claude Code, Codex or Cursor and stage the build. The judgement calls are your tiers and your exit criteria, and getting the criteria checkable is worth more than anything the app does.
Product and Engineering
Generate the right checks for the kind of release it is, block on the ones that matter, and tell the teams who need to know before it ships. Prompts to build it, and what it takes to run it.
Product and Engineering
Collect requests from everywhere, merge the duplicates, weight them by the revenue behind them, and close the loop when something ships. Prompts to build it, and what it takes to run it.
Marketing
One calendar covering every channel, with review routed by what the content contains rather than by who remembers to ask. Prompts to build it, and what it takes to run it.
Last reviewed September 2026.
Helix is the governed runtime for AI-built apps. Deploy what you build, put SSO in front of it, connect it to your systems with managed credentials, and give it a named owner.
Your private status link is on its way to your inbox.