Leadership, Facilitation and Organisational Adoption

Introduction

Design thinking is often presented as a sequence of activities—research, ideation, prototyping and testing. In professional product management, however, its success depends less on the sequence than on the conditions under which people collaborate. A technically sound workshop can fail when decision rights are unclear, senior stakeholders dominate discussion, evidence is dismissed, or delivery teams are excluded from discovery. Conversely, a modest workshop can create substantial value when it is well facilitated, psychologically safe and connected to organisational decision-making.

This chapter examines the leadership work required to make design thinking consequential. It focuses on five connected capabilities: leading multidisciplinary workshops, managing conflict and stakeholder power, communicating design evidence, building psychological safety and design maturity, and integrating design thinking with Agile delivery and digital transformation. The chapter treats design leadership not as charismatic direction but as the deliberate design of conditions in which teams can learn, decide and act.

Learning objectives

By the end of this chapter, the reader should be able to:

1. Design and facilitate inclusive, outcome-oriented multidisciplinary workshops.
2. Distinguish productive task conflict from destructive relationship or process conflict.
3. Analyse stakeholder power, interest and influence without reducing engagement to a simplistic matrix.
4. Communicate qualitative and quantitative design evidence with appropriate claims and limitations.
5. Establish psychological safety while preserving accountability and high standards.
6. Assess design maturity and formulate practical adoption strategies.
7. Connect discovery, experimentation and user learning with Agile planning and delivery.
8. Evaluate ethical, governance and organisational risks associated with design-led transformation.

1. Design leadership as an organisational capability

Design leadership is the practice of shaping direction, participation and learning so that an organisation can solve meaningful customer and organisational problems. It includes conventional leadership activities—setting priorities, allocating resources and making decisions—but also less visible activities such as framing questions, protecting dissent, making evidence legible and creating feedback loops.

A product manager frequently operates without direct authority. Influence is therefore achieved through four mechanisms:

• Purpose: clarifying why the problem matters and for whom.
• Process: creating a credible method for inquiry and decision-making.
• Evidence: connecting claims to observations, experiments, behavioural data or operational facts.
• Relationships: building trust across functions and levels of hierarchy.

A useful distinction is between designing an artefact and designing the system around the artefact. The first concerns the product experience. The second concerns incentives, governance, workflows, technology, metrics and behaviours that determine whether the experience can be delivered and sustained.

Design leadership also involves stewardship. Leaders must prevent design thinking from becoming a ritual in which sticky notes substitute for research, voting substitutes for judgment, and prototypes create an illusion of certainty. The purpose of facilitation is not consensus at any cost; it is informed commitment to a testable course of action.

2. Leading multidisciplinary workshops

2.1 Workshop architecture

A workshop is a temporary decision and learning environment. Its quality should be judged by the quality of its outputs and subsequent action, not by energy during the session. Before inviting participants, the facilitator should specify:

• the decision or learning objective;
• the problem boundary and relevant constraints;
• participants and their roles;
• evidence that will be available;
• activities and timeboxes;
• decision rights;
• expected outputs;
• how outputs will enter product planning.

A strong workshop objective is observable. “Understand the customer” is too broad. “Identify and prioritise three barriers preventing first-time users from completing account verification” is more actionable.

The facilitator should distinguish divergent activities, which expand the range of possibilities, from convergent activities, which narrow options using explicit criteria. Premature convergence often occurs when the first plausible solution is discussed before the problem has been adequately understood. Endless divergence occurs when the team avoids commitment by generating more ideas.

2.2 Roles and decision rights

Participants should know whether they are contributing expertise, representing a user group, making a decision or implementing an outcome. A simple responsibility arrangement can prevent later conflict:

The decision owner need not facilitate. Separating these roles reduces the risk that participants interpret facilitation as advocacy for a predetermined answer.

2.3 A practical workshop sequence

A typical problem-framing and concept-selection workshop may follow this pattern:

1. Opening and contract: state purpose, agenda, decision rights and participation norms.
2. Shared evidence: present research excerpts, behavioural data, service constraints and known uncertainties.
3. Sensemaking: allow individuals to review evidence before group interpretation.
4. Problem framing: formulate opportunity statements or “How might we?” questions.
5. Divergence: generate alternatives individually and collectively.
6. Clarification: group similar ideas without judging them prematurely.
7. Evaluation: apply explicit criteria such as customer value, feasibility, viability, accessibility and strategic fit.
8. Decision and experiment design: select options, identify assumptions and define the next test.
9. Close: record owners, dates, dependencies and unresolved dissent.

