Working Framework
What it is
A method for handling weak, continuous evidence — deciding which day-to-day signals deserve interpretation, which need probing, and which should not harden into confident stories.
The problem it addresses
Teams say they want continuous discovery, but most of the evidence arriving day to day is fragmentary, delayed, and easy to overread. By the time a conversion dip, a strange search term, or a support pattern gets noticed, the pressure is already to explain it fast and act faster. The real problem isn’t a lack of data — it’s the absence of a disciplined way to decide which weak signals carry meaning and which are noise dressed as insight.
Signal-Driven Discovery exists to slow that reflex at the right moment. It treats a signal as a disturbance to be tested, not a finding to be explained — and builds in, at every step, the specific way that step tends to be misread under delivery pressure.
When to use it
- When behaviour shifts and no single release, campaign, or seasonal factor explains it cleanly.
- When interviews are too slow, expensive, or operationally heavy to trigger every time something moves.
- When several weak signals cluster around the same part of the journey but the problem is still blurry.
- When the next step needs to be a concrete probe or decision, not another round of speculative discussion.
- When quiet absences need tracking alongside the loud anomalies teams already notice.
How it works: the six steps
Each step carries the mistake it invites. The misread is the point — the method’s value is in naming, in advance, how each stage goes wrong when a team is in a hurry to be right.
01 · Signal — Notice a shift, absence, or recurring trace that refuses to stay incidental. Name the disturbance without pretending it already explains itself. What gets misread: a single anomaly is treated as insight before its shape, context, or persistence has been checked.
02 · Triage — Check whether the signal survives basic context: timing, segment, instrumentation, recent releases, operational noise. Decide whether it deserves attention now, later, or not at all. What gets misread: triage becomes explanation, and the team smuggles a favourite cause in before the evidence has narrowed.
03 · Interpretation — Read across sources until the pattern is legible enough to frame a working explanation. Analytics, search, recordings, verbatims, and support should tighten the same question, not perform agreement. What gets misread: cross-source repetition is mistaken for certainty, even when each source is echoing the same blind spot.
04 · Probe — Push the interpretation hard enough to expose where it fails. A probe can be a fast analysis cut, a counter-question, a lightweight experiment, or a small piece of qualitative follow-up. What gets misread: any probe that confirms the first hunch is taken as validation, while disconfirming evidence is treated as noise.
05 · Decision — Translate the strongest remaining reading into a concrete move: test, content change, design change, escalation, or deliberate non-action. If there’s no decision pathway, the framework stops being useful. What gets misread: decision is reduced to shipping something, even when the right move is to escalate, wait, or gather a different kind of evidence.
06 · Loop — Carry the result into the next round: what changed, what stayed absent, what now deserves quieter ongoing listening. The loop keeps anomalies and ambient signals in conversation instead of dying as isolated tickets. What gets misread: the loop is treated as closure, so the team records an outcome but never adjusts what it watches next.
A worked example
Signal. Mobile conversion on a category page drops over three weeks. No release, campaign, or seasonal factor explains it. Alongside it, an unusual internal search term starts recurring, and support sees a small rise in “can’t find” contacts on the same category.
Triage. The dip survives context: it isn’t a tracking change, isn’t confined to one campaign segment, and predates the most recent release. Three weak signals — conversion, search, support — cluster on the same part of the journey. It deserves attention now. The discipline here is resisting the ready explanation (“the new filter broke it”) before the evidence narrows.
Interpretation. Read across the three sources. They tighten the same question — users on this category can’t locate a subset of products — rather than three separate problems. The risk at this step is treating the agreement as proof; all three could be echoing the same instrumentation gap, so the reading stays a working explanation, not a conclusion.
Probe. A fast session-replay cut on the search term, plus a lightweight check of zero-result queries. This is designed to disconfirm — if replays show users finding products by another route, the interpretation fails. They don’t: users search the recurring term, get no useful result, and abandon.
Decision. The strongest reading — a findability gap for a product subset, not a checkout problem — points to a concrete move: fix the search mapping and category tagging for that subset, and instrument the zero-result path so the absence stays visible. Shipping a broad category redesign would be the misread here; the evidence supports a narrow fix, not a rebuild.
Loop. After the fix, check what changed (conversion recovery on that category), what stayed absent (whether the search term still returns nothing), and what now deserves ongoing listening (zero-result queries as a standing signal, not a one-off investigation).
Where it breaks
- Weak instrumentation turns noise into false signals, or hides the signals that matter.
- No decision pathway leaves the team able to describe a pattern but unable to act on it.
- Overinterpretation makes correlation sound like understanding, especially under delivery pressure.
- Organisational constraints block escalation, so the method keeps surfacing issues it has no permission to move.
- Signal that reflects the wrong users or the wrong question. The most dangerous failure isn’t thin signal — it’s abundant, well-instrumented signal produced by the wrong population or by a moment that isn’t the one the decision is about. Traffic from existing users can’t tell you why non-users never arrive; support contacts capture people who complained, not those who left silently. Before a signal is trusted, confirm it’s produced by the users you’re deciding for, encountering the problem you’re actually deciding about. If it isn’t, the method needs a scheduled study, not more signal.