The Cheat Code You Don't Always Get

On building for people whose problems aren't your own

I write this newsletter to share my learnings about founder-led growth and bootstrapping, gained from my past 10 years of building AI startups and my current journey. AI is pushing the cost of building products and launching startups down toward zero. What's left is authentic POV, based on lived experiences, shared compellingly.

The cheat code

If you can be your own customer, you have a significant advantage. You have at least one real data point. You feel the problem personally. You know when the solution actually works because you experience it yourself. That feedback loop is fast and honest in a way that's hard to replicate.

A lot of the most durable early-stage companies are built this way. The founder had a problem, built a solution for themselves, and found out other people had the same problem. That's not luck. That's the cheat code working exactly as intended.

But not every worthwhile problem lives inside the founder's personal experience. Some of the most impactful problems in the world are ones you've never had to deal with. And not being the user doesn't mean you can't build something that genuinely serves them. It just means you don't get the shortcut.

What closing the gap actually requires

When we moved into crypto with CharmVerse, I was not a Web3 community manager. I hadn't run a grants program. I didn't know how the major blockchain foundations actually operated or what their day-to-day looked like. We came from AI and SaaS and had to figure out an entirely different world.

So you work three times as hard to get into the mind of the people you're building for. Not by reading about the space, though that helps. By having multiple conversations with people across the same world who each bring their own processes, their own history, their own workarounds. You're looking for the pattern underneath the variation.

And when you can, you observe them directly. Not in an interview, not on a call where they're describing their workflow from memory. Actually watching them do the work.

That distinction matters more than most founders realize. When you ask people to describe how they do something, they tell you how they think they do it. Which is often how they were trained, or how they'd do it if everything went according to plan. The actual process is different. It has shortcuts. It has workarounds. It has steps where the SOP says one thing and the person does another because they figured something better out six months ago and never updated the documentation.

You don't find any of that in an interview. You find it by sitting next to someone while they work.

The assumption you have to fight

The thing that catches founders who are building outside their own experience is assuming they've already done enough. A few customer calls, a handful of interviews, maybe a demo or two. That feels like research. It often isn't.

The gap between what you think you understand about a customer's world and what's actually true tends to be larger than it appears. The only way to close it is more exposure, more conversations, more time watching rather than asking.

That's the tax you pay for not having the cheat code. It's not a disqualifier. But it's real, and underpaying it tends to show up later in ways that are expensive to fix.

Until next time.