Individual reflection before group discussion is important because it reduces anchoring and gives less vocal participants time to formulate views. Silent brainstorming, written critiques and round-robin reporting are practical tools, but they should not be applied mechanically. Accessibility needs, cultural norms and remote participation arrangements must be considered.

2.4 Facilitation techniques

Effective facilitation involves active observation. The facilitator monitors who speaks, whose ideas receive uptake, which assumptions remain unexamined and whether the group is solving the stated problem. Useful interventions include:

• “What evidence supports that assumption?”
• “We have heard two views. What would make each view more or less likely?”
• “Let us separate the customer desirability question from the implementation question.”
• “I am recording this as a risk rather than resolving it by opinion.”
• “Before we move on, I would like to hear from people who have not spoken.”

The facilitator should distinguish equal airtime from equitable participation. Equal airtime may be inappropriate when expertise differs, whereas equitable participation ensures that status, confidence, language or remote access do not silence relevant knowledge.

3. Conflict, power and stakeholder alignment

3.1 Productive and destructive conflict

Conflict is not inherently harmful. Task conflict concerns alternative interpretations, priorities or solutions and can improve decisions when evidence and respect are present. Relationship conflict involves personal distrust, status threats or identity-based antagonism. Process conflict concerns roles, resources, timing and decision procedures. Any of these can become destructive when it is personalised or left implicit.

The facilitator should not suppress disagreement in pursuit of superficial harmony. Instead, disagreement should be made specific and testable. “Engineering will never support this” is a generalised position. “The proposed identity flow requires an integration that is unavailable until the next platform release” is a constraint that can be investigated.

A useful conflict sequence is:

1. Identify the issue without attributing motives.
2. Clarify each party’s interests, assumptions and constraints.
3. Separate facts, interpretations, preferences and fears.
4. Identify the decision criterion or evidence that would resolve the issue.
5. Generate options, including a low-cost experiment.
6. Record the decision, owner and conditions for revisiting it.

3.2 Stakeholder power

Stakeholders possess different forms of power. Formal authority derives from role or governance. Resource power derives from control of budget, people or infrastructure. Expertise power derives from specialised knowledge. Network power derives from relationships and reputation. Coercive or gatekeeping power may arise when a group can block access, approval or implementation. Users and frontline workers may have little formal power but high experiential knowledge.

A stakeholder map is useful only when it informs behaviour. A conventional interest–influence grid can be supplemented with questions such as:

• Who can approve, block or delay the work?
• Who bears the consequences if the product fails?
• Whose knowledge is routinely ignored?
• Who can mobilise support or resistance informally?
• Which groups are affected but absent from the room?

The product manager should avoid treating high-power stakeholders as the only legitimate audience. A responsible engagement strategy gives decision-makers the information they need while ensuring that marginalised or less powerful users are represented through research, accessibility review and service evidence.

3.3 Alignment without false consensus

Alignment means that participants understand the decision, rationale, implications and next steps. It does not mean that everyone prefers the outcome. A decision log should record:

• the decision;
• alternatives considered;
• evidence and assumptions;
• the decision owner;
• dissenting concerns;
• review conditions and date.

This practice prevents “decision amnesia,” in which teams later revisit settled questions because the original reasoning was not visible. It also creates accountability without requiring every participant to agree.

4. Communicating design evidence

4.1 Evidence is an argument, not a decoration

Design evidence becomes influential when it connects a claim to a method, observation and implication. A concise evidence statement has four parts:

1. Claim: what appears to be happening.
2. Basis: how it was learned.
3. Strength and limitation: how confidently it can be generalised.
4. Implication: what decision or experiment follows.

For example: “In eight moderated sessions, six participants misunderstood the recovery step. This indicates a comprehension problem in this task context, but it does not estimate prevalence across the entire customer base. We should test clearer language with a larger sample and monitor completion behaviour.”

This is stronger than “Users hate the recovery flow,” which overstates the evidence and offers no decision path.

4.2 Qualitative and quantitative evidence

