Platform Roadmaps and Value Measurement

Every January the platform team published a roadmap: twenty-five items in four quarterly columns, each with a name, an owner, and a target month. By December it had shipped twenty-three of them, most within a quarter of the promised date, and the year-end review opened with that figure. The second slide was harder. Six of the twenty-three were used by fewer than one team in ten. The developer satisfaction score, asked twice a year with the same questions, had fallen from 3.6 to 3.2 on a five-point scale. Support tickets were up. And when the CTO asked what the platform had been worth to the company that year, the honest answer was that the team had delivered twenty-three items, and did not know.

The team had counted delivery without agreeing what each item should change for users. Its report also blurred delivery by year-end with delivery on the promised date. A dated list can make changes feel like broken promises when nobody distinguishes a forecast from a commitment, but dates do not prevent a team from learning or revising its plan. The company is fictional. This article examines how a platform roadmap can connect investment to outcomes, how to interpret adoption and work measurements, and how to change priorities while keeping obligations and commitments visible.

What a roadmap is for

Marty Cagan’s alternative to feature roadmaps preserves two management needs: choosing valuable work and making dependable commitments where dates matter. He proposes prioritizing business objectives and evaluating whether delivered changes achieve them. In his onboarding example, the desired result is an average below three hours instead of thirty days. That is a testable ambition, not evidence that any particular solution will achieve it. A platform team likewise needs to explain what its shipped capabilities changed and what it learned when they did not deliver the intended result.

In Cagan’s earlier account, a roadmap connects the current product to its strategy; a desired date becomes credible only after discovery, engineering estimates, and scheduling. The now-next-later roadmap described by Janna Bastow and Simon Cast is one way to express that uncertainty. Now contains active work, including solution experiments; Next shapes opportunities; Later explores broader strategic bets. Discovery can occur in all three. Genuine external deadlines, internal dependencies, and strategic milestones can be shown alongside these horizons. The following comparison describes the fictional team’s old habits and a proposed alternative, not properties every dated roadmap must have. The CNCF maturity model similarly illustrates making intended value and high-level feature targets visible to the organization.

	The fictional team’s old roadmap	Proposed outcome roadmap
Unit	A feature with a target month	A problem for a named segment, with the change it should produce and how that will be measured
Accountability	Output count and dates dominated the review	Investigating and improving agreed outcomes, with explicit delivery commitments where needed
Contradictory evidence	The team felt pressure to ship the listed feature	Reconsider the solution or problem, and explain changed obligations, forecasts, and choices
What stakeholders read	A schedule, and every month on it as a promise	Direction and confidence: what is in motion, what is being shaped, what is a bet
Dates	Forecasts and promises were not distinguished	Track required deadlines, current forecasts, confidence, and accepted commitments separately
Annual review	Items shipped over items planned	Outcome evidence, costs and guardrails; original, added, dropped, and continuing work reported separately

An outcome-roadmap entry identifies its users, problem, evidence, intended change, measurement plan, and current uncertainty. The Vote Always Went to the Forty explains how to choose problems across segments. Unknown cost need not exclude an entry: a bounded investigation can establish whether further investment is justified. For example, a database initiative might aim for eligible service teams to obtain a ready database with backups and monitoring within an hour of a valid request, without troubleshooting help. Required approvals remain visible in the elapsed-time measurement. Define readiness, the observation period, failures, and safety checks before testing the target. Retiring unnecessary team-maintained database paths is a separate proposed benefit, conditional on a validated replacement. The GOV.UK Service Manual recommends expressing a change, expected benefit, and rationale as a hypothesis. The value hypothesis records that claim, while the CNCF maturity model encourages discussing outcome evaluation before delivery.

Four kinds of value, and how each is measured

A platform can report use, user experience, operational outcomes, and business effects, but each claim needs suitable evidence. The CNCF platforms white paper covers user satisfaction and productivity, organizational efficiency, and product delivery impact. DORA recommends combining delivery performance, developer satisfaction, adoption and retention, and task success. These perspectives help select measures rather than supplying a universal score. The HEART framework adds a systematic way to connect user goals with behavioral and attitudinal signals. The table below is an application of those ideas to the fictional platform.

