From Strategy to TOM: The Linkage Chain — Market Signals, Value Proposition, Business Model, Operating Model and the Target Operating Model
v0.2 · 19 October 2026 · First issued 1 September 2026 · Custodian: BusinessGPS · Version index and changelog
Position. A transformation design is only as strong as the joins between its artefacts. Strategy chooses where and how to create value; the business model explains how value is created and captured; the operating model explains how the organisation must work to make that model real; the target operating model adds implementation-grade detail. Each object hands to the next through an explicit, evidenced, reconciled join — and every operating decision must be traceable back up the chain to the customer value it exists to serve. Where a join is silent, the design breaks there.
Executive summary
There is no shortage of good design objects in transformation work. Teams produce strategies, value propositions, business model canvases, operating model canvases and target operating models — often each one competent in isolation. Transformation can still fail, and a place for it to fail is the join. A value proposition is written and never turned into an operating response. A business model promise is captured and no process is ever designed to keep it. A target operating model is decomposed to the level of roles and systems, and no one can any longer explain which customer job that role exists to serve.
The chain from market signal to operating decision is a sequence of design objects, but the discipline that makes it hold together is not in the objects — it is in the handoffs between them. This paper defines that chain and specifies the handoff at each join: what the upstream object must decide before the downstream object can legitimately begin, what evidence crosses the boundary, and how the through-line is preserved so that any operating decision can be traced back to the strategy and customer value it serves.
Three properties make the chain trustworthy. First, the mapping between the business model and the operating model is many-to-many, not one-to-one — a single customer promise touches processes, information, organisation, suppliers and management measures at once, so the join must be modelled with links, not copied text. Second, the chain is a governed learning cycle, not a one-time cascade — evidence from operations can legitimately reopen any upstream object. Third, the chain is bidirectional in assurance: intent flows down, but traceability must run back up, and a design that cannot be traced upward has a broken join somewhere in it.
This is the traceability companion to Operating Model Construction and Elevation, which sets out how an operating model is built (top-down, bottom-up, or by convergence) and how a domain model elevates to the enterprise. That paper answers “how is the operating model built and integrated.” This paper answers a different question: “how does each design object hand to the next without losing the thread.” Together with The Five-Layer Activity Model, which says where enterprise work sits, and TCM Discipline, which names the discipline that governs the whole cycle, it completes the method.
1. The chain, in one pass
The linkage chain runs, in order: market signals and current reality → strategic choices → mission and target outcomes → customer profile and customer journey → value proposition → business model canvas → operating model canvas → high-level and detailed target operating model → current-to-target capability gaps → transformation roadmap → portfolio alignment and execution → operate, realise value and learn — and then back to the top, because operating evidence can reopen any object above it.
Read as prose that is a cascade. Read as a discipline it is a loop: each arrow is a join, and each join has a handoff contract — an upstream decision that must be settled, an evidence set that crosses the boundary, and a reconciliation test that the downstream object must pass before it is accepted. The rest of this paper is about those joins.
The two properties to hold in mind throughout: this is a governed learning cycle, not a one-time cascade — evidence from execution and operations may legitimately alter the proposition, the business model, the operating model, the target operating model, or the strategy itself; and the joins are where design decisions are actually made, not merely recorded.
2. What each design object decides
Before the joins can be examined, each object’s own job must be clear. The value of the chain comes from each object deciding its own question and no more — a business model that quietly makes operating decisions, or an operating model that quietly re-opens strategy, is a join failure disguised as an artefact.
| Design object | Primary question | Principal decision it owns | Evidence it requires |
|---|---|---|---|
| Environment / current reality | What is changing, and what is true now? | The priority strategic issue, opportunity and constraint | Market, customer, operational, financial and stakeholder evidence |
| Mission and outcomes | Why do we exist, and what outcomes matter? | Purpose, mission, vision, values, goals and measurable objectives | Authorised strategic intent and measurable target outcomes |
| Customer profile and journey | For whom, in what context, across what experience? | Priority segments, jobs, pains, gains and moments of truth | Direct customer, buyer or operator evidence |
| Value proposition | What value will we offer, and why does it fit? | Products and services, pain relief, gain creation | Coverage links to ranked evidence and defined fit tests |
| Business model canvas | How will value be created and captured? | Customer-facing, operating and economic logic | Desirability, viability, feasibility and adaptability evidence |
| Operating model canvas | How must the organisation operate to deliver that model? | High-level operating design across its six elements | Demand, flow, capability, capacity, control and dependency evidence |
| Target operating model | What detailed operating arrangements are required? | Processes, capabilities, roles, decisions, data, technology, suppliers and controls | Cross-domain traceability and operability assurance |
| Transformation roadmap | How will current operations become the target model? | Capability outcomes, initiatives, sequence, milestones and gates | Gap, dependency, capacity, benefit and risk evidence |
The linkage discipline is that no object decides another object’s question. When it does, the join upstream of it has failed — the artefact has absorbed a decision that was never handed to it.
3. Join one — strategy into the business model
Strategy establishes the design constraints; the business model works inside them. Strategy first understands the environment: customer preferences and unmet needs, market and economic trends, competitor performance and positioning, supplier and ecosystem capabilities, technology change, legal and environmental and social and political factors, current operational and financial performance, and the organisation’s own capability, capacity and governing constraint. Strategy then chooses: the customers or beneficiaries to serve, the outcomes and value to create, where and how the organisation competes or fulfils its mission, which capabilities differentiate it, which capabilities must be owned, shared, partnered or rented, and the economic and risk boundaries within which any model must work.
The handoff contract at this join: a strategy is not complete until its choices can be represented as a coherent business model and a workable operating model. That is the acceptance test for strategy itself — not eloquence, but representability downstream. What crosses the boundary is the set of strategic constraints the business model must honour: the chosen beneficiaries, the target outcomes, the make-or-rent capability decisions, and the economic envelope. What must not cross is a pre-decided operating arrangement; strategy that arrives already specifying processes and systems has skipped two objects and will contradict the customer evidence that has not yet been gathered.
4. Join two — customer value into the value proposition
Between strategy and the business model sits the value proposition, and it has two halves that must meet. The customer profile establishes customer jobs, pains and gains for a defined segment and context. The customer journey adds the sequence of goals, actions, touchpoints, emotions, experiences and moments of truth. The value map responds with products and services, pain relievers and gain creators, each carrying explicit links to ranked customer evidence and defined tests and thresholds for fit.
The handoff contract: customer–proposition fit is a hypothesis until observed evidence meets an agreed threshold. It is segment-specific, and it must never be inferred from internal enthusiasm. The join fails in a recognisable way — a value proposition that lists gain creators with no link back to a ranked customer pain, or a fit claimed without a threshold ever being set. What crosses this boundary into the business model is a fit-tested proposition with its evidence links intact; what must not cross is an untested internal conviction dressed as customer value.
5. Join three — the business model into the operating model
The business model canvas connects nine blocks across three domains, and it is a whole-system hypothesis, not a set of independent decisions.
| Business model domain | Blocks | Design focus |
|---|---|---|
| Front end | Customer segments, value propositions, channels, customer relationships | Who receives value, what is offered, how relationships operate |
| Back end | Key activities, key resources, key partners | What must happen, and what assets and ecosystem are required |
| Financial model | Revenue streams, cost structure | How value is captured, and what the model costs |
As a whole-system hypothesis it must be tested — for desirability (customers or beneficiaries value it), viability (economics and benefits are credible), feasibility (required capabilities, capacity and dependencies are obtainable), and adaptability (the model can respond to material change without unacceptable loss of value or control). But the business model does not itself explain the complete operating arrangements. That is the join: the business model hands what value is created and captured to the operating model, which decides how the organisation must work to make it real. A business model that starts specifying processes has crossed the join early; an operating model that re-litigates revenue logic has crossed it backwards.
6. The join three handoff is many-to-many
This join is easy to get wrong, and copying can break it. There is no dependable one-block-to-one-element conversion between the business model and the operating model. A single business model decision fans out across the operating design:
- a customer promise affects processes, information, organisation, suppliers and management measures at once;
- a channel choice may affect processes, locations, technology, data and partner arrangements;
- a revenue or cost assumption can constrain all six operating elements simultaneously;
- a key partner may require supplier governance, information sharing, process integration and management controls together.
The handoff discipline follows directly: preserve the through-line with stable identifiers and traceability links, not by silently copying text from one canvas into the next. Each operating element records which business model decisions it responds to; each business model promise records which operating elements answer it. The join is a web of links, and it is the links — not the prose — that let a design be traced later. Where a team copies a promise into an operating element as free text, the identifier is lost, and with it the ability to prove the promise is still being kept three artefacts downstream.
The operating model canvas expresses the operating design across six elements, each connected back to the business model:
| Operating element | Design question | Principal business model connections |
|---|---|---|
| P — Processes / value-delivery chains | What end-to-end work creates and delivers value? | Value propositions, key activities, channels |
| O — Organisation | Who performs and owns the work, decisions and outcomes? | Key resources, key activities, customer relationships |
| L — Locations | Where are work, assets, people and interactions located? | Channels, activities, resources, segments |
| I — Information | What data, knowledge, applications and flows are required? | Activities, resources, channels, relationships |
| S — Suppliers | What must external parties provide, and how are dependencies governed? | Key partners, resources, activities |
| M — Management system | How are objectives, decisions, performance, risk and improvement governed? | Strategy, targets and every business model block |
The correct starting point inside this join is the value-delivery chain, not the organisation chart. For each material value proposition: define the beneficiary outcome and demand characteristics; map the end-to-end value-delivery chain; identify the major stages, decisions, handoffs, waits, exceptions and controls; determine the required service, quality, speed, capacity, cost and experience; then design organisation, locations, information and suppliers around the flow; and finally design the management system that governs outcomes, performance, risk and learning. Starting with the organisation chart, the application stack or a preferred supplier optimises a component before the value flow is understood — and quietly breaks the join, because the component is now anchored to an internal preference rather than to a business model decision.
7. Assurance at the operating model join
A join is only closed when it is tested. Before an operating model is accepted, run the alignment tests — each one is really a test of a join, checking that the operating design still traces to what handed to it:
- Strategic alignment — does it enact the strategic choices and target outcomes?
- Customer alignment — can it deliver the proposition and the critical journey moments?
- Business-model alignment — does every material business model promise have an operating response?
- Economic alignment — can the model work within its cost, revenue, benefit and funding assumptions?
- Internal alignment — do the six operating elements reinforce rather than contradict one another?
- Constraint alignment — does the design improve the governing constraint rather than move or disguise it?
- Execution alignment — can the organisation absorb the transition at the proposed pace?
- Human–AI alignment — are accountability, review, monitoring, fallback and appeal explicit?
The tell-tales of a broken join are specific and worth naming: a value proposition with no delivery chain; an activity or decision with no accountable owner; a channel with no supporting information or location; a supplier with no integration, control or exit arrangement; a target with no operating response; an operating element with no upstream rationale; technology or an AI capability proposed with no constraint benefit and no accountable human control; and a financially attractive business model that cannot operate at the required demand or service level. Each of these is a link that should exist and does not — which is exactly what a broken join looks like in a traced model.
8. Join four — the operating model into the target operating model
The one-page operating model canvas is a high-level decision surface. It is not the full operating model, and the join to the target operating model is a decomposition, not a translation. Once the operating model is approved, it is decomposed into target-operating-model views covering: value streams and processes; capabilities and maturity; organisation, roles and skills; accountability and decision rights; locations and capacity; information, data and knowledge; applications, integration, automation and AI; suppliers, sourcing and service integration; policies, controls and risk; and objectives, measures, service levels and management routines.
The handoff discipline that keeps this join traceable is a per-element record. Every detailed target-operating-model element should carry current state, target state, gap, rationale, upstream link, owner, confidence, dependencies and controls. The upstream link is the load-bearing field: it is what lets any role, system or control in the finished target operating model be traced back through the operating element, the business model promise and the customer value it ultimately serves. Strip the upstream link and the decomposition still looks complete — but the thread is cut, and no one can any longer answer why a given detailed arrangement exists.
9. The dual view the join must carry across
When the target operating model embeds AI or agents into the work, the join from operating model to target operating model must carry a dual view across the boundary — because a process improvement that quietly erodes a capability is a broken join that no single-view design will detect. For every material value-chain stage, the target operating model should hold three linked designs:
- Process design — human and AI activities, agent authority, decisions, exceptions, controls and beneficiary outcomes.
- Capability design — the enduring ability required, the human judgement, the AI or agent contribution, the information and context, the owner, the maturity and the performance.
- Ownership and governance design — what is owned, co-owned or rented; supplier dependency; human accountability; portability, monitoring, fallback and reconstruction requirements.
The two views ask different questions. The process view asks whether AI can perform the work. The capability view asks whether the enterprise remains capable after AI performs it. Process improvement accompanied by capability erosion is not an acceptable target operating model — and the only way to see the erosion is to carry both views across the join together. Carrying process design alone breaks the join in the most expensive way, because the loss is invisible until the capability is needed and gone.
10. Join five — target operating model gaps into transformation
The final join turns a designed target into a governed programme. It runs: the current operating model and target operating model, compared, produce capability and operating gaps; the gaps produce named transformation initiatives; the initiatives carry milestones, dependencies and gates; and the initiatives move the organisation through transition states toward target operations.
The handoff discipline is that a transformation roadmap must include explicit time horizons, target capability outcomes, named initiatives rather than workstream labels alone, accountable owners, dependencies and capacity requirements, benefits and measures, risks and controls, observable milestones, and human proceed / revise / pause / stop gates. Dates remain indicative until scope, capacity and critical dependencies are accepted. The join fails when a gap is handed to a “workstream” with no named initiative and no owner — the thread from customer value reaches the target design and then dissolves into an unaccountable label.
11. The chain is a loop, and the model is versioned
The linkage chain closes on itself. The operating model evolves through a repeating cycle: a material reason to change is identified; a high-level target operating model is designed; approved detail is developed in the target operating model; the organisation transforms from current toward target operations; temporary mixtures of current, transition and target arrangements are governed; the organisation operates, measures, learns and improves; the next material signal or constraint is detected; and strategy and operating-model design are re-entered.
Two consequences follow for the joins. First, the target model is versioned — transformation does not end when projects close; it succeeds when new capability and operating outcomes are absorbed and sustained, and each absorbed change is a new version of the traced chain. Second, the up-chain joins are real joins, not just metaphor: operating evidence can reopen the operating model, the business model, the value proposition or the strategy, and when it does, the same handoff discipline applies in reverse — the evidence must be reconciled with the object it reopens, not simply pasted over it.
12. Where this sits in the O2O method
The linkage chain maps cleanly onto the O2O method, and each position is a set of joins to be closed rather than a stage to be completed.
| O2O position | Principal linkage work | Exit output |
|---|---|---|
| Step 1 — Business Context | Environment, mission, customer evidence, current business and operating model, lived flow and constraints | Accepted current reality and the priority strategic issue |
| Step 2 — Business Goals | Value-proposition fit, business model options, economics, outcomes, measures and strategic selection | Approved or conditional business model option and target outcomes |
| Step 3 — Business Change | Why the business must change and for whom, what changes and when, and how it will be financed, operated and transitioned | An agreed change narrative and its scope |
| Steps 4 to 6 — Platform Change, Update and Decision Strategy | Platform strategy, target architecture intent, target capabilities and controls; the choices locked | A target design that is assured and decided |
| Steps 7 to 9 — Initiative Alignment, Structure and Planning | Value and cost pools; the target operating model with named capability owners; current-to-target gaps into pre-projects and initiatives; sequence and the transformation roadmap | An approved roadmap, ready for the portfolio |
| Portfolio and Execution (steps 10–18) | Sequence initiatives as a portfolio by strategic value, constraint leverage, dependency, capacity and risk | A governed, execution-ready portfolio |
| Execution: step 18 cells (18.1–18.9) | Pilot, implement, govern transition and build capability | Accepted operating capability and readiness evidence |
| Operations (steps 19–27) | Run, realise benefits, monitor drift and learn | Sustained outcomes and controlled re-entry signals |
Transformation Capability Management provides the standing management capability that governs this full cycle — it is the discipline that keeps the joins closed as the model versions over time.
13. Decision rights across the chain
An AI capability may extract, cluster, map, compare, simulate, trace, challenge and monitor across the whole chain — and traceability, in particular, is work an AI does well, because a link is a checkable object. But named humans retain authority at every join: strategic choices and mission intent; customer-fit acceptance; business model and operating model selection; target and investment trade-offs; decision rights and workforce consequences; risk acceptance; target-operating-model approval; and transformation sequencing and stage exit.
No AI-enabled target operating model is complete until named humans approve, for each material stage, the process authority, the capability delivery model, the capability ownership, the supplier dependency, the fallback and the residual risk. AI prepares and checks the linkage; people own the decisions the linkage carries. This is the same principle the construction-and-elevation paper applies to elevation gates — the machinery assembles the evidence, the human owns the choice.
14. Anti-patterns of the broken join
Avoid: writing a value proposition that no operating response ever answers; copying business model text into operating elements as free text and losing the identifiers that make it traceable; converting the business model to the operating model as if it were one-block-to-one-element; treating the one-page operating model canvas as the full operating model; decomposing a target operating model without the upstream link on each element; carrying process design across the operating-to-target join without the capability view beside it; handing a gap to an unnamed workstream; treating the chain as a one-time cascade that cannot be reopened by operating evidence; and pasting operating evidence over an upstream object instead of reconciling it. Every one of these is the same failure in a different costume — a join left silent, so the thread from customer value cannot be followed through to the operating decision.
15. The canonical principle
A transformation design holds together at its joins, not in its artefacts. Strategy chooses value; the business model creates and captures it; the operating model makes it operable; the target operating model makes it detailed and buildable. Each object hands to the next through an explicit, evidenced, reconciled join, and every operating decision must remain traceable — by stable identifier, not copied text — back to the strategy and customer value it serves. Where a join is silent, the design breaks there, however strong each artefact looks alone.
This gives every design team a discipline of joins rather than a filing cabinet of canvases — and it makes traceability a property that can be checked, so that the answer to “why does this role, this system, this control exist?” is always a path back up the chain to a customer value the enterprise chose to serve.
Companion papers
- Operating Model Construction and Elevation — how the operating model is built (top-down, bottom-up, or by convergence) and how a domain model elevates to the enterprise. This paper is its traceability companion: that one builds the model; this one keeps the thread unbroken between the objects.
- The Five-Layer Activity Model — where enterprise work sits (the diagnostic lens the linked objects populate).
- TCM Discipline: The Missing Discipline — the discipline that governs the linkage-and-learning cycle described here.
Version index and changelog
- v0.2 (19 October 2026): wording, O2O step names and references aligned with the published method; no argument changed; before publication, the method table corrected so that steps 3 to 9 each carry their own work (the target operating model and the roadmap sit at steps 7 to 9, inside the strategy tile), and the companion papers cited at the versions being published (v0.4 and v3.2).
- v0.1 (1 September 2026).
The business model, value proposition and operating model canvases are established methods; the contribution here is the governed linkage, the handoff discipline at each join, the traceability convention, the O2O placement and the target-operating-model handoff.
From BusinessGPS source R&D.