{"site":{"name":"Koji","description":"AI-native customer research platform that helps teams conduct, analyze, and synthesize customer interviews at scale.","url":"https://www.koji.so","contentTypes":["blog","documentation"],"lastUpdated":"2026-10-01T10:07:10.160Z"},"content":[{"type":"documentation","id":"6e3181ea-0e74-433f-bc1d-8846f0be04bb","slug":"referred-complaints-wrong-feature-blamed","title":"Referred Complaints: Why Users Blame the Feature That Is Not Broken (2026)","url":"https://www.koji.so/docs/referred-complaints-wrong-feature-blamed","summary":"Users report problems at the surface they can observe rather than where the fault lives, because any observer resolves an ambiguous signal toward the layer it can represent in detail. The misattribution is systematic rather than random, so it can be mapped from resolved bug pairs and attached to intake. Running root cause analysis before confirming the locus produces a coherent, confident explanation about a component that was never broken.","content":"## The short answer\n\nUsers report problems at the surface they can see, not at the place the problem lives. This is not confusion and it is not carelessness. It is a structural property of any system where an observer has a detailed model of one layer and no model at all of the layer underneath. The complaint arrives attached to the wrong component, and because the complaint is specific and confident, the team investigates the component named in it.\n\nMedicine has a precise name for this and a worked-out theory of why it happens. Referred pain is defined as \"Pain perceived at a location other than the site of the painful stimulus.\" A heart attack is felt in the left shoulder, arm or hand. Gallbladder disease is felt at the right tip of the scapula. An irritated diaphragm is felt in the left shoulder. None of these are random errors. They are predictable, repeatable, and documented well enough that clinicians are taught the map.\n\nThe useful part for research is that second property. If misattribution were random you could do nothing about it. Because it is systematic, you can build the map for your own product and read complaints through it. This article covers the mechanism, the measurable cost of a misrouted report, why five whys makes things worse rather than better, and how to construct a referral map from feedback you already have.\n\n## Why the referral happens, and why it is predictable\n\nThe anatomical explanation is convergence. Afferent nerve fibers from different tissues converge onto the same spinal neuron. Signals from an internal organ and signals from a patch of skin arrive on shared wiring, and the brain receives a message on that wire without a reliable tag saying which input produced it.\n\nWhat the brain does next is the important bit. It does not report uncertainty. It assigns a location, and it assigns it to the body wall. As the description of the mechanism puts it, \"The CNS does not clearly discern whether the pain is coming from the body wall or from the viscera, but it perceives the pain as coming from somewhere on the body wall.\"\n\nThat is the whole phenomenon in one sentence, and it transfers exactly. The brain has fine-grained spatial representation of skin and muscle, because it needs it, and almost none of internal organs, because it never had to point at them. Faced with an ambiguous signal, it resolves to the layer it can represent in detail.\n\nYour users are in the same position. They have a rich, detailed, continuously updated model of your interface. They have no model whatsoever of your sync service, your rate limiter, your cache invalidation, or your third-party billing webhook. When something goes wrong in a layer they cannot see, they do not report uncertainty either. They report a location, and the location they report is on the surface they can represent.\n\nSo a failing background sync gets reported as \"the dashboard is wrong.\" A webhook that silently drops gets reported as \"your export is broken.\" An eventual-consistency window gets reported as \"saving does not work.\" In every case the named component is healthy, and in every case the report is specific, plausible and wrong.\n\nThe referral is segmental in medicine, meaning it follows the wiring. It is segmental in software too, and the wiring is the shared surface: whichever screen renders the affected data is where its failures will be reported, regardless of which service produced them.\n\n## What a misrouted report actually costs\n\nIt is tempting to treat misattribution as a routing annoyance that costs a day. The clinical data says the cost is much larger than that, because a report that does not present with its expected symptom is degraded at every subsequent step, not just the first.\n\nCanto and colleagues published the definitive measurement in JAMA in 2000 (volume 283, issue 24, pages 3223 to 3229), using the National Registry of Myocardial Infarction 2: 434,877 patients with confirmed heart attack across 1,674 US hospitals, enrolled between June 1994 and March 1998. Chest pain is the canonical symptom of a heart attack. In this cohort, 142,445 patients, or 33 percent, presented without it.\n\nFollow what happened to that third:\n\n- They were far less likely to be correctly identified at the door: 22.2 percent were diagnosed with confirmed heart attack at admission, against 50.3 percent of those with chest pain.\n- They arrived later, with a mean delay before hospital presentation of 7.9 hours against 5.3 hours.\n- They were less likely to receive every major treatment, including thrombolysis or primary angioplasty at 25.3 percent against 74.0 percent, and aspirin at 60.4 percent against 84.5 percent.\n- In-hospital mortality was 23.3 percent against 9.3 percent, with an adjusted odds ratio for mortality of 2.21 and a 95 percent confidence interval of 2.17 to 2.26.\n\nOne clarification, because precision matters here: this study measured the absence of the expected symptom, which is a broader category than referral specifically. Referral to the shoulder or arm is one way a heart attack presents atypically, not the only way. What the study establishes is the shape of the cascade rather than the anatomy of referral.\n\nAnd that shape is the transferable finding. When a problem does not arrive wearing its expected symptom, the failure compounds: slower to be reported, much less likely to be classified correctly at intake, less likely to receive the intervention, and far worse outcomes. Every one of those steps has a direct analogue in a support queue and a backlog. A report filed against the wrong component is not merely in the wrong bucket. It is triaged by the wrong team, against the wrong severity heuristics, with the wrong owner, and it stays there longer.\n\n## Why five whys makes this worse\n\nRoot cause analysis assumes the symptom locates the system. Ask why five times and you travel downward from the reported problem toward its cause. That works beautifully when the starting point is right.\n\nStart at a referred location and the same technique becomes actively dangerous. You are drilling into a component that is functioning correctly, and because real systems are complicated, you will find something. Every layer of \"why\" produces a plausible answer about the healthy component, and the chain gets longer and more confident as you go. Five whys applied to the wrong locus does not fail loudly. It converges, and it converges on a defensible-sounding cause in a part of the system that was never broken.\n\nThis is worth stating plainly because the depth and coherence of an analysis feel like evidence that its premise was sound. They are not. A five-layer causal chain rooted at the wrong component is more persuasive than a two-layer one, and equally wrong.\n\nThe ordering follows directly: establish that the reported locus is the actual locus before you drill. Referral is a question about *where*, and root cause analysis is a question about *why*. Answering the second before settling the first is the error.\n\n## Building a referral map for your product\n\nClinicians do not diagnose referral from first principles in the moment. They use a learned map. You can build yours from data you already have, and it is a one-off exercise you refresh occasionally.\n\n**Step 1: harvest resolved pairs.** For every bug resolved in the last two quarters, record two fields: the component named in the original report, and the component that was actually changed in the fix. You almost certainly have both, in your issue tracker.\n\n**Step 2: build the confusion matrix.** Tabulate reported component against actual component. The diagonal is reports that landed correctly. Everything off-diagonal is a referral you have already experienced.\n\n**Step 3: keep the cells above chance.** Most off-diagonal cells will be noise. A few will be dense and repeatable, and those are your referral pairs. In practice teams find two or three strong ones, typically where one screen renders data produced by several services.\n\n**Step 4: attach the map to intake.** When a report names a component with a known referral partner, the partner gets checked before the named component is investigated. That is the entire intervention, and it costs one line in a triage checklist.\n\n**Step 5: probe laterally, not just downward.** The question that surfaces referral is not \"why do you think that happened\" but \"where else did you notice anything unusual around the same time.\" Referral is diagnosed by finding the second site, exactly as in medicine. A user who reports slow dashboards and, when asked, mentions that a total looked wrong last week, has just told you the problem is in data, not in rendering.\n\n## How Koji handles this\n\nReferral is hard to catch with surveys and easy to catch in conversation, because catching it requires a follow-up that depends on what the participant just said. That is precisely what an AI interviewer does at scale.\n\n- **Koji's AI interviewer probes laterally in the moment.** When a participant names a symptom, Koji can follow up on when it occurred, what else was happening, and what else looked wrong, on every session. A human moderator running their eighth interview of the day asks that follow-up inconsistently. A static survey cannot ask it at all, because the question depends on an answer that does not exist yet.\n- **The Mom Test framework is built in, and its question patterns are already the right shape.** Koji ships methodology frameworks including The Mom Test, Jobs to be Done, discovery, exploratory, and lead magnet research. The Mom Test patterns push toward concrete past episodes, with prompts such as walking through how someone currently handles a task and asking what happened after that. Concrete episode reconstruction is how you locate a problem in time and therefore in the system, rather than collecting the user's theory about which feature is at fault.\n- **Structured questions pin the locus down.** Koji supports six question types: `open_ended`, `scale`, `single_choice`, `multiple_choice`, `ranking`, and `yes_no`. A `multiple_choice` item listing the surfaces where a user noticed anything odd turns a single reported location into a set, and a set is what reveals a referral pattern. A `yes_no` asking whether any displayed number was ever wrong separates a data fault from a rendering fault in one question.\n- **Analysis stays grounded in transcripts.** Because Koji ties each extracted item back to the passage it came from, you can search for the second site across an entire study instead of re-reading sessions looking for a detail you did not know mattered at the time.\n- **Reporting is available while fieldwork is still open.** Referral patterns show up as a shape across sessions rather than inside any one of them, so seeing results accumulate in real time is what lets you add a lateral probe mid-study rather than discovering the pattern after the study closed.\n\nTraditional tooling fights you here. A survey platform such as SurveyMonkey collects the location the user volunteered and stops, which means the referred location is the only location you will ever have. Koji is built to collect the second site, which is the one that identifies the source.\n\n## Common mistakes\n\n- **Treating the reported component as data about the system.** It is data about what the user can see. Those are different claims.\n- **Running root cause analysis before locating the fault.** Depth of analysis is not evidence of a correct premise, and a long causal chain rooted in the wrong place is the most convincing wrong answer available.\n- **Assuming misattribution is random.** If it were, a map would be impossible. It is systematic, follows shared surfaces, and is therefore learnable.\n- **Blaming users for imprecision.** They are resolving an ambiguous signal to the only layer they can represent, which is exactly what a nervous system does. Specificity in a report is not accuracy.\n- **Building the map and never attaching it to intake.** The map is worthless unless a named component with a known partner triggers a check of the partner first.\n\n## Frequently asked questions\n\n### What is a referred complaint in product feedback?\n\nIt is a complaint whose reported location is not where the problem actually is. A failure in a layer the user cannot observe, such as a sync service or a webhook, gets reported against the visible surface that displays the affected data. The report is specific and confident, which is why teams investigate the named component rather than questioning the location.\n\n### Why do users blame the wrong feature?\n\nBecause they have a detailed model of your interface and no model of what sits behind it. Given an ambiguous signal, any observer resolves it toward the layer it can represent in detail. This mirrors referred pain, where the central nervous system cannot tell whether a signal came from an organ or the body wall and perceives it as coming from the body wall, the surface it represents precisely.\n\n### How is this different from root cause analysis?\n\nRoot cause analysis answers why, and it assumes you already know where. Referral breaks that assumption. Starting a five-whys chain at a referred location produces a long, coherent, confident explanation about a component that was never broken, because complicated systems always yield something when you dig. Establish the locus first, then drill.\n\n### How do I build a referral map for my product?\n\nTake every bug resolved in the last two quarters and record the component named in the original report alongside the component actually changed in the fix. Tabulate one against the other. Off-diagonal cells that recur are your referral pairs. Then attach the map to intake, so a report naming a component with a known partner triggers a check of that partner first.\n\n### What question reveals a referred complaint?\n\nNot \"why do you think that happened,\" which invites a theory. Ask where else the person noticed anything unusual around the same time. Referral is identified by finding the second site, and the second site is usually already in the user's memory but never volunteered, because they saw no reason to connect two unrelated-looking oddities.\n\n### How much does a misrouted report actually cost?\n\nMore than the routing delay. The clinical analogue is stark: among 434,877 confirmed heart attacks, the 33 percent presenting without the expected symptom were correctly diagnosed at admission 22.2 percent of the time against 50.3 percent, arrived later, received less treatment, and had 23.3 percent in-hospital mortality against 9.3 percent. A report that does not arrive wearing its expected symptom is degraded at every downstream step, not just the first.\n\n## Related Resources\n\n- [Root Cause Analysis Guide](/docs/root-cause-analysis-guide) - the technique that assumes the symptom already locates the system\n- [The Five Whys Technique in User Research](/docs/five-whys-technique-user-research) - why depth converges confidently when the starting locus is wrong\n- [Did the Feature Cause the Complaint?](/docs/complaint-causality-dechallenge-rechallenge) - grading whether a causal link exists at all\n- [Support Ticket Research Analysis](/docs/support-ticket-research-analysis) - mining the queue the referral map is built from\n- [Product Feedback Triage Guide](/docs/product-feedback-triage-guide) - where to attach the map so it changes a decision\n- [Structured Questions Guide](/docs/structured-questions-guide) - the six question types, and which ones pin down a location\n","category":"Analysis & Synthesis","lastModified":"2026-09-30T03:34:52.910462+00:00","metaTitle":"Referred Complaints: Users Blame the Wrong Feature","metaDescription":"Users report faults at the surface they can see. Build a referral map so you stop investigating healthy components.","keywords":["referred complaints","misattributed feedback","wrong feature blamed","referral map","feedback triage","root cause analysis"],"aiSummary":"Users report problems at the surface they can observe rather than where the fault lives, because any observer resolves an ambiguous signal toward the layer it can represent in detail. The misattribution is systematic rather than random, so it can be mapped from resolved bug pairs and attached to intake. Running root cause analysis before confirming the locus produces a coherent, confident explanation about a component that was never broken.","aiPrerequisites":["Access to an issue tracker with resolved bugs","Basic familiarity with feedback triage"],"aiLearningOutcomes":["Explain why misattributed reports are predictable rather than random","Quantify the downstream cost of a report lacking its expected symptom","Build a referral map from resolved bug pairs","Ask the lateral probe that identifies a second site"],"aiDifficulty":"intermediate","aiEstimatedTime":"9 min"}],"pagination":{"total":1,"returned":1,"offset":0}}