How do you build something people actually want?

The fastest path to product-market fit is deceptively simple: solve a problem you personally have, then get obsessively close to the first people who share it. Most founders fail not because they can't execute, but because they spend months building something nobody needed in the first place. The frameworks below give you a repeatable method to avoid that trap.

Start with a problem you live inside

The single most reliable signal that a product is worth building is that you yourself desperately want it to exist. This isn't just motivational advice—it's an epistemological shortcut. When you are the user, you have ground-truth access to what the problem actually feels like, which features matter versus which just sound good in a pitch, and where existing alternatives fall frustratingly short. Paul Graham's point about building what you yourself want to use is one of the most under-applied ideas in startupland, precisely because it sounds too obvious to be actionable.

The practical implication is that you should be suspicious of ideas you arrived at through desk research or brainstorming sessions rather than through lived frustration. If you've never felt the pain of the problem you're solving, you're essentially working from a map drawn by someone else—and maps are always wrong in ways that matter. Your competitors who do live inside the problem will outmaneuver you on intuition every time.

This also means your early adopters are easier to find than you think. If the problem is real and you have it, your friends, colleagues, and professional network probably have some version of it too. That overlap is your initial audience—people who already understand why the problem is annoying, who won't need convincing that it's worth solving, and who'll give you honest feedback because they want the solution as much as you do.

Do things that don't scale—on purpose

Every founder worries about scalability. It's almost always the wrong thing to worry about first. Graham's argument in his essay on unscalable tactics is that doing things manually, personally, and inefficiently with your first users is not a compromise—it's a method. The feedback you get from ten deeply engaged users is worth more than survey data from ten thousand passive ones.

One specific tactic worth adopting immediately: pick a single target user and treat your product like a custom consulting engagement built for just them. This sounds like it defeats the point of building a product, but it doesn't. The constraints of one real human with real needs will force you to make decisions that abstract product thinking never will. Once you've nailed the fit for that one user, you'll almost always find that the adjacent population of users who share the same need is larger than you expected.

Another underused practice is physically watching people use your product—not asking them about it afterward, but sitting with them while they struggle, succeed, skip features you thought were obvious, or get confused by copy you thought was clear. This kind of direct observation surfaces problems that no user would ever think to articulate in a feedback form. As Graham notes in 'Do Things that Don't Scale,' the feedback from your earliest users is the best you'll ever get; once you're big enough to need focus groups, you'll miss this window deeply.

The fear that this attention won't scale is almost always wrong in two ways: first, most of the lessons you learn transfer into product improvements that serve everyone; and second, a culture of caring about users at the individual level tends to persist inside companies that build it early.

Find the narrow market first, then expand

One of the most counterintuitive moves in early product development is deliberately shrinking your target audience. The instinct is to maximize potential reach from day one—broader market means more opportunity. But in practice, a product that tries to serve everyone at launch tends to serve no one particularly well, which means no one feels compelled to tell their friends about it.

Facebook's early strategy illustrates this pattern well. By restricting the platform to Harvard students initially, the product became intensely relevant to a small group rather than mildly interesting to a large one. That intensity created the critical mass that made expansion possible. The narrowness wasn't a constraint—it was the engine. As Graham explains in 'Do Things that Don't Scale,' this 'fire' approach—containing the burn to build heat before adding fuel—applies well beyond social networks.

For B2B founders, this means picking one industry vertical, one company size, or even one job function and making your product so specifically useful to that slice that they'd feel its absence immediately. For consumer founders, it often means one city, one community, or one behavioral niche. The goal is to earn passionate users, not polite ones. Passionate users spread products. Polite users churn.

Diagnose demand by what users do, not what they say

User feedback is a noisy signal and you have to learn to read it correctly. What people say they want in interviews and what they actually do with a product are reliably different—not because users lie, but because it's genuinely hard to introspect on your own behavior before you've experienced an alternative. Your job is to triangulate between their words, their actions, and the outcomes they're trying to achieve.

A useful diagnostic: look for the users who find workarounds. If someone is duct-taping together three tools to approximate what your product could do natively, that's a powerful signal of latent demand. They've already voted with their time—the most honest currency. Similarly, look for users who adopt your product in ways you didn't design for. Unexpected use cases often reveal a deeper need than the one you set out to solve.

Writing down what you're learning—not just logging it in a spreadsheet, but actually articulating the user's problem in prose—forces a clarity that passive note-taking doesn't. Graham's observation in 'Putting Ideas into Words' about how writing surfaces unconscious knowledge applies directly here: the act of writing a crisp problem statement will expose gaps in your own understanding that you'd otherwise paper over. Many founders have discovered, mid-draft, that they couldn't actually explain clearly why their target user had the problem they were solving—which is the right time to find that out.

Use genuine curiosity as a quality filter

There's a practical reason why product curiosity matters beyond the motivational cliché. Graham's framework in 'How to Do Great Work' identifies curiosity, delight, and the desire to do something impressive as the three most powerful drivers of sustained hard work. For founders, curiosity functions as a built-in quality filter: if you're not genuinely curious about the problem—if you don't find yourself thinking about it in the shower, reading tangential articles about it, or getting annoyed when you see bad solutions to it—you'll consistently underinvest in understanding it deeply enough to solve it well.

This is especially relevant when evaluating which user feedback to act on. A founder who is deeply curious about a problem space can distinguish between feedback that reflects a real structural pain and feedback that reflects a user's surface-level articulation of a different underlying issue. Without that curiosity-driven depth of understanding, you'll tend to build features reactively rather than synthesizing what you're hearing into a coherent insight about what people actually need.

The filtering function also applies to the problem space itself. If you find that certain customer conversations energize you and others feel like an obligation, pay attention to that asymmetry. The customer segment that energizes you is probably the one you'll serve best, because you'll think harder about their problems, tolerate more ambiguity in solving them, and care more about whether the solution actually works.

“I have never once seen a startup lured down a blind alley by trying too hard to make their initial users happy.”

— Paul Graham, source

The one thing to do

Pick one person who desperately needs what you're building, sit with them while they use it this week, and let what you observe—not what they say—drive your next build decision.

Frequently asked questions

What if I'm not my own target user—can I still build something people want?

Yes, but you have to work much harder to compensate. You need sustained, direct access to people who live inside the problem—not occasional interviews, but ongoing relationships where you can observe behavior over time. The risk is that you'll always be one step removed from ground truth, which tends to slow down your iteration loop significantly.

How many users do I need to talk to before I build anything?

Fewer than you think for directional insight, more than you want for confidence. Five to ten deep conversations with people who genuinely have the problem will surface the core patterns. The mistake is treating early conversations as a box to check rather than an ongoing practice—you should still be talking to users every week even after you've shipped.

How do I know when I've found real demand versus polite interest?

Real demand shows up as action: users who find workarounds, who come back without prompting, who refer others without being asked, or who get visibly frustrated when the product breaks. Polite interest shows up as positive survey responses paired with low engagement. Trust behavior over stated sentiment.

Should I start with a broad product and narrow down, or start narrow and expand?

Almost always start narrow. A product that's intensely useful to a small group is far easier to improve than one that's vaguely useful to everyone. Narrow markets give you faster feedback loops, more passionate early users, and clearer signals about what actually matters—all of which make expansion much more tractable.

Sources

More playbook answers · Growth Prophet home