Over the past year I’ve used AI coding tools to build things I never would have attempted on my own. Nova, Cruxwire, Ceres, Backyard Birds, a dozen smaller tools. All small, all personal, all running in my house right now. I’m not an engineer, and these projects haven’t turned me into one. But building them changed how I think about my own job, and I suspect it’s a preview of where product management is heading.
For most of my career, the distance between an idea and working software ran through an engineering team, and for good reason. Building real products takes skills I don’t have. What’s changed is that for small personal projects, the tools can now carry someone like me across that distance. Crossing it myself, even at hobby scale, taught me more about the PM job than I expected.
What The Tools Took Over
The parts of building I couldn’t do myself are largely handled now, at least at this scale. The first draft of the code, the boilerplate, the plumbing of wiring services together. When I have an idea for Ceres, the distance to a running version is measured in hours.
I want to be careful with that claim. None of these projects have to survive real users, real scale, or a security review. Professional engineers spend most of their time on exactly those problems, and nothing I’ve used comes close to replacing that judgment. What the tools removed, for me, was the barrier to finding out whether an idea is any good.
What Still Matters, And Matters More
Here’s the part that surprised me. Removing the building constraint didn’t make the product skills less important. It made them the whole game. When you can build almost anything quickly, the only thing separating a good result from a wasted weekend is deciding what’s worth building.
Problem selection. Judgment about what to leave out. A feel for when something is done versus when I’m just tired of it. I picked up those instincts over years of working alongside engineers, designers, and users who were generous enough to tell me when I was wrong. The week I tore out half of Ceres’s schema wasn’t a technical achievement. It was a product call, and it was the most valuable thing I did that week.
The New Skills That Showed Up
A few skills showed up that I didn’t need before, and they’re specific to building on models. Designing evals, because you can’t trust a probabilistic feature you haven’t measured. Choosing models and deciding where they run, because cost and latency are product decisions now. Orchestrating agents, and more often deciding not to. Setting confidence thresholds, because that’s where you trade one kind of mistake for another.
I’m early on all of these. But they feel less like engineering skills and more like product skills wearing new clothes, which is probably why I’ve enjoyed them.
The PM This Points Toward
I don’t think any of this replaces the core of the job. Understanding users, earning trust with a team, saying no well. If anything, a working prototype I can hand an engineer is a better conversation starter than a spec ever was.
But a PM who can get from problem to running software, who owns the judgment calls the model can’t make, and who’s comfortable with the probabilistic parts, has a shorter path from question to answer. The bottleneck moves from building capacity to the quality of your decisions.
That’s a version of the job I’d like to keep getting better at. Building these projects in my spare time has mostly been me practicing.
