Before You Build: Why Persona and Problem Statement Aren't Optional

A developer friend of mine recently built a "How Might We" ideation tool. Clean, thoughtful, genuinely useful. I opened it and felt that warm designer flicker — like watching a baby take their first steps. A bit wobbly. Full of potential. Worth celebrating.

But something was off.

The tool started with persona, then slid into context — which sounds right until you're actually using it. Because "context" is vague, and vague inputs invite the classic failure mode: you blend your persona with your problem, dump everything into one field, and the tool generates ideas based on a muddy premise. Great ideation engine. Wrong foundation.

The questions that would have sharpened the thinking just weren't there yet.

I snickered — not at him. At the recognition. Because here's the thing: he built something real. He just hadn't decided why yet.

"Because I Can" Is Not a Problem Statement

We are living in the most powerful building moment in history. Engineers can ship in hours what used to take months. AI handles the scaffolding. The barrier to building is basically gone.

And so people build. Because the tech is interesting. Because they want to practice a pattern. Because they had a Saturday afternoon and a good idea. Because they could.

None of that is wrong. But it creates a critical ambiguity that UX cannot fix from the outside:

Are you building for yourself, or for other people?

These are not the same mission. They don't share the same success metrics. They don't even share the same definition of "done." And if you're not clear on which one you're doing — or you start as one and quietly drift into the other — you will build something that satisfies neither.

Two Valid Modes. One Dangerous Confusion.

Building for yourself is legitimate and underrated. Some of the best tools ever made started as someone scratching their own itch. The builder is the user. The pain is bone-deep. The empathy is automatic.

But "I built this for me and it works great" is not a product. It's a prototype of a product. To make that leap, you have to do the translation work: who else has this problem? How are they different from me? What assumptions did I bake in that only apply to someone with my exact context?

Building for others means you don't get to start with the solution. You have to start with the person. Who are they? What aches? What workarounds are they already using? What would make them switch?

Most builders I meet are doing one of these while telling themselves they're doing the other. They're solving for themselves — their instincts, their preferences, their workflow — while pitching it as a product for thousands. The gap between those two things is where products go to quietly die.

What I Actually Do in Founder Conversations

When someone pitches me, they almost never open with the problem. They open with the product.

"It can do X, Y, Z. It integrates with your existing workflow. It uses AI to automate the process."

And I listen. Then I ask: who is this for, and why do they need it?

Then: how do you imagine people actually using this?

Not the investor pitch version. The real one. The workflow they picture. That's where the value lives — and that's also where I find out whether we're building for real humans or building for the founder's mental model of real humans. Those are very different things.

My job is to translate the beauty of what they've built into actual usefulness for actual humans. Sometimes those are the same. Often they're slightly different angles — and that slight difference is everything.

The Question UX Keeps Asking

I have blisters on my tongue from repeating some version of: what are we actually solving here?

Not because founders are careless. Most of them care deeply. But when you're building at speed, in a world where speed is the whole game, it's easy to skip the foundation. Features accumulate. Scope creeps. The original pain point gets buried.

Personas aren't a deliverable. They're a discipline. A problem statement isn't a slide. It's a filter.

Without them, you're not building a product. You're building a demonstration of what's technically possible. Which might be impressive. But impressive and useful are not the same thing.

Build to Make the World Slightly Better

Back to my developer friend: I'm not here to critique the tool. I'm here because watching someone teach themselves to think in users is genuinely one of my favorite things.

The gap in his ideation tool — the blurry persona, the missing questions — isn't a flaw. It's a first draft. It's the beginning of understanding why the why matters as much as the what.

Tech can build anything now.

That doesn't mean anything should be built. It means we have a responsibility to be clearer than ever about who we're building for and what ache we're solving. Because the cost of building the wrong thing has never been lower — and the opportunity cost of not building the right thing has never been higher.

So before you open your IDE. Before you prompt your AI. Before you name the thing:

Who is this for? Why do they need it? How do you imagine them actually using it?

Answer those three questions first. Everything else gets easier.

Kate Huezo is a founding designer and agentic AI UX specialist. She works with early-stage AI startups at the zero-to-one moment — when design decisions are hardest to undo and the right questions matter most.