Technology Roadmaps and Strategic Planning

The insurance group wrote a five-year technology plan every autumn. Each was a hundred pages, each had a Gantt chart with forty initiatives and a month for every one, and each was abandoned by the following spring, when the budget round funded something the plan had not mentioned and the chart was quietly left out of the board pack. Four plans in four years. The pattern was visible to anyone who compared them: the first two years of each plan were detailed and wrong, the last three were vague and identical, and the two dates that had actually mattered in that period, the end of standard vendor support for the policy administration system and the effective date of a reporting regulation, appeared on none of them. No support notice had reached an owner with a funded response, and the group had purchased a fixed-term extension at a price twice its earlier migration estimate. The regulation had been met by a team pulled off the plan’s flagship initiative, which was then a year late. The planning director’s summary at the fourth retrospective was the honest one: we had dates for everything and confidence about nothing, and the two dates that were real were never on the page.

This fictional group recorded different kinds of future work as though each were an equally certain delivery promise. It mixed external obligations, internal commitments, tentative opportunities, and estimates of when existing constraints would become binding. Its debt items lacked specific costs and decisions, and its strategic assumptions went unexamined. A useful plan makes these distinctions visible, connects work to strategy or necessary obligations, and exposes the choices that dependencies leave open. Format helps communicate those judgments; it does not replace them.

A roadmap is not the strategy, and it is not a schedule

A technology roadmap connects strategic direction to work and investment over time. Forty-Seven Initiatives and No Strategy describes the strategy’s diagnosis, policy, and coherent actions. Roadmap items should trace to those goals or to identified operating, maintenance, and compliance obligations; not every mandatory activity belongs among the strategy’s few discretionary actions. Show their competing demands on funding and capacity. Marty Cagan distinguishes a product roadmap’s objectives from a feature specification and emphasizes discovery and engineering estimates before credible delivery planning. A schedule adds task timing, resources, and dependencies, but remains a forecast under stated assumptions rather than a guarantee.

The Federal Enterprise Architecture Framework v2 describes an enterprise roadmap as a high-level account of current and future states and the transition between them, connecting strategy, projects, budgets, dependencies, and risks. For this group, it links the current estate to the target architecture, identifies funded and unfunded needs, and shows important transition choices. Cagan’s portfolio-roadmap discussion also supports using enough abstraction to coordinate multiple products without reproducing every team’s task list. Twenty-Three of Twenty-Five Shipped covers platform product roadmaps and outcomes. The enterprise view should connect to those plans, with detail appropriate to the decision and confidence available.

Separate obligations, commitments, and direction

The group presents obligations and accepted commitments together so their authority and delivery risks can be examined. Exploratory direction has a separate view, where investigation can change the proposed work. Label each date in either view. An external deadline states an applicable obligation or constraint; an internal commitment records an authorized delivery promise; a target expresses an intention; and a forecast estimates what may happen. A capacity-exhaustion forecast depends on demand and supply assumptions and needs a range and update trigger. Contract dates may have negotiated alternatives, while a mandatory legal deadline does not disappear because delivery looks unlikely. Neither establishes that the proposed implementation can meet it. ProdPad’s now-next-later roadmap organizes work by confidence while allowing meaningful external deadlines, internal strategic commitments, and milestones. Its columns need not correspond to quarters. Record a date’s basis, owner, scope, confidence, and authority for changing it separately from the confidence horizon.

Layer	What goes in it	How it is dated	What the reader may rely on	The insurance group
Obligations and accepted commitments	Applicable external requirements and internally approved work, with their different authority recorded	Deadline or promised date alongside a current delivery forecast, assumptions, and a risk-adjusted start target	Who has accepted which obligation, the evidence behind the forecast, and when delivery risk is escalated	Migration before the purchased support extension expires; the next applicable reporting requirement
Direction, nearer investigation	Chosen problems under investigation; options, costs, and dependencies being examined	No automatic quarter; a useful timing estimate or discovery milestone is labeled separately	The problem and current learning plan, not a guaranteed solution or delivery date	Claims data platform; identity consolidation
Direction, further exploration	Broader opportunities with a rationale and decision-relevant uncertainties	Triggers and review points; meaningful dates may be attached without pretending delivery is committed	Why an option is worth examining and what would change that judgment	Straight-through underwriting; retiring a second policy system

Richard Rumelt distinguishes strategy from a long list of stakeholder wishes. His example of a plan with 47 strategies and 178 action items illustrates how a long-term label can hide a lack of choice. A further-horizon entry should instead state the problem or opportunity, why it matters, and what evidence would justify more work. Nearer objectives connect the challenge to feasible action, with resources and constraints made explicit. Moving an item closer is a decision supported by evidence, not an automatic reward for waiting.

Turn technical debt into a scoped investment decision