Kind of value	Question	Measures	How it misleads
Adoption	Who starts, currently uses, and continues using a capability?	Active teams among eligible teams; new adopters in a defined period; continued use by a prior cohort; time to a first relevant successful task	Confusing registration with use, new users with retained users, or mandatory adoption with voluntary preference
Use	Which capabilities serve real tasks, and with what help?	Task-relevant breadth or frequency; verified success without troubleshooting support; unnecessary independent maintenance retired after replacement validation	Automation dominating volume; deleting a valid alternative or copy and calling that evidence of trust
Satisfaction	How do users describe a defined experience?	Tested survey items with recorded versions, populations and periods; relevant segment summaries; feedback from success, failure, support and exit points	Changed response composition; unvalidated question changes; failure-only responses presented as all users
Effect on work	What changed in delivery, operations, or business outcomes?	Delivery metrics per service, shared with responsible teams; task-specific fulfillment time; support effort and lifecycle cost under stated workloads	Attributing a before-and-after difference to the platform without a credible comparison; mixing services or tasks

Define the unit before interpreting adoption. GOV.UK digital take-up measures completed digital transactions as a share of all-channel transactions in the same period, including assisted digital transactions. A platform team-coverage measure instead uses active eligible teams divided by all eligible teams; that is a different measure, not the same formula with interchangeable units. New adoption counts teams beginning use during a period. Retention follows a prior cohort into a later period. If 25 of 50 earlier users remain and 25 new teams arrive, active coverage can stay at 50 of 100 eligible teams while retention is only 25 of 50. State what counts as use, the periods, and how infrequent tasks, dissolved teams, and missing observations are treated. Required use is still adoption, but does not establish voluntary preference.

The evidence described in data product adoption also needs adaptation. Retiring unnecessary independent maintenance can document reduced duplication after the replacement is validated. Deleting a cache or recovery copy does not prove trust; retaining one does not disprove adoption. HEART cautions that expected enterprise use may make overall engagement uninformative, while feature-level frequency or depth can still answer a useful question. Completing a task independently concerns task success or a separately defined independence measure. Neither breadth nor frequency is universally preferable.

Satisfaction is a perceptual measure. Measure the Friction, Not the People explains how to examine the people and work represented as well as the wording. Preserve useful trend questions, but correct misleading ones with a recorded version and a continuity check or new baseline. GOV.UK recommends feedback at relevant intermediate and final points, including dropout and assisted support. For a platform, production deployment is one possible endpoint; diagnosing an incident, obtaining access, and completing an analysis have others. Failure-only prompts describe that sampled experience, not overall satisfaction.

The DORA metrics describe delivery performance for an application or service. Share them with the responsible teams, distinguishing delivery of the platform itself from delivery by its consumers. For an aggregate, disclose the service population, weighting, and distribution: changing the mix can move a team average without improving any service. Tasks that do not involve deployment need their own success, latency, and reliability measures. DORA’s platform guidance cautions that favorable experience can coexist with weaker delivery performance; include adverse results as well as gains.

As Who Is This Table For? explains, observation and attribution are different for time and cost as well as revenue. Record comparable work, users, periods, concurrent changes, and the assumptions of an experiment or other comparison. A retired pipeline can remove charges while migration and new operating costs offset the savings. Shorter waiting is not automatically freed labor, and freed labor is not automatically lower payroll. Multiple contributors do not make a business effect impossible to estimate; they make the comparison design important. When the evidence only establishes a plausible contribution, describe that limit.

A baseline records the reference and its measurement definition. Do not replace it to make a result look better. If it is invalid or the workflow changes, preserve the reason and version and establish a comparable reference. A proxy metric stands in for a broader outcome: task completion can directly measure completion while serving only as a proxy for overall productivity. State and test that link. Direct measures also have definition, coverage, and sampling limits. The CNCF maturity model invokes Goodhart’s law to highlight incentives that move a number without delivering the intended benefit.

GOV.UK recommends a small set of headline measures, with context from segments, trends, and comparisons. The fictional platform chooses active coverage, independent task completion, and satisfaction, alongside service-level delivery, reliability, and cost evidence. HEART’s goals–signals–metrics process starts with what users need to achieve, identifies observable evidence, and then defines a metric. For independent completion, record a cohort of eligible requests and the proportion with verified success within a declared interval without troubleshooting or guidance through tickets, chat, or direct staff contact. Required approvals are separate from that assistance; measure their waiting time too. Classify failed, abandoned, still-open, and unobserved cases rather than silently dropping them. Report full automation separately if it matters.

