Roadmap Planning for Salesforce: The 12-24-36 Month Framework

Why Most Salesforce Roadmaps Fail

Salesforce roadmaps fail in predictable ways. Understanding the failure modes is the starting point for building something better.

The wish list roadmap. Built by compiling everything every stakeholder has requested, ordered by loudest voice. Has no investment logic, no sequencing rationale, and no capacity constraint applied. Every quarter, the items in the first three months slip to the next three months because the team cannot deliver the volume implied by the list. Stakeholders lose confidence in the roadmap because it never reflects what actually happens.

The static roadmap. Built once, presented to the board, and never formally revisited. Business priorities change, Salesforce releases new capabilities, integration dependencies shift — but the roadmap does not. After 18 months, the gap between the roadmap and delivery reality is so large that the roadmap is no longer used as a planning tool.

The delivery roadmap. A Gantt chart of projects and phases with no business outcome framing. Tells you when things will be delivered, not what business value they will generate. Stakeholders outside IT cannot use it to connect technology investment to business results. It is a delivery plan, not a strategy.

The fantasy roadmap. Contains capabilities that depend on organisational changes, data quality improvements, or capability development that has not been committed to. "In Q3 next year we will deploy AI-driven lead scoring using Data Cloud" — when the data estate required is not in place and the Data Cloud licences have not been purchased. Fantasy roadmaps create expectation gaps that damage credibility.

The 12-Month Horizon: Committed

The 12-month horizon is the committed horizon. Every item in the 12-month plan should be: funded (budget secured or in the approved budget cycle), resourced (delivery team capacity confirmed), scoped (requirements understood at a level of detail that supports confident estimation), and sequenced (dependencies mapped). Items that do not meet these criteria should be in the 24-month horizon, not the 12-month horizon.

The 12-month plan should be structured in quarterly blocks. Each block has: a set of capabilities being delivered, a set of dependencies that must be resolved before delivery begins (data readiness, integration testing, change management preparation), and a set of business outcomes expected to begin accruing after the block completes. The quarterly block structure gives the plan flexibility — detailed sprint planning happens within the block, but the block boundaries are the governance checkpoints.

The 12-month plan should be approved at governance level — not just by the technology team, but by the business owners of each capability area. Business owner approval creates accountability on both sides: the platform team commits to deliver, the business team commits to provide SME time, participate in testing, and lead adoption activities. Without this bilateral commitment, the delivery team will find that business resources are unavailable when needed.

The 24-Month Horizon: Directional

The 24-month horizon is directional — it communicates intent but does not carry delivery commitment. Items in the 24-month plan should be: aligned to strategic priorities, estimated at a confidence level sufficient for budget planning (±50% is acceptable), and mapped for major dependencies. The 24-month plan is primarily a planning tool for three audiences: the finance team (for budget preparation), technology architecture (for infrastructure and capacity planning), and Salesforce (for licence and roadmap discussions).

The 24-month plan should be reviewed quarterly, not just annually. Business priorities shift; Salesforce's product roadmap changes; integration timelines move. Items in the 24-month plan should be actively managed — some will be promoted to the 12-month committed horizon when they are sufficiently defined and funded; some will be deprioritised or deferred as business priorities change; some will become irrelevant because the problem they addressed has been solved differently.

Avoid the temptation to over-specify the 24-month horizon. Items should be described at capability level ("deploy Einstein conversation insights for service teams") not feature level ("implement the following 47 Einstein conversation insights configuration items"). Feature-level specification in the 24-month horizon creates false precision and makes the roadmap resistant to change when requirements evolve.

The 36-Month Horizon: Strategic Intent

The 36-month horizon communicates strategic intent — the platform direction the organisation is headed, expressed as business capability ambitions rather than technology features. It answers: "Where will our customer engagement capability be in three years, and what platform investments will enable it?" It is the horizon at which Salesforce as a platform is considered in relation to emerging capabilities (Agentforce, Data Cloud, Industry Clouds) that have not yet reached general availability maturity for the organisation's use case.

The 36-month horizon should be reviewed annually as part of the business strategy planning cycle. It should be influenced by three inputs: the organisation's business strategy (which customer capabilities are required to support the three-year business plan), Salesforce's product roadmap (which platform capabilities will be available and mature in the 24-36 month window), and the organisation's own capability development trajectory (what technical and organisational capabilities are being built that will enable more sophisticated platform use).

Do not present the 36-month horizon as a delivery commitment. Present it as a strategic direction — the set of capability ambitions that inform current investment decisions. "We are building toward a position where our service agents have AI-assisted case resolution, personalised at scale using Data Cloud unified customer profiles. The investments we are making now — in data quality, in agent desktop consolidation, in service process standardisation — are the foundation for that capability."

Four Sequencing Principles and Keeping the Roadmap Current

Investment sequencing determines whether later capabilities can be built on a stable foundation or require expensive rework. Four principles guide Salesforce roadmap sequencing.

Foundation before extension. Data quality, core object model design, permission architecture, and integration backbone must precede advanced capabilities. AI capabilities that depend on data quality will fail if deployed before data quality programmes are complete. Process automation on top of a poorly designed permission model will create security gaps. Sequence foundation work first, even when stakeholders want to skip to the exciting capabilities.

Adoption before expansion. Do not add new capabilities to populations that have not adopted the existing ones. A sales team that is not using Salesforce for basic pipeline management will not use AI-assisted next best action tools. Deploying additional capabilities to under-adopted populations does not drive adoption — it creates complexity that further depresses adoption. Reach adoption targets before expanding capability scope.

Simple before complex. Configuration-based capabilities before code-based capabilities. Native Salesforce capabilities before customisation. Simpler integration patterns before complex ones. This principle is violated when delivery teams are eager to demonstrate technical ambition, or when stakeholders request a complex capability without understanding that simpler prerequisites have not been met.

Dependency-aware sequencing. Map all inter-capability dependencies before committing to the roadmap sequence. A capability that depends on an integration that has not been built, data that has not been migrated, or a business process that has not been redesigned is not ready for its planned quarter. Surface dependencies early — the delivery team discovering a dependency during implementation is a governance failure, not a delivery failure.

To keep the roadmap current, establish a quarterly roadmap review as a governance meeting agenda item. At each review: confirm that 12-month items are still on track (reprioritise if not), review the 24-month horizon for items ready to be promoted to committed status, incorporate any new strategic priorities from the business, and update for Salesforce product developments that affect planned capabilities. Assign the roadmap owner role — one named individual who is accountable for keeping the roadmap current and for managing stakeholder expectations when it changes.