Martech Roadmap: Plan 12 Months of Work Your Team Can Deliver

A martech roadmap sequences the customer workflows and decisions your team needs to support, with dependencies, owners, build effort, operating capacity, costs and acceptance gates. For a small team, plan the next quarter concretely and later quarters conditionally. Include renewals and work you are postponing. A useful roadmap shows what can happen next when an assumption fails, not just when a tool might launch.

Jafrin Akter AloLast updated 16 min read
On this page
A cobalt railway turnout with lime rails and a pink switch selects between two routes, beside Plan the Build: Fund the Run.

A founder asks for better attribution. Sales wants a new CRM workflow. Marketing wants an AI assistant, and finance needs a trustworthy revenue report. Putting all four in the next quarter does not resolve their shared dependency on identity, source data and someone’s time.

The roadmap’s job is to make those choices explicit. Use the startup stack stage map to decide whether another layer is justified. Use this guide to decide which work to commit, what must happen first and how to keep the commitment feasible after earlier releases need maintenance.

What should a martech roadmap contain?

Each roadmap item should name a useful workflow, its acceptance evidence, dependencies, accountable owner, delivery effort, ongoing work and commercial constraints. The executive view can stay on one page while the implementation records carry the detail.

What should a martech roadmap contain?
FieldUseful entryWeak entry
OutcomeQualified trial accounts reach the correct sales owner within the agreed windowImplement CRM
DependencyVerified account ID and agreed qualification ruleData team
Owner and capacityNamed operations owner with allocated build and run hoursMarketing
AcceptanceCorrect routing, exclusion and recovery cases passIntegration connected
Cost and commitmentMetered usage, operating hours, payment timing and review deadlineVendor starting price

GOV.UK’s roadmap guidance distinguishes intended outcomes from a delivery backlog and recommends making exclusions visible. It also recognizes that work further into the future is less certain. Those are useful planning principles; they do not make a quarterly column a guaranteed delivery date. Roadmap principles

Our martech integration work delivered in phases starts with the workflow and evidence that should justify the next phase. Buying the platform can be one task within that plan; it is rarely the whole outcome.

Keep one maintained roadmap. A board slide, a project tracker and a spreadsheet can show different levels of detail, but they should reference the same decisions. If the slide says a workflow is complete while the operator is still reconciling its output, fix the status rather than decorating the slide.

How do you turn audit findings into priorities?

Start with the business decision or customer problem, then identify the smallest change that can improve it. Rank work using impact, dependency, urgency and confidence rather than the enthusiasm attached to a product demo.

Bring in findings from the martech stack audit, recurring operating incidents and the customer journeys that matter. Preserve the evidence already collected. Do not start another broad discovery exercise when the unresolved question is one missing account relationship.

For example, “send trial reminders” is incomplete until the team can identify the trial account, determine whether it is still eligible and stop messages when the account activates. The smallest useful release might be one correctly scoped journey, with its exit and recovery behavior, before adding another channel.

How do you turn audit findings into priorities?
CandidateDecision it supportsMissing prerequisiteNext useful action
Sales routingWhich account needs a timely conversation?Qualification and ownership rulesTest one routing cohort with negative cases
Revenue reportingWhich acquisition cohorts produce retained value?Billing identity and refund definitionsReconcile a bounded account population
Lifecycle automationWho still needs help reaching value?Current product state and preferencesProve entry, exit and duplicate prevention
AI reporting assistantCan an operator retrieve an agreed answer reliably?Trusted model, permissions and evaluation casesTest a known question against a constrained dataset

A regulatory or contractual deadline may override a convenient value ranking. Record the actual obligation, responsible person and consequence of missing it. A supplier’s sales deadline is a different kind of urgency and should not silently become a technical dependency.

When the benefit remains uncertain, put a bounded investigation on the roadmap. Its output is a decision and evidence, not a promised production rollout. GOV.UK’s alpha guidance recommends doing the minimum needed to test the riskiest assumption. Apply that principle without importing its public-service phase durations as a delivery benchmark for your company. Testing risky assumptions

Which dependencies should determine implementation order?

Work backward from the required output. Establish the identities, permissions, data and operating decisions it consumes before committing the downstream automation.

For an account-level onboarding journey, the dependency list might be stable user and account IDs, membership rules, a current activation fact, channel eligibility and a CRM or messaging update contract. Consent decisions must precede the collection or use that requires them; they are not a cleanup task after tracking launches.

