When User Behavior Looks Like a Demand Signal, Check Whether It's a Symptom
A note on reading behavior data honestly in mature products.
Mature products generate a lot of behavior signal. Users click things. Users make things. Users save things. Product teams get better and better at instrumenting the surface, and PMs get comfortable using the resulting data to make prioritization decisions.
Somewhere in that maturity, a specific failure mode shows up. A behavior that looks like a demand signal — users creating a lot of X — becomes the basis for building more of X, when the actual reading of the data would have been users are creating a lot of X because they can't find the existing X they already have, and every new X they create makes the problem worse.
The demand signal was the symptom. Building more of what users appeared to be asking for made the underlying problem worse. This isn't rare. In products where users create things and content accumulates, this is the modal failure mode of product prioritization.
The pattern
I want to name it because it recurs with a specific shape.
- Users have to do X repeatedly.
- The tool for finding the existing X is worse than the tool for creating a new X.
- So users create new Xs — sensibly, individually, in response to friction.
- The collection of Xs grows.
- The larger the collection, the harder it is to find any specific X.
- The harder it is to find, the more incentive to create rather than search.
- The loop reinforces itself.
At any single point in time, an instrumentation dashboard reading of this system shows: high creation rate for X. It looks like healthy demand. It's not. It's a discovery failure feeding itself, and the prioritization move that follows — invest in making creation easier — quietly makes the loop worse.
What the honest reading looks like
The honest reading requires talking to users, not just watching them.
I encountered a version of this in a mature reporting product. Users were creating ad-hoc reports at a steady clip. The instrumentation read that as a case for investing in the creation experience: better templates, better saved queries, easier duplication. The user-research reading was different. Users were creating new reports because they couldn't reliably find or trust the existing ones they'd used before. Each new report made the reporting library larger. The larger the library, the harder to search. And so on.
The right design work wasn't to make creation easier. It was to reduce the friction of finding and confidently reusing existing content, so the incentive to create new dropped. Not by blocking creation — users had legitimate custom needs — but by removing the pressure that made creation the easier path to what were, in many cases, reuse problems.
That specific inversion — the demand signal is a discovery-and-trust failure in disguise — is the interesting design move. And it wasn't visible from the behavior data alone. It required generative research, close listening, and a willingness to argue for a problem framing that would inconvenience the roadmap.
Why the pattern is so common in mature products
Two structural reasons.
Products that let users create things generate compounding data problems. Every user-created object is a potential future retrieval task. If retrieval doesn't scale with creation, the friction gets worse over time — not linearly, but as a function of the library size versus the quality of search and navigation. Products that ship the creation experience without commensurate investment in the retrieval and lifecycle experiences drift into this failure mode by default.
Behavior data privileges observable actions. A user who searches, doesn't find, sighs, and creates a new thing generates three data points: search miss, dwell time, creation event. The one the dashboard highlights is the creation event, because it's what triggered downstream work — a new saved artifact, a scheduled job, an API call. The failed search and the frustration are invisible or aggregated. The system's own instrumentation biases the story toward demand for creation rather than failure of discovery.
Diagnostic questions
If a behavior signal is being used to justify investment, some questions worth asking before the investment commits.
- What was the user trying to do? Not what did they do. What did they want. If you can't answer this without talking to users, don't build against the behavior signal yet.
- What friction did they encounter before the observed action? The action is often a workaround. The workaround is what's visible in the data. The underlying friction usually isn't.
- What's the second-order effect of making the observed behavior easier? If more of it makes the underlying problem worse, you have a symptom, not a demand.
- Is there a reinforcing loop I can name? If you can draw the loop, you can argue for interrupting it rather than accelerating it.
None of these are exotic questions. They're just the ones that get skipped when a behavior dashboard is confident enough that the next investment feels self-evident.
What this asks of the design work
It asks the designer to hold two readings of the data at once — the behavior-signal reading and the underlying-user-need reading — and to argue for the second when the evidence supports it, even though the first is what the roadmap will default to.
This is one of the highest-leverage moves a designer can make in a mature product. Not the visual craft, not the interaction design, not even the research method — the reframe from symptom to underlying problem. Everything downstream — principles, direction, prioritization, validation — follows from getting this reading right.
If the reading is wrong, the downstream design work is polish on the wrong object. If it's right, the design work is doing something the behavior data alone would have missed.
The stance
Behavior data is real. It's also incomplete. In products where users create things and content accumulates, a "high creation" signal deserves a closer look — because the modal explanation isn't demand, it's discovery failure in disguise.
The design contribution is often the reading, not the artifact. Get the reading right first.