9.1 Evidence-Based Management (EBM) Overview and Goal Hierarchy

9.1 Evidence-Based Management (EBM) Overview and Goal Hierarchy

Quick Answer: Evidence-Based Management (EBM) is an empirical framework created by Scrum.org that enables organizations to measure, manage, and continuously increase the customer value and business impact they deliver. In complex product environments, predictive management fails because customer needs and market conditions evolve unpredictably. EBM replaces speculative planning with empirical evidence, transitioning organizations from tracking outputs (features shipped, story points burned, velocity) to measuring outcomes (verifiable changes in customer behavior) and impacts (systemic business results). EBM structures ambition through a three-tier Goal Hierarchy: Strategic Goals (broad, multi-year aspirations), Intermediate Goals (measurable 2- to 6-month milestones mapped directly to the Product Goal), and Immediate Tactical Goals (1- to 4-week stepping stones mapped directly to the Sprint Goal). Progress along this hierarchy is achieved via the Experiment Loop: Plan -> Do -> Check -> Adapt.

---

The Core Philosophy of Evidence-Based Management: Escaping the Feature Factory

Traditional product management operates under a flawed industrial assumption: that value is directly proportional to delivery volume. In this legacy mindset, executive leadership constructs multi-year roadmaps filled with anticipated features, budgets are allocated upfront, and success is evaluated by adherence to triple-constraint baselines: on-time, on-budget, and on-scope delivery.

This dynamic creates what product management authority John Cutler termed the "Feature Factory"—an organizational treadmill where cross-functional teams continuously churn out software features without ever validating whether those features resolved customer friction, improved market position, or generated economic returns. Success in the feature factory is measured purely by output velocity rather than realized value.

+----------------------------------------------------------------------+
|                 The Flawed "Feature Factory" Paradigm                |
+----------------------------------------------------------------------+
|  Effort / Hours  ===>  Features Shipped  ===>  ASSUMED Value (?)     |
|  (Internal Work)       (Output Volume)          (Never Validated)    |
+----------------------------------------------------------------------+

                                  VS

+----------------------------------------------------------------------+
|           Scrum.org Evidence-Based Management (EBM) Paradigm         |
+----------------------------------------------------------------------+
|  Activity  ===>  Output  ===>  Outcome (Behavior)  ===>  Impact      |
|  (Code/Test)    (Feature)    (Measurable Change)    (Value Realized) |
+----------------------------------------------------------------------+

Scrum.org developed Evidence-Based Management (EBM) to break this dysfunctional cycle. EBM recognizes that product development resides firmly within the Complex domain of the Cynefin framework, where cause-and-effect relationships are only understandable in retrospect. In complex domains, no amount of upfront market research or executive intuition can guarantee that a feature will deliver value. Therefore, the only rational management approach is empiricism: making decisions based on observable evidence, real-time telemetry, and validated learning.

---

Deconstructing the Value Chain: Activities, Outputs, Outcomes, and Impacts

A central competency evaluated on the PSPO II assessment is the Product Owner's ability to rigorously differentiate between the four links of the organizational value chain. Conflating these elements leads to flawed prioritization, misleading reporting, and wasted capital.

[!IMPORTANT] The PO Mandate on Outputs vs. Outcomes: A Product Owner is not a "delivery manager" accountable for maximizing output volume. As the 2020 Scrum Guide establishes, the Product Owner is explicitly accountable for maximizing the value of the product resulting from the work of the Scrum Team. In EBM terms, this means the PO's primary lever of accountability is maximizing outcomes with the minimum possible output. Shipping fewer features that achieve greater behavioral shifts is the pinnacle of professional product ownership.

---

The EBM Goal Hierarchy: Navigating Complexity through Cascading Intent

Navigating uncertainty requires more than just measuring the present; it demands an explicit, coherent target architecture. If an organization lacks clear goals, empirical measurements become disconnected vanity statistics. EBM defines a formal three-tier Goal Hierarchy that bridges visionary executive aspiration with daily tactical sprint execution:

