In Their Shoes

Your best product research is happening without you

What looks like a control problem is the clearest signal you have about what your clients actually want.

Somewhere in your company right now, a person who talks to clients all day is opening an AI tool and building something. Maybe it’s a custom report a client asked for in passing. Maybe it’s a little calculator, a reworked onboarding doc, a mockup of the dashboard the client said they wished they had. It took twenty minutes. They didn’t file a ticket or wait for a roadmap slot. They made the thing, sent it over, and the client loved it.

If you run product, or operations, or IT, your first reaction when you find out is probably a small spike of dread. Unbranded files going out the door. No version control. No record of what was promised, and nobody reviewed it. It’s the kind of thing that surfaces in a risk audit, so it gets treated like one: a memo goes around, the tools get locked down, everyone is reminded to use the official channels.

I understand the instinct. I’ve also come to think it’s one of the most expensive instincts a company can act on right now.

Here’s the reframe. What looks like a process problem is a research opportunity wearing a disguise. The person building that deliverable isn’t going rogue. They’re responding, in real time, to a specific human need they understand better than anyone on the product team does, because they’re the one in the room when the client describes it. The thing they built isn’t a liability. It’s a data point. It’s the clearest possible signal of what a client actually wants, made by the person closest to the wanting.

Think about what that signal normally costs you. Discovery interviews. Surveys. A research vendor. Weeks of synthesis to arrive at a recommendation that is, even then, a guess about what people would use. Meanwhile your account manager just watched someone use the thing and react to it. That’s not a worse version of research. In a lot of ways it’s a better one, because it’s grounded in a real relationship and a real ask, not a hypothetical.

And here’s the trade-off most companies are making without realizing they’re making it. When you suppress the activity, you don’t just remove the risk. You remove the signal. The prototypes stop, yes, but so does your visibility into what your most engaged clients are reaching for. The need doesn’t disappear. It goes quiet, and then it goes to a competitor who said yes faster. You’ve traded a manageable governance question for a much worse one: you no longer know what your clients are asking for, because you taught the people who knew to stop telling you.

The people closest to the user almost always see the future of the product before the product team does.

So what does it look like to do this well? It starts with a decision: you treat client-facing prototyping as a sanctioned activity, not a tolerated one. You give the people doing it real tools, hosted properly, inside your walls, so the work is legible to you instead of living in a personal account you’ll never see. You make it clear that building a quick thing for a client is a good instinct, not a workaround, which is the only way people stop hiding it. And then, this is the part that matters, you watch. Not to police. To learn. Every tailored deliverable a client team builds is a tiny, unsolicited usability study. What did they make? What did the client respond to? Which official tool was too slow or too generic to do the job, such that someone felt they had to route around it?

Then you feed it back into the product, not occasionally but as a loop. The patterns are right there. The same kind of report getting rebuilt across five accounts is a feature request with a hundred-percent validation rate. The thing a client lit up about is a positioning insight you didn’t pay for. The workaround that keeps recurring is a roadmap item your own customers have already pre-tested for you.

The companies that figure this out get a feedback loop their competitors structurally can’t match, not because they have better researchers, but because they stopped treating their most user-adjacent people as a compliance problem and started treating them as a sensor network. They turned the thing everyone else is trying to shut down into the thing that tells them where to go next.

I keep coming back to a principle that’s bigger than this one situation. The people closest to the user feel the gap first, in their gut, in the specific frustration of a specific client they can’t fully serve with the tools they’ve been handed. When they reach for AI to close that gap themselves, they aren’t making a mess. They’re showing you the map. The only question is whether you treat what they build as evidence to clean up, or evidence to follow.

More to read