# Technology roadmap — fictional worked example

This is an original hypothetical software-company example, not a client case study, measured result or market benchmark. Names identify fictional planning roles. Replace all assumptions before using it for an actual decision.

Prepared by: Technology lead
Business sponsor and funding approver: CEO
Planning horizon: Next operating quarter
Last reviewed: Initial planning workshop
Next review: After the onboarding workflow investigation
Status: Draft; only the investigation is authorized

## Business outcome

Make enterprise onboarding more predictable without committing to an untested platform rewrite. The current baseline is not established: support tickets and implementation notes use inconsistent start/end definitions. The first authorized work must define and measure the current workflow before proposing a numerical improvement target.

Scope: customer onboarding workflow, integration exceptions and related engineering handoffs.
Exclusions: billing replacement, a complete product rewrite and expansion to new customer segments.

## Portfolio view

| ID | Business outcome | Initiative | Horizon | Accountable owner | Dependency | Next decision |
| --- | --- | --- | --- | --- | --- | --- |
| R1 | Understand onboarding delay | Map workflow and establish baseline | Now | Technology lead | Access to support and implementation records | Approve bounded pilot or investigate further |
| R2 | Test a repeatable integration path | Pilot one agreed integration pattern | Next | Engineering lead | R1 findings and product-approved customer scope | Authorize pilot scope, capacity and acceptance criteria |
| R3 | Reduce recurring onboarding exceptions | Expand the validated pattern | Later | Product lead | R2 acceptance and evidence of broader relevance | Expand, revise or stop; no release date committed |

## R1 — Workflow investigation

- Reason: The team cannot distinguish integration delay from customer or internal approval delay.
- Evidence status: Partial; existing notes need reconciliation.
- Owner: Technology lead; delivery counterpart: engineering lead.
- Output: Workflow map, consistent measurement definition, exception list and a bounded pilot proposal.
- Capacity assumption: Two engineers reserve three days each during the investigation period: six engineer-days total. This is a resource allocation, not an elapsed-time estimate.
- Other commitments: Support coverage remains assigned separately; no assumption that the engineers are free for the whole period.
- Budget: Existing internal allocation; any external spend requires separate CEO approval. No invented currency amount.
- Timing: Decision checkpoint after the investigation evidence is reviewed; no pilot delivery date promised.
- Acceptance: Product and engineering can reconcile representative onboarding records using the same start/end definitions and identify unresolved exceptions.
- Stop/reconsider: If available records cannot support a useful baseline, revise the measurement plan before choosing an integration solution.

## Sponsor decision

Approve the bounded R1 allocation and access to the relevant records. Do not approve R2 or R3 as delivery commitments yet. At review, decide whether the evidence supports a pilot, another investigation or a different priority. Record which existing work is displaced by the six engineer-days.

## Example change log

| Review event | New evidence | Decision | Consequence |
| --- | --- | --- | --- |
| Initial workshop | Inconsistent onboarding definitions | Authorize R1 investigation only | Defer a promised integration rollout date |
| R1 review | To be established by actual investigation | Pending | Do not fill in an invented result |

Guide: https://fractionalctoexperts.com/templates/technology-roadmap
Version: 2026-09-09