ExpertsFMOpenAI Codex lead on the new shape of product work | Andrew Ambrosino
Lenny's Podcast: Product | Career | Growth · June 28, 2026
5 Selected Lessons:
heuristic · 2 framework · 2 priority · 1
Don't let role collapse erase specialized best practices
Source
Lenny's Podcast: Product | Career | Growth — OpenAI Codex lead on the new shape of product work | Andrew Ambrosino (June 28, 2026) · at 24:26 ▸
When this applies
when a hyped technology enables generalists to do tasks previously reserved for specialists, tempting an organization to eliminate the specialist function entirely
The takeaway
Lowering the barrier to entry for a skill (via new tools) does not eliminate the value of that discipline's accumulated knowledge — conflating 'can perform the task' with 'understands the discipline' is a category error.
Why it works
Each discipline accumulates real tried-and-tested best practices over time; removing the role removes institutional memory of what's been tried and failed, not just a job title, leading to repeated avoidable mistakes.
One level up
Distinguish between removing artificial gatekeeping (tool-based barriers) and removing genuine expertise (knowledge-based barriers) when restructuring around new capability.
Where it stops holding
This stops working when a discipline's 'best practices' were actually just tool-fluency gatekeeping with no real underlying knowledge — in that narrower case, collapsing the role is fine.
Detail
hierarchy:
- Preserve disciplines' accumulated best practices and knowable specialties
- Remove artificial boundaries/gatekeeping based solely on tool fluency
- Allow role fluidity in execution, not in disregard of expertise
rationale: I've heard a lot of companies be like, we're getting rid of the product role... and then what happens is they abandon this discipline that's been built up with real best practices, real things that have been tried and failed.
In their words
I've heard a lot of companies be like, we're getting rid of the product role. Which I think is, by the way, a terrible idea. And everybody's just gonna be like a builder.
Defining 'taste' as a multi-layered judgment skill
Source
Lenny's Podcast: Product | Career | Growth — OpenAI Codex lead on the new shape of product work | Andrew Ambrosino (June 28, 2026) · at 8:28 ▸
When this applies
when trying to operationalize 'good judgment' or 'taste' as a hiring/evaluation criterion in any creative or product field
The takeaway
Decompose a fuzzy evaluative skill like 'taste' into concrete sub-components (aesthetic fit, systemic coherence, strategic framing) so it can be taught, hired for, and checked.
Why it works
Good judgment integrates aesthetic sense, systems thinking (how a piece fits the whole), and strategic sense (what the goal even is), not just surface visual polish — so narrow aesthetic-only definitions miss most of the real decision-making load.
One level up
Vague virtue-words used as hiring/evaluation criteria should be unpacked into their actual component judgments before being trusted.
Where it stops holding
This stops working when the domain truly has no systemic or strategic ambiguity (purely mechanical, single-criterion tasks), where aesthetic/systems judgment doesn't add value.
Detail
procedure:
- Ask: does this fit the system (systems thinking)?
- Ask: does this match our theme/direction (strategic framing)?
- Ask: does this specific detail (animation, interaction) match its intended semantic meaning (aesthetic/craft fit)?
- Ask: if we can build anything, what's actually the goal here and how do we get there (the 'real' taste question)
benchmarks: {}
rationale: Aesthetic taste alone (e.g. visual polish) is necessary but insufficient; the deepest form of taste is deciding what should exist at all given unlimited build capacity.
In their words
there's like the the like what should this be? If we can build anything, what's the goal here and how do we get there? That I think is actually the real taste question here.
Build-and-bank: create artifacts now, re-test them against future model upgrades
Source
Lenny's Podcast: Product | Career | Growth — OpenAI Codex lead on the new shape of product work | Andrew Ambrosino (June 28, 2026) · at 31:38 ▸ · at 34:04 ▸
When this applies
when a product/feature idea fails today only because the enabling technology (AI capability, infra, cost curve) isn't there yet
The takeaway
When failure is driven by an external, improving variable rather than conceptual flaw, bank the work as a standing test case and periodically re-trigger it against the improved variable instead of discarding it.
Why it works
Building a working artifact, even if imperfect, creates a reusable test harness; as the underlying capability improves, you can cheaply re-run the same feature against the new capability rather than re-deriving it from scratch, and whether a feature is 'good' becomes a function of model intelligence, not just shape.
One level up
Separate 'is this concept wrong' from 'is this concept just waiting on an external capability curve' and design your process to re-test the latter cheaply over time.
Where it stops holding
This stops working when the failure is actually due to the feature's conceptual shape being wrong, not insufficient capability — re-testing it repeatedly would just waste resources on a fundamentally flawed idea.
Detail
procedure:
- List all features you're interested in building over the next year or two
- Prototype all of them
- Decide which are ready now and ship those
- Let the rest sit and bake as artifacts
- Each time there's a model capability leap, re-try the baked features with the new model swapped in
benchmarks: {}
rationale: Whether these features were good or not was based on whether the model was smart enough, not the shape of the feature itself — so re-testing against new models is cheap and valuable.
In their words
Let's prototype all of them, decide which things are ready now, and then just let the others sit and bake. And then every time there's like a new leap in models, let's try that thing again with it swapped out.
Pick the medium for the message, not out of habit
Source
Lenny's Podcast: Product | Career | Growth — OpenAI Codex lead on the new shape of product work | Andrew Ambrosino (June 28, 2026) · at 5:22 ▸ · at 8:28 ▸ · at 16:16 ▸
When this applies
when choosing a communication artifact (doc, prototype, deck, demo) to convey an idea inside an organization
The takeaway
Choose your communication medium based on the specific clarity goal you need (abstract direction vs. concrete interaction testing), not based on what's currently fashionable or easiest to produce.
Why it works
Different artifacts carry different implicit signals (a polished prototype implies something is late-stage and de-risked); mismatching artifact to actual stage misleads stakeholders into premature decisions.
One level up
Artifacts are signals as much as content; be deliberate about what signal you're sending, independent of how cheap the artifact became to produce.
Where it stops holding
This stops working when everyone in the organization already shares calibrated expectations about what each medium implies, so mismatched signals don't cause confusion.
Detail
rule: If your goal is product clarity around a vague area, use a document; if your goal is to stress-test an interaction pattern, use a prototype.
threshold: Ask explicitly 'what point am I trying to make and what stage of the process is this' before choosing format.
rationale: Because implementation is now abundant, people default to whichever artifact is cheapest to make rather than the one that best matches their communicative goal — and polished prototypes falsely signal 'ready for production' even when still exploratory.
In their words
If that point is product clarity around a vague area, then it might actually be a document. If what you're trying to do is get something in people's hands to try out and to stress test an interaction pattern, it's a prototype.
Blank-slate agent discovery: start with curiosity and intentional outcome, not a prescribed use case
Source
Lenny's Podcast: Product | Career | Growth — OpenAI Codex lead on the new shape of product work | Andrew Ambrosino (June 28, 2026) · at 1:06:38 ▸
When this applies
when adopting any new general-purpose AI tool whose product surface wasn't designed for your particular job
The takeaway
When facing a general-purpose tool not designed for your task, the way to extract value is to bring curiosity plus a clearly intended outcome and simply try it, since the cost of experimentation is low.
Why it works
A sufficiently general-purpose tool's value is discovered empirically by users applying curiosity and a clear intended outcome, since the tool's maker cannot anticipate every use case in advance; low cost of experimentation (a few tokens) makes this discovery cheap.
One level up
In low-cost-of-failure environments, discovery by trial dominates discovery by specification.
Where it stops holding
This stops working when the cost or risk of experimentation is high (e.g., production systems, regulated data), where blind trial-and-error is not advisable.
Detail
rule: Approach an unfamiliar general-purpose AI tool with curiosity and an intentional outcome, and just try it — there's minimal risk given the low cost (a few tokens) of experimentation.
threshold: Cost of trying is 'a few tokens' — effectively negligible, which justifies broad experimentation.
rationale: Basically, every job we feel like starts with a story like this, which is the product's not designed for it, but it's sort of a blank chatbot that can write code, so it can do everything, but what are the useful things for it to do.
In their words
Mean, people just have to have curiosity about the project. They have to, have an intentional outcome and use Codex as the platform for that just to see what happens. There's no risk at all.