+----------------------------------------------------------------------+
|                         The EBM Goal Hierarchy                       |
+----------------------------------------------------------------------+
|  1. Strategic Goal        : Broad, ambitious long-term destination   |
|                            (Horizon: 1 to 3+ Years)                  |
|                                       |                              |
|                                       v                              |
|  2. Intermediate Goal     : Measurable milestone along the path      |
|     [Product Goal]         (Horizon: 2 to 6 Months)                  |
|                                       |                              |
|                                       v                              |
|  3. Immediate Tactical    : Short-term objective for a single Sprint |
|     Goal [Sprint Goal]     (Horizon: 1 to 4 Weeks)                   |
+----------------------------------------------------------------------+

1. The Strategic Goal

The Strategic Goal represents the organization's overarching, long-term destination. It is ambitious, visionary, and expansive, typically spanning a 1- to 3-year horizon (or longer). Because it is positioned far in the future, it involves significant uncertainty.

• Nature: Highly aspirational, qualitative, yet supported by verifiable measures of success.
• Uncertainty: Maximum. Market conditions, competitors, and technology will inevitably shift before it is reached.
• Example: "Become the preferred, trusted digital banking partner for European freelance entrepreneurs, eliminating administrative accounting friction and securing 25% market share by 2028."

2. The Intermediate Goal (The Product Goal in Scrum)

Because a Strategic Goal is too broad and distant to provide actionable guidance for a Scrum Team's daily work, the organization identifies Intermediate Goals. An Intermediate Goal represents an explicit, measurable stepping stone toward the Strategic Goal, typically spanning a 2- to 6-month horizon.

• Scrum Mapping: In the Scrum framework, an Intermediate Goal maps directly to the Product Goal—the explicit commitment for the Product Backlog.
• Characteristics: Achievable within several Sprints, outcome-oriented, and bound to objective Key Value Measures (KVMs).
• Scrum Rule Alignment: The Scrum Team must fulfill or abandon one Product Goal before taking on another. This operationalizes EBM at the intermediate level, enforcing strategic Work-in-Progress (WIP) limitation across the entire enterprise.
• Example: "Enable self-employed freelancers to automatically categorize cross-border tax deductions in real-time, reducing monthly bookkeeping reconciliation time from 6 hours to under 30 minutes, with 15,000 active monthly users by Q3."

3. The Immediate Tactical Goal (The Sprint Goal in Scrum)

An Intermediate Goal is still too expansive to guide the work of a single 1- to 4-week Sprint. Therefore, the Scrum Team identifies Immediate Tactical Goals.

• Scrum Mapping: An Immediate Tactical Goal maps directly to the Sprint Goal—the single commitment for the Sprint Backlog.
• Characteristics: Highly focused, providing tactical coherence for the Developers during the Sprint timebox. It articulates the specific outcome or learning hypothesis the team intends to validate in the immediate increment.
• Scope Flexibility: The Sprint Goal describes the 'why' (the outcome); the selected Product Backlog items describe the forecasted 'what'. If the work turns out to be more complex than expected, Developers negotiate the scope of the backlog items with the PO without sacrificing the Sprint Goal.
• Example: "Enable freelance users to snap a smartphone receipt photo and extract German VAT invoice line items with 95% OCR accuracy, validating that receipt processing latency remains under 3 seconds."

---

The Empirical Experiment Loop: Plan, Do, Check, Adapt

How does an organization move between these goal levels? In traditional management, movement is governed by executing a linear project plan. In EBM, movement is governed by the Experiment Loop, which embeds the scientific method into organizational governance:

                    +-----------------------------+
                    |          1. PLAN            |
                    | - Formulate Hypothesis      |
                    | - Define Target Outcome     |
                    | - Select Leading KVMs       |
                    +--------------+--------------+
                                   |
                                   v
                    +-----------------------------+
                    |           2. DO             |
                    | - Execute Small Experiment  |
                    | - Build Minimum Increment   |
                    | - Deploy to Real Users      |
                    +--------------+--------------+
                                   |
                                   v
                    +-----------------------------+
                    |          3. CHECK           |
                    | - Inspect Live Telemetry    |
                    | - Measure Actual KVMs       |
                    | - Compare Expected vs Real  |
                    +--------------+--------------+
                                   |
                                   v
                    +-----------------------------+
                    |          4. ADAPT           |
                    | - Fulfill Goal              |
                    | - Pivot Backlog Scope       |
                    | - Abandon Invalid Goal      |
                    +-----------------------------+

