By Tan Simin
The Best AI Engineer on My Team Still Isn’t the Product Owner
A functional product isn't necessarily a good product. Someone still needs to connect the technical possibilities with user needs, define the experience, make trade-offs and push for something people actually want to use.
One of the strangest things I've learned from building with Claude Code is that I often trust its technical judgement more than my own.
It can inspect a codebase in seconds, identify dependencies I hadn't noticed and suggest solutions I wouldn't have thought of, but that doesn't mean I should let it make all the product decisions.
Claude Knows How to Build. I Know Why We're Building.
When Claude proposes a technical solution, I can usually learn something from it, but it doesn't automatically know which user problem matters most, what the product should feel like, or which trade-off I'm willing to make.
That's my job. That's the importance and value of a PM. It is on us to say: “No, that's not what we're trying to achieve.”
I Challenge It Anyway
The interesting part is that I don't treat AI as an authority just because it's technically stronger than me. I'll question its assumptions, propose an alternative, or point out a product implication it hasn't considered. Sometimes, it agrees that my concern changes the solution.
That dynamic feels less like using a tool and more like working with an extremely capable engineer.
The PM Becomes the Bottleneck
This has changed how I think about the PM role in an AI-native development process. When implementation becomes dramatically faster, the bottleneck shifts from building to deciding.
What should we build? Why does it matter? What does “good” look like? What should we deliberately not build?
AI can help answer these questions, but it shouldn't silently own them.
AI Doesn't Remove Product Taste
A functional product isn't necessarily a good product. Someone still needs to connect the technical possibilities with user needs, define the experience, make trade-offs and push for something people actually want to use.
For me, that's the PM's job.
Conclusion: I don't need to be the best engineer in the room. I need to be the person who knows what we're building, why we're building it, and when the technically correct answer isn't the right product answer.