Qualitative research is valuable for understanding meanings, motivations, workarounds and failure mechanisms. It is not automatically representative. Quantitative data can estimate frequency, variation and behavioural change, but it may not explain why behaviour occurs or reveal people excluded from the measurement system.

A product decision may combine:

• interview and observation data;
• usability findings;
• support contacts and operational data;
• funnel or retention measures;
• experiment results;
• accessibility and inclusion assessments;
• technical and regulatory constraints.

When comparing an outcome before and after an intervention, the absolute change is:

The relative percentage change, when the baseline is non-zero, is:

Here, “value” must refer to the same defined metric, population and measurement period. These calculations describe change; they do not by themselves establish causation. Seasonality, concurrent releases, selection effects and changes in measurement may explain part of the difference.

4.3 Communicating to different audiences

Executives often need the decision, strategic relevance, risk and resource implications. Engineers need constraints, edge cases, dependencies and testable acceptance conditions. Designers need user evidence and experience implications. Operations teams need process impact, training and exception handling. Regulators or risk teams may need traceability, fairness analysis and controls.

The underlying evidence should remain consistent, but the representation should vary. A good evidence narrative moves from problem significance to observed behaviour, interpretation, options, uncertainty and recommended action. It does not hide inconvenient findings to secure approval.

5. Psychological safety and accountability

Psychological safety is a shared belief that a team can take interpersonal risks—such as asking questions, admitting uncertainty or reporting mistakes—without humiliation or retaliation. It is not comfort, permissiveness or the absence of performance standards. A psychologically safe team can challenge a senior stakeholder and still be expected to deliver high-quality work.

Leaders build safety through observable behaviour:

• asking for disconfirming evidence;
• acknowledging their own uncertainty and errors;
• responding appreciatively to bad news;
• criticising ideas and processes rather than identities;
• making speaking-up channels available beyond the meeting;
• protecting dissent from retaliation;
• following through on reported risks.

Safety must be paired with accountability. Teams need explicit quality standards, owners, deadlines and escalation paths. Otherwise, “safety” may become an excuse for avoiding difficult feedback. Conversely, accountability without safety produces concealment, defensive reporting and local optimisation.

A useful workshop norm is: “Make the work discussable.” This means surfacing assumptions, ethical concerns, technical debt, accessibility failures and evidence gaps early enough to act on them.

6. Building design maturity and organisational adoption

Design maturity describes the extent to which an organisation can repeatedly use design practices to produce better decisions and outcomes. It is not measured simply by the number of designers or workshops. Dimensions commonly include:

Maturity models should be used diagnostically, not as league tables. A unit may be advanced in research but weak in decision rights or delivery integration. Adoption therefore requires a portfolio of interventions.

6.1 Adoption strategy

A practical adoption strategy includes:

1. Diagnose the current system: identify incentives, bottlenecks, existing strengths and sources of resistance.
2. Find a consequential entry point: choose a product or service problem where design practices can produce visible value.
3. Create an enabling coalition: include product, design, engineering, operations, data, compliance and executive sponsors.
4. Demonstrate through practice: use a real initiative rather than training alone.
5. Codify lightweight standards: define research ethics, decision logs, discovery expectations and evidence requirements.
6. Integrate with governance: connect customer evidence to funding, prioritisation, risk and portfolio reviews.
7. Build capability: provide coaching, communities of practice and role-specific learning.
8. Measure and adapt: evaluate outcomes and unintended consequences.

Resistance is often rational. Teams may fear additional workload, loss of expertise, exposure of weak assumptions or disruption to delivery commitments. Leaders should address these concerns directly rather than labelling resistance as an attitude problem.

7. Integration with Agile delivery

Design thinking and Agile are complementary but not identical. Design thinking emphasises understanding people, framing problems and exploring alternatives. Agile emphasises incremental delivery, feedback and adaptation. Agile does not automatically guarantee user-centred discovery, and design thinking does not automatically guarantee technical delivery.

An effective operating model connects discovery and delivery through several loops:

• Problem loop: investigate needs, contexts and outcomes.
• Solution loop: prototype and test alternative responses.
• Delivery loop: build, release and monitor a usable increment.
• Learning loop: compare observed outcomes with assumptions and revise direction.

Discovery should not be treated as a one-time phase that ends before engineering begins. Research, design and technical learning continue during delivery. At the same time, delivery teams should not be asked to build speculative concepts without evidence or clear hypotheses.

