LEADERSHIP / PLAYBOOK 02 / OPERATING MODEL · DECISION RIGHTS · VALUE STREAMS
From business value to digital results
A playbook for a design-led product operating model. A strong digital operating model does
more than coordinate product, design, and engineering. It creates a repeatable way to
translate business strategy into customer value, invest in the capabilities with the
greatest leverage, manage risk before it becomes expensive, and measure whether the
resulting experience changes customer behaviour.
USE WHEN
Design work arrives as a queue of requests, decision rights are implicit, or roadmaps
overinvest in visible features and underinvest in capabilities
HORIZON
A 90-day implementation, then a quarterly review of the operating model itself
WHO IT IS FOR
Design, product and engineering leaders building one operating model across value
streams
CORE ARTIFACTS
Value-driver map · Visual Roadmap · UX architecture · Capability portfolio ·
Decision-rights map · Product scorecard
THE MODEL CONNECTS SEVEN ACTIVITIES
Better decisions, not more process.
The purpose of the model is not to introduce more process. It is to improve the quality
and speed of decisions throughout the product lifecycle. Each activity feeds the next,
and measured results return to reshape business priorities.
01
Business priorities
02
Product strategy
03
Capability investments
04
Experience direction
05
Delivery
06
Market activation
07
Measured results
01 / VALUE FRAME
Establish the business value frame.
Before prioritizing features, leadership must agree on how the digital experience is
expected to create value. For each driver, define the business result being sought, the
customer behaviour that would produce it, the experience or platform capabilities
required, the evidence that would demonstrate progress, and the executive owner
accountable for the result. This becomes the value frame against which product
opportunities and investments are evaluated.
BUSINESS VALUE DRIVER
CONTRIBUTION OF THE DIGITAL EXPERIENCE
EXAMPLE MEASURES
Competitive advantage
Create differentiated capabilities and workflows that are difficult to replicate
Win rate, preference, market share, feature differentiation
Brand expression
Turn the brand promise into recognizable behaviours across digital touchpoints
Trust, satisfaction, brand perception, consistency
Growth and activation
Help prospective and new customers reach value quickly
Conversion, activation, onboarding completion, time to value
Adoption and engagement
Make important workflows easier and more valuable to use
Active use, task completion, workflow frequency, retention
Customer expansion
Help customers discover and adopt capabilities that deliver greater value
Feature penetration, upgrades, cross-sell, revenue per customer
Operational efficiency
Reduce manual work, errors, support demand, and duplicated effort
Cost to serve, processing time, support volume, error rate
Risk management
Support security, accessibility, compliance, reliability, and customer confidence
Incidents, audit results, accessibility conformance, failure rate
01
The business result
being sought.
02
The customer behaviour
that would produce that result.
03
The capabilities
of experience or platform that are required.
04
The evidence
that would demonstrate progress.
05
The executive owner
accountable for the result.
02 / EXPERIENCE DIRECTION
Translate strategy into product and experience direction.
Product strategy should make clear choices about where the organization will compete,
whom it will serve, which problems it will solve, and which capabilities will create an
advantage. Design contributes by making the strategy tangible through two complementary
tools: the Visual Roadmap and the UX architecture.
A USEFUL PRODUCT STRATEGY DEFINES
Target customers and priority segments.
Important customer jobs, needs, and circumstances.
The business outcomes the product must influence.
The product's intended position in the market.
Experience principles that express the brand.
The capabilities required to deliver the strategy.
Areas the organization will intentionally not pursue.
Assumptions that still require validation.
TOOL 1 / THE VISUAL ROADMAP
A compelling view of the future experience.
The Visual Roadmap connects individual initiatives into a coherent journey and helps
stakeholders understand how near-term delivery contributes to a larger destination.
Unlike a feature roadmap, it illustrates:
How the customer experience will evolve.
Which customer problems will be addressed.
How capabilities build on one another.
Where important dependencies exist.
What the organization expects to learn at each stage.
How the experience supports business outcomes.
It should be updated when market evidence, customer behaviour, technology constraints, or strategic priorities change.
TOOL 2 / THE UX ARCHITECTURE
Freedom within a shared system.
The UX architecture defines the structural model that allows experiences created by
different teams to function as one product. It prevents local feature decisions from
fragmenting the overall experience. It should cover:
Platform navigation and information architecture.
Workspaces organized around customer roles and jobs.
Core domain objects and their relationships.
End-to-end workflows that cross product boundaries.
Shared interaction and content patterns.
Permissions, roles, and access models.
Integration points between product areas.
Responsive, accessible, and multilingual behaviour.
Experience principles and architectural constraints.
03 / CAPABILITY INVESTMENT
Prioritize outcomes and enabling capabilities.
Roadmaps often overinvest in visible features while underinvesting in the capabilities
required to deliver them effectively. The scorecard informs judgment; it should not
replace it. Leadership still needs to make explicit choices about which outcomes matter
most and what the organization is willing to defer.
CORE CAPABILITIES MAY INCLUDE
Identity, permissions, and customer profiles.
Navigation, search, and workspace models.
Design systems and reusable UX patterns.
Content management and localization.
Accessibility infrastructure.
Analytics and product instrumentation.
Experimentation and feature management.
Customer feedback and research operations.
Shared data, workflow, and integration services.
ASSESS EACH INVESTMENT AGAINST A COMMON SCORECARD
01
Business value
Which strategic outcome could it improve?
02
Customer reach
How many customers, segments, or journeys benefit?
03
Customer impact
How significantly does it improve the experience?
04
Strategic fit
Does it strengthen the intended market position?
05
Capability leverage
How many teams or initiatives will it enable?
06
Risk reduction
What operational, technical, or market risk does it reduce?
07
Confidence
How strong is the available evidence?
08
Cost and complexity
What investment, dependency, and change are required?
04 / TEAM TOPOLOGY
Organize work around value streams.
Design capacity should be organized around persistent sources of customer and business
value rather than a queue of disconnected requests. A practical topology includes four
types of teams. Designers can remain embedded in value streams while participating in a
centralized design practice, which preserves product context while maintaining craft
standards, professional development, shared methods, and architectural coherence.
Value-stream teams
Cross-functional teams responsible for a customer journey or business outcome.
Product, design, engineering, data, and relevant business partners work together over
time.
Platform and capability teams
Teams responsible for shared services such as identity, navigation, data, workflow
infrastructure, analytics, and experimentation.
Experience-system teams
Teams responsible for the design system, UX architecture, shared interaction patterns,
accessibility, content standards, and contribution governance.
Enabling teams
Specialists in research operations, content design, service design, analytics,
accessibility, and design operations who increase the effectiveness of other teams.
Staffing should reflect the amount of uncertainty, customer risk, coordination, and decision-making in a value stream, not simply the number of engineers assigned to it.
05 / DECISION RIGHTS
Define decision rights.
Effective collaboration requires clarity about who makes which decisions. Disagreements
should be resolved by the leader accountable for the disputed decision domain. Material
trade-offs and accepted quality risks should be recorded rather than left implicit.
DECISION
ACCOUNTABLE LEADER
REQUIRED CONTRIBUTORS
Business outcomes and investment envelope
Business or executive sponsor
Product, design, engineering, finance
Product strategy and roadmap priorities
Product leader
Design, engineering, data, business
Customer problem definition and research quality
Design leader
Product, research, data, customer-facing teams
Experience principles and UX architecture
Design leader
Product, engineering, content, accessibility
Technical architecture and engineering feasibility
Engineering leader
Product, design, security, operations
Initiative outcome and scope
Product owner
Design and engineering leads
Interaction and visual quality
Design lead
Engineering, product, content
Release readiness
Product owner
Design, engineering, operations, marketing
Go-to-market strategy and communication
Marketing or product marketing
Product, design, sales, support
Post-launch investment decision
Product leader
Design, engineering, data, business sponsor
Product
Owns the outcome, priority, and business trade-offs.
Design
Owns customer understanding, experience coherence, usability, and design quality.
Engineering
Owns technical integrity, feasibility, security, performance, and operability.
The product, design, and engineering triad operates as the primary decision-making unit. It jointly owns solution direction, delivery confidence, and measured results.
06 / INITIATIVE LIFECYCLE
Use a consistent initiative lifecycle.
Every roadmap initiative should move through the same sequence of questions, although
the depth of work should be proportional to its uncertainty and risk.
01
Frame the opportunity
Clarify the business goal, the target customer, their jobs, needs and concerns, the
current experience and available evidence, alternative solutions or behaviours,
market position and competitive context, constraints, dependencies and non-goals,
and the expected behavioural and business outcomes. The result is an initiative
brief, not a predetermined feature specification.
02
Form the hypothesis
Express the initiative as a testable proposition and document the assumptions that
must be true for it to succeed.
03
Explore alternatives
Consider multiple solution directions before committing to implementation. Evaluate
them against customer value, strategic fit, UX architecture, feasibility,
differentiation, and cost.
04
De-risk the concept
Test the most consequential assumptions first: desirability, comprehension,
operational readiness, technical feasibility, data availability, regulatory
constraints, or commercial viability.
05
Design and deliver
Translate the chosen direction into coherent workflows, states, content,
specifications, analytics events, accessibility requirements, and reusable patterns.
Design and engineering collaborate throughout implementation rather than
transferring work through a one-time handoff.
06
Verify quality
Review the developed experience in its actual environment. Validate behaviour across
realistic data, roles, devices, languages, accessibility settings, errors, loading
states, and edge cases.
07
Activate and learn
Treat release as the beginning of market validation. Support customers in
discovering the capability, reaching value, and incorporating it into their
behaviour.
THE HYPOTHESIS
We believe that providing this capability to this audience in this context will
produce this customer behaviour, contributing to this business result. We will know
this is true when these measures change.
07 / VALIDATION
Validate at the moments that matter.
Validation should increase confidence as the cost of reversing a decision increases.
Each stage needs predefined success thresholds, monitoring, and an explicit decision.
Validation should produce a change in direction, confidence, scope, or investment, not
merely a report.
CHECKPOINT
QUESTION
EVIDENCE
TYPICAL AUDIENCE
DECISION
Direction
Are we solving a strategically important problem?
Strategy review, market evidence, customer research
Leaders, stakeholders, representative customers
Proceed, revise, or stop
Risky assumptions
What must be true for this to work?
Interviews, concept tests, data analysis, experiments
Small target sample
Continue, adapt, or test further
Design viability
Does the concept create meaningful customer value?
Prototypes, journey evaluation, value testing
Target users and product partners
Select or revise direction
Feasibility
Can it be built, operated, secured, and supported?
Technical spikes, architecture review, operational assessment
Engineering and control partners
Commit, constrain, or redesign
Usability and accessibility
Can intended users complete important tasks?
Usability testing, accessibility evaluation
Representative users
Refine or approve
Design quality
Does the implementation meet the intended experience?
Design QA, responsive review, coded-product testing
Design and engineering
Fix, accept debt, or release
Communication readiness
Will customers understand and discover the change?
Message testing, support review, launch rehearsal
Customers and internal channels
Improve or activate
Limited release
Does it work for a real customer cohort?
Alpha or beta telemetry, feedback, support signals
Selected target audience
Expand, revise, or withdraw
General availability
Is it delivering value at scale?
Adoption, engagement, retention, operational and business metrics
All eligible customers
Invest, optimize, maintain, or retire
SAMPLE SIZES SHOULD GROW WITH CONFIDENCE AND EXPOSURE
01
Internal validation
02
Selected customers
03
Representative cohort
04
Staged rollout
05
General availability
08 / GOVERNANCE
Govern design execution without slowing delivery.
Governance should create a reliable path to quality, not a centralized approval queue.
The design leader is accountable for maintaining these practices, but quality is a
shared responsibility across product, engineering, and design.
Product and experience direction review
Evaluates alignment with product strategy, business value, customer evidence, and
the Visual Roadmap.
UX architecture review
Evaluates navigation, workflows, information models, roles, and cross-product
coherence.
Design-system contribution review
Determines whether new patterns should be reused, extended, contributed to the
shared system, or treated as intentional exceptions.
Implementation review
Design and engineering inspect the working product during development, not only
before release.
Experience acceptance
Confirms that critical usability, accessibility, content, responsive, and
interaction requirements have been met. Exceptions receive an owner, rationale,
remediation date, and measurable risk.
Outcome review
Compares the original hypothesis with post-release evidence and determines the next
investment decision.
09 / MARKET ACTIVATION
Make go-to-market part of the experience.
A feature that ships but is not understood, discovered, or adopted has not delivered its
intended value. Design should contribute to product communication across every channel,
ensuring that the experience promised by marketing is consistent with the experience
delivered by the product.
FOR EACH MEANINGFUL RELEASE
Develop an activation plan covering ten elements.
01
Target customers and eligibility.
02
Customer value proposition.
03
Product positioning and differentiated benefits.
04
In-product discovery and onboarding.
05
Marketing, sales, service, and support communication.
06
Training and enablement.
07
Feedback channels.
08
Instrumentation of key workflows.
09
Rollout stages and exit criteria.
10
Expected activation, adoption, and engagement behaviour.
10 / MEASUREMENT
Measure the complete value-delivery system.
The operating model should be evaluated through a balanced scorecard. Metrics should be
interpreted together. High feature adoption accompanied by poor task success, support
growth, or low retention is not a successful result.
BUSINESS RESULTS
Revenue growth or retention
Conversion and customer expansion
Cost to serve
Operational efficiency
Risk reduction
Market preference or competitive performance
CUSTOMER OUTCOMES
Task success and completion
Time to value
Customer effort
Satisfaction and trust
Error and abandonment rates
Accessibility and inclusion
Resolution of priority customer jobs
ADOPTION & ENGAGEMENT
Awareness among eligible customers
Activation of the intended workflow
Breadth of adoption across accounts or roles
Depth and frequency of use
Repeat use and retention
Progression to higher-value capabilities
DELIVERY EFFECTIVENESS
Time from opportunity framing to evidence
Time from validated direction to release
Rework introduced after development begins
Blocked work and dependency delays
Initiatives with defined outcomes and instrumentation
Decisions supported by customer evidence
DESIGN QUALITY
Usability success on critical workflows
Accessibility conformance
Design defects before and after release
Consistency across product areas
Quality debt and time to remediation
Alignment between intended and implemented experience
CAPABILITY LEVERAGE
Adoption of shared components and patterns
Teams enabled by a core capability
Reduction in duplicated design and engineering effort
Speed of delivering common workflows
Contribution and exception rates
Time redirected from rebuilding foundations to customer-value work
11 / OPERATING CADENCE
Establish an operating cadence.
These forums should make decisions. Status reporting should be automated or handled
asynchronously wherever possible.
CADENCE
PURPOSE
Annual or semi-annual
Refresh business value drivers, product strategy, UX architecture, and future vision
Quarterly
Select outcome priorities, capability investments, capacity allocation, and major
hypotheses
Monthly
Review portfolio evidence, dependencies, quality risks, and outcome performance
Biweekly
Review product direction, customer evidence, and cross-product experience decisions
During delivery
Conduct design-engineering reviews of working software
Before release
Confirm experience quality, instrumentation, communication, and operational readiness
After release
Review early signals, target-audience feedback, adoption, and business outcomes
Quarterly operating-model review
Improve roles, practices, governance, staffing, metrics, and decision speed
12 / SHARED ARTIFACTS
Maintain a small set of shared artifacts.
The operating model can be supported with a concise set of living artifacts. Each
artifact should have an owner, audience, review cadence, and decision it supports. If an
artifact does not improve a decision, it should be simplified or removed.
01
Business value-driver map
02
Product strategy
03
Visual Roadmap
04
UX architecture
05
Capability investment portfolio
06
Initiative brief
07
Assumption and risk map
08
Experiment and validation plan
09
Experience specification
10
Design-system contribution or exception record
11
Launch and activation plan
12
Product scorecard
13
Outcome review and decision log
13 / QUARTERLY REVIEW
Periodically review the operating model itself.
At least quarterly, leadership should assess whether the system is improving value
delivery. The output should be a short set of operating changes: practices to
strengthen, processes to remove, capability investments to increase, and ownership gaps
to resolve.
01
Are the highest-value problems receiving sufficient investment?
02
Are enabling capabilities reducing duplication and accelerating teams?
03
Are product, design, and engineering involved early enough?
04
Are decision rights understood?
05
Are risky assumptions being tested before major commitments?
06
Is evidence changing product decisions?
07
Is design quality improving in the released product?
08
Are customers discovering and adopting new value?
09
Are metrics connected to investment decisions?
10
Which reviews, artifacts, or dependencies create unnecessary delay?
11
Does team topology still match the organization's value streams?
IMPLEMENTATION
A practical 90-day implementation.
Establish the baseline, pilot the model on one important value stream, then scale the
practices and adjust team structure and investment according to the first evidence.
DAYS 1–30
Establish the baseline
Align leaders on business value drivers.
Map current initiatives to customer and business outcomes.
Inventory core capabilities and experience debt.
Document decision rights and escalation paths.
Baseline delivery, quality, adoption, and outcome measures.
DAYS 31–60
Pilot the model
Select one important value stream.
Establish its product-design-engineering triad.
Create the initiative brief, hypotheses, Visual Roadmap, and relevant UX
architecture.
Introduce progressive validation checkpoints.
Instrument the intended customer behaviours and business outcomes.
DAYS 61–90
Scale the practices
Apply the model to additional value streams.
Establish experience-system and capability ownership.
Launch the portfolio, architecture, quality, and outcome reviews.
Publish the shared scorecard.
Adjust team structure and investment according to the first evidence.
THE INTENDED RESULT
Traceability from strategy to customer behaviour.
A mature product operating model creates traceability from strategy to customer behaviour. Every significant investment supports a defined business value driver. Every initiative addresses a meaningful customer problem. Every solution is tested in proportion to its risk. Every release is evaluated for quality, adoption, and results. Every insight informs the next investment decision.
In this model, design is not a service added after product decisions are made. It is a leadership function that helps determine where to compete, makes strategy tangible, reduces uncertainty, protects experience coherence, improves execution quality, and demonstrates whether digital investment is delivering meaningful value.
NEXT / PLAYBOOK 03
Grow the team behind the operating model
Continue reading
Discuss a design-led product operating model
Start a conversation