A warehouse audience has a different path: source coverage, a reviewed model at the correct grain, freshness, destination matching and a defined exit. A customer-facing AI action adds another question: who may approve the action and how will the result be checked? None of these paths implies that every team must buy every layer.

Treat IDs, event meaning, CRM object structure and retained history carefully because changing them can affect several consumers. They are not all literally irreversible. Their cost comes from coordinated correction, loss of historical evidence or changed customer behavior. The scalable stack guide explains those choices in more detail.

Amazon’s shareholder letter distinguishes consequential decisions that are hard to reverse from reversible decisions a small group can make quickly. Use that distinction to allocate review effort, not to label every configuration field a permanent architectural commitment. Amazon decision framework

Do not rebuild foundations merely because they belong in an early phase on someone else’s diagram. Verify the existing contract and its evidence. If the IDs and consent behavior already work, the next dependency may be an unowned field update or an export permission.

A dependency should identify both a deliverable and its accepting owner. “Wait for engineering” does not say what the team is waiting for. “Application emits the accepted account-created event, including account ID, with replay tests passed” gives the next team a usable release condition.

How do you budget build work, maintenance and software separately?

Estimate three different quantities: one-time delivery work, recurring operating work and cash commitments. Keep their units visible so internal capacity is not mistaken for an invoice or counted twice.

For build effort, include definition, implementation, test data, review, repair, deployment and handover. For run effort, include monitoring, incidents, schema changes, vendor updates, reconciliation and small improvements. A workflow that needs six hours monthly to maintain consumes time every quarter after it launches.

Use your own observed work or a scoped estimate. The hours in this article are hypothetical planning inputs, not martech implementation benchmarks. The implementation-cost guide explains what belongs in the delivery scope, while the business-case guide connects it to the decision finance must make.

How should the software line reflect the actual meter?

Price the workload and required capabilities, not just the entry fee. Customer.io Essentials lists USD 100 monthly, 5,000 people and object profiles, and one million monthly emails; additional profiles cost USD 0.009 each and additional emails USD 0.12 per thousand. Premium starts at USD 1,000 monthly, billed yearly. A monthly equivalent and an annual commitment are different cash-planning inputs. Customer.io pricing

For a hypothetical Essentials workload with 12,000 billable profiles and 600,000 emails, the selected monthly software lines are:

How should the software line reflect the actual meter?
ComponentCalculationMonthly USD
BasePublished Essentials starting fee100
Additional profiles7,000 × 0.00963
Additional emailUsage stays within the included million0
Selected subtotalBase plus specified overages163

If a peak month reaches 1.2 million emails, the extra 200,000 sends add USD 24, producing USD 187 for these lines. Tax, SMS, other paid features and implementation are excluded. Confirm that Essentials supports the actual workflow before using either subtotal.

Use the provider’s billable profile count. Customer.io counts profiles across all workspaces and includes profiles that existed during the billing cycle, even if later deleted. A month-end application-user count is therefore not necessarily the right input. Customer.io billing units

Fivetran’s Free plan includes 500,000 connection MAR, 3,500 activation MAR and 5,000 model runs monthly. Paid standard connections with 1 to 1 million MAR have a USD 5 base charge, which does not apply to the Free plan. That base is not the complete usage bill. Forecast each connection and the other applicable meters. Fivetran pricing

Record cloud compute, storage, data movement and monitoring separately. Use the BigQuery cost model or your chosen warehouse’s equivalent to price the intended workload. A query estimate cannot stand in for the complete warehouse operating cost.

How do you show internal capacity without inventing cash savings?

Suppose a new workflow needs six internal operating hours monthly and the planning value of that time is USD 75 per hour. That adds USD 450 of monthly capacity value. Combined with the USD 163 software subtotal, it gives USD 613 of modeled monthly resources for the defined scope.

If those hours belong to a salaried employee already on payroll, the additional cash invoice may still be USD 163. The capacity is nevertheless unavailable for another task. Show the cash and capacity columns separately, and do not count the same salary again as both a project invoice and an internal hourly cost.

What does a feasible four-quarter plan look like?

A feasible plan respects cumulative operating work and makes later phases conditional on evidence. The following is a hypothetical 15-person B2B SaaS team’s plan, with four consecutive three-month quarters. It is an illustration of scheduling, not a recommendation to copy every tool or deadline.