The group’s recurring instruction to reduce debt identified neither a limitation nor a feasible remedy. technical debt concerns limitations that create avoidable present or future work; a support-driven migration is not automatically debt repayment. Ward Cunningham’s metaphor connects shipping and learning with the burden of leaving an implementation unconsolidated. Martin Fowler compares the extra effort from a limitation with the cost of improving it and stresses the uncertainty of those estimates. For each item, identify affected changes or operations, likely future demand, improvement cost, transition risk, and remaining useful life. Frequent change can make improvement worthwhile, but does not by itself give the item first priority.

Choose a treatment for the specific limitation. A large improvement may need a funded roadmap item; a smaller one may fit work already touching the affected area. Recurring maintenance can have an agreed capacity allocation while larger improvements receive individual decisions. Deferring a major refactoring can be sensible for a retiring system, but necessary security, integrity, compliance, containment, and migration work remain. Record the residual exposure and review date rather than treating retirement as a blanket exemption. Fowler’s quadrant helps distinguish how limitations arose, including those exposed by later learning; it is not a priority formula. The group’s fifth plan identifies six systems with concrete limitations and ranges for avoidable effort and improvement cost, and compares those proposals with other work. It separately funds the support transition and mandatory maintenance.

Show which dependencies constrain which decisions

A dependency constrains a particular task or operating state, not necessarily the start of an entire project. Map system dependencies in both directions, including infrequent jobs, and distinguish hard prerequisites from preferences and choices made by the current design. The claims service needs an accepted customer-key contract before production integration; discovery and development can proceed against an agreed interface and test data while identity work continues. Those arrangements need their own validation and can create rework. Capability gaps likewise identify the minimum skills, capacity, and controls required at a particular gate, rather than demanding a complete foundation before any initiative. For support lifecycle planning, record the policy as well as dates: Kubernetes API rules depend on stability and release conditions, and deprecated REST API requests can emit warnings and metrics. Microsoft Modern Lifecycle coverage has product-specific servicing, licensing, and provider-support conditions, not a fixed retirement date for every installed component. deprecation can precede a removal decision; distinguish the two.

Dependency	Where it comes from	Planning question or constraint	How it is kept current
Technical	Data, behavior, availability, or decisions required by a particular task	At which integration or operating gate is the dependency needed? Can contracts, adapters, or staged delivery support parallel work?	Confirm scope and compatibility through lineage, owners, and tests, including rare work
Capability	Skills, staffing, controls, or a service needed for defined work	What minimum capability is needed by which gate, and what can safely proceed while it develops?	Review capacity and readiness when scope, evidence, or the intended stage changes
Published lifecycle	Product/version coverage, release-based windows, notices, and any confirmed end date	Compare migration, eligible extension, and permitted alternatives; estimate testing, transition, and contingency time	Inventory installed versions, policy conditions, owner, unknown dates, and next check; monitor events and choose cadence for lead time and notice risk
External	Applicable regulation, contracts, leases, or audit obligations	What outcome is required by when, and which compliant implementations or authorized contractual alternatives remain?	Named owners establish applicability and track changes; coordinate technical impact and escalate forecast shortfalls

The group works backward from the purchased extension’s expiry using a range for migration, testing, and recovery preparation. That produces a start target and contingency plan, not a guaranteed latest safe date. Resource conflicts and critical dependencies can change the forecast. The team compares a combined migration with staged identity integration and chooses the latter after testing the shared key contract. Compliance and engineering also assess the reporting requirement before reserving capacity; its deadline does not itself dictate one solution or consume a whole team for a year. The roadmap records these choices alongside the constraints, so leadership can revisit them when assumptions change.

Showing uncertainty instead of hiding it

A dated chart can show uncertainty through ranges, assumptions, and confidence; confidence columns can hide it if they are merely renamed quarters. Choose a representation that makes the intended meaning clear. Identify important assumptions and prioritize tests using their consequences, uncertainty, dependencies, cost, and information value. A riskiest assumption is not necessarily one unique belief, and some experiments or development can proceed in parallel. Keep alternatives explicit, including the cost of maintaining them and the evidence needed to choose. Record external events or measurements that would prompt reconsideration, without assuming that every trigger automatically promotes an item. The group uses four pages for its core roadmap and a fifth-page appendix for declined work. It separately labels two accepted commitments, five problems under investigation, and four broader opportunities, with estimates and meaningful milestones where useful. At review, it can examine what was learned and why choices changed.

When the strategy is reviewed

Use periodic checks and event-driven review

A strategy review asks whether the challenge, policy, assumptions, and evidence still support the chosen actions. The group adopts quarterly roadmap checks and an annual broader review as its initial cadence, with earlier reviews when circumstances warrant. These are local choices, not universal intervals. Named owners watch support notices, applicable regulation, organizational changes, competitor developments, important test results, and measures. Each signal prompts an impact assessment: it may affect a delivery plan, a roadmap priority, the guiding policy, or the diagnosis. Record strategic choices with context, alternatives, authority, and review conditions. The discipline in Architecture Decisions is useful, but only architectural choices require an architecture decision record; other strategic decisions can use an appropriate business decision record.