Normalization alone does not make a trend comparable. Suppose two task groups retain success rates of 20% and 80%.

Task group	Unchanged success rate	Earlier attempts	Earlier successes	Later attempts	Later successes
Lower-success tasks	20%	490	98	120	24
Higher-success tasks	80%	110	88	480	384
Total	Task mix changes	600	186 (31%)	600	408 (68%)

Among 600 attempts, a mix of 490 lower-success and 110 higher-success tasks gives 186 successes, or 31%. Changing the mix to 120 and 480 gives 408 successes, or 68%, without either group improving.

Similarly, unchanged satisfaction means of 2 and 4 yield 3.6 with a 20:80 response mix and 3.2 with a 40:60 mix. These are illustrative calculations. Examine within-group results, changes within broad segments, missing data, and uncertainty before calling a headline movement an improvement or attributing it to the platform.

When feedback changes the plan

Feedback should prompt examination, not a reflexive change to every priority. DORA’s platform guidance stresses user-centered product management and understandable task feedback. The CNCF maturity model illustrates how users can disengage when they cannot see whether feedback was considered. Neither requires every request to ship or every review to change the roadmap. The practices below are proposals for this platform; A Mandate Is a Measurement explains the continuing loop of evidence, decisions, communication, and follow-up.

• A measure moved. Check definitions, coverage, workload and uncertainty before reconsidering priority. A plateau may warrant research, while a target sustained over an agreed period with guardrails met may allow an improvement initiative to close. The service still needs an operating owner, support, security work and monitoring. Reallocate only the improvement capacity actually released after that handoff.
• A cost or constraint changed. A failed workaround, new obligation, or longer wait triggers review of the evidence and consequences. Product, engineering and the authorized sponsors weigh impact, dependencies, capacity and switching cost. Scores can structure the comparison; they do not make the decision.
• A request supplied new evidence. Record known users, impact, cost and sources, marking unknowns explicitly. A bounded investigation may be the next investment. The CNCF model’s Measurement Level 2 example reserves 20% for user-defined features; this is an illustration, not a universal quota or extra capacity. Set a local budget alongside operation, support and obligations, and connect accepted work to intended outcomes.
• Discovery contradicted an attempt. Determine what the experiment actually ruled out. The team may test another solution in Now, revisit the problem in Next, explore a broader direction in Later, or pause or stop. Record the evidence, affected expectations, and remaining questions. A failed prototype is not an automatic move between columns.
• An obligation, dependency or commitment is at risk. Notify affected people and escalate according to impact, urgency and authority, whether or not the item has a high-confidence delivery commitment. A change outside the commitment list may still threaten safety, operations, another team’s plan, or an external deadline.

Keep each material change and its reason in a decision record or lightweight equivalent, with an owner and reconsideration conditions. Publish the appropriate change history and actively notify people whose plans are affected; a log alone does not ensure they know. Cagan recommends reviewing whether roadmap items met their business objectives. Report original, added, dropped, and continuing initiatives separately, along with the significance of their outcomes and costs. A success fraction can organize the review, but does not make differently sized outcomes equivalent or establish why they changed.

The commitments an organization actually needs

Separate three things: an obligation and its deadline, the current delivery forecast and uncertainty, and an accepted delivery commitment. In Team Objectives – Commitments, Cagan describes high-integrity commitments as exceptional promises supported by sufficient discovery of value, usability, feasibility, and viability. He also recognizes internal team dependencies, not only external dates. Bastow allows meaningful strategic dates and milestones alongside confidence horizons. A sponsor’s request therefore needs its rationale examined rather than automatic acceptance or dismissal. Neither format makes an existing obligation disappear when delivery confidence is low.