The team reserves 50 martech hours monthly across its named contributors: 150 hours per quarter. Existing operations and incident coverage consume a planned 60 hours each quarter. New build work and maintenance from earlier releases must fit into the remaining 90 hours.

Assume each phase launches at quarter end. Its additional run work starts in the following quarter. This simplifying assumption must change if your releases or maintenance begin earlier.

What does a feasible four-quarter plan look like?
QuarterBounded deliveryBuild hoursGate before the next phase
Q1Tracking contract, identity and eligibility checks60Agreed source population reconciles; identity, consent and replay cases pass
Q2One qualified-trial routing and onboarding workflow72Correct owner, eligibility, exit and recovery cases pass
Q3, conditionalOne recurring cross-system revenue model48Billing, refunds and account grain reconcile; operating owner accepts it
Q4, conditionalOne audience activation and selected retirement work24Destination matching, removal and customer-action checks pass

The phases add four, six and eight monthly maintenance hours respectively after Q1, Q2 and Q3. Those are invented workload assumptions. Their cumulative effect is the important part:

What does a feasible four-quarter plan look like?
QuarterExisting run reserveNew buildAdded run from earlier phasesTotal / 150 hours
Q160600120
Q2607212144
Q3604830138
Q4602454138

Q2 has only six unallocated hours. If the routing workflow needs 12 extra build hours, its total becomes 156 and no longer fits. Move scope, obtain real capacity or change the sequence. Do not label the excess an efficiency assumption and leave the same commitment on the slide.

The first three phases leave the team with 18 additional monthly operating hours by Q4. Add the Q4 release’s future maintenance to the next planning horizon too. Otherwise the roadmap hides its most persistent cost just outside the final column.

What should each quarter’s gate actually prove?

Q1 should establish the tracking contract, person/account relationships and permitted collection. A matched sample is useful, but record its scope and reconcile the wider source totals separately. One good customer trace does not prove every signup is correct.

Q2 should prove a whole customer workflow, including the case that must stop it. For example, an activated account should leave a trial-help journey, and replaying its source event should not create a second sales task. The acceptance owner needs evidence of those outcomes, not just a screenshot of the workflow canvas.

Q3 should happen only when the warehouse trigger is met. A recurring question needing several sources and history can justify it. If the question remains occasional and a controlled export is sufficient, retain that process and use the capacity on a more valuable item.

Q4 should activate one reviewed audience, with matching and removal tested in the destination. It should not automatically add predictive scoring, another CDP or an AI agent with write access. Those proposals need their own evidence and operator.

Use the maturity model to describe the capability the next phase needs. Treat maturity as a statement about working processes, not the number of platforms installed.

How should renewals and startup offers change the sequence?

Schedule the decision early enough to preserve the option you may need. Track the applicable contract notice, migration lead time, discount expiry and the person who can approve the commercial action.

For example, if a contract needs 45 calendar days’ notice and a replacement needs 75 days, the replacement decision cannot wait until the notice boundary. Those are hypothetical inputs; read the actual agreement. The renewal-traps guide explains why supplier price notices and customer non-renewal deadlines are different fields.

HubSpot’s funded startup track advertises 90%, 50% and 25% discounts across three years, while its general FAQ still describes a typically two-year period. Use the accepted product and discount schedule, including its annual commitment. Do not assume every startup receives the funded track. HubSpot for Startups

If an accepted agreement gives 90% off in year one and 50% off in year two on an unchanged eligible list-price basis, the payable proportion rises from 0.10 to 0.50: five times the earlier amount. That is arithmetic for the stated assumptions, not a forecast of your future price. Seats, package, list price and benefits can also change.

Mixpanel’s Startup Plan runs for a year from acceptance and requires participants to start sending data within 90 days. Applying long before the implementation is ready can consume the useful period or jeopardize eligibility. Put the implementation requirement and graduation decision on the roadmap alongside the offer. Mixpanel Startup Program

Do not choose an architecture solely to spend temporary credits. Forecast the undiscounted or accepted next-period case, preserve export options and assign someone to evaluate renewal before the contract commits the business again.

What should a copyable roadmap item look like?

Use one record per accepted unit of work, with dependencies represented by stable item IDs. Keep the item’s gate and stop condition separate: the gate defines evidence of success, while the stop condition says when to hold or reconsider the work.

