The Sensor Map
Use this when you need to weigh what each internal function tells you about users, knowing what each one sees well and what it systematically misses. Started in “Customer-Facing Teams Rarely See the People Who Use the Software,” completed in “Knowing the Subject Doesn’t Make Someone a Typical User.”
The Sensor Map, with its fixed biases and two columns for this month’s reports.
| Sensor | Sees well | Systematically misses | What it reported this month | Label (level and distance) |
|---|---|---|---|---|
Customer Success |
Relationships, renewal risk, account politics, the buyer’s mood |
Normal daily work, users who never talk to CS |
||
Support |
Failures, errors, confusion severe enough to call about |
The denominator, normal work, problems people work around silently |
||
Sales |
Buyer objections, RFP requirements, competitive claims |
Production behavior, users who weren’t in the demo |
||
Internal clinician or subject-matter expert |
Domain rules, clinical safety, vocabulary |
Other roles’ work, other practices’ variation, current frontline conditions |
||
Product and Design |
The product’s model, the roadmap, interaction patterns |
First-time use, what the interface means to someone who didn’t design it |
||
Engineering and QA |
Whether the software meets its specification |
Whether the specification describes the work |
||
Executives |
Strategy, market, money |
Repetitive daily friction |
Put each report next to the column of things that sensor misses. A report that falls inside its sensor’s blind spot (Customer Success describing normal daily work, Support describing how often a task goes fine) needs a second source before anyone acts on it.