1/5
The PM job inverted: Andrew Ambrosino on Codex and AI-native product work
A five-card PM digest of Lenny’s conversation with OpenAI’s Andrew Ambrosino, focused on taste, prototype abundance, role overlap, and what Coda PMs can reuse.
This card set distills Lenny Rachitsky’s June 28, 2026 conversation with Andrew Ambrosino, product and engineering lead for the Codex desktop app at OpenAI. The episode centers on how AI changes the shape of product work: implementation gets cheaper, judgment gets scarcer, and the PM role moves closer to curation, orchestration, and taste. 1 2
Card Notes
- The PM job inverted. Ambrosino argues that the old product process was built around expensive implementation. In an AI-native team, many people can create working versions quickly, so the expensive work becomes deciding what deserves attention and how it should fit together. 2
- Choose the medium. He pushes back on the blunt idea that PRDs are dead. A document is still useful when the team needs product clarity around a vague area; a prototype is better when the team needs to stress-test an interaction pattern. 2
- Taste means curation. The useful version of taste is not just aesthetics. Ambrosino describes it as systems judgment: knowing the goal, how something fits the broader product, and which parts of many explorations should be folded into the real direction. 2
- Zone defense. OpenAI’s Codex team has more overlap between product, design, and engineering than a traditional team, but Ambrosino warns against pretending specialties no longer matter. The healthier shift is less fencing and more coverage. 2
- Coda PM lens. The practical takeaway for a Coda product manager is to turn AI abundance into operating rhythm: prototype faster, preserve the artifacts that explain decisions, and keep a visible map of who is covering which product risks.
Detailed Summary
Andrew Ambrosino’s core point is that AI flips the product-development cost structure. When teams can build rough versions of almost anything, the bottleneck is no longer getting from idea to artifact. The bottleneck becomes choosing the right artifact, interpreting many competing attempts, and deciding what should become part of the product system.
That does not make product discipline disappear. It raises the bar for it. The episode repeatedly separates tool access from disciplinary judgment: being able to write code does not mean someone automatically understands product strategy, design quality, finance, or organizational tradeoffs. Roles can overlap more, but specialties still carry accumulated practice.
The episode’s most reusable framework is the medium-choice rule:
- Use a document when the team is still trying to make a vague product area legible.
- Use a prototype when the team needs to test interaction, flow, or feel.
- Do not let a polished prototype imply that the thinking is ready for production.
For roadmaps, Ambrosino also describes a sharper near-term planning bias: the shorter-term the work, the more detail it needs; a nine-month plan in a fast-moving AI product area risks false precision. That is especially relevant for AI features where model capability, user behavior, and workflow expectations are moving together.
Coda Implications
For a Coda PM, the episode points toward a more artifact-native operating model:
- Turn PRDs into living decision spaces. A Coda doc should not just state the plan. It should show the uncertainty, alternatives, prototype links, decision log, and what would change the team’s mind.
- Make prototype review structured. If everyone can make versions, Coda can hold the review rubric: user problem, interaction bet, system fit, quality risks, and what should be folded into the canonical direction.
- Create a coverage map. A simple table can make zone defense explicit: product risk, owner, supporting functions, open questions, and latest artifact.
- Preserve taste as evidence. Capture why one direction is better than another, not just which direction won. That makes judgment reusable instead of trapped in meetings.
- Watch for new primitives. When repeated AI workflows appear across teams, treat them as candidates for templates, packs, automations, or embedded product surfaces.
Comments
Sign in to comment.