← Back to the blog

Article

I'm a product builder

Some of the most fun I've had in my career has come in the last year: cutting a branch, opening a PR, getting CI to go green, and merging a change into production in a matter of days, sometimes hours. I do this at work and on my own side projects now, and it's still a rush every time. A few years ago, a product manager couldn't do that without an engineer. For most PMs, that's still true.

Earlier this year, Harrison Chase at LangChain wrote about how coding agents are reshaping product, design, and engineering teams, and a lot of it matches what I see. He splits the future into two kinds of roles. Builders use coding agents to take features from idea to production. Reviewers are deep specialists who check that what gets built is sound. I'm clearly heading toward the builder side, and I think he's right about that role. The reviewer half is where I disagree.

Everyone can do more of each other's jobs now

Engineers can do product thinking and design work. Product managers can write and ship code. Designers can build working prototypes and reason about how a system should be put together. With Claude Code and Claude Design, the hands-on work that used to belong to one role is open to anyone willing to learn the tools.

Instinct is harder to hand over. Most engineers, designers, and product managers ended up in those roles because something about the work fit how they think. Add years or decades of daily practice, and you get someone who can look at a half-built feature and tell you quickly whether it's any good. A prompt doesn't give you that. And as coding agents produce more prototypes, features, and pull requests, a lot more work needs someone with that instinct to look at it.

Why "reviewer" undersells the job

The word makes the job sound like proofreading: wait for the work to arrive, approve it or send it back. When an experienced engineer looks at a prototype, they can point to the part that will fall over under load. A designer can walk through a flow and tell you exactly where a user will get stuck. A strong product manager can look at a feature and tell you whether it solves the customer's problem or only looks like it does.

Each of them is answering the same questions from a different angle. Was this built with the customer in mind? Does it solve their problem? Is it easy to use? Is it built well, and will it hold up as usage grows? Answering those quickly, while the work is still moving, keeps the team headed in the right direction. I'd call that evaluating, or steering. It happens throughout the build, from every discipline, and it's some of the most skilled work on the team.

Why product management is hardest to automate

I'm biased, but I think product management is the role AI will have the hardest time replacing, because so much of it is soft skills: communication, stakeholder management, influence, and pulling a lot of different points of view into one plan.

Engineering and design both have a large tactical core, and that's the part coding agents are taking over first. Product management has one too. PMs shouldn't be writing Jira tickets or user stories by hand anymore; Claude can draft those. Product managers have always been able to work down at that level. The job has also always covered two higher ones.

The middle level is the roadmap. That means keeping a rolling plan three or four months out, so that when one quarter ends, the team already knows what the next one holds, and making sure designers and engineers are working on and prioritizing the right problems. The top level is strategy. Does what we're building serve the company's goals? Does it match what sales, marketing, and support are doing? Are the executives bought in? Are good ideas from executives and other stakeholders making it into the plan?

That's glue work: hours of conversation, persuasion, and synthesis across a dozen relationships at once. I don't see AI doing that anytime soon, because the work is getting a group of people to agree on what to build and why.

The builder part

The new piece is that product managers can now deliver, too. A PM can talk to customers, validate an idea, get stakeholders on board, set the roadmap, and then build some of it. If the designer is busy, I can design it. If engineering is booked, I can ship it. On a small feature, I can do the whole thing start to finish.

I wouldn't want to do that full time. The roadmap and the stakeholder work are still the core of the job. But I can make the product better in small and medium ways, and occasionally larger ones, without waiting for someone else's sprint to open up.

The specialists matter as much as ever. What's changed is that anyone in product, design, or engineering can now move between the details and the big picture in the same week, sometimes the same day. Product managers have always had to move between those levels. Now we can build at every one of them, and that's the most exciting shift I've seen in my career.

Keep reading

← Back to the blog