Practical integration mechanisms include dual-track work, joint discovery sessions, design–engineering pairing, shared refinement, thin vertical slices, hypothesis-driven backlogs and regular outcome reviews. A product backlog item should ideally express user or business value and testable behaviour, not merely an internal design activity.

For example, instead of “Build new dashboard,” a stronger hypothesis is: “For operations supervisors who currently inspect three systems, a consolidated exception view will reduce time to identify unresolved cases.” The team can then define a prototype, a technical slice and measures of time, accuracy and adoption.

8. Digital transformation and sociotechnical change

Digital transformation is not simply the introduction of new software. It changes processes, roles, data flows, decision rights, customer expectations and organisational identity. Design thinking contributes by making the experience of customers and employees visible and by exposing unintended consequences across the service system.

A transformation initiative should therefore examine:

• front-stage customer interactions;
• backstage operational processes;
• data ownership and quality;
• platform and integration constraints;
• workforce capability and role change;
• accessibility and inclusion;
• security, privacy and regulatory obligations;
• measures of value and harm.

Service blueprints, journey maps and ecosystem maps can help connect these elements, but they are models rather than reality. They must be validated with people who perform or experience the work.

Artificial intelligence can support synthesis, transcription, clustering and scenario generation, but its use requires governance. Product teams should protect confidential research data, disclose relevant automation, check for biased or fabricated outputs and retain human responsibility for interpretation and decisions. AI-generated themes are hypotheses until reviewed against source evidence.

9. Ethics, governance and inclusion

Leadership and facilitation involve power, so ethical practice is not optional. Key responsibilities include informed consent, privacy protection, minimisation of data collection, secure storage and respectful treatment of participants. Research participants should understand how their information will be used, especially when recordings, biometric data or sensitive personal information are involved.

Inclusive facilitation requires attention to disability, language, culture, socioeconomic position, age, gender and digital access. “Designing for the average user” can reproduce exclusion. Teams should identify who is absent from research and who may experience disproportionate harm.

Governance should address:

• traceability from evidence to decision;
• accessibility standards and testing;
• privacy and data protection;
• security and abuse scenarios;
• model or algorithmic bias where automated systems are involved;
• escalation of severe or irreversible harms;
• accountability after launch.

A mature organisation treats ethical review as part of normal product work, not as an approval hurdle added at the end.

10. Illustrative case: redesigning a public benefits application service

Background

A government service team responsible for housing assistance had high abandonment in its online application. The programme involved product management, service design, engineering, policy, call-centre operations, legal advisers and local support organisations.

Problem

Senior officials initially proposed adding a progress bar and simplifying the visual design. Call-centre staff argued that applicants lacked required documents. Community organisations reported that people were confused by policy language and feared making an incorrect declaration. Engineering warned that the legacy eligibility service could not support real-time validation.

Analysis

The product manager convened a workshop with representatives from all groups, including two community advocates. Before the meeting, the team assembled anonymised call themes, application funnel data, policy rules and technical constraints. Participants independently reviewed the evidence before discussion.

The workshop separated three questions: where applicants abandoned, why they struggled, and which constraints limited possible responses. Observation of support calls and moderated sessions showed that applicants interpreted “household income” differently from the policy definition. The funnel data showed a large drop at the income declaration step, but the data could not determine whether confusion, missing documents or fear caused the drop.

Approach

The team agreed on a staged response:

1. Rewrite the question using plain language and an example.
2. Add an explanation of why the information was required.
3. Provide a save-and-return function for applicants gathering documents.
4. Test the content and interaction with people using screen readers and translation support.
5. Build a low-fidelity prototype before changing the legacy service.
6. Monitor completion, correction requests, support contacts and unequal outcomes across relevant groups.

The decision log recorded engineering limitations and the policy team’s unresolved concern about interpretation. The product manager explicitly stated that the first release would test comprehension, not prove that the entire service had been solved.

Outcome

The prototype revealed that the proposed progress bar was helpful but insufficient. Participants understood the revised income question more consistently, while translation testing exposed an ambiguity not found in English sessions. The delivery team implemented the revised content and save-and-return capability in a thin vertical slice. After release, the team observed improved completion at the target step, but continued monitoring showed that users with unstable internet access still experienced failure. This led to a subsequent offline-support intervention.

Learning points

