The Marmation ReviewProduct Systems2 min read / Essay

Should product managers become AI builders?

The new skill is closer contact with software, not pretending product and engineering are the same job.

Written for

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 it under pressure

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 reasoning
Where the recommendation changes

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.

Read the reasoning

The 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.

  1. The state of AI in 2026 McKinsey

    Verify actual wording and survey population when quoted; does not mean SaaS is obsolete.

  2. Thoughtworks Technology Radar Thoughtworks

    Not day-one direct competitor in size; inspiration not copy. Editorial reference not Marmation affiliation

Discuss the decision in front of you Return to Product Systems