Your customers aren't who you think they are

I've been writing and talking about human-centric product strategy and design for a while now — on Medium, LinkedIn, the How This Works show, and in this newsletter — but I haven’t really explained what this newsletter is about. Then this conversation happened that got under the bigger why.

So I was chatting with a startup founder last week who'd just closed his seed round of funding. We met at a coworking mixer and this was our first 1:1 conversation. We joked about his AI notetaker — I was taking notes manually and he wondered if it was slacking off. "I can't live without it," he said.

I agreed, saying how important it was to have notes.

"I use ChatGPT for everything," he continued, explaining that he had taken an advanced prompt engineering course from Sander Schulhoff. “I have the Pro version (of ChatGPT),” he declared.

“Did you build the app in ChatGPT,” I asked.

“No,” he said. “Used Bolt. Hired a friend of a friend who’s an engineer. Took about three weeks.”

"Sounds like you've got it together," I said. "You mentioned before that you all have more than a thousand users. That's great."

"1,250 now," he said. "Over 1,250."

"What can you tell me about them?" I asked.

"Well, they want to be more productive," he said. "Looking for efficiency." A pause. One, two, three, four, five. "We did some research early on, but you know, customers don't know what they want."

I've heard so many versions of this. ‘Customers say one thing and do another.’ Or ‘you can't just ask customers what they want.’ This isn't a singular problem to him. And it's not specifically even a founder issue either. It happens when you have really powerful tools/frameworks and get busy with process with pent up bias, but no clear picture of who they’re building for.

I've been seeing this pattern for a while: clients would come in with a variety of different asks — dashboards, chatbots, a website overhaul, making complex customer processes, etc. We’d sign the work, then we’d level set, establishing the current state, interviewing stakeholders and team members, looking at previous work. All this to get to some success state.

But when I'd ask about their customers, they'd get vague. Sometimes, defensive. "Well, they're professionals in their 30s who are really focused on doubling their output.” Or even worse, say nothing. Or they’d produce outdated customer surveys, a stack of NPS documentation, or personas made without being based on any kind of user research.

Here's an experiment: think about your last three customer conversations. Not surveys or analytics dashboards — actual conversations where you asked someone about their day-to-day problems. Can you remember specific quotes? Specific pain points they described?

Now think about your last three conversations about AI tools or new features. I’ll bet those are easier to recall.

I had a conversation last fall with a startup CTO who worked for a company with a few months of operational runway left. They’d closed a series A worth $5M a couple of years before, but had squandered it with shiny demos and pet projects but never once moved their core metrics or had business growth not related to ad spend. Turns out their customer hypotheses were not only wrong but also so expensive.

They'd gotten really good at what looked like product work — using the most current tools, making pitch decks, workshops, etc. Like product theater. They had no idea what problem they were actually solving and burned through so much cash in about 30 months.

(In case you’re wondering, the CTO joined a new company in Jan. He’s okay. The new company has a robust customer experience practice who has a rotating board of customer advisors along with other best in class practices. Coincidence?)

We've got all these new capabilities now, but we're still making the same old mistake of building first and asking questions later — if ever.

The companies I see thriving aren't necessarily the ones with the most advanced tech. They're the ones who understand what job their customers are hiring them to do. Then they figure out how to do that job better than anyone else.

Most of the conversation splits into camps. You've got the tool enthusiasts talking about what's possible. You've got the research folks talking about what customers want. And there's this gap in the middle where the actual building happens.

That's what this newsletter is about — connecting what you learn about people to what you build for people. Connecting our product and design work to business outcomes.

Every week or so, I'll share something I'm seeing around this. Maybe it's a technique that gets a team aligned on who they're serving. Maybe it's a case study about something that worked. Or maybe it's just me thinking out loud about how understanding people and building for people fit together.

No frameworks disguised as wisdom.

Just curiosity about how this stuff actually works in practice.

Most teams I work with are building things for people they've never talked to. But the moment you start connecting what people actually need with what you're building (or capable of building), everything gets clearer.

When you solve a real problem for a specific group of people so well that they're eager to pay for it, you haven't just built a product. You've built something that sustains itself. Assuming, of course, it's a sizable market and the business fundamentals work.

I wonder, What would be different if you knew exactly who you were building for and what they were really trying to accomplish?

Until next time,

Skipper Chong Warson

_{Making product strategy and design work more human — and impactful}

_—

If you're wrestling with any of this stuff or tired of building features based on assumptions instead of real customer understanding, just hit reply. Let’s have a talk.

And if someone forwarded this to you and you want more of these thoughts on the regular, subscribe here.