To build a Salesforce roadmap, collect every request in one intake list, describe each one as a business outcome, score it for value and effort, and group the winners into releases timed around Salesforce's three seasonal upgrades. Then give one person ownership of the backlog, set up a small group that approves priorities, and publish the plan in a format business leaders can read in two minutes. A roadmap is a decision record, not a wish list.
Why orgs without a roadmap stall
Without a roadmap, Salesforce work goes to whoever asks loudest or most recently. The admin spends the week on a new report for one sales manager while a broken lead assignment rule quietly costs the whole team. Nobody decided that trade; it just happened. Over a year, the org fills with one-off fixes, and the larger improvements that would change how the business runs never get started because they never fit into a single week.
A roadmap fixes this by making priorities explicit. It does not need special software or a long planning cycle. It needs a single list, a consistent way to compare items on it, and someone with the authority to say which come first.
Step 1: Gather requests in one place
Requests arrive through hallway conversations, chat messages, emails to the admin and complaints in team meetings. Route all of them into one intake point, such as a simple Salesforce case or custom object, a form, or a shared tracker. The tool matters far less than the rule that anything not in the list does not exist.
- Ask for the problem, not the solution: what is hard today, who it affects and how often.
- Capture the requester, the team and the business goal it supports.
- Note any deadline that is real, such as a contract, an audit or a product launch.
- Link related requests so five asks for similar reports become one item.
- Add items that users will never request, such as security fixes, technical debt and Release Updates with enforcement dates.
Also go looking for work that nobody submits. Interview a few users from each team, review the findings of your last health check, and read the list of automations and integrations that fail most often. The best roadmap items frequently come from watching people work rather than from the intake form.
Step 2: Score by value and effort
Scoring turns an argument about opinions into a comparison of stated reasons. Keep it simple enough that the steering group can score a new item in a few minutes. Rate value from the business side: revenue or cost impact, number of users helped, risk reduced, and fit with the year's goals. Rate effort from the delivery side: build complexity, data work, integration changes, testing and training.
| Request | Value | Effort | Decision |
|---|---|---|---|
| Fix lead assignment so web leads reach the right rep | High: every inbound lead depends on it | Low: rule and queue changes | Next release |
| Sync order status from the ERP to the account page | High: service and sales stop calling operations | High: integration, mapping and testing | Plan as its own release with a discovery step first |
| New dashboard for one regional manager | Medium: helps one team | Low: report changes | Batch with other reporting work |
| Rename picklist values to match new product names | Medium: cleaner reports | Medium: touches Flows, reports and integrations | Schedule after dependency review |
| Customer portal for order tracking | High, but depends on the ERP sync | High: Experience Cloud build and licensing | Hold until the sync is live |
| Custom button a single user asked for | Low: one person, existing workaround | Low | Decline or revisit next quarter |
High value and low effort goes first. High value and high effort gets planned deliberately, often with a discovery step to firm up the estimate. Low value and low effort gets batched into maintenance time. Low value and high effort gets declined, politely and on the record, so it stops coming back every month.
Dependencies override raw scores. The portal in the table scores well but cannot ship before the data it would display exists in Salesforce, so the sequence matters as much as the ranking.
Step 3: Sequence releases around the Salesforce calendar
Salesforce upgrades every org three times a year, in its Spring, Summer and Winter releases, and sandboxes on preview instances receive each upgrade several weeks before production. Those dates are published well ahead on the Salesforce Trust site, so put them into the roadmap first. They are fixed points your own releases have to work around.
A pattern that works for many teams is to avoid deploying major changes in the weeks around a production upgrade, and to use the preview window for regression testing and release-note review instead. Your own releases then land in the quieter stretches between upgrades. Layer in your business calendar as well: quarter-end, peak season, annual enrollment or budgeting cycles are poor times to change the screens people depend on.
Group items into releases by theme rather than by arrival order. A release that improves the full quote-to-order path is easier to test, train and explain than one that touches ten unrelated corners of the org. Keep a small, recurring slot for fixes so urgent issues do not force their way into a planned release.
Step 4: Governance and a backlog owner
Every roadmap needs one backlog owner: the person who keeps the list clean, writes or refines the requirements, runs the scoring and brings the ranked list to the decision meeting. In a smaller company this is often the Salesforce admin or an operations lead. In a larger one it may be a dedicated product owner for the CRM. What matters is that it is one named person, not a committee.
The decisions themselves belong to a small steering group with a leader from each team that relies on Salesforce, plus whoever controls the budget. Meet monthly, or at each release boundary, to approve the next release and settle conflicts. Give the group a short set of rules: how an item gets scored, who can request an emergency change, and what happens to requests that are declined.
Governance also covers the work that nobody finds exciting. Reserve part of each release for technical debt, security findings and Release Updates, and protect that share when feature requests pile up. Orgs that skip this end up with a roadmap that slows down every year for reasons no one can name.
Step 5: Communicate the roadmap
A roadmap nobody sees does not change behavior. Publish a one-page view with three columns, now, next and later, and a sentence on the business outcome of each item. Leave out estimates and technical detail on the shared version; keep those in the backlog for the delivery team.
- Tell each requester what happened to their item, including a clear no with the reason.
- Announce each release with what changed, who it affects and where to get help.
- Share a short summary of each seasonal upgrade that changes something users will notice.
- Review progress with leadership quarterly, showing what shipped against what was planned.
Consistent communication is what keeps people using the intake process. When requesters can see their items being scored and scheduled, they stop working around the system.
Roadmap building and backlog ownership are regular parts of the optimization and managed services work our U.S.-based team delivers, and have been since Abstrakt became a Salesforce Consulting Partner in 2017. They matter most for companies without a CRM product owner of their own.
