Roadmap to revenue: which deals wait on which feature, and which ones moved when it shipped

How the Roadmap to revenue workflow will rank what to build by the open pipeline waiting on it, and report the deals each shipped capability moved.

Roadmap to revenue is a workflow for founders and product leaders deciding what to build next. Deals that wait on a capability will add up to demand, ranked by the open pipeline behind each one. When the work ships, a report will name the deals it moved and the customers who still need telling. Sales as Code supplies the deals, CommitOps holds the promises and will rank the demand, and RepoOps will trace the work.

Sales as Code’s part is built. Two parts are still to go.

The problem

The roadmap tends to follow whoever spoke last. A loud customer or a big logo in a sales call wins the next sprint. Nobody can say which open deals are waiting on which feature, so the argument runs on anecdotes.

The other end is as blind. A feature ships, and nobody checks which deals it was meant to move. The customers who were promised it often hear about it late, or not at all.

How the workflow solves it

Each deal in Sales as Code can name the capability it waits on. The workflow will read those deals into the CommitOps ledger and rank the capabilities by the pipeline that waits on them. That will turn the roadmap argument into a list with a number next to each item.

When RepoOps sees the work for a capability ship, the workflow will report which deals moved within 30 days and list each waiting customer who has not been told yet. A person will approve each notice before it goes out.

Step by step

When the workflow runner ships, a run will take these steps. Present tense means the part works in its product today; “will” means it is still to build.

A run will start every Monday, or when a capability ships.

1. Sales as Code reads the capability each deal waits on. It sends the capability with a customer reference only, under the org’s grant.
2. CommitOps reads those deals into the ledger. This is built and switching on.
3. CommitOps will rank capabilities by blocked pipeline. The ranking will count distinct pipeline: two deals at one company that wait on the same capability count that company’s pipeline once.
4. RepoOps will find the shipped work for each capability. RepoOps already records each merged change and its roadmap item. Reporting the capability and the deals behind a shipped change is the new part.
5. CommitOps will report the deals each shipped capability moved. Its shipped_not_told tool lists the waiting customers, oldest first.
6. A person approves telling each waiting customer in PromptCompute, before any notice goes out.

The notice is the only step that reaches a customer, so it is the only one that will wait for a person.

What the workflow will report

Each run will report three things:

• The open pipeline attached to each capability.
• The deals that moved within 30 days of the capability shipping.
• The shipped promises not yet told to the customer. The plan sets the target at 0 after 7 days.

The first figure is the ranking itself, and the second will tell you whether shipping the capability did what the ranking said it would. The third is a list of customers to tell.

Why it matters to a founder

You will be able to defend a roadmap with the pipeline behind each item, and check afterwards whether the bet paid off. A capability with a lot of waiting pipeline and no deals moved after it shipped will tell you something about the deals, or about the capability.

It will also stop shipped work from going untold. The report will list every waiting customer by how long they have waited, and each notice goes out once a person approves it.

How to set it up

Outside the family you connect your CRM (HubSpot, Salesforce or Attio) and GitHub.

When the runner and the signed-in app ship, setup will be:

1. Sign in with PromptReports ID and pick your org.
2. Connect Sales as Code, CommitOps and RepoOps. Link the CRM through Sales as Code and GitHub through RepoOps.
3. Register the agent that will run the weekly report.
4. Set the approval policy for telling a customer (commitops.customer.notify) and updating a deal (crm.deal.update).
5. Choose the trigger, every Monday or each shipped capability, and start a dry run.
6. Start the run, read the ranking, and approve the notices to waiting customers.

An agent will start the run through the PromptReports MCP server or API, with the proposed start_run tool.

Roadmap to revenue is on every plan. Plans are per user per month: $25 for 100 workflow requests, $50 for 500, and Enterprise above 500. There is no free tier. A weekly run is one request a week.

Without the runner you can already call CommitOps on its MCP server. shipped_not_told lists customers whose promised work shipped without anyone telling them, and promised_not_started lists promises with no work behind them yet. Each call takes a CommitOps key that a person issues.

What is built today and what is planned

The workflows page lists Roadmap to revenue as partly built: two of three parts are merged, and the RepoOps report of the deals a shipped change moved is still to go.

Built:

• Sales as Code deals send the capability they wait on, by customer reference only (Sales-Intelligence #2809). The signed statements switch on with a setting.
• CommitOps reading those deals into its ledger is built and switching on.
• CommitOps ranks each capability by what waits on it: the open promises, the earliest due date and the deal value they block (commitops #150).

Still to go:

• RepoOps reporting the capability and the waiting deals behind a shipped change, so each shipped capability reports the deals it moved.
• The workflow runner. No runner exists today. The plan is a durable runner service in the PromptCompute stack, with one run id across products, approvals as steps, and each run metered as one workflow request.

Read more

• Every workflow and its state
• Pricing
• The revenue loop: from a forecast to a promise kept
• Sales as Code, CommitOps and RepoOps