How to build a product roadmap for a payments product

A payments product roadmap combines two kinds of work: externally dated obligations, such as scheme mandates, regulatory deadlines and partner certifications, and discretionary bets that grow revenue or reduce cost. Build it by listing the obligations first and sizing the capacity they need, then arranging discretionary items in Now, Next and Later horizons. Give every item a label that says whether its date is externally fixed, committed or only forecast, and draw executive and partner views from one source record.

Why is a payments roadmap different from other product roadmaps?

Three things set it apart:

• Dates you do not set. Card schemes, regulators, standards bodies and banking partners publish changes with effective dates. Missing one can mean fines, lost acceptance or a blocked launch.
• Dependencies outside the company. An acquirer's certification window or a bank's test environment can hold a feature that is otherwise ready.
• Mandatory work customers never see. Reconciliation, security, resilience and reporting compete for the same engineers as new features.

That last point is why the risk-adjusted backlog uses four lanes: growth and conversion, reliability, risk and compliance, and finance and operations. A roadmap that shows only the first lane is not describing the product.

Now/Next/Later or dates: which roadmap format suits payments?

Use the hybrid. Put obligations on a dated track and everything else in horizons. The GOV.UK Service Manual's roadmap guidance advises making future uncertainty visible and keeping multiple versions consistent, which a hybrid format does by design. GOV.UK: developing a roadmap

What inputs belong on a payments roadmap?

Some recent examples show the shape of external inputs:

• Security standards. PCI DSS v4 introduced requirements that were best practice until 31 March 2025 and mandatory afterwards. PCI SSC: future-dated requirements Long notice periods tempt teams to defer, then compress the work into the final quarters.
• Scheme programs. Visa's 2025 fact sheet says it consolidated earlier acquirer, fraud and dispute monitoring programs into one program, the Visa Acquirer Monitoring Program. Visa: VAMP fact sheet 2025 A change like that lands on the roadmap of every acquirer and merchant platform as dispute and fraud tooling work.
• Message standards. In August 2026, Swift accepted a community request to extend the structured-address migration timeline for ISO 20022 payment messages and said it would give an update by December 2026 at the latest. Swift: structured address migration External dates can move, so record the source and its status, and keep preparing; Swift's address delay explains why.

Regional inputs differ. In the EU, authentication changes trace back to the strong customer authentication standards in Regulation (EU) 2018/389. In the UAE, card products may need to account for Jaywan, the country's first national card scheme. CBUAE: Jaywan Ask compliance for a dated list per market rather than relying on news coverage.

How do you plan mandatory work before discretionary work?

1. List every external obligation with its source, effective date, scope and status (confirmed, proposed or under review).
2. Assess the impact of each: affected flows, systems and partners, plus an effort range.
3. Reserve capacity for the total, with a margin for late clarifications from the issuing body.
4. Rank discretionary items in the remaining capacity, using your prioritization method; the CSPO and RICE walkthrough shows one.
5. Revisit when an obligation changes, and record what moved as a result.

If mandatory work exceeds capacity, raise it as a funding or scope decision for the sponsor. Quietly dropping discretionary commitments leaves sales and partners working from a roadmap that is no longer true.

How should confidence labels work on a payments roadmap?

A date on a payments roadmap can mean very different things. Why a roadmap date needs a confidence label sets out the general approach; a payments product needs one more category, for dates set by someone else:

Rate dependencies, not only build progress. A feature that is code-complete but waiting for an unbooked certification slot is still a forecast. Payment partner certification readiness covers what that slot depends on.

How do you present a payments roadmap to executives and partners?

Executives need one page: the share of capacity taken by obligations, the top discretionary bets and their intended outcomes, items whose label changed since the last review, and the decisions required. Lead with changes and decisions, not a full list.

Partners such as acquirers, processors and banks need only the items that depend on them or affect them: integration milestones, certification windows, test environment needs and planned deprecations. Leave out internal priorities and revenue figures.

Sales and merchant-facing teams should see committed and available items, with forecasts shown only alongside their conditions.

Generate all three from the same record, so a change appears everywhere at once.

What does a payments roadmap template look like?

The rows below are illustrative.

Keep the "next checkpoint" column honest. It tells readers when the label will next be tested, which matters more than the label itself.

FAQ

What should a payments product roadmap include?

External obligations such as scheme, regulatory and security deadlines, partner certifications, reliability and operations work, and discretionary bets, each with a label, an owner and a dependency.

Should a payments roadmap have dates?

Only where the date is real: external obligations and authorized commitments. Discretionary work is better shown in Now, Next and Later horizons.

How far ahead should a payments roadmap look?

Far enough to cover the known external obligations, which are often published well in advance. Beyond that, horizons are more honest than dates.

How do you handle a new regulatory deadline mid-quarter?

Assess its impact, reserve capacity, and take the trade-off to the sponsor as an explicit decision. Then update every roadmap view and tell the people who relied on the items that moved.

What is the difference between a roadmap and a release plan?

A roadmap shows priorities, outcomes and obligations over time. A release plan schedules specific scope into specific releases once work is committed.