This article is based on a piece by Vladyslav Ukis originally published on InfoQ, covering data-driven decision making practices applied at Siemens Healthineers.
Overview: The Data-Driven Decision Making Series
Software delivery organizations must make fast decisions across three core activities: Product Management, Development, and Operations. The Data-Driven Decision Making Series examines how each of these activities can be guided by data rather than intuition alone:
- Product Management: Hypotheses steer the effectiveness of product decisions.
- Development: Continuous Delivery Indicators steer the efficiency of the development process.
- Operations: SRE’s SLIs and SLOs steer the reliability of production services.
Applied together, these three frameworks allow a software delivery organization to optimize for effectiveness, efficiency, and reliability simultaneously — without siloing these concerns into separate departments.
Why Data-Driven Product Management Matters
Building features that customers never use is one of the most expensive mistakes a product team can make. Feature prioritization is often driven by internal politics, loudest stakeholder voices, or gut feel — none of which reliably predict customer value.
Replacing opinion-based decisions with data from production requires a cultural shift: data must be treated as Process Indicators that describe what is happening in the delivery system, not as People KPIs used to evaluate individual performance. This distinction is critical. When data is used to measure people rather than processes, teams are incentivized to game the numbers rather than improve outcomes.
Leadership must set this norm explicitly. Without top-down support for treating data as a process lens, data quality degrades and the feedback loop breaks down.
Hypothesis-Driven Development (HDD): The Core Framework
Hypothesis-Driven Development (HDD) frames each feature as a scientific experiment. Before implementation begins, the team states what they expect to happen — and defines how they will measure whether it actually does.
A Hypothesis is expressed using a three-part structure:
We believe that this <Capability>
Will result in this customer <Outcome>
We will know we have succeeded when we see this <Measurable Signal> in productionCode language: HTML, XML (xml)Breaking Down the Three Components
- Capability: The feature or functionality being built. Describes what the system will be able to do.
- Outcome: The expected change in customer behavior or experience. Focuses on the user, not the system.
- Measurable Signal: A quantitative or qualitative indicator observable in production that confirms or refutes the Outcome.
This structure enforces a Build → Measure → Learn cycle. Each release becomes a deliberate experiment. The team does not just ship code — they also instrument the feature to collect the Measurable Signal, then evaluate results once the feature is live.
What This Means for Developers
Implementing Measurable Signals is not a product management activity alone. Developers must:
- Plan capacity for instrumentation as part of feature work — not as an afterthought.
- Apply Operations skills (logging, metrics, telemetry) during feature implementation.
- Treat the production environment as an active source of feedback, not just a deployment target.
This is where Hypotheses directly reinforce DevOps culture: the boundary between Development and Operations dissolves when developers are responsible for measuring what they build.
Hypotheses as a Bridge from Projects to Products
Many organizations are transitioning from project-based to product-based delivery models. Traditional project thinking scopes requirement engineering around development activities alone — requirements are written, features are built, and the project ends at release. What happens in production is someone else’s problem.
A Hypothesis with a Measurable Signal forces the requirement to include production evidence. The feature is not considered complete until the signal is observed. This naturally incorporates Release and Operations concerns into the requirement engineering process — which is precisely what a product mindset demands.
Additional benefits of Hypotheses in a project-to-product transition:
- Teams become more business-driven by focusing on Outcomes rather than output volume.
- Teams can operate with less management overhead, guided by Measurable Signal data rather than project governance.
- The current state of any feature is transparent through signal values, reducing the need for status meetings.
Real-World Application: Siemens Healthineers
The Hypotheses framework was introduced to the teamplay platform — a global digital healthcare service from Siemens Healthineers — across a distributed organization of 16 software delivery teams in three countries.
Enablement Approach
To support adoption, the team expanded their existing Business Feature template to include dedicated fields for Capability, Outcome, and Measurable Signals. They then ran focused workshops of 30–60 minutes with individual teams, taking a real in-flight requirement and reformulating it as a Hypothesis. After the feature was deployed to production, the team revisited it to evaluate the actual Measurable Signals.
This hands-on loop — define, build, measure — helped teams internalize the process quickly. Teams found that the Hypothesis definition discussions also improved the quality of their downstream requirement engineering, including Behavior-Driven Development (BDD) user stories, by forcing scope to be clarified early.
Example 1: teamplay User Administration
| Component | Definition |
|---|---|
| Capability | Enable user invitations by hospital admins |
| Outcome (Admin User) | Ability to onboard non-admin users with appropriate user rights |
| Outcome (Non-Admin User) | Ability to skip the registration process and access applications by accepting an invitation from the hospital admin |
| Measurable Signal 1 | Average users per hospital in 2020 > average users per hospital in 2019 + 30% |
| Measurable Signal 2 | > 10% of hospitals registered before 31.12.2019 used the user invitation feature at least once in 2020 |
| Measurable Signal 3 | > 50% of hospitals registered after 01.01.2020 used the user invitation feature at least once in 2020 |
| Measurable Signal 4 | Time between invitation sent and accepted < 1 week |
When the feature shipped, early quantitative signal values indicated that usage growth would take time to reach the defined thresholds. However, qualitative feedback from Sales indicated that customer onboarding had become significantly easier — an unexpected qualitative Measurable Signal that the original Hypothesis had not anticipated. This provided a basis for iterating on the Hypothesis definition itself to better reflect real-world customer value.
Example 2: teamplay Data Access Management
| Component | Definition |
|---|---|
| Capability | Data access by hospital location and department |
| Outcome (Admin User) | Ability to enable users to see data appropriate to their scope of work |
| Outcome (Non-Admin User) | Default focus on data from my hospital department to streamline my work |
| Outcome (C-Level User) | Ability to compare KPIs across different hospital departments |
| Measurable Signal 1 | > 50% of hospital networks enabled Data Access Management |
| Measurable Signal 2 | Number of non-admin users in hospital networks with access to all data > 0 |
Adoption Observations
Teams responded positively to the Hypotheses framework from the outset. The process was easy to understand, and the definition discussions added immediate value to requirement scoping. However, implementation of Measurable Signals in production varied by team — only a subset fully instrumented their features initially. Increased release frequency was expected to accelerate adoption of production instrumentation over time.
One team encountered a notable edge case: during implementation of a Hypothesized capability, they discovered that an external framework had severe limitations that made the intended Capability impossible to deliver. Because the Hypothesis had defined the expected Outcome and Measurable Signal explicitly, the team could recognize early that the Outcome could not be achieved — and pivoted to evaluate alternative frameworks before shipping something that would have failed silently.
Documentation: Embedding Hypotheses in Your Toolchain
For Hypotheses to be consistently applied, they must be documented directly inside the tool where user stories are written — not in a separate wiki, spreadsheet, or document that teams forget to check. Extending your existing feature template (in tools such as Jira, Azure DevOps, or Linear) to include Capability, Outcome, and Measurable Signal fields ensures the Hypothesis is visible at the point where decisions are made.
Using Hypothesis Data for Prioritization
Once a body of Hypotheses has been tested in production, the resulting data becomes an input for prioritization decisions. This data arrives in two forms:
- Positively or negatively tested Hypotheses: Features that did or did not achieve their defined Measurable Signals.
- Unexpected insights: Qualitative or quantitative signals that were not anticipated in the original Hypothesis definition.
Product Owners and delivery leads can use this data to navigate trade-offs across three investment dimensions:
- Invest in new features to increase product effectiveness.
- Invest in development process improvements to increase efficiency.
- Invest in reliability work to improve service stability.
Translating Hypothesis data into consistent prioritization decisions requires practice. Teams benefit from explicit coaching on how to read and act on signal data — especially when signals are ambiguous or when qualitative and quantitative signals point in different directions.
Summary
Hypothesis-Driven Development gives product teams a structured, measurable approach to answering the hardest question in product management: are we building the right things?
Key takeaways:
- Express features as Hypotheses using Capability / Outcome / Measurable Signal triples before implementation begins.
- Plan development capacity for instrumentation alongside feature work — Measurable Signals require engineering effort.
- Treat Hypothesis data as Process Indicators, not as individual performance metrics.
- Embed Hypothesis documentation directly in your user story tooling so it stays visible.
- Use Hypothesis outcomes as a data input for ongoing prioritization decisions.
- Recognise that Hypotheses naturally enforce a DevOps mindset by requiring developers to think about production observability during feature design.
A team that consistently works with Hypotheses moves from being a feature factory to being a delivery organization that is accountable for the value it creates in production. Over time, this leads to higher user engagement, reduced waste, and more transparent — and less political — product decisions.
This article is part of the Data-Driven Decision Making for Software Product Delivery Organizations Series. Future articles cover data-driven decision making in Development (Continuous Delivery Indicators) and Operations (SRE SLIs and SLOs).