1. Plan (Hypothesis Formulation)

Rather than committing to build a monolithic set of features, the Product Owner and Scrum Team formulate a falsifiable hypothesis linked to an Immediate Tactical Goal or Intermediate Goal:

"We believe that by providing automatic VAT invoice scanning (Output), freelance users will log expenses within 24 hours of purchase rather than waiting until month-end (Outcome), which will increase monthly platform retention from 62% to 75% (Impact). We will know this is successful when 40% of beta users process at least 5 receipts in Week 1."

2. Do (Experiment Execution)

The Scrum Team designs the smallest viable experiment or Increment capable of testing the hypothesis. Developers build the slice of functionality according to their Definition of Done and release it to actual users in production. Crucially, the experiment must reach real end users; internal staging environments cannot generate valid market evidence.

3. Check (Inspect Telemetry and KVMs)

The Product Owner and Scrum Team inspect empirical measurements. They do not rely on user opinion surveys alone; they examine behavioral telemetry, transaction completion rates, error logs, and customer cycle times. The team compares the observed results against the baseline and expected target.

4. Adapt (Strategic Decision Making)

Based on the empirical evidence gathered during the Check phase, the Product Owner makes one of three strategic decisions:

1. Fulfill: The target outcome has been realized. The Product Goal is fulfilled, and the team collaborates with stakeholders to formulate the next Intermediate Goal.
2. Pivot / Iterate: The hypothesis was partially validated, but revealed unexpected user friction or edge cases. The Product Owner refines and reorders the Product Backlog, creating a new Immediate Tactical Goal for the next Sprint to address the findings.
3. Abandon: The empirical evidence decisively disproves the value hypothesis (e.g., users actively reject the feature or find an alternative manual workaround faster). The Product Owner courageously abandons the feature or Product Goal, eliminating the sunk cost fallacy and preserving organizational capital.

---

Critical Anti-Patterns in EBM Goal Formulation

On the PSPO II assessment, scenario questions frequently probe whether candidates can identify and dismantle subtle anti-patterns that disguise legacy waterfall practices in EBM terminology:

Anti-Pattern 1: The Disguised Feature List (Output-Driven Product Goals)

• The Flaw: Executive leadership presents a "Product Goal" that is merely a list of functional deliverables: "Deploy microservice architecture, migrate Oracle database to PostgreSQL, and release iOS v4.0 by Q2."
• The Remedy: The PO must ask: "Why are we building these systems? What customer or operational problem will be solved when this is done?" The goal must be reframed around outcomes: "Achieve 99.99% checkout availability during peak traffic spikes and reduce database query latency below 50ms, decreasing abandoned transactions by 25%."

Anti-Pattern 2: The Multi-Goal Congestion (Macro WIP Violation)

• The Flaw: The Product Owner allows the Scrum Team to pursue three concurrent Product Goals (e.g., expanding to the US market, overhauling the billing engine, and building a mobile app) to appease competing executives.
• The Remedy: The PO must enforce the fundamental Scrum rule: The Scrum Team must fulfill or abandon one Product Goal before taking on another. Pursuing concurrent strategic goals divides cognitive focus, causes context switching, multiplies unresolved dependencies, and violates Little's Law, drastically lengthening Time-to-Market.

Anti-Pattern 3: The Untestable Strategic Dream

• The Flaw: Formulating a Strategic Goal that is purely rhetorical: "Become the most customer-centric enterprise on earth."
• The Remedy: While a Strategic Goal should be visionary, it must include verifiable target measures. The PO works with leadership to establish quantifiable boundaries (e.g., "Achieve an industry-leading Net Promoter Score of +65 and resolve 90% of customer support inquiries within 2 hours across all operating markets").