ChatGPT
Claude
Google AI
Copilot
The quarterly list is a column of features from a keynote. Nothing on it says which release you are absorbing, and nothing on it names a pain someone timed. The kill list is a slide with no owner allowed to deactivate a flow. An agent went live as a second front door. The screen people already use is still there, with no date to remove it. The mobile page gained a field because a region asked, and another field because the next region asked. At the end of the quarter the story is that the org is moving. The quote is still rekeyed. The case still takes the second call. The org is heavier.
A roadmap that only adds features is how a Salesforce org gets heavier. More flows on the same save. More fields on the same page. More paths that do one job. The quarterly list has two columns. What you will change because a release or a pain requires it. What you will remove. If the second column is empty, you do not have an improvement roadmap. You have a backlog of additions.
Tied to a release, or to a pain
Salesforce ships on a calendar. Say which release you are absorbing, and what in it you will actually turn on, leave off, or delay. "We will review the release" is not an item. An item is a named feature, a decision, and a date: turn on, leave off, or delay, and who owns the decision. Leaving something off is a result. Write it down so the next quarter does not relitigate it because a demo was impressive.
Separate that from operational pain. The case that takes a second call. The quote that gets rekeyed. The report a country manager does not trust. If an item is not tied to a release or to a pain you can point at, it is a wish. Park it where wishes go, and do not let a keynote pull it back onto the list. Wishes return as demos. They do not jump the queue because a vendor session was energetic.
Write the pain in hours or rework, the same way you would baseline a programme. "Sellers complain" is not yet an item. "Quotes are rekeyed, and we timed ten of them, and the second sitting is the price being typed again" is an item. The hours are what you will score. A story that the team feels better is not a score. The method for those hours is the one in how a return is counted before a programme starts. If this roadmap cannot point at a baseline, it will fill with clouds and call that improvement.
The kill list is the improvement
Every quarter, name what will be turned off. A flow nobody can explain. A field that duplicates another. A page replaced last release and still linked from a home layout. An integration nothing calls. An agent path that sits beside a screen people already use, with no date to remove the screen. A report that disagrees with the sentence the executive page uses. Removals need an owner and a date, the same as additions. The owner is allowed to deactivate the flow. A kill list that is a slide, with no one allowed to turn the thing off, is decoration, and the org will keep every good idea that was ever switched on.
Deactivate means in the org, on the date, with a note of what you watched the week after. A flow turned off on Friday and turned back on Monday because a seller shouted is not removed. It is a finding that the pain was not understood, or that the replacement was not ready. Put it back on the list with the reason, or admit the removal was early. Do not leave both the old path and the new path up and call the quarter a success because the new path exists.
Salesforce describes Agentforce in one product line: "Agentforce is the AI agent platform that delivers 24/7 autonomous support at enterprise scale." That is the vendor's description. It is not a measured outcome for your org, and it is not a reason to add a second front door while the first stays up forever. If an agent replaces a path, the roadmap shows the path leaving, with a date and the person who will turn it off. If it does not replace a path, say what narrow job it does this quarter, and what you will not ask it to do. "Autonomous support" on a slide, with the old queue still the way work gets done, is an addition. The kill list is what makes it a replacement.
Field service is documented as a hub you can keep shaping: "Agentforce Field Service and Operations (formerly known as Field Service) gives you a powerful, highly customizable, mobile-friendly field service hub in Salesforce." Configurable is how a hub gains another field every time a region asks. The kill list is how the mobile page stays the one a technician can finish before they leave the site. A field added for one region, unused by the people who actually update the work order, comes off. Watch one job. The fields they skip are the removal candidates. The fields they text the office for are the additions, and only those.
Who proposes, who cuts
Operators propose from the pain they can show. A timed quote. A case that bounced. A report the country manager will not use. The platform owner, or the centre, cuts against the standard and against the capacity you actually have. Capacity is the number of items you can land and the number you can remove without breaking the month. A list of thirty items for a team that can do six is a wish list with dates on it. Cut it in the room, not by silently missing the dates.
A roadmap written only by people who demo features will fill the year. A roadmap written only from tickets will never touch the release, and you will miss the things that are about to change under you. One list. Both kinds of item. Dates. The release items that you will leave off are on the list too, so "we did not get to it" is not how a feature turns itself on.
At the end of the quarter, three questions. Did the pain move, in hours or rework, not in a story. Did the kill list get removed, in the org, not on the slide. Did the release item land, or did you slip it and say so. Publish the answers where the next quarter's list is written. A roadmap nobody scores will accumulate until the org is a museum of good ideas, all still switched on. The score is allowed to be worse. If the hours got worse, that is the result, and the next list starts from it.
| Column | An item sounds like | Leave it off when |
|---|---|---|
| Release | This feature, this release, turn on or leave off, owner, date | It is "review the release notes" |
| Pain | A process, hours or rework, a person who counted | It is "users want it to be better" |
| Kill list | A flow, field, page, or path, owner, date they may turn it off | Nobody is allowed to deactivate it |
| Agent | The path it replaces, and the date that path leaves | It is a second door beside the old one |
| Score | Hours moved, removal happened, release decision was said | The quarter is a story |
A release item is one feature, one decision, and one date. Turn it on, leave it off, or delay it, and name the person who decides. "Review the notes" produces a meeting. It does not produce a row you can score. If you delay, write what you are waiting for, so the next quarter does not treat the delay as a forgotten yes. If you leave it off, write the reason in a sentence the next demo cannot wave away. The reason is usually that the pain it claims to solve is not the pain you timed, or that the org cannot absorb another path this quarter.
Say a slip in the same place you publish the score. "We did not get to it" is not a slip. A slip is: this item, this new date, this consequence for the pain it was tied to. If the pain is still there and the item moved, the next list has to say whether the pain still deserves a place or whether you were wrong about the remedy. Dropping both quietly is how the roadmap and the work diverge, and how the following quarter starts from a story instead of from the hours.
When two items compete for the same people, cut in the room. The kill list and the pain item outrank a feature that has no timed pain behind it. That is the whole priority rule. You do not need a scoring framework with weights. You need the two columns and the courage to leave the third item off. Write the item you cut, so it is not smuggled back as a ticket the week after the meeting. Put the cut item in the same note as the score. People will ask for it again. The note is how you answer without re-running the meeting. If the pain it claimed to solve is still on the list, say which remaining item now carries that pain. An orphan pain, with its remedy cut and nothing put in its place, will come back as a feature request with a new name.
A removal that waits for a perfect replacement will wait forever. Turn off the flow nobody can explain this quarter, watch the week after, and write what broke. If nothing broke, the removal stands. If something broke, you have found the pain the flow was quietly covering, and that pain is a better item than the feature you were about to add. The kill list is how you learn what the org actually depends on. A list that only adds never finds out.
Cheap, this quarter: writing the two columns, timing one pain, deactivating one flow nobody can explain, and publishing the three answers even if they are dull.
Expensive, after a year of additions: a save nobody can explain, a mobile page a technician will not finish, and two front doors for the same question. You will not lighten that with another feature. You lighten it by turning something off, on a date, and by refusing the next item that cannot name a release or a pain. The score is how you know you did.
