Build, build, build. But what?

Everyone is building. Every day a new tool launches with one goal, to help more people build faster. Every meeting I sit in, every coffee, every dinner, someone is showing me something they shipped over the weekend. It's exciting, and I mean that. But after the demo I keep asking the same two questions, and I rarely get a good answer to either. Build what? And why?

Everyone got promoted overnight

For a product person, this moment is strange. A free account, or a $20 one, turns anyone into a product manager and a developer at the same time. You describe what you want to Claude, ChatGPT or Gemini, and twenty minutes later there's a working app with a login screen. The part of the job that used to be the most visible, turning an idea into a spec that engineers could build from, now looks like something anyone can do in a chat window.

So the craft looks cheaper from the outside. If the output is software and anyone can produce software, what exactly is the product person on the team for? I hear that question more often now, sometimes said out loud, sometimes just implied by how a roadmap gets set.

Prompting is the smallest part of the job

Product was never mainly about telling someone what to build. That was the last step. Before it comes everything that decides whether the thing should exist at all. Is there a market, and is it big enough to matter? Who are the users, and what are they doing today instead? Who else is solving this, and why would anyone switch? Which stakeholders need to say yes, and what does each of them actually care about? How does it get sold, how does it get positioned, and what is the one sentence a customer will repeat to a colleague?

None of that shows up in a prompt. A model will happily build you a beautiful answer to a question nobody is asking. It will not tell you that three funded competitors already own the category, that your buyer and your user are different people with different incentives, or that the feature everyone asked for in interviews is the one nobody will pay for.

I saw a version of this in DeFi. Forking a protocol took an afternoon, so the market filled up with forks. The code was rarely the problem. Most of them had no reason to exist beyond the fact that they could, and they faded as fast as they appeared. Speed of building was never the bottleneck. Knowing what was worth building, for whom, and how it would win, was.

Keep building. Just don't confuse it with product.

To the builders and vibe coders: keep going. What you're doing is real, it's fun, and it's teaching a lot of people how software actually comes together. Some of the best product instincts I've seen started exactly like this, with someone scratching their own itch. I've written before that the ability to go from spec to working demo is a new superpower for product managers, and I still believe it.

But inside a company, shipping a prototype and owning a product are different jobs. The second one means living with the thing after launch: the market fit that moves under you, the stakeholders who pull in different directions, the positioning that decides whether anyone notices, the users who churn quietly for reasons they won't volunteer. That takes experience, judgment, and a profession's worth of pattern recognition. A subscription doesn't come with any of it.

If anything, the flood of builders makes that profession more valuable, not less. When building is cheap, the expensive mistake is building the wrong thing well. Someone on the team has to be accountable for that call.

Bottom lines

Building got cheap. Deciding what to build did not. The cost moved from execution to judgment, and judgment is still scarce.

Prompting is the last step of product work, not the job. Market, users, competition, stakeholders and positioning all come before it.

More builders means more noise. In a crowded market, knowing why something should exist is the differentiator.

Vibe coding and product management are allies, not substitutes. Teams win when builders move fast and a product person decides where.

This really is the time to build. The tools are extraordinary, and I use them every day. But the question at the start of every meeting shouldn't be what we can build this week. It should be what's worth building at all, and that question still belongs to someone whose job it is to answer it.