Moving from strategy slides to a concrete target operating model starts with one question: “What must be true, operationally, for this strategy to work?”
This chapter is about answering that question in a disciplined way. You will:
- Turn strategy into a small set of operating model design principles.
- Identify the critical value streams and customer promises that the TOM must support.
- Make explicit the guardrails and non-negotiables (risk, regulatory, brand, technology).
- Bring this together into a simple, repeatable strategy-to-TOM cascade that your team can use.
3.1 Translating Strategy into Operating Model Design Principles
Design principles are the bridge between strategy and the detailed TOM. They are short, concrete statements that encode how your strategy should shape the way you operate.
Think of them as instructions to your future self: when you are deep in debates about central vs local, platform vs product, automation vs headcount, these principles tell you which way to lean.
Examples (illustrative):
- “End-to-end ownership for each priority customer journey.”
- “Global products and platforms; local go-to-market and regulatory adaptation.”
- “Automation-first for repeatable, transactional work.”
- “Single source of truth for core customer and product data.”
A practical way to derive design principles:
1. Extract the strategic themes
Take your strategy and value agenda and boil it down to 3–5 themes such as:
- “Win on speed and reliability in delivery.”
- “Shift mix toward recurring revenue and services.”
- “Be visibly safer and more compliant than competitors.”
2. Ask ‘so what for how we operate?’
For each theme, ask:
- What does this imply for how we organize?
- What does it imply for how work should flow?
- What does it imply for technology, data, and capabilities?
3. Example:
- Theme: “Win on speed and reliability in delivery.”
- Implications might include: fewer handovers, clear journey ownership, real-time tracking, empowered front line to resolve issues.
4. Turn implications into principle-shaped sentences
Good design principles are:
- Short: one sentence each.
- Directional: they tilt decisions one way.
- Testable: you can ask, “Does option A or B better fit this principle?”
- Stable: they won’t change every quarter.
5. Weak principle: “We like automation and people.”
Strong principle: “Where tasks are repeatable and rules-based, we will prioritize automation over adding headcount.”
6. Prioritize and refine with the full leadership team
You want 5–10 principles, not 25. In a working session:
- Start from a draft set.
- Ask each executive: “Which three do you most care about?”
- Merge overlaps and remove vague or redundant ones.
- Resolve contradictions (e.g., “maximum local autonomy” vs. “high global standardization”).
By the end of this step, you should have a one-page design principles sheet that can be used to test any TOM design choice later in the process.
A quick quality check:
- Can you imagine saying each principle to a skeptical business leader and defending it in two sentences?
- Could a team, reading only these principles, make 70–80% of the same design choices you would?
If yes, you’re in good shape.
3.2 Identifying Critical Value Streams and Customer Promises
Strategy is ultimately delivered through a small number of end-to-end value streams—the major “pipes” through which you acquire customers, deliver products and services, and manage risk and resources.
Value streams (or journeys) typically sound like:
- “Acquire and onboard customer”
- “Design, price, and launch product”
- “Deliver order / fulfill service”
- “Service and retain customer”
- “Collect cash and manage credit risk”
Your TOM work will be much more effective if you explicitly identify the critical few value streams that matter most for your strategy.
A simple approach:
- Start from the P&L and strategy themes
Look at where revenue, cost, and risk are concentrated:- Which activities generate most of your revenue?
- Where is most of your operating cost?
- Where do the most serious risk events or customer complaints originate?
- This will usually point you to 3–7 priority value streams that deserve full TOM attention.
- Define each value stream at a high level
For each, write a 1–2 line description in plain language, for example:- “Lead to Cash”: from first contact with a prospect through quote, contract, delivery, invoicing, and payment.
- “Order to Delivery”: from order capture to final delivery and post-delivery confirmation.
- “Incident to Resolution”: from issue logging to root-cause fix and customer feedback.
- Resist the urge to break everything into 20 sub-streams at this stage. You want a manageable backbone, not a process encyclopedia.
- Clarify the customer and stakeholder promises
For each priority value stream, articulate the specific promises your strategy makes. These should be concrete enough that they can later be turned into operating requirements.
Example for “Lead to Cash”:- For mid-market customers, we commit to:
- Providing a qualified response to new inquiries within 4 business hours.
- Issuing standard quotes within 24 hours and complex quotes within 3 business days.
- Ensuring that the onboarding process can be completed digitally without branch visits.
- For mid-market customers, we commit to:
- These promises should reflect:
- Your competitive positioning (are you winning on speed, customization, price, reliability?).
- The segments that matter most to your strategy (flag where promises differ by segment).
- Link promises to potential operating requirements
Without fully designing the TOM yet, note the obvious implications:- If you promise 24-hour quotes, you will need:
- Clear process ownership.
- Standardized configurations and pricing rules.
- Sufficient capacity and decision rights closer to the front line.
- If you promise digital self-service onboarding, you will need:
- Fit-for-purpose digital channels and identity verification.
- Integrated data and workflows across risk, operations, and support.
- If you promise 24-hour quotes, you will need:
This step ensures that your TOM is being designed around real, explicit commitments to customers and stakeholders, not generic aspirations.
A quick checklist to test your work:
- Have you identified no more than 7–8 priority value streams at enterprise level?
- For each, can you name the primary customer or stakeholder and the core promise in one or two sentences?
- Do your promises reflect actual strategic differentiation, not just “faster, better, cheaper” across everything?
If not, refine before you move on. Otherwise your operating model will try to be “great at everything,” which in practice means great at nothing and expensive everywhere.
3.3 Defining Guardrails: Risk, Regulatory, and Other Non-Negotiables
Before you unleash teams to design their ideal future, you need to define guardrails: the constraints within which they can innovate.
Guardrails are not a bureaucratic exercise. When done well, they avoid repeated, unproductive arguments and prevent designs that will never be approved from consuming time and energy.
Sources of guardrails typically include:
- Regulation and law
- Licensing requirements, capital and solvency rules, data residency and privacy, market conduct obligations, labor law constraints, etc.
- Group-level policies and standards
- Risk appetite statements, information security policies, financial controls, approval limits.
- Existing strategic commitments
- Long-term outsourcing contracts, union agreements, public commitments to employees or customers, ESG pledges.
- Technology constraints
- Core platforms that will not be replaced within the TOM timeframe.
- Architectural standards (e.g., cloud strategy, integration patterns).
- Values and cultural red lines
- For example, commitments about not centralizing certain customer-facing decisions, or maintaining specific local capabilities.
The process to define guardrails is straightforward:
- Collect candidate guardrails
- Ask Risk, Legal, Compliance, HR, IT, and key business leaders to propose non-negotiables.
- Insist on specificity: “We must comply with GDPR” is obvious; what you need is the implication (e.g., “Customer personal data must be stored and processed only in approved regions; any data lake design must respect this.”).
- Challenge and refine
- Guardrails should be truly binding constraints, not preferences disguised as rules.
- For each proposed guardrail, ask:
- “Is this mandated by law/regulation/contract, or is it a choice we’ve made?”
- “Could we get an exemption or change it within the next 3–5 years if the value case were strong enough?”
- If the answer is yes, it might be a strong design preference, not a guardrail.
- Classify guardrails into ‘hard’ and ‘soft’
- Hard guardrails: cannot be breached in the TOM (e.g., segregation of duties requirements, certain capital or safety standards, hard regulatory boundaries).
- Soft guardrails: should normally be respected but can be overridden with explicit senior approval (e.g., preference for certain locations, vendor standards that could be revisited, internal policies that are not legally required).
- Translate guardrails into TOM-relevant language
Rather than listing regulations by name, phrase them in a way that is directly usable in design discussions:- Instead of: “We must follow regulation XYZ-123.”
- Say: “Any credit decision above €X must be independently approved by a second authorized person, separate from the originator, and this must be enforced systemically.”
- Limit the number of guardrails in the working set
- Aim for 10–20 well-phrased guardrails, grouped by theme (risk, regulatory, tech, people, commitments).
- Keep detailed legal and policy references in an appendix or link, not in the core TOM design pack.
A short test of guardrail quality:
- Can a design team, reading the list, quickly see what’s off-limits?
- Are there clear hard vs soft categories?
- Do the guardrails avoid prescribing the solution where not strictly necessary (e.g., “must be approved” vs. “must be approved in a physical meeting in this building”)?
With clear guardrails, your TOM design teams know where they have real freedom and where they do not—reducing both risk and wasted effort.
3.4 Strategy-to-TOM Cascade (Step-by-Step Guide)
With the building blocks in place, you can now structure the overall strategy-to-operating-requirements cascade. This is the repeatable path your leadership team can follow whenever you refresh the TOM.
A practical step-by-step sequence:
Step 1: Confirm the strategy and value agenda
- Reconfirm the strategic direction, target segments, and value proposition.
- Re-state the value agenda in operational terms (e.g., “+X% growth from these segments,” “–Y% structural cost,” “reduction of risk losses by Z%,” etc.).
- You are not re-doing strategy; you are aligning your TOM work with what has already been agreed.
Step 2: Identify 3–5 strategic themes
- Condense the strategy into a small set of themes like:
- “Digital-first customer engagement.”
- “Platform-based operations.”
- “Capital-light growth in emerging markets.”
- These themes are the hooks on which you will hang operating implications.
Step 3: Draft and agree design principles
- For each theme, derive operating implications and convert them into design principles (Section 3.1).
- Review as an executive team:
- Combine overlaps.
- Remove weak or generic statements.
- Resolve contradictions.
- Finalize a set of 5–10 principles and capture them on one page.
Step 4: Map the critical value streams
- Identify the 3–7 end-to-end value streams that:
- Drive most revenue or margin.
- Are central to your differentiation.
- Represent major risk or regulatory exposure.
- Assign a provisional owner for each stream (this will matter later when you define journey ownership).
Step 5: Articulate customer/stakeholder promises per stream
- For each priority value stream, specify:
- Who the main customer or stakeholder is (segment, region, channel).
- The explicit promises you are making on:
- Speed (e.g., response times, lead times).
- Quality (e.g., error rates, rework, reliability).
- Experience (e.g., self-service, omnichannel continuity).
- Keep it concrete enough to guide future SLAs and capacity planning, but not yet down to detailed metrics for every micro-step.
Step 6: Convert promises into high-level operating requirements
- For each value stream and promise, capture the key requirements:
- Process: what must be standardized, simplified, or re-sequenced.
- Organization: where clear ownership is needed; where silos must be bridged.
- Technology and data: which capabilities are essential (e.g., workflow, integration, analytics).
- People and skills: which new roles or capabilities you will need.
This is often best done in a series of focused working sessions with the leaders who own those streams today.
Step 7: Define and agree guardrails
- Synthesize risk, regulatory, and other non-negotiables into a short, clear guardrails list (Section 3.3).
- Confirm with Risk, Legal, Compliance, and IT that:
- The list is accurate and complete at the level needed.
- Hard vs soft constraints are properly distinguished.
- Validate with the executive team that guardrails are tight enough to be safe, but not so tight that they make change impossible.
Step 8: Assemble the TOM Design Brief
Bring everything together into a concise TOM Design Brief—the document that officially kicks off detailed design.
Typical contents:
- One page: Strategy and value agenda
- Strategic themes, priority segments, top-level value targets.
- One page: Design principles
- 5–10 clear, directional principles.
- One to two pages: Priority value streams and promises
- List of streams, with short descriptions.
- Customer/stakeholder promises per stream.
- One page: Guardrails
- Grouped list of hard and soft constraints.
- One page: High-level operating requirements
- Summary of implications for processes, organization, technology, and capabilities.
This brief is what you will give to TOM workstreams, design squads, or external partners. Its purpose is to ensure that everyone is solving the same problem, within the same boundaries, with the same definition of success.
A simple final check before you move on:
- Can every member of your leadership team explain the TOM design brief in 10 minutes to their own teams without altering the intent?
- If you gave this brief to a strong external team (consultants, independent experts, or internal transformation leaders), would they:
- Know what to design.
- Understand the constraints.
- See how success will be measured.
If the honest answer is yes, you have done the hard upfront work properly. You are now ready to move into current-state mapping and detailed design with a clear line of sight from strategy to operating requirements.
