Should product managers become AI builders?
The new skill is closer contact with software, not pretending product and engineering are the same job.
CPO, VP Product, VP Engineering
The argument in brief.
The traditional divide between product language and engineering implementation created avoidable translation work. AI tools can lower that friction by allowing product managers to test workflows, explore API constraints and document desired states in more concrete artifacts. The failure mode is letting that capability blur accountability for architecture, security and operations.
Put the idea under realistic pressure
A PM builds a draft invoice-review screen using an agent. The screen looks polished but accepts a total when the backing service returns an error. That is a valuable discovery if the team identifies the missing failure state early. It is dangerous if the prototype is treated as deployable without the transactional contract.
Read the reasoningWhen the recommendation changes
For simple low-risk internal tools, cross-functional teams can responsibly ship with less ceremony. In regulated, multi-tenant or financially consequential products, specialist reviews remain essential. The boundary depends on impact, not job title or enthusiasm for the tool.
Read the reasoningThe reasoning behind the recommendation.
A product manager can now produce an interactive feature sketch, interrogate a codebase and ask a coding agent to implement a small change. That is meaningful. It shortens the distance between an idea and something testable. But a prototype that compiles is not necessarily a product that should be released.
The decision behind the technology
The traditional divide between product language and engineering implementation created avoidable translation work. AI tools can lower that friction by allowing product managers to test workflows, explore API constraints and document desired states in more concrete artifacts. The failure mode is letting that capability blur accountability for architecture, security and operations.
A better way to frame the work
Give product managers a sandbox and a supported prototype workflow. Teach them to define state, error and permission requirements, inspect generated behavior, and use technical artifacts to ask better questions. Pair the prototype with a product brief and acceptance criteria. Engineers should review platform changes and own production decisions; the product manager should remain accountable for the customer problem and prioritization.
Put the idea under realistic pressure
A PM builds a draft invoice-review screen using an agent. The screen looks polished but accepts a total when the backing service returns an error. That is a valuable discovery if the team identifies the missing failure state early. It is dangerous if the prototype is treated as deployable without the transactional contract.
When the recommendation changes
For simple low-risk internal tools, cross-functional teams can responsibly ship with less ceremony. In regulated, multi-tenant or financially consequential products, specialist reviews remain essential. The boundary depends on impact, not job title or enthusiasm for the tool.
What to decide before moving forward
Create a prototype permission model, a required engineering review gate, product acceptance tests and a shared vocabulary for “demo,” “pilot” and “production.” Measure fewer misunderstood requirements and faster validation rather than counting generated screens.
References and context
McKinsey, State of AI 2026; Thoughtworks Technology Radar 2026.
Source notes
References supplied with this manuscript. Source scope and limitations are retained; inclusion is not an endorsement of every claim.
- The state of AI in 2026 McKinsey
Verify actual wording and survey population when quoted; does not mean SaaS is obsolete.
- Thoughtworks Technology Radar Thoughtworks
Not day-one direct competitor in size; inspiration not copy. Editorial reference not Marmation affiliation