Why Most Products Start With the Wrong Problem

The worst time to discover you are solving the wrong problem is after you have built the product.

Most teams skip problem definition not because they are careless, but because they are confident. They have a vision, a category, a sense of the market. That confidence is the trap. Categories are not problems. Markets are not people. And a product built for everyone is built for no one.

Start with a person, not a market

Broad audiences produce vague problems. The narrower the person you are designing for, the faster the real problem becomes visible.

The first version of Circa was a location-based online community for anyone. Users could post. Businesses could share deals. The marketing went out to a general audience with no particular person in mind.

It did not work.

The team narrowed the focus to college students. Not because the broader market was uninteresting, but because the narrower audience made the problem visible. College students were not missing a community platform. They were dealing with a specific, daily friction: social coordination spread across posters, GroupMe, Facebook, word of mouth, and a dozen other channels with no single place to find what was happening.

That is a real problem. You can describe the person experiencing it. You can observe the workaround they are already using. You can build something that replaces the workaround.

The test is simple: can you pick your target user out of a crowd? If the answer is no, your audience is too broad and your problem is probably wrong too.

The community vs. tool distinction

Here is where most product teams make the second mistake. They identify a real problem, then try to solve it by building a community instead of a tool.

Community is an outcome. It is what happens when enough people find a product useful enough to keep coming back and bring others. You cannot manufacture it by building a social feed and hoping people show up. If the feed is not active, people leave and do not return.

A tool is different. A tool gives a single person a reason to show up before anyone else is there. It solves the problem whether or not the community exists yet.

Circa shifted from building community infrastructure to building an event tool. One university. One focused problem. The tool worked for the first user before there were ten thousand of them.

The cold start problem is a problem definition problem

The cold start problem is when a product requires other users to be present before it is useful to any single user. It is usually treated as a distribution challenge. It is more often a sign that the problem was not defined narrowly enough.

When Circa launched, the team learned this directly. The product did not spread itself. An intern had to post flyers and seed existing channels to get the first users in the door. DMs were not in the product, so users shared social handles and moved their conversations off-platform.

Both of those observations were problem definition failures showing up as launch failures. The product had not fully solved the coordination problem, so users worked around it. Growth required manual intervention because the tool alone was not enough to pull people in.

The cold start problem is usually diagnosed as a distribution problem. It is often a product definition problem. When the tool solves a specific enough problem, users bring others because they want the people in their life to have the same tool. When the tool is broad or incomplete, the burden falls on marketing and manual seeding.

What to do before design starts

Talk to the specific person. Not a user persona, not a target demographic: the person you can pick out of a crowd.

Ask what they are currently doing to solve the problem. The workaround tells you more than any survey question. Circa users were coordinating across five channels because nothing existed that worked. That behavior told the team more about the real problem than any focus group would have.

Then ask whether you are building the thing that replaces the workaround, or the community you hope forms around it. If the answer is the community, go back a step. Find the tool first. The community follows the utility.

Scale comes after fit, not before

Narrowing your audience does not limit your ceiling. It gets you to product-market fit faster. Product-market fit is the point where users are pulling others in without prompting, because the tool solves a real problem well enough that they want the people around them to have it too. That is the only foundation worth scaling from.

A product that works deeply for one specific person is easier to expand than a product that works loosely for everyone. Once you understand the problem well enough that users are pulling in others without prompting, you have something worth growing. Until then, going wide spreads the same unresolved problem across a larger surface.

The v3 of Circa starts with an event-based tool built for the coordination problem, not a platform built for a community that might eventually form. Building the tool first is how you find out whether the community is worth building at all.

Final thoughts

Broad audiences produce vague problems. Vague problems produce products no one needed. The discipline is in the willingness to narrow before you build: one person, one problem, one workaround to replace. Once you have that, you have something worth scaling.