The case demonstrates that facilitation can prevent solution fixation, evidence must be interpreted with appropriate limits, and delivery constraints should shape experiments rather than terminate inquiry. It also shows that organisational adoption is strengthened when frontline knowledge, user experience, policy and engineering evidence are treated as complementary rather than competing forms of truth.

Challenges and limitations

Design-led leadership has several limitations. Workshops can create false confidence when participants are not representative or when the problem is structurally constrained. Consensus techniques may privilege majority preferences and marginalise minority risks. Stakeholder maps can oversimplify power and encourage transactional engagement. Psychological safety cannot be created by meeting rules alone if organisational incentives punish candour. Maturity models can become bureaucratic scorecards. Agile integration can collapse discovery into a delivery factory if velocity dominates outcome learning.

Leaders should therefore ask whether the chosen method is proportionate to the decision, whether affected people have meaningful influence, whether evidence is being overstated and whether the organisation is willing to act on what it learns. The most mature practice is not the most elaborate process; it is the ability to adapt process while maintaining ethical and evidential discipline.

Best-practice checklist

Before a major design-led decision, the product manager should be able to answer:

• What decision or learning objective is this activity serving?
• Who has decision authority, and who is affected but absent?
• What evidence supports the current framing?
• Which assumptions are most consequential and testable?
• How will dissent and uncertainty be recorded?
• What accessibility, privacy, security and fairness issues arise?
• How will the output enter Agile planning and governance?
• What outcome will be monitored after implementation?
• When will the decision be revisited?

Chapter Summary

Design thinking becomes organisationally valuable when leadership creates the conditions for evidence-based collaboration and action. Effective facilitators design workshops around explicit outcomes, separate divergence from convergence, clarify decision rights and protect equitable participation. Conflict should be surfaced and structured rather than suppressed; stakeholder power should be analysed alongside the knowledge and consequences held by less powerful groups.

Design evidence is an argument connecting claims, methods, limitations and implications. Qualitative and quantitative evidence answer different questions and should be triangulated without overstating causality. Psychological safety supports candour, but it must coexist with accountability, standards and follow-through. Organisational adoption requires capability, governance, incentives and integration with real work—not workshops or training alone.

Design thinking and Agile are complementary learning systems. Discovery, prototyping, delivery and measurement should form connected loops. In digital transformation, product leaders must consider the whole sociotechnical service, including operations, data, roles, inclusion and governance. Ethical practice requires privacy, accessibility, traceability and responsibility for unintended consequences. Ultimately, design maturity is demonstrated by better decisions and outcomes, not by the vocabulary or volume of design activity.

Key Terms

Design leadership: Shaping direction, participation and learning so that teams can make and implement better product decisions.

Facilitation: Designing and guiding a group process toward purposeful learning or decision-making.

Multidisciplinary team: A group combining different professional knowledge, responsibilities and perspectives.

Divergence: Expanding the range of possible interpretations, ideas or solutions.

Convergence: Narrowing alternatives using explicit criteria and judgment.

Task conflict: Disagreement about ideas, priorities or interpretations.

Relationship conflict: Interpersonal tension involving distrust, status or identity.

Process conflict: Disagreement about roles, procedures, resources or timing.

Stakeholder power: The capacity to influence, approve, block or shape a product decision.

Decision rights: Explicit authority to recommend, decide, approve or implement.

Design evidence: Information used to support or challenge a product claim or decision.

Triangulation: Combining different evidence sources or methods to improve understanding.

Psychological safety: A shared belief that interpersonal risks can be taken without punishment or humiliation.

Design maturity: The organisational capability to use design practices repeatedly and effectively.

Discovery: Structured learning about users, problems, contexts, constraints and opportunities.

Dual-track work: Coordinating discovery and delivery as connected, ongoing activities.

Digital transformation: Sociotechnical change involving technology, processes, roles, data and organisational practices.

Service blueprint: A model connecting customer-facing interactions with backstage processes and systems.

Decision log: A record of decisions, evidence, assumptions, owners, dissent and review conditions.

Outcome measure: An indicator of change in customer, organisational or system value rather than merely activity completed.

Review Questions

Short Answer Questions

1. What is the difference between divergence and convergence in a workshop?
2. Why should decision rights be clarified before a multidisciplinary workshop?
3. Distinguish task conflict from relationship conflict.
4. What does psychological safety mean, and what does it not mean?
5. Why should design evidence include its limitations?