Candidate	Date and authority	Delivery evidence or gap	Recorded decision and follow-up
Retire the build system before its license ends in June	Contractual expiry; renewal or retirement is an explicit decision	Pilot tested, remaining migrations estimated, owners and capacity agreed	Owner accepts a retirement commitment; track remaining teams and any renewal contingency
Upgrade before runtime support ends in September	Published support end; internal owner requires completion before that date	Staging rehearsal plus production inventory, dependencies, rollout and recovery plan	Record forecast and accepted commitment; review remaining risk with service owners
GPU environments for data science	No deadline established in this example	Problem evidence and prototype; operating capacity still being assessed	Now initiative with experiments and outcome reviews; report consequential changes
Faster preview builds by the end of Q2	Sponsor request; strategic reason and effect of delay not yet established	No credible estimate yet	Investigate rationale, dependencies and capacity; record a justified milestone or an uncommitted preference
Secrets rotation before the March audit	In this fictional case, an internal control owner has required this scope and date	Half the services use an unsupported pattern; delivery forecast is at risk	Keep obligation, owner and deadline on the register now; escalate the gap and evaluate authorized remedies without claiming a dependable delivery promise

The last row remains visible precisely because confidence is low. The owner must identify acceptable remedies, resources, and any required risk decision; an audit date alone does not establish a legal requirement for a particular rotation scheme. Only an authorized decision can change the applicable scope or deadline. If an external obligation also applies, internal re-planning cannot waive it. Update the forecast as evidence improves and record any accepted commitment separately. Completion requires the control owner’s verification, not merely installation of new tooling. A short commitment list can make promises clearer, but trust still depends on delivery and timely communication.

What a reviewer should ask

1. For each item on the roadmap, what is it supposed to change, for whom, and what number will show it?
2. Which original and added initiatives achieved their intended outcomes, which were dropped or remain open, and what were their costs?
3. What share of each segment has adopted the platform, and what is the denominator?
4. Which unnecessary maintenance paths were retired after validation, and which copies or alternatives remain legitimate?
5. Are survey definitions and respondents comparable, and how were changed questions or missing groups handled?
6. Which changes were observed, and what comparison and assumptions support attributing an effect to the platform?
7. What reference and measurement version were used, and how were justified baseline corrections documented?
8. What moved on the roadmap since last quarter, and does each move have a recorded reason?
9. Which obligations and deadlines remain at risk, including those without a delivery commitment, and who must act?

In a possible continuation of the fictional case, the next January’s roadmap shows nine initiatives across three segments, with evidence and uncertainty for each. A linked register tracks two accepted delivery commitments and the unresolved secrets-rotation obligation. In this version of the story, the control owner later verifies an approved remediation before March; the record retains the initial forecast gap and the evidence that closed it. At year-end, seven original initiatives have met their stated criteria and transferred to continuing operation, while two have been stopped with reasons. Of three initiatives added during the year, one has met its criteria and two remain in progress. They are reported separately rather than disappearing from the denominator.

Active service-team coverage is reported at four in five, alongside the eligible population and new-adopter and retained-cohort figures. The headline independent-completion rate is 68%, compared with 31% earlier, but the review also shows task mix, within-group results, the observation window, and incomplete cases. Satisfaction results include respondent composition and the mobile segment’s unresolved concerns. Those headline figures alone establish neither improvement in comparable work nor a causal platform effect, as the earlier arithmetic shows. The answer to the CTO now includes what changed, what the evidence supports, ongoing operating cost, and the next decisions—not just the number shipped.

References:

• Marty Cagan — The Alternative to Roadmaps, SVPG, 7 September 2015
• Marty Cagan — Product Roadmaps, SVPG, 7 January 2009
• Marty Cagan — Team Objectives – Commitments, SVPG, 4 March 2020
• Janna Bastow — Now-Next-Later Roadmap, ProdPad glossary, updated 29 June 2026
• GOV.UK Service Manual — How to set performance metrics for your service (Open Government Licence v3.0)
• GOV.UK Service Manual — Measuring digital take-up (Open Government Licence v3.0)
• GOV.UK Service Manual — Measuring user satisfaction (Open Government Licence v3.0)
• Kerry Rodden, Hilary Hutchinson, and Xin Fu, Measuring the User Experience on a Large Scale: User-Centered Metrics for Web Applications, CHI 2010, author’s version.
• DORA — Platform engineering, 12 January 2026 (CC BY 4.0)
• DORA — Software delivery performance metrics, 5 January 2026 (CC BY 4.0)
• CNCF TAG App Delivery — Platform Engineering Maturity Model (CC BY 4.0)
• CNCF TAG App Delivery — Platforms White Paper (CC BY 4.0)