Knowing your customer is not the same as having met them

"We know our customers."

I've heard that sentence in pretty much every company I've worked at, and it's almost always said to end an argument rather than start one. And the frustrating thing is that the people saying it aren't being dishonest. They usually have met their customers, at some point. There were interviews, there was a readout, maybe there are personas on a wall somewhere. The work got done. It's just that the work happened a while ago, and what's left of it now is less like knowledge and more like a set of half-remembered impressions that have quietly calcified into things everyone treats as obviously true.

Which is the whole problem, really. Meeting your customers is a thing you do once. Knowing them is a thing you have to keep doing, and the gap between those two is where a lot of bad product decisions live, including a few of mine.

How the mix-up happens

Part of why it happens is just how research tends to get scoped. It's a project. It has a kickoff and a deadline and a deliverable, and once the findings have been presented and everyone's nodded along, the project closes and the team gets back to building. The deck goes in a drive somewhere. And the understanding it captured was at its absolute sharpest the week it was presented, and from that point on it only gets less accurate, because the customers carry on changing and the product carries on changing and nobody's going back to check whether the thing you learned in March is still true in November. The belief just keeps doing the job the evidence used to do, long after the evidence stopped backing it up.

The time I built a whole prototype on a belief that wasn't true

I did this myself, fairly memorably, on an insurance product a few years back.

The users were insurance brokers, and there was a settled view inside the company that brokers were reasonably tech-savvy. So we ran with it. The first design direction was this powerful, flexible system where brokers could build their own custom premium-calculation questionnaires and pricing algorithms more or less from scratch, lots of control, very few guardrails, because the assumption was that capable users would want the room to do clever things. More flexibility, more power, more better.

And I want to be fair to where that assumption came from, because it wasn't pulled out of thin air. There'd been some user research. The trouble is it was light, and it was really there to back up an understanding the company already had rather than to genuinely test it, so the sample was never representative enough to be trusted the way we ended up trusting it. We'd talked to enough brokers to feel like we knew them. Nowhere near enough to actually know them. But it didn't feel like that at the time. At the time it felt like we'd done our homework.

Then we put wireframes in front of actual brokers, and the whole thing fell over. All that flexibility we were quietly pleased with turned out to be the problem rather than the selling point. A blank-slate system with barely any structure wasn't empowering for most brokers, it was just bewildering, too much scope, too many ways to get it wrong, too much to hold in your head. What they actually wanted was to be walked through it. A guided, wizard-style flow that took them step by step through building a questionnaire and an algorithm, with all the heavy flexibility tucked somewhere off to the side for the small handful of people who genuinely wanted to get their hands dirty.

We caught it, and I'm honestly mostly grateful we caught it as early as we did, in testing, before any of it got built for real. But it was a close enough call that I don't feel especially clever about it. By the time those wireframe sessions happened we'd already produced a full interactive prototype, and because the entire design philosophy was built around this open, do-anything premise, it had ballooned into an enormous tangle of user-flow permutations, every path branching into three more. Weeks of work, all of it pointing the wrong way, all because of a belief about the customer that we'd never properly stress-tested and had just decided to treat as true.

The research that kicked it all off wasn't even bad research. It was just a snapshot, and we'd mistaken a snapshot for an ongoing relationship.

What actually saved it

So here's the bit I actually care about. The reason that project got rescued wasn't that we eventually did more research up front. It's that we kept checking. The wireframe test was really just another moment of contact with a real broker, and it caught something the original research had waved through. If we'd treated that early research as settled, which is precisely what "we know our customers" encourages you to do, we'd have built the entire thing on a foundation that wasn't there.

That's the thing I'd want a younger version of me to understand. Whether you know your customers has very little to do with how much research you've done and almost everything to do with whether your understanding is actually current at the moment you're making a decision. Not banked. Not from last year. Current. The useful question in the room isn't "have we done the research," it's something closer to "is the customer actually here with us right now, in some honest and recent form, or are we just going off what we remember of them."

Why teams reach for the wrong fix

And most teams, when they sense their grip on the customer is slipping, reach for another research project. Another event, another deck, another readout. Which I get, and it's not nothing, but it's a bit like treating something chronic with a one-off. Give it six months and the new findings will have gone stale in exactly the way the old ones did. The less satisfying answer is the ongoing, faintly boring discipline of just regularly putting real customer signal in front of the people making the calls, so the understanding never gets the chance to quietly fossilise. The problem with that kind of work is that when it's going well nothing visibly happens. You just carry on being roughly right, which nobody throws a party for. A research project at least produces something you can point at.

One question to keep in your back pocket

Anyway. If there's one thing worth taking from this, it's a question. Next time someone says the team knows its customers, ask, gently, when the last time was that any of you learned something about them that actually changed your mind. If there's a recent, specific answer, good, that's a team that's still in contact with reality. If you find yourselves reaching back to some research project from last year, or worse, not coming up with anything, then it isn't really knowledge you've got. It's a memory of an introduction, getting fuzzier the whole time you've been building on it.