Technical Leadership & Architecture Roadmaps

Your Salesforce backlog is not an architecture roadmap

JSBC Labs11 October 20268 min read

Priority is not direction

A Salesforce backlog can be impeccably maintained and still lead an org in the wrong architectural direction. User stories, defects and change requests describe demand. Even when they are ranked by business value, they rarely show the shared data model, integration boundaries, security controls, platform capabilities and operational work that future delivery depends on.

The JSBC Labs position is that the backlog and architecture roadmap are complementary products. The backlog answers what the delivery teams are preparing to implement. The roadmap explains which capabilities and constraints must evolve across releases. Without that second view, every sprint can look successful while change becomes slower, riskier and more expensive.

Start with business capabilities

A feature roadmap naturally fills with screens, fields, automations and reports because those are easy to request. Architecture should begin one level higher: which business capability needs to become reliable, scalable or adaptable? Customer onboarding, pricing, fulfilment or service routing may cross several Salesforce products and external systems even when the initiating request mentions one object.

Define the target outcome, consumers, service level and policy boundary for each capability. Then map the enabling data, identity, automation, integration and operational changes. Salesforce provides capability, feature and system roadmap patterns because each view answers a different planning question. A page redesign cannot carry the dependency story of an enterprise capability by itself.

Make dependencies visible before sequencing

Backlogs often imply that high-priority items can be pulled independently. Salesforce delivery rarely works that way. A new service experience may rely on identity changes, a canonical customer key, integration versioning, permission redesign and observability that belong to different teams. Starting the visible feature first can lock temporary assumptions into production.

For each roadmap item, record prerequisites, consumers and the order in which compatibility must be introduced. Show which changes can be additive, which require coordinated activation and which create a point of no return. Sequence foundational work early enough to enable value, but avoid speculative platforms with no committed consumer. The roadmap should expose dependency risk, not bury it inside story links.

Translate technical debt into business impact

‘Refactor automation’ competes poorly with a revenue feature because the comparison is meaningless. Salesforce Well-Architected guidance recommends tracking technical debt with context, business impact and estimated remediation effort. It also asks teams to weigh the cost and benefit of action versus inaction rather than treating maintenance as repayment for yesterday's mistakes.

Describe the interest being paid now: release delays, repeated incidents, audit exposure, consumption limits, manual reconciliation or inability to adopt a supported capability. Name the business processes and roadmap items constrained by the debt. Estimate the risk window and cost curve. Some debt can be accepted deliberately; invisible debt cannot be governed because stakeholders never see the capacity it consumes.

Reserve capacity before the crisis

A roadmap that allocates every available sprint to features assumes the platform has no maintenance, reliability or tooling needs. Salesforce's continuous-improvement patterns explicitly recommend reserving engineering capacity for operational improvement, technical-debt reduction and automation investment. Without a deliberate allocation, improvement work enters only after an outage or failed release makes it urgent.

Set a capacity policy appropriate to the platform's condition, then revisit it with evidence. A stable product may need a modest continuous allocation; a heavily constrained org may require a focused recovery horizon. Protect work that improves test speed, deployment safety, observability and shared components because it increases future delivery capacity. Do not hide this investment as spare time between features.

Feed operations back into architecture

Production tells you which parts of the architecture are actually expensive. Incident trends, failed deployments, slow transactions, support volume and recurring manual recovery reveal constraints a design workshop may miss. Salesforce Well-Architected guidance calls for feedback loops in which incidents drive architecture improvements, monitoring drives optimisation and deployment failures drive better test coverage.

Create a route from operational evidence into roadmap decisions. A post-incident action should name the capability, owner, risk reduction and delivery horizon rather than disappear into an unranked improvement queue. Review near-misses as well as outages. If the same weakness returns, the organisation has closed tickets without changing the system that produced them.

Use horizons with different certainty

A twelve-month list of detailed user stories creates false precision. Near-term commitments can be specific because dependencies and capacity are better understood. Medium-term work should describe capability increments and architectural enablers. Longer-term items should express direction, decision points and conditions rather than pretending that scope is already settled.

Use horizons such as now, next and later, but attach entry criteria. A data consolidation initiative may move forward when ownership and source authority are agreed. An integration replacement may depend on a vendor contract or API readiness. Conditional roadmaps preserve intent while allowing evidence to change sequencing. Repeatedly moving an undifferentiated backlog item provides no explanation of what became newly known.

Record the decisions behind the roadmap

The roadmap should not become a collection of attractive arrows without architectural accountability. For material choices, capture the problem, constraints, options, decision, consequences, owner and review trigger. Link that record to the capability and delivery work it affects. This prevents settled questions from reopening whenever a team member changes.

Decision records also make exceptions governable. A temporary point-to-point integration or duplicated field may be the correct trade-off for a deadline, but its conditions and exit path must be explicit. Review decisions when scale, regulation, product capability or business ownership changes. Architecture is not frozen documentation; it is a history of deliberate trade-offs.

Measure whether change is getting easier

Counting delivered stories rewards activity without showing platform health. Combine business outcomes with delivery and operational signals: lead time, deployment failure, recovery time, escaped defects, manual steps, automation density, obsolete metadata and time spent resolving cross-team dependencies. Salesforce's operational guidance points to incident trends, DORA indicators and user satisfaction as inputs to improvement.

Use a small scorecard per capability rather than one org-wide health percentage. A platform can release quickly while one critical integration remains fragile, or have high test coverage while permissions still require manual repair. Metrics should change roadmap decisions. If a measure never alters sequencing, capacity or ownership, it is reporting theatre rather than governance.

Run one portfolio conversation

Bring product, architecture, security, data, operations and delivery leaders into one recurring roadmap cadence. Product owners should own outcomes and priority; technical leaders should expose constraints and options; delivery teams should validate effort and sequencing; operations should contribute production evidence. The Center of Excellence can facilitate this without becoming a separate approval queue.

Publish the roadmap with assumptions, dependencies, capacity allocations and recent decisions, then keep the implementation backlog linked to it. A healthy Salesforce portfolio does not choose between features and architecture. It invests in the capabilities that deliver outcomes today while preserving the ability to change tomorrow. That is direction a ranked list alone cannot provide.