Why product people should build more

What changed my mind on this was accessibility. Software development has become dramatically more approachable, mostly because of AI. Modern models let almost anyone put together something that runs: a small script, an automation, a little app, a website, a rough solution to a problem that was annoying you an hour ago. Tools like Cursor, Claude Code, v0, Bolt or Lovable have collapsed the distance between an idea and a working prototype from weeks into an afternoon. Some of this gets called “vibe coding,” half as a joke, but the shift underneath the joke is real: you describe what you want, watch something take shape, then poke at it, break it, fix it, and learn more in that loop than in a stack of documentation. Getting good at describing what you want, precisely and with the right constraints, turns out to be a real skill of its own.

The category is bigger than any single tool: GitHub Copilot, the low-code and no-code platforms, standards like MCP that let these models reach into your systems instead of just talking about them. But the names matter less than the change, and they will be different names in two years anyway. What matters is what it lets me do before anyone else is involved: test an idea myself. Put a rough, ugly, working version in front of a real person and watch their face, before a developer ever spends a sprint building the polished one. Half the ideas die at that step, cheaply, which is exactly where ideas should die.

None of this is the same as shipping. A prototype that works on my laptop is a world away from software real people depend on. No edge cases, no scale, no security, no one else's data to lose. But that gap is not a problem for what I'm describing. The gap is where the learning is.

To be clear about my own limits: I would not call myself a software developer, and I could not take a serious application from an empty repository all the way to production entirely alone. That is not false modesty; it is just true, and pretending otherwise would be the fastest way to lose an engineer's respect. But building my own small things has taught me more about software than any book or course ever did. I have had to deal, in miniature, with data flows, APIs, servers, databases, authentication, deployment, hosting, cloud services. And, more instructively than any of them, with all the small, stupid, specific ways those things break.

You do not learn technology by reading about it. You learn it by building something and running into the same wall every developer runs into: the config that is wrong for no reason, the thing that works locally and not in production, the error message that means something completely different from what it says. The wall is the lesson. You cannot get it secondhand.

That experience changes the conversations I have with engineers, and this is the real payoff. You start to talk at eye level. You understand why something a stakeholder called “a quick change” is not quick at all, and why something that sounds enormous is really a config flag. You spot technical risk earlier, while it is still cheap to avoid. You set better priorities, because you can feel the difference between what is hard and what only sounds hard. And, maybe most of all, you develop real respect for how much careful, invisible thought good software takes. The part that never shows up in a demo.

I want to be very clear about what this is not, because it is the way this argument usually goes wrong. It is not Product Managers replacing developers. It is the opposite. The better I understand how developers work, the better I can support them: protect their focus, scope things realistically, and push back on the stakeholder who wants everything by Friday. A PM who has felt how hard the work is becomes an ally, not a second-guesser. The goal is collaboration, not competition, and anyone using “I can build too” as a way to overrule engineers has completely missed the point.

Being technical today does not mean understanding every algorithm, or reversing a binary tree on a whiteboard, or memorizing how a database index works. It means being able to judge technical trade-offs: to hear two options and understand roughly what each one costs, to know which questions to ask, to smell when an estimate is optimistic, to tell the difference between “this is genuinely hard” and “I would rather not do this.” That kind of judgment used to take years of proximity to code. AI has made the on-ramp shorter than it has ever been, and for the first time that understanding is within reach of almost anyone willing to build a few things and pay attention to what breaks.

So the difference between a good Product Manager and an exceptional one is shifting. It used to be mostly business understanding: knowing the market, the customer, the numbers. That still matters. But increasingly, the edge is also the willingness to experience technology firsthand instead of managing it from a safe, comfortable distance.