Long Answer Questions

1. Explain how a product manager can facilitate disagreement without suppressing dissent or allowing conflict to become personal.
2. Discuss the dimensions of organisational design maturity and propose actions for moving from emerging to more mature practice.
3. Compare the contributions of qualitative and quantitative evidence to product decision-making.
4. Explain how design thinking and Agile delivery can be integrated without reducing discovery to a one-time phase.
5. Analyse the leadership and governance responsibilities involved in design-led digital transformation.

Analytical / Application Questions

1. A senior executive insists that a workshop end with unanimous agreement. How would you redesign the process and explain the difference between alignment and consensus?
2. A product experiment increases completion by 12% relative to a baseline, but a major marketing campaign ran simultaneously. What can and cannot be concluded, and what additional evidence would you seek?
3. Design a stakeholder and facilitation strategy for a product initiative in which engineering controls a critical platform, operations understand the problem best, and affected users have little formal power.

Multiple Choice Questions with Answers

Question 1

Which statement best describes the primary purpose of facilitation in a design-thinking workshop?

A. To ensure that the most senior participant's preferred solution is selected

B. To create conditions for structured learning and informed decision-making

C. To eliminate disagreement before the workshop ends

D. To replace the decision owner's responsibility

Correct Answer: B. To create conditions for structured learning and informed decision-making

Question 2

Which example is task conflict rather than relationship conflict?

A. A participant questions another person's competence

B. Two team members distrust each other's motives

C. Engineering and design disagree about the feasibility of a proposed interaction

D. A manager excludes a colleague from discussion after a personal dispute

Correct Answer: C. Engineering and design disagree about the feasibility of a proposed interaction

Question 3

What is the most appropriate interpretation of six usability failures in eight moderated sessions?

A. Exactly 75% of all users will fail

B. The finding proves the product has no commercial value

C. The sessions indicate a possible problem in that task context but do not estimate population prevalence

D. The finding should be ignored because the sample is not statistically representative

Correct Answer: C. The sessions indicate a possible problem in that task context but do not estimate population prevalence

Question 4

Which practice most directly supports psychological safety?

A. Punishing teams that report risks late in the project

B. Asking for disconfirming evidence and responding constructively to bad news

C. Avoiding all critical feedback during workshops

D. Allowing participants to ignore agreed quality standards

Correct Answer: B. Asking for disconfirming evidence and responding constructively to bad news

Question 5

If a metric rises from 40 to 50, what is the relative percentage change?

A. 10%

B. 20%

C. 25%

D. 40%

Correct Answer: C. 25%

Question 6

Which statement best characterises the relationship between design thinking and Agile?

A. They are identical methods with different names

B. Design thinking replaces iterative delivery

C. Agile guarantees user-centred discovery without additional practices

D. They can be integrated as connected systems of discovery, delivery and learning

Correct Answer: D. They can be integrated as connected systems of discovery, delivery and learning

Question 7

What should a decision log normally record?

A. Only the final decision and the meeting date

B. The decision, evidence, assumptions, owner, dissent and review conditions

C. Only the opinions of high-power stakeholders

D. All workshop conversation verbatim, regardless of relevance

Correct Answer: B. The decision, evidence, assumptions, owner, dissent and review conditions

Question 8

Why is a stakeholder map insufficient when used alone?

A. Stakeholders never influence product decisions

B. It may oversimplify power and overlook affected groups with limited formal influence

C. It can only be used by engineers

D. It eliminates the need for user research

Correct Answer: B. It may oversimplify power and overlook affected groups with limited formal influence

Question 9

Which activity is most consistent with responsible use of AI in design research?

A. Treating automatically generated themes as verified findings

B. Uploading confidential participant data to an unapproved tool

C. Using AI for preliminary synthesis while checking outputs against source evidence

D. Allowing AI to make the final ethical decision without human review

Correct Answer: C. Using AI for preliminary synthesis while checking outputs against source evidence

Question 10

What is a central characteristic of design maturity?

A. The number of workshops conducted each quarter

B. The number of design tools adopted by a team

C. The organisation's ability to use design practices repeatedly to improve decisions and outcomes

D. The complete removal of uncertainty from product work

Correct Answer: C. The organisation's ability to use design practices repeatedly to improve decisions and outcomes