From strategy to backlog: product requirements and the roadmap

A product roadmap is a promise about sequence, not a promise about dates. It states what the product will do first, what it will do next, and what it will not do yet, and it states the reason for the order. In payments the order is usually driven by regulation, by scheme deadlines, and by the corridors that generate the most volume. A roadmap that puts a nice feature before a mandatory scheme change is a roadmap that will miss the scheme deadline, and a missed scheme deadline means the product cannot process payments at all. Prioritisation in payments uses the same frameworks as other products, but the weights are different. The RICE framework scores reach, impact, confidence and effort. In payments, the impact of a mandatory regulatory change is infinite, because the product stops working without it, so it always comes first. The impact of a new corridor is measured in the volume it will carry, not in the number of customers who asked for it. The effort of a payment feature is usually higher than it looks, because every feature needs screening, reconciliation, exception handling and reporting, not just the happy path. The product requirements document is where the strategy becomes buildable. It states the problem, the target customer, the scope, the user stories, the acceptance criteria, and the non-functional requirements. For a payment product the non-functional requirements are often more important than the functional ones: the maximum processing time, the availability target, the recovery time objective, the throughput, the data retention period, and the audit requirements. A PRD that omits the recovery time objective is a PRD that will produce a product that cannot recover. Stakeholder management in payments is harder than in most products, because the stakeholders include the scheme, the correspondent banks, the regulator, and the operations team, none of whom report to the product owner. The scheme sets the rulebook and the deadline. The correspondent sets the cut-off and the charge. The regulator sets the reporting obligation. The operations team lives with the exceptions. The product owner must therefore manage stakeholders who cannot be overruled, and the roadmap must reflect their constraints, not just the customer's wishes. The minimum viable product in payments is larger than in most domains. A payment MVP must include initiation, screening, processing, settlement, status reporting, exception handling and reconciliation, because a payment product that cannot handle an exception is not a product, it is a demo. The MVP can be limited to one corridor, one currency and one customer segment, but it cannot be limited to the happy path. The requirements must state the MVP scope explicitly, and the acceptance criteria must include an exception test. Measuring the roadmap is a discipline. The roadmap must be reviewed every quarter, and the review must ask three questions: did the features that were delivered produce the expected outcome, did the regulatory deadlines move, and did the market change. A roadmap that is never reviewed becomes a list of promises that no longer match reality. The review must be documented, and the changes to the roadmap must be approved by the same people who approved the original. For a business analyst, the roadmap is a traceability exercise. Every requirement must trace to a roadmap item, every roadmap item must trace to the strategy, and every change to the roadmap must be recorded with the reason. The acceptance criteria must include a test where a requirement is traced from the strategy to the roadmap to the backlog to the test case, with no break in the chain. Last reviewed 7 November 2026. Further reading: Marty Cagan, Inspired; the RICE prioritisation framework; the European Payments Council rulebook change calendar; the SWIFT standards release calendar.