The visible event creates pressure for a quick response.
By Richard Faint · 30 September 2026 · 6 min read
Last updated
On screen
Screen references
TL;DR
Discovery frameworks help us understand needs, challenge assumptions and organise evidence. Systems thinking extends that investigation to the relationships, incentives and feedback loops producing those needs. The aim is to make a better decision about where to intervene, including whether a product change will help at all.
Product Discovery: Investigate the System Behind the Feature Request
If Sunnydale employed a product manager, someone would eventually request a vampire dashboard. It would show attacks by neighbourhood, offer a cemetery heat map and provide senior stakeholders with reassurance that the situation was being monitored. There would probably be a discussion about whether impending apocalypses should appear in red or amber, followed by a steering committee to agree what counted as an apocalypse.
The request would be understandable. People want visibility when things keep going wrong, and a dashboard is considerably easier to commission than a conversation about why the town was built on a Hellmouth. Buffy and the Scooby Gang, however, have to investigate what they are facing, how it behaves and what might stop it. Counting bite marks only gets them so far.
That is the challenge of product discovery. A request arrives with a proposed solution already attached, and our job is to understand enough of the situation to decide whether that solution deserves to exist.
Discovery question
Are we improving the proposed solution, or investigating the conditions that made it seem necessary?
Late Delivery Dashboards: Symptoms or Transport Planning Problems?
Imagine a transport operation asking for a dashboard of late deliveries. Planners want earlier warnings, customer services want reliable updates and managers want to know why performance is deteriorating. Interviewing these people is a sensible beginning, but their explanations will reflect where they sit: planners may blame loading delays, the warehouse may blame unrealistic schedules, and sales may point out that customers expect delivery windows somebody has to promise.
A useful systems-thinking lens separates events, patterns and structure. One late delivery is an event; repeated delays on particular routes form a pattern; the capacity, commitments and planning rules shaping those routes are part of the structure. Beneath these sit assumptions, such as the belief that every customer promise must be accepted and operations will somehow find a way to deliver it.
Sunnydale makes the distinction memorable. The latest monster demands attention, but the recurring trouble invites a wider investigation. In an organisation, we should be equally curious about the conditions that keep generating apparently separate requests. We may need to deal with today’s incident while also changing what makes tomorrow’s likely.
Stakeholder Perspectives in Product Discovery: Assemble the Scooby Gang
Buffy brings direct experience of fighting the threat, Giles brings research, Willow brings different technical capabilities, and Xander contributes another perspective. Product discovery benefits from a similar mix because nobody experiences the whole operation, however confidently they explain it in a meeting.
System boundaries matter here. If we define the problem as “planners need better alerts”, we will investigate planning screens and notification preferences. If we ask “what prevents us keeping delivery promises?”, the investigation expands to sales commitments, loading capacity, scheduling and customer behaviour. Neither boundary includes everything, but each makes different causes and interventions visible.
We need a boundary broad enough to explain the problem and narrow enough to support action. Otherwise discovery becomes either a tour of the interface or an indefinite investigation into the human condition, with Giles still in the library six months later and no one prepared to authorise a stake.
What Product Discovery Frameworks Reveal and Miss
Discovery frameworks give this investigation some discipline, provided we remain curious about what falls outside them.
| Approach | What it helps us see | What needs further investigation |
|---|---|---|
| Customer interviews | Experiences, workarounds and specific examples of difficulty | Whether people’s explanations match observed behaviour and operational evidence |
| Jobs to Be Done | The progress someone wants to make in a particular situation | Conflicts between different people’s jobs and the conditions limiting that progress |
| Opportunity solution trees | Possible opportunities and experiments connected to a desired outcome | Whether the chosen outcome improves the wider operation and whose needs are missing |
For our planner, the job might be to identify a threatened delivery early enough to recover it. That is more useful than “receive notifications”, because it leaves room for several solutions. Yet a planner’s need to recover a schedule may conflict with a warehouse manager’s need to stabilise loading, particularly if every intervention changes the loading sequence.
The framework helps us articulate the job; systems thinking asks how pursuing it affects everyone else’s work. Giles’s books are useful, but finding a familiar creature in the index does not guarantee that tonight’s problem behaves exactly as expected.
How Delivery Alerts Create a Reinforcing Planning Feedback Loop
Suppose the operation responds to delays by adding more alerts. Planners investigate each warning, answer calls and revise routes, leaving less time to prepare upcoming work. If that reduced planning time contributes to further delays, it generates still more alerts and interruptions. This is a reinforcing feedback loop: the response can amplify the conditions that prompted it.
Interactive animation
When the response feeds the problem
Increase the alert load and watch attention move from preparing upcoming work to reacting to interruptions. Then improve alert quality to see where the loop can be weakened.
Visibility improves, but every warning asks for attention.
Planners investigate warnings, revise routes and answer calls.
Upcoming work receives less calm, preventative planning.
The alert system is useful, but interruption is beginning to consume the capacity needed to prevent tomorrow's problems.
This is an explanatory model, not an operational forecast. Its purpose is to make the proposed feedback mechanism testable through observation and data.
That is a hypothesis to investigate, rather than a conclusion we can announce because we have drawn some arrows. We would need to observe how planners spend their time, examine which alerts lead to useful action and compare interruption levels with subsequent performance. More alerts might help when warnings are scarce; they might overwhelm people when attention is already the constraint.
There may also be delays between intervention and effect. Changing delivery promises could take weeks to influence schedules, while a dashboard produces an immediate and pleasing sense of activity. Judging both after three days would favour the intervention that becomes visible fastest, rather than the one that improves the operation.
Buffy has an advantage here: a vampire turning to dust provides unusually prompt feedback. Product teams generally have to work harder to establish whether their intervention achieved anything.
When Is There Enough Discovery Evidence to Choose the Next Step?
Discovery cannot provide complete knowledge of a changing system. It should provide enough evidence to choose a proportionate next step, explain the assumptions behind it and recognise when those assumptions fail.
For the delivery operation, that might mean testing fewer, more actionable alerts with a small group of planners. We would examine delivery performance alongside planner workload and disruption to the warehouse, because an improvement that depends on moving the burden elsewhere may be difficult to sustain. If unrealistic promises appear more influential, the next experiment might involve sales and operations agreeing different commitment rules.
The output is a decision supported by evidence, with an account of what remains uncertain. Sometimes that justifies a feature; sometimes it points towards a process, policy or incentive that the product team cannot change alone.
In the opening article, I argued that frameworks make assumptions visible without taking away our responsibility for judgement. Discovery is where that becomes practical: use the model to organise the investigation, then examine the relationships it leaves out.
Sunnydale could certainly use better information. Before commissioning the vampire dashboard, though, I would want Giles in the room and a fairly serious discussion about the Hellmouth.