Trigger	Who watches	What it reopens	What the group missed
A support policy, coverage condition, or retirement notice changes	Lifecycle owner with the affected service owner	Applicability, delivery risk, alternatives, and the needed level of escalation	The standard support date was not connected to an owner and funded response
A reporting obligation is announced or changed	Compliance with a named technology counterpart	Applicable outcomes and dates, implementation options, costs, and capacity	The previous rule disrupted a flagship initiative because the impact was assessed late
An acquisition or other operating-model change	Executive leadership with affected owners	Which assumptions, shared capabilities, and investments need reconsideration	No such event in the example year; the review route still needs an owner
A significant assumption is challenged or an opportunity trigger occurs	The option or experiment owner	What the evidence rules out, what remains viable, and whether further learning is worth funding	Earlier bets had neither explicit assumptions nor a review route
A measure crosses a specified threshold	The measure owner with the decision owner	Data quality, uncertainty, causes to investigate, and the affected decision	The old plan lacked measures tied to decisions

Match review scope to the evidence

A periodic roadmap review may leave the diagnosis intact, but it must be able to escalate evidence that challenges it. Conversely, a routine vendor update need not reopen the entire strategy. Decide the scope and authority for the response, document the reason, and assess the impact on obligations and accepted commitments before changing them. If the diagnosis was implicit, first reconstruct the goals, assumptions, constraints, and reasoning; then decide what to retain, improve, or replace. The group’s second-year review retains its diagnosis while changing two sequences, funding further investigation of one opportunity, and ending another after assessing the failed approach and remaining alternatives. Those outcomes are examples, not prescribed proportions of change.

Judging a plan and its roadmap

A useful review checks that each item serves a strategic goal or an identified obligation, and that dates distinguish constraints, commitments, targets, and forecasts. Important assumptions, owners, and decision gates should be visible. Debt treatments should compare avoidable burden, cost, risk, remaining life, and mandatory work. Dependencies should identify the task and gate they constrain, with design and resource choices recorded. The lifecycle inventory should include relevant policy conditions and unknown dates rather than invented expiry dates. Test whether signals can reach someone authorized to assess and act on them; a real trigger need not already have fired. Evaluate resulting decisions, delivery risk, costs, and service outcomes rather than page counts or apparent precision.

What a reviewer should ask

1. Which strategic goal or operating, maintenance, or compliance obligation justifies each item, and what capacity does it require?
2. Which dates are external constraints, accepted commitments, targets, or forecasts, and what evidence and change authority support them?
3. What duration range, resources, dependencies, validation, and contingency support each commitment’s current forecast and start target?
4. For each direction item, what is known, what is assumed, and what would move it nearer or drop it?
5. Which limitations create avoidable effort or exposure, which treatment is justified, and what mandatory work remains even where major repayment is deferred?
6. Which task and gate does each dependency constrain, and what parallel, staged, or alternative arrangements were considered?
7. Who detects and assesses each review signal, how quickly must they act, and has the escalation route been checked?
8. What did the last review change, what did it leave alone, and why?
9. What is on the list of things the organization decided not to do?

The insurance group’s fifth plan contains a diagnosis and three strategic actions, linked to a roadmap that also reserves capacity for necessary obligations. It chooses quarterly roadmap checks, an annual broader review, and named event owners. The policy-administration migration finishes eleven weeks before the purchased extension expires. The extension already bought remains a cost; the group avoids buying another one.

A later reporting requirement enters the obligations view once compliance confirms its applicability, and engineering evaluates options before capacity is committed. Claims development proceeds alongside identity work, with production integration waiting for the validated shared-key contract and operating readiness. At the second-year review, a vendor announcement justifies further investigation of one opportunity. Another is dropped after a failed pilot and assessment show that the remaining approaches do not justify their cost and risk. The group records those judgments and checks service outcomes after delivery. The visible basis for decisions lets owners revise the plan as evidence changes. Page counts and calendars help present that reasoning, while the remaining uncertainty still needs assessment at each decision and review.

References:

• Ward Cunningham, The WyCash Portfolio Management System, OOPSLA ’92 Experience Report, 1992.
• Martin Fowler, Technical Debt
• Technical Debt Quadrant
• Marty Cagan, Product Roadmaps, Silicon Valley Product Group, 2009.
• Janna Bastow, Now-Next-Later Roadmap, ProdPad Glossary.
• Richard Rumelt, The perils of bad strategy, McKinsey Quarterly, June 2011.
• Office of Management and Budget, Federal Enterprise Architecture Framework Version 2, January 2013 (PDF).
• Kubernetes, Kubernetes Deprecation Policy
• Microsoft, Modern Lifecycle Policy