Product Discovery: The Wrong Problem | Richard Faint
By Richard Faint · 30 September 2026 · 6 min read
Sunnydale After Dark — A Product Discovery Simulation
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.
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.
Get Richardfaint’s stories in your inbox
Join Medium for free to get updates from this writer.
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.
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.
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.
Originally published at https://richard-faint.com on October 5, 2026.
