The best products in the world weren't born in strategy decks. They were born from frustration. Someone needed something, couldn't find it, and decided to build it themselves. That's the whole playbook. Scratch your own itch. It sounds simple because it is simple. But most people in product development have forgotten it entirely.
After 15 years in advertising, I've sat through hundreds of user research presentations. Personas with names like "Active Alex" and "Mindful Mia." Journey maps with seventeen touchpoints. Empathy exercises. Insight mining sessions. All of which produce the same output: a PowerPoint deck that tells you what you already knew, wrapped in language designed to make it sound like a discovery.
Here is what I've learned from building 24+ products with Claude Code over the past year: the single most reliable way to build something useful is to build something you personally need. Not something you think someone else might need. Not something a survey tells you people want. Something you, right now, today, are frustrated enough about to actually build.
The frustration is the brief
Every product I've shipped started the same way: I needed something and it didn't exist. Not in the abstract. Not as a market gap identified through competitive analysis. As a real, felt, in-the-moment frustration that made me think, "Why doesn't this exist?"
Take First Out. I was standing on a tube platform, guessing which door would open nearest to the exit at my destination. Everyone does this. Millions of people, every day, making the same guess. The information exists (TfL publishes it) but nobody had built a clean, fast tool to surface it at the moment you actually need it. So I built one. It now has 95+ features, works as a PWA, and gets checked before most tube journeys.
Or take Little London. I wanted a curated directory of activities in London, organised by type, filterable by area, updated regularly. The information was scattered across twenty different sites, none of which answered the simple question: what's worth doing, near me, today? So I built exactly that. Clean, fast, curated. No booking platform. No review system. Just a useful list.
Oishii London started because I wanted a guide to the best Japanese food in London and every existing list was either too broad or too outdated. Modern Retro started because I was obsessed with 1970s retail aesthetics and wanted to see what modern brands would look like through that lens. Buggy Smart started because navigating London's public transport with a pushchair is genuinely terrible and nobody was mapping the accessible routes.
None of these started with market research. None of them started with a competitor analysis deck. They started with me, needing something, not finding it, and deciding to build it before the frustration faded.
Why personal need beats user research
There are three specific advantages to building from personal need that no amount of research can replicate.
First, you know what "good enough" actually means. When you're the user, you know the difference between a feature that matters and a feature that just sounds impressive in a sprint review. You know that the core value of First Out is speed (tell me where to stand, right now, in two seconds) and that adding social features or gamification would actively make it worse. Research can tell you what people say they want. Being the user tells you what actually works.
Second, you never lose sight of the problem. One of the biggest failure modes in product development is solving a problem that nobody has. It's easy to do. You start with a real insight, then layer on complexity, then pivot to address a "bigger market," and suddenly you're building something that solves a theoretical problem for an imaginary user. When you're the user, that drift is impossible. The problem is sitting right in front of you, every single day, reminding you why you started.
Third, you can test instantly. No recruiting. No scheduling. No incentive payments. No two-way mirror. You just use the thing and know, immediately, whether it works. The feedback loop between building and testing collapses to zero. You ship a change, you try it, you know. That speed is everything.
Constraints as a feature
I hear people talk about needing more time, more resources, more budget to build things. I understand the impulse. But constraints aren't the enemy of good products. They're the engine.
When you have limited time, you can't build a complex multi-feature application with user authentication, payment processing, and an admin dashboard. You can build one thing that does one thing well. And that, more often than not, is exactly what users actually want. A quiz that works. A directory you can browse. A guide that tells you where to stand. Simple, useful, shipped.
Building from personal need forces you to think in terms of the smallest useful version. What can I cut without losing the core value? What does the user (me) actually need, right now, this minute? Not what the roadmap says. Not what might be nice in six months. What solves the problem today?
This is the discipline that matters. Not agile. Not lean. Not any specific methodology. Just the relentless focus on: does this solve a real problem for a real person? If you are that person, the answer is never ambiguous.
The measure that matters
The products I've built from personal need aren't always my most technically impressive work. They aren't the ones with the most elegant architecture or the cleverest engineering. But they're the ones that get used. Actually used, by actual people, for actual purposes. First Out gets checked before tube journeys. Little London gets browsed on weekends. Oishii London gets shared when someone asks for restaurant recommendations. Trove is where I save everything I find interesting online.
That is the measure. Not how clever the code is. Not how beautiful the design system is. Not how impressive the technology stack sounds in a conversation. Does it get used? Does it solve the problem? Does it make someone's day a little bit easier?
After 15 years of helping brands understand their audiences through research and strategy, the most useful thing I've learned about building products is this: be the audience. Solve your own problem. Ship the thing you actually need. Everything else is commentary.