These two original YAML records illustrate the structure. The hours and quarters are planning assumptions for these items, not the full quarterly budget above. Replace role labels with accountable people before committing delivery.

YAML
items:
  - id: identity_contract
    workflow_supported: account_level_trial_routing
    depends_on: []
    owner_role: product_engineering_owner
    quarter: Q1
    build_hours: 24
    monthly_operating_hours: 2
    licence_cost_and_source: existing_systems_reviewed_no_new_licence
    gate: account_ids_and_membership_cases_pass
    stop_condition: ambiguous_account_identity_remains
    commercial_review: none_for_this_item
    status: planned
  - id: qualified_trial_routing
    workflow_supported: correct_sales_owner_for_eligible_trial
    depends_on: [identity_contract]
    owner_role: revenue_operations_owner
    quarter: Q2
    build_hours: 30
    monthly_operating_hours: 3
    licence_cost_and_source: approved_CRM_order_and_usage_forecast
    gate: routing_exclusions_replay_and_recovery_pass
    stop_condition: upstream_contract_fails_or_operator_capacity_missing
    commercial_review: confirm_order_notice_and_required_features
    status: conditional

The dependency list is not a complete acceptance specification. The second item still needs agreed qualification, consent, ownership and field-update rules in its delivery record. Add them as separate roadmap dependencies when they require their own work or accepting team.

Validate the register before presenting it. Every dependency ID must exist, IDs must be unique and a cycle must be resolved. An item scheduled before an unfinished prerequisite needs resequencing. A quarterly bucket also cannot establish the order of two dependent items within the same quarter; record their actual delivery sequence.

Keep unknown cost or effort visible. A missing estimate should not become zero when the spreadsheet totals the plan. Mark the item as discovery or conditional until the owner can establish a useful range and the uncertainty that drives it.

Which work should go on the not-this-year list?

Defer work that lacks a current decision, prerequisite or operating owner, and name the evidence that would reopen it. A deferral with a trigger is more useful than an indefinite rejection.

Which work should go on the not-this-year list?
Deferred proposalReason to waitTrigger for another review
Second CRMExisting process and ownership are unresolvedA distinct workflow cannot be supported after repair
Broad CDP rolloutRequired audience definitions and destinations are unclearSeveral maintained destinations need the same verified rules
Marketing mix modelingSuitable history or decision capacity is missingThe required data and budget-allocation question are ready
Predictive personalizationBasic lifecycle behavior still failsReliable data, measurable intervention and a viable experiment exist
AI agent writing to CRMAction authority and rollback are undefinedConstrained task, approval policy and evaluation cases pass

These are examples, not a mandatory list for every company. A business with an urgent multi-destination requirement may justify a CDP earlier; another may never need one. Record the reason instead of tying the decision to a funding-stage label.

Also put retirements on the roadmap. Removing a tool requires proving that its important work has moved and handling the commercial exit. Use stack rationalization to define that work before treating the subscription as a guaranteed saving.

How do you keep the roadmap useful when reality changes?

Review actual evidence, effort and operating load, then change the sequence openly. Do not carry a failed dependency into the next quarter under a new completion percentage.

At the review, ask whether the gate passed, whether the expected customer or business benefit appeared, what now takes more time to operate and which commercial deadlines are approaching. Distinguish a delivery defect from a changed requirement. Either can require new work, but they should not disappear inside the same status label.

How the workflow fits together
Define the workflow and require evidence that supports proceeding. Missing evidence or failed delivery returns to resolving the assumption or gap and revisiting the workflow. Verified work is priced with dependencies, ownership and operating load. Changed scope reenters that evidence gate. A bounded release proceeds only when acceptance and operating readiness pass, then the next quarter is updated.
Read diagram as text
  • Define workflow outcome and unresolved assumptions to Evidence supports the proposed workflow?.
  • Evidence supports the proposed workflow? to Resolve the failed assumption or delivery gap: No.
  • Resolve the failed assumption or delivery gap to Define workflow outcome and unresolved assumptions.
  • Evidence supports the proposed workflow? to Price dependencies ownership and operating work: Yes.
  • Price dependencies ownership and operating work to Capacity and cash commitments fit?.
  • Capacity and cash commitments fit? to Reduce scope or resequence the work: No.
  • Reduce scope or resequence the work to Define workflow outcome and unresolved assumptions.
  • Capacity and cash commitments fit? to Build and test one bounded workflow: Yes.
  • Build and test one bounded workflow to Acceptance and operating readiness pass?.
  • Acceptance and operating readiness pass? to Resolve the failed assumption or delivery gap: No.
  • Acceptance and operating readiness pass? to Maintain the release and update the next quarter: Yes
