Stack Planning
Marketing technology roadmaps
Build a marketing technology roadmap that orders changes by outcome, dependency and campaign timing, with clear checks before release.
A marketing technology roadmap shows which changes a team will investigate or deliver, in what order, and what must be true before each change goes live. Start with the marketing work already promised.
Give each proposed change a reason
Write the outcome before naming a tool: for example, "campaign managers can see corrected enquiry sources before the weekly review". Then describe the current obstacle, the teams affected and the evidence that a change would help. A request for a new platform is a candidate response, not a roadmap objective.
Keep a separate list of ideas that have not earned a place in the plan. The roadmap should show decisions the organisation is prepared to investigate or deliver, with an owner for each. It need not turn every suggestion into a dated commitment.
Prioritise against goals and capacity
Compare proposed changes with the marketing and business goals they support, rather than treating every request as equally urgent. Show how near-term work contributes to longer-term goals so stakeholders can see why one item is ahead of another.
Use the roadmap to make priorities visible to the teams affected by them. A shared view helps connect day-to-day delivery with the direction the organisation has chosen, and gives stakeholders a place to understand progress and planned milestones.
Make capacity part of the sequence. Record the people, budget and responsibilities needed for each change before treating its timing as workable; an item without an owner or available resources may need to move behind work that can be delivered.
Include staff training and cyber security considerations in planning where a change requires them. These can be dependencies or release checks, rather than tasks left until after the technology change is live.
How to Prioritise Marketing Tech Changes
- Align with marketing and business goalsEnsure each proposed change supports strategic objectives such as improved customer engagement or operational efficiency.
- Assess team capacityRecord people, budget, and responsibilities required for each change; ensure resources are available before scheduling.
- Include training and cyber securityTreat staff training and security checks as dependencies or release checks, not afterthoughts.
Put dependencies and commitments on one view
For each proposed change, record its earliest useful date, the work it depends on and the live campaigns it could disturb. Include contract decision dates, planned launches, reporting deadlines and periods when key staff are unavailable. A tool replacement might depend on agreed data definitions, an export route and the receiving team's approval before anyone can set a cutover date.
| Roadmap field | Decision it should make clear |
|---|---|
| Outcome | What marketing task or decision improves? |
| Dependency | What must be settled first, and by whom? |
| Commitment | Which live campaign or reporting cycle constrains timing? |
| Evidence gate | What observation is needed before moving forward? |
| Release and fallback | Who authorises the change, and how will work continue if it fails? |
Use broad time horizons for uncertain work and firm dates where a commitment requires them. Keep detailed tasks and dates in the delivery schedule. Review the roadmap when priorities, evidence or supplier availability changes.
Roadmap Field Decision Clarity Guide
- OutcomeWhat marketing task or decision improves?
- DependencyWhat must be settled first, and by whom?
- CommitmentWhich live campaign or reporting cycle constrains timing?
- Evidence gateWhat observation is needed before moving forward?
- Release and fallbackWho authorises the change, and how will work continue if it fails?
Move from investigation to release
A practical change can pass through four decisions:
- Investigate:Confirm the problem and compare an improvement to the current process, configuration or software.
- Prepare:Assign owners, agree data and workflow rules, and set a bounded acceptance case.
- Release:Choose a cutover point, communicate the new route and give someone authority to stop a wrong result.
- Review:Check the receiving outcome and record what still needs repair.
These are planning gates, not claims that a proposed product has passed them. A supplier's future feature belongs in the investigation column until its availability and suitability for the organisation's plan are established. A feature described as rolling out may still be unavailable in the relevant account.
Suppose a campaign team wants a new audience workflow before a major send. The roadmap can schedule definition and safe sample checks before the campaign, while reserving live cutover for a period when the team can verify the audience and respond to errors. If the necessary evidence arrives too late, keep the existing approved route for that send and revisit the change afterwards.
On Microsoft's AI at Work Roadmap, a feature marked "In development" is in development and testing, and might be available to some customers participating in a preview program. "Rolling out" means deployment has begun, but the feature is not yet available to all applicable customers. "Launched" means it is available to all applicable customers.
Other suppliers may use different statuses and definitions, so check the relevant supplier's roadmap.
Microsoft's roadmap treats a public preview as a development-stage feature that may change before production release. Treat its preview date as evidence for review, not as confirmation that the production change is ready for a planned campaign.
Marketing Technology Roadmap: Key Decision Stages
- Investigate
- Confirm problem and compare improvement to current process, configuration or software.
- Prepare
- Assign owners, agree data and workflow rules, set bounded acceptance case.
- Release
- Choose cutover point, communicate new route, assign authority to stop incorrect results.
- Review
- Check outcome, record what still needs repair.
Microsoft AI at Work Roadmap Status Definitions
- In developmentFeature is in development and testing; may be available to preview program participants. Subject to change before production release.
- Rolling outDeployment has begun but not yet available to all applicable customers.
- LaunchedAvailable to all applicable customers.
Keep the roadmap a decision record
At each review, ask what changed: a business priority, campaign commitment, dependency, supplier release, observed result, customer feedback or a change in the competitive landscape. Update the order and record the reason. Close completed items with the result seen by the people doing and receiving the work; return unresolved items to a named owner and next check.
In this guide
- Sequencing tool changes around campaign commitmentsPlan marketing tool changes around committed campaigns with preparation, cutover and decision points that protect live work.
- Separating a vendor's roadmap promise from a shipping featureDistinguish planned, preview, rolling-out and available software features before depending on a vendor promise in a marketing roadmap.
- Planning stack upgrades after a business acquisitionSequence marketing stack changes after an acquisition around live work, system ownership and the actual customer-data boundary.
- Reviewing the stack against the next year's marketing needsCompare next year’s marketing work with current tools, people and processes to decide what to keep, improve, investigate or watch.
