In my work with product teams, leaders, and management, I often see the same problem: organizations try to manage product risk as if they were operating in a stable, predictable environment. They create risk lists, color-code them, and discuss statuses, yet the most serious problems still show up later. This is not because someone neglected the process. It is often because some things simply could not have been meaningfully predicted earlier.
This is especially important in product work. The Scrum Guide describes Scrum as a framework that helps people, teams, and organizations generate value through adaptive solutions for complex problems. Evidence-Based Management (EBM) goes further and emphasizes that in such a world, better decisions require intentional experimentation and feedback. In other words, in many situations, you simply cannot “plan the whole journey well” upfront. You have to learn as you go. [1] [2] [3]
Why Traditional Risk Management Is Often Not Enough
The traditional approach to risk still has its place. It is needed where we deal with safety, compliance, deadlines, costs, dependencies, or operational repeatability. ISO 31000 still makes a strong case that risk should be connected to decisions, strategy, planning, and organizational culture. This is not a flawed approach. The problem begins when we try to use the same method for areas where customer behavior, market response, technology, or organizational dynamics only become visible in the course of action.[4]
This is where Dave Snowden’s perspective and the Cynefin framework become useful. Not everything Product Owners, Product Managers, or Leaders face today can be treated as a problem with a clear cause-and-effect relationship. In the complex domain, patterns only become clear in hindsight, and the right response is not to look for one “best practice,” but to act, observe, and respond to what emerges. Cynefin was created precisely to help leaders understand what type of situation they are dealing with and how to choose an appropriate way of acting.[5]
This means that in product work, risk does not always look like an item on a list titled “X might happen.” Sometimes risk sounds more like this:
We assume users will want to use this on their own.
We assume this change will shorten the process rather than make it longer and more chaotic.
We assume the market will respond in line with our research.
These are not project risks. They are product risks, which we might call assumptions or, when framed more specifically, hypotheses. Let us also remember that risk can be an opportunity.
Risk Management not Just for Scrum Teams
This topic is sometimes mistakenly associated only with delivery teams or with Scrum. That can be too narrow a view.
Evidence-Based Management explicitly says that this is about making better-informed decisions by people, teams, and organizations using experiments and feedback. ISO 31000, in turn, emphasizes that risk management should be embedded in governance, strategy, planning, and organizational culture, and that it can be applied by any organization, regardless of size or sector. This means the topic concerns not only the Product Owner or Product Manager, but also managers, directors, and leaders responsible for decisions, priorities, the allocation of people and resources, and the way the organization responds to signals from the market.
In practice, management often influences product risk more than it realizes. For example, when it:
- expects a large, fully ready rollout instead of a small test,
- expects certainty where there is really only a hypothesis,
- rewards activity and output rather than learning,
- delays responding to signals because “it is still too early to draw conclusions,”
- or, on the contrary, reacts too late because the problem was not previously entered into a formal risk register.
In an environment where not everything can be predicted, maturity does not mean that the organization knows everything in advance. It means that it can notice faster when something is not working and respond early enough.
A Short Example from Product Practice
Imagine a company developing an appointment-booking app for a network of physical therapy clinics. The team wants to introduce a new feature: the patient can reschedule an appointment independently in the app, without contacting the front desk.
At first glance, the risk looks fairly traditional. Will the calendar integration work? Will the confirmation SMS be delivered? Will the user have the right permissions? Will the system prevent double bookings?
These are all important questions. But once the feature goes live, it turns out that the biggest problem appears somewhere else.
Patients do begin rescheduling appointments on their own, but they do it much more often at the last minute. In some clinics, the number of unfilled appointment slots increases. The front desk receives fewer simple phone calls, but more difficult cases that require manual handling. Older users get lost in the process and still call anyway. Clinic managers begin working around the system because they prefer local manual confirmation. The feature that was meant to streamline day-to-day operations ends up increasing chaos in some locations.
Was that a risk? Yes.
Could it have been fully predicted in advance? Not necessarily.
Could the team have prepared for it better? Absolutely.
Not by trying to create the perfect list of every possible problem, but by asking a few key questions earlier:
- What assumptions are behind this change?
- How will we know early that one of them is false?
- What signal should stop us or prompt a correction?
- What small test can we run before rollout?
That is exactly the difference between “risk management as a register” and “risk management as a learning capability.”
What Works Better Than Trying to Predict Everything
In product work, something often works much better than risk identification alone: managing three things at the same time—assumptions, signals, and response.
1. Work with assumptions, not just threats
Many important product risks are hidden in statements we do not even call assumptions. For example: “users need this,” “this feature will reduce operational workload,” “this change will improve retention,” or “teams will support this.”
Each of these statements is better treated as a hypothesis rather than a fact. EBM describes exactly this way of working: run an experiment, observe the result, compare it with the expected outcome, and adapt the next step. Lean Startup frames it very similarly with the build-measure-learn loop: build just enough to learn, measure the response, and draw conclusions before investing too much. [3] [6]
2. Look for early signals
Many organizations react only when the risk has already materialized. That is too late.
A better question is: what small signal will appear earlier? What will we notice first? What metric, user behavior, market response, or operational resistance might tell us that we are moving in the wrong direction?
In the app example, such signals could include:
- an increase in appointment changes within the last 24 hours,
- more manual interventions by the front desk,
- lower-than-expected adoption among the 65+ age group,
- a higher number of unfilled open appointment slots,
- or clinics locally bypassing the process.
These signals are far more valuable than a late conclusion such as: “the rollout did not deliver the expected result.”
3. Build risk control as a response capability
In many companies, “risk control” is associated with a document, an approval, or a formal checkpoint. Sometimes that is needed. But in product risk, control should often mean something else: the ability to safely test a hypothesis and respond quickly.
Snowden has emphasized the importance of probe-sense-respond in complex situations for years. EBM and experimentation practices also show that instead of going broad immediately, it is better to take smaller steps and learn faster. Risk control may therefore take the form of a pilot in one location, limiting the rollout to a selected user segment, the option to switch to manual handling, additional monitoring of a specific behavior, or a clear threshold beyond which we stop the change.
A Simple Tool: the Product Risk Signal Card
This is a tool I use when I want to help a team or leaders move from a general statement like “this is risky” to practical action. Sometimes I adjust it depending on the situation. Let us remember that another list or register will not replace an understanding of how to build risk control. It can support it, just like any other tool.
Product Risk Signal Card
For our example, it could look like this:
Assumption: Self-service rescheduling will reduce the front desk workload.
Risk: Patients will change appointments more often at the last minute, increasing operational chaos.
Early signal: The number of appointment changes made less than 24 hours before the visit is increasing.
Response threshold: If the metric increases by more than 15% during the pilot for two consecutive weeks.
Protective action: We limit the feature to selected visit types and add an extra confirmation step for last-minute changes.
Observation owner: The Product Manager together with the clinics’ operations manager, reviewed weekly.
This tool connects the perspectives of product, operations, and decision-making. It forces earlier recognition of a problem and agreement on the response. I want to emphasize again that the tool is meant to support and visualize signals, and it can be replaced with another one that better fits the specific situation.
How to Start
At the beginning, three steps are usually enough.
First, with every larger change, ask yourselves: what are the three most important assumptions behind this decision?
Second, for each of them, add: what early signal will show us that this assumption is not working?
Third, agree in advance: who will observe it, how often, and what will we do if the signal appears?
This approach is useful both for the product team and for management. It helps the team avoid getting stuck in an illusion of certainty. It helps leaders make more responsible decisions without assuming that everything can be known in advance.
In Closing
Mature risk management in product work is not about predicting every possible situation. In many cases, that is simply unrealistic.
It is about something else: recognizing which areas are predictable and which are not; distinguishing project risk from product risk; working with assumptions, signals, and fast response; and building the organization’s ability to learn before the problem becomes costly.
And that is exactly why this topic is not just for Scrum Teams. It matters to everyone who makes decisions about the product, investments, priorities, and change.
In product work, risk rarely disappears just because it has been entered into a table. Much more often, it decreases when the organization learns to notice it earlier and respond more wisely.
The topics covered in this article certainly do not exhaust the full area of product risk management. They do, however, highlight one aspect I wanted to focus on here.
You can read more about outputs and outcomes in the Product Thinking document:
https://scrumexpansion.org/product-thinking/ and here: https://magdalenafirlit.com/outputs-or-outcomes/
I organize training sessions on product risk management. Get in touch to learn more.
Notes and Sources
[1] Scrum Guide 2020 – Scrum as a framework for generating value through adaptive solutions for complex problems; the role of inspection and adaptation. [Back]
[2] Online Evidence-Based Management Guide, Scrum.org – EBM as an approach to making better-informed decisions through intentional experimentation and feedback; working in small steps in a complex world. [Back]
[3] Unlocking Business Agility with Evidence-Based Management, P. Kong, K. Bittner, T. Miller, R. Ripley – – empiricism, experimentation, fast feedback, and an uncertain path to the goal in a changing world. [Back]
[4] ISO 31000:2018, ISO – risk management as part of decisions, strategy, planning, culture, and governance; an approach applicable to any organization. [Back]
[5] The Cynefin® Framework, The Cynefin Company – a framework that helps leaders understand the type of situation they are facing and choose an appropriate way of acting. [Back]
[6] Lean Startup Methodology – build-measure-learn as a loop for rapid learning before larger investment. [Back]
