Your best customer will tell you what hurts today. They will not tell you what they need next quarter. This is not a failure of communication — it is a structural fact. Customers describe symptoms. They rarely diagnose the underlying condition.
The advice "build what customers ask for" is good starter wisdom. It keeps young teams from wandering into the woods. But followed too literally, it becomes a trap. You end up with a product shaped exactly like today's complaints, with no room for the problems your users haven't noticed yet.
The interesting work starts when you watch behavior instead of listening to words.
Three patterns show up repeatedly before an unasked-for feature becomes necessary:
Workarounds that persist. When multiple customers build the same clumsy process around your product — exporting data to a spreadsheet, manually re-running a step, writing a cron job to poll your API — that is a signal. Nobody files a ticket that says "I wish I didn't have to do this." They just do it, because the pain is low enough to tolerate and too diffuse to articulate.
Support tickets that cluster but don't match. Five tickets in a week, each about a different surface-level issue, all touching the same workflow. Individually, each one looks like a small bug or a misunderstanding. Together, they outline a missing capability.
Usage that plateaus in a specific cohort. A group of customers adopts your product enthusiastically, hits a ceiling, and stops expanding. They don't churn — they just stop growing. This is the quietest and most expensive signal, because nobody complains. They decided your product does 70% of the job and built the rest elsewhere.
None of these signals arrive labeled. You have to go looking for them.
Henry Ford's apocryphal quote about faster horses gets overused, but the kernel is real. People frame requests inside the product they already know. A customer who has adapted to a limitation stops seeing it as a limitation. It becomes the shape of the world.
This is especially true for your best customers. They have invested the most time learning your product's quirks. They have built processes around those quirks. Asking them "what should we build next?" often produces answers that reinforce the current architecture rather than challenge it.
The insight you're looking for lives in the gap between what customers do and what they say. That gap is only visible if you watch both.
Spotting the signal is not enough. Plenty of teams see a pattern and then build for six months on a hunch. That is not disciplined intuition — it is expensive guessing.
Here is how to structure the bet before you write a line of code:
Set a usage threshold in advance. Define what adoption looks like before the feature exists. "If we build this, we expect 30% of accounts in the target cohort to use it within 45 days without prompting." Write it down. Share it with the team. The number forces you to be specific about who this is for and how you'll know it worked.
Time-box the experiment. Give yourself a hard boundary — two weeks of build, six weeks of observation, then a decision. The constraint prevents the feature from becoming a pet project that lives forever in a half-finished state because someone is emotionally attached to the thesis.
Define failure before you start. This is the step most teams skip. Failure is not the feature being bad. Failure is the feature not meeting the threshold you set. If you don't define it up front, you will rationalize the results after the fact. You will say "well, adoption was low, but the customers who did use it loved it." That is not a result. That is a story you tell yourself to avoid killing your work.
Commit to the kill decision. If the experiment fails, remove the feature or stop investing. Deciding this in advance, when you are calm and objective, is far easier than deciding it in the moment, when sunk cost is whispering in your ear.
Pure data worship leads to incremental improvements on existing behavior. Pure customer voice leads to a product shaped by the loudest stakeholders. Neither is wrong. Both are incomplete.
The compound skill is reading patterns in data and support logs, forming a thesis about a need customers haven't expressed, and then subjecting that thesis to a structured test with a pre-committed outcome.
This is not "trusting your gut." Your gut is the pattern-matching engine. The framework is the correction mechanism that keeps the engine honest.
Sometimes the experiment fails. You built something nobody needed, and the usage threshold proves it. This feels bad, especially when the original signal was real.
But a failed two-week experiment that you kill cleanly costs almost nothing compared to a six-month roadmap item that lingers because a customer once mentioned something similar on a call.
The goal is not to be right every time. The goal is to be wrong quickly, cheaply, and with full awareness that you are wrong — so you can redirect the effort toward the next signal in the data.
Your best customers will keep telling you what hurts today. Your job is to also see what will hurt tomorrow, and to test that vision with enough rigor that you can trust it.
Be the first to comment.
0 comments
Loading comments...