Design Through a Design-Thinking Lens:
Designing a Target Operating Model (TOM) begins with a simple but profound shift: we stop treating the operating model as a static blueprint and start experiencing it as the lived reality of customers, employees, and partners. In a business environment defined by speed, ambiguity, and constant change, organizations need operating models that translate strategy into everyday action. Leaders need models that are intuitive to navigate, resilient under stress, and capable of evolving without losing coherence. Design thinking offers exactly that: a human‑centered approach that builds TOMs around real needs, tests ideas early, and scales only what works.
At its core, a TOM is the company’s way of delivering value. It connects why the organization exists with how it operates: the services it provides, the processes it runs, the roles people play, the data and technology that enable them, the way decisions get made, and the measures and forums that keep everything aligned. Traditional TOM programs often begin with boxes and lines: org charts, process flows, technology stacks. But when we put people and experiences first, the operating model becomes more than a design artifact; it becomes a system of outcomes shaped by journeys, capabilities, and feedback loops.
The journey typically starts with empathy. We spend time with those who experience the operating model daily: customers navigating a service, employees trying to get work done, leaders making trade‑offs, and partners who rely on our clarity and cadence. Through interviews, observations, and journey mapping, we uncover pain points that cut across silos, handoffs that create friction, decisions that get made twice, reports that don’t answer the questions people actually have. Just as importantly, we identify the moments that matter: where a single improvement in experience can multiply across processes and teams. This stage isn’t about collecting anecdotes; it’s about seeing patterns and translating them into opportunity.
With those insights in hand, we define the problems we truly need to solve and the principles that will guide how we solve them. These principles act as a North Star: “automation first,” “one source of truth,” “risk by design,” “customer-in, employee-through.” They prevent us from falling in love with tools or org structures too early and keep the team anchored to outcomes rather than outputs. We articulate the success criteria clearly: what will change for customers, what will become easier for employees, what metrics must move, and what risks must be controlled from the day one.
Then comes ideation, which is not as a free‑for‑all brainstorming session, but as a disciplined exploration of viable options. Cross‑functional teams sketch and compare different operating model patterns: centralized services where scale matters, federated models where proximity and context are critical, centers of excellence where specialized knowledge compounds, or hybrids that balance autonomy with standardization. We rethink end‑to‑end processes through the lens of experience and flow: removing redundant steps, embedding controls into the workflow, and making data the connective tissue. Ideas evolve from concepts into tangible options with pros, cons, and measurable trade‑offs.
Prototyping turns those options into something the organization can actually touch. We build just enough to learn: a draft service catalogue that clarifies what we do and for whom; a process blueprint that overlays controls and data points; a RACI sketch that tests accountability; a technology reference architecture that reveals integration needs; a simple workflow simulation that shows where a delay will occur. Instead of betting the program on a massive rollout, we run safe‑to‑fail pilots that surface issues early, validate value hypotheses, and de‑risk scaling. Prototypes don’t need to be perfect; they need to be truthful enough to teach us something.
Testing and iteration complete the loop. We measure what matters for the company: cycle time, right‑first‑time rates, cost to serve, control effectiveness, adoption, time‑to‑competence and we listen carefully to feedback. We learn what works in one context and what must be adapted in another. The point isn’t to arrive at a single, finished design; it’s to establish an operating model that can learn. Governance becomes a cadence of course corrections rather than a compliance checkpoint. Benefits tracking shifts from a retrospective tally to a living scorecard, potentially reviewed monthly and recalibrated quarterly.
The impact of a design‑thinking approach leads TOM is both practical and cultural. Processes become simpler and more reliable because they are designed around actual user journeys and informed by data. Automation finds its right place, it augments work, not complicates it. Teams collaborate across boundaries because the operating model clarifies decision rights and creates shared goals. Risk management improves because controls are embedded into processes and systems rather than layered on top. Above all, the organization becomes more agile, able to adjust service models, roles, and technology enablement as conditions change without losing its strategic throughline.
It’s important to acknowledge the pitfalls. Technology can seduce teams into solutioning too soon, before problems are truly understood. Over‑engineering can creep in, adding complexity under the banner of completeness. Vague accountability can undo the best designs if decision rights aren’t explicit and tested in pilots. Change management, when underfunded, turns even good designs into shelfware. And without canonical data models and integration patterns agreed up front, measurement and automation stall. The antidotes are simple in principle and demanding in practice: start with people and principles, prototype quickly, measure relentlessly, and invest in change as a first‑class workstream.
The approach scales across functions. In Finance, it reshapes period‑end activities and enables self‑service analytics. In HR, it refocuses on moments that matter and builds a skills‑based organization. Supply chains gain visibility through integrated planning and control towers. Customer operations orchestrate omnichannel workflows with knowledge at the core. Compliance and risk functions move toward continuous monitoring with automated evidence. The same logic applies to specialized domains such as Tax, where data lineage, scenario modeling, and regulatory confidence are paramount; the TOM simply emphasizes those dimensions more strongly.
A practical way to start is small and serious. In the first week, map stakeholders and journeys and establish baseline metrics. In the second, synthesize insights, define problem statements, and set design principles. In the third, convene ideation sessions and narrow to a few high‑value options with clear business cases. In the fourth, prototype the essentials: service catalogue, process blueprint, roles, and data/technology enablers. Over the following two weeks, run pilots, measure outcomes, iterate, and present a one‑page TOM canvas with a wave plan and benefits model. This cadence creates momentum and evidence, not just documentation.
Ultimately, the Target Operating Model is not a destination; it is a disciplined way of aligning strategy with everyday execution. Design thinking brings that discipline to life—grounded in empathy, animated by creativity, and steered by evidence. When organizations adopt this mindset, they don’t just redesign processes or redraw boxes; they craft operating systems for value creation that can evolve with their markets and their people. In a world where change is the only constant, that may be the most sustainable advantage of all.