Open full diagram

The CEO view should show the workflow, next decision, gate, cash commitment, operating capacity and deferred items. Link to detailed estimates and evidence for review. A precise-looking launch date is less useful than knowing the unresolved condition that could move it.

Checklist

  • Each committed item supports a named workflow or decision.
  • Required definitions, consent, data and ownership precede their consumers.
  • Unknown assumptions have bounded investigation work.
  • Build hours include review, testing, repair and handover.
  • Maintenance from earlier releases reduces later available capacity.
  • Software estimates use the correct meter, feature tier and payment period.
  • Contract notices, offer expiry and implementation requirements have owners.
  • Every phase has acceptance evidence and an explicit stop condition.
  • Deferred work has a reason and a trigger for reconsideration.
  • Retirements and next-horizon operating work remain in the plan.

Bring the current map and recurring pain points to the $99 martech audit. For a bounded next phase, compare the implementation plans with the workflow, dependencies and acceptance gate. Fast delivery is USD 4,800 for Starter and USD 12,150 for Growth after the 25% plan discount; work outside their inclusions needs a Custom scope. Each plan covers a defined implementation, rather than a full year of marketing operations.

Keep reading

Browse all Martech Strategy guides

Questions people ask

How far ahead should a small team plan?

A six-to-twelve-month horizon is usually enough to show dependencies and commercial decisions while keeping the near-term commitment concrete. Treat later phases as conditional when their need or inputs remain uncertain. Review the plan when a material assumption changes, not only at quarter end. The horizon should help the team decide what to do next rather than imply certainty it does not have.

Who should own the roadmap when several teams contribute?

Name one person who can maintain priorities and bring unresolved trade-offs to the accountable sponsor. Each item still needs its own delivery and acceptance owners. Confirm their actual capacity across other commitments. A shared roadmap does not mean every participant can independently add urgent work without changing scope, sequence or the capacity available for already accepted items.

Can a tool renewal be deferred until the implementation is complete?

Only if the applicable commercial terms and operational dependency allow it. A notice deadline can arrive before the replacement is ready, and negotiation does not automatically stop renewal. Track the decision, notice mechanism and migration lead time separately. Price an extension or reduced scope where appropriate, and obtain the written terms needed before depending on that option.

Should every roadmap item have an ROI estimate?

It should have a reason to do the work and evidence that can support the decision. A numerical ROI model is useful when the assumptions are credible, but an invented revenue uplift creates false precision. Some items restore reliability, meet an obligation or remove a prerequisite. Explain that purpose, its alternatives and the consequence of deferring it.

What should happen when a quarterly gate fails?

Hold the dependent rollout, identify the failed assumption or implementation boundary and assign the corrective work. Recalculate the remaining capacity and commercial consequences before committing a replacement date. Preserve completed work that still has value, but do not declare the phase accepted merely because its original quarter ended. The next decision should follow the evidence, with an owner for the revised plan.

Sources

  1. GOV.UK: Developing a roadmap.
  2. GOV.UK: Testing assumptions in alpha.
  3. Amazon: Shareholder letter on decision types.
  4. Customer.io: Pricing and included capacity.
  5. Customer.io: Billing units and workspaces.
  6. Fivetran: Pricing and Free plan meters.
  7. HubSpot: Startup programme terms.
  8. Mixpanel: Startup programme timing and graduation.
Portrait of Jafrin Akter Alo

Written by

Jafrin Akter Alo

Data Engineer and Co-founder at Martechdevs and Growth and Analytics Partners

Jafrin writes practical guides to marketing technology, customer data, analytics and AI workflows. Martechdevs is a Growth and Analytics Partners company.

View LinkedIn profile

Book a Free Call

Thirty minutes on your stack and what it needs. Free, and no pitch.

Thirty minutes, and you leave with a plan

We look at what you have, what it is costing you and what to do about it first.

  • 30 minutes
  • Video call, link on booking
  • No obligation

What we'll cover

  • Your current stack and where it hurts
  • Quick wins we can ship first
  • An integration roadmap
  • Timeline, scope and next steps

Calendar not loading? Open it in a new tab or email hello@martechdevs.com.