Why a Category Matters More Than a Product

Most founders start with a product. They sketch screens, list features, picture the user. It feels like the responsible thing to do — make something real, then go find customers. But I've come to think the most important work often happens before any of that. It's deciding what kind of thing your product is. The category. And the category can matter more than the features.

You can see this when two companies build nearly the same software and get completely different results. One becomes the default. The other struggles to get anyone to care. The code wasn't the difference. The difference was the space each one claimed in the customer's head. It's almost always easier to teach someone a new kind of thing than to convince them to switch to a slightly better version of a thing they already use.

A category starts with what you call it. Name your product a "sales automation tool" and you've just walked into a crowded room full of CRMs and AI assistants, and now you're one more of those. Call it a "relationship intelligence platform" and you're standing somewhere with more room. Same product. But it gets compared to different things, and the comparison decides what people expect and whether they're interested at all. Investors and journalists react to the framing before they ever look at the thing itself.

The category does something the product can't: it defines the problem. A product solves a problem. A category tells people the problem exists and is worth caring about. Stripe didn't sell payment infrastructure — they sold developers a way to take money without dealing with banks. Slack didn't sell chat. It sold the idea that there should be a single place where work happens. Those framings did more work than the first version of either product, and they did it before the product was any good.

This is also where Memory Escrow died, and looking back it died at the category, not the code. The idea — metered, rule-based AI access to your data — addressed a real worry. But there was no category to put it in. People didn't already feel they needed "an AI memory layer," so I'd have had to create that need from scratch, and the technical reality undercut me: AI works better with more context, so the whole premise cut against itself. The problem I was naming wasn't one users recognized, which made the category impossible to sell. No amount of polishing the product would have fixed that.

That's the useful thing about thinking in categories early. It's diagnostic. Trying to name the category forces you to ask whether the problem is real, whether you can explain it, whether the solution even makes sense. A strong category can carry a weak first product. A weak category sinks a good one. Better to find that out by struggling to write the one-sentence pitch than by struggling to get downloads.

It also makes building easier, which surprised me. Once you know the category, feature decisions get simpler. The question stops being "what should I build" and becomes "what does this category need to be true." The features start serving the idea instead of accumulating into a pile.

There's a limit, of course. You can define a category too aggressively, or too early, and lose people. If the framing is too foreign nobody follows; if it oversells, nobody believes it. The trick is the balance — new enough to make someone pay attention, familiar enough that they can place it. You get better at this by studying how other categories formed, and by playing with the words before you write any code.

So I'd tell a founder to spend as much thought on the category as on the product. Without one, you're just another option in a crowded market. With one, you get to decide what market it is.