How The Leading AI Companies Do Product (Part 1)
Hey Ant here 👋 I write a newsletter that won't go viral - and that's the point.
Because hot takes, clickbait and AI slop won't help you ship better products. But practical content grounded in real work will - the kind I do every day on my own products and the product leaders I coach.
Join 15,000+ product people who subscribe. Same applies to my YouTube channel!
Recent posts you might have missed:
- Nobody's Actually Prioritising 'Value'
- Stop Using Epics & User Stories
- 8 Strategy Concepts Every PM Should Know
I’ve watched 30+ Interviews with the people behind Claude Code, Codex and Cursor. Here’s what they agree on, what they don’t and how all that compares to what I’m seeing on the ground.Let’s talk about how the leading AI companies do product!
Over the past several months I've gone down a rabbit hole watching just about every video and podcast interview I could find from someone working at Anthropic or Open AI.
Does everyone actually code?
Do PMs really ship 100 PRs a day?
What does working with the latest models look like?
And more importantly; what’s hype vs what’s genuinely an interesting shift?
This post became far too long for a single newsletter so I’ve cut it into two.
Today we’re going to cover:
The two fundamental shifts
What these companies consistently do (and what they don't agree on)
And next week we’ll continue with:
The skills survive in the AI era
Why copying all this will blow up in your face!
And what I'm actually seeing on the ground
Let's get into it.
FYI everything in this post I covered in my recent livestream if you prefer putting this on in the background.
The two BIG shifts
Shift 1: Everyone is a manager now
There’s a great management book called “Who Not How” by Dan Sullivan.
The core concept is that as a manager you need to stop asking "How can I do this?" and start asking "Who?”
Great IC (individual contributors aka not managers) are great at answering “how”. They’re whole job is about “how can I solve this problem in the best way?” But being a manager is a different beast. Your job is to create the environment to get the most out of the people solving those problems.
Hence your job is who is best to solve this problem and how can I enable them to solve it.
This is why sometimes your best people make poor managers.
And working with AI is a bit like this too - although not 100%.
But the shift is there. You need to shift away from asking "how do I do this?" to asking "how do I get AI to do this on my behalf?"
Here’s some real examples from my own business:
Metrics: I don’t open dashboards or analytics tools anymore. I have a set of agents that pull the data together and push insights to me. If I have a question, I just ask Claude of Codex and it will go and pull the data for me.
Hypotheses: I have a hypothesis tracker which is referenced by multiple agents regularly. For example, when metrics are pulled above an agent looks at what’s in my hypothesis list. It then looks to see if there is any new data that either supports or invalidates a hypothesis.
Tooling: I use Notion and my clients have tools like Jira, Linear and Confluence. Yes I almost never open these tools anymore. They still play an important part for documentation but it’s Claude and ChatGPT that reads, updates and manages them for me. In fact I have a weekly agent that sweeps my workspaces and will organise and clean up for me. Solving the problem we all have where confluence spaces get out of control and messy.
My livestream agent also reminded me that I needed to confirm my next live stream, which will be in 3 days on AI in product discovery, if you’re interested. I’m going to share how I’ve been using AI in discovery and we’re going to build one of these agents live!
Shift 2: The work got bigger
"On the Claude Code team, coding is rarely the slow part anymore.” - Fiona Fung who manages the Claude Code team at Anthropic
When coding is no longer the bottleneck a few interesting things happen.
Of course the pressure is shifted up and down stream but it also changes the way we think about breaking down the work.
In the past we’ve often broken work down from some large feature - even a future vision of it - into an MVP and then into smaller user stories and even day to day tasks.
This was necessary when building anything took a couple of days to multiple weeks.
Breaking down work into chunks that are a couple of hours to a couple of days long is effective to manage product development.
But when you can code the whole feature in a couple of days - or a subset of it - it kinda makes all this redundant.
And this is the second big shift. The work chunks up.
Kanban boards now have whole features on them rather than user stories.
And it’s not because we’ve suddenly moved back to waterfall, the unit of work has just gotten bigger.
What They All Claim to Do
Across all the interviews a few consistent practices kept showing up.
1. They're bottom-up
Cat Wu, Head of Product for Claude Code said on Lenny's podcast:
"We want to make sure every single person on the team feels empowered to take their idea from just an idea to out in the world in less than a week, sometimes even in a day."
This is a consistent theme across these AI companies. They all seem to be very bottoms-up.
And I was a bit skeptical at first but hearing Alexander Embiricos, who heads up Codex at OpenAI talk about this on Lenny’s podcast made me more of a believer.
Firstly because Alexander gives a very balanced view in his interview - he’s not “all roles are dead” in fact he’s kinda the opposite, says that it’s going to take a lot longer than we think.
But mostly because he gave an honest explanation of why it works for them: they genuinely don't know what's technically feasible next, or what will resonate. Nobody's done this before. So diverging fast, throwing a lot of different ideas out there to see what sticks, is a deliberate strategy for navigating uncharted territory.
Alexander makes the comparison to when he was running his startup, he said the path was relatively known. That they could put the effort in to say, yes this is where we should go and how it’s not the same at OpenAI.
Comments like this are the most important things to take away from these types of interviews because it’s the why. It also helps you decide what to do with the information - does it translate to your context? Does it need adapting?
For example, if you're a bank, you are not in uncharted territory. Your customers have clear problems with clear next steps. Extreme bottoms-up in a regulated enterprise probably won’t work.
It’s also important to understand how they enable this.
This isn’t everyone is shipping the same code.
Designers are often shipping low risk front end changes and PMs are shipping more simpler features. Engineers are still the ones working on the higher risk and more complex problems.
They also don’t ship to production. There’s still a PR review process, automated tests, evals and a whole suite of safe guards.
AND everything is shipped to a beta environment first. For Anthropic this is their research preview.
I worry that founders and executive have heard "everyone ships a feature every week" and forget all the scaffolding that makes this both safe and possible.
Even Cat Wu, the Head of Product for Claude Code conceded that there has been a cost to moving so fast with overlapping features, inconsistency and customers struggling to keep up.
2. Dogfooding
Another thing they all seem to universally practice is dogfooding.
If you’ve never heard of dogfooding before it’s where you use your own product.
It’s a great way to identify issues, bugs, improvements before your customers do and it’s also a great way to build empathy.
The danger with dogfooding is that you’re not always your ideal customers.
Alexander Embiricos talked about this happening with the Codex team when they realised that their AGI-pilled vision of the product was very different to how their customers say things so they dialled it back.
Which is a great reminder that dogfooding doesn’t replace discovery. You can’t just test and learn internally.
This was something else that came out in the postcasts and videos, they all clearly still did the basics.
And when I say basics I don’t mean writing PRDs (we’ll get to that in a minute).
I mean strategy, discovery, using data to drive decision making, etc.
3. Prototypes
Fiona Fung, who leads the Claude Code team at Anthropic tells a story about how when she started at Anthropic her and Brois, the Head of Engineering and creator of Claude Code had a disagreement and she almost did what she did before - book a meeting room and get them both around a whiteboard to debate it. But instead she decided, let’s just both prototype our paths and compare them.
And this is a theme that I’m seeing and something that has come up consistently throughout the podcasts.
When the cost (and time) to build a prototype dramatically reduces it takes the same time to produce the different prototypes and test them than it does to get around a whiteboard and discuss.
A simple example is AB testing. Often we’ll do 2-3 options but with AI you could spin up 10+ options.
And to be clear when I say prototype I don’t necessarily mean working code. Having the right fidelity still matters and even with AI creating several different designs in a design tool like the ones I explored in this live stream are much cheaper than producing code. Remember that there’s no tokenomics to consider. So whilst it might not be a big difference in time, tokens aren’t cheap!
5. Long running AI sessions
PRDs was a topic none of them could agree on.
Some talked about doing what is often referred to as ‘spec driven development’ where they create a plan.md file or a detailed specification (with the help of AI) that would then be handed to agents that would build from.
Others talked about giving less details and not doing PRDs or any form of specs, they would give the agents a clear goal and let the model figure it out.
But what they all aligned on is having different ways for agents to run more autonomously.
Whether you write down all the details as a PRD, spec, plan, or simply give the AI a goal. The core mechanics were the same.
To make agents run more autonomously you need to give them:
Context to make smart decisions
A clear view of the end state
A verification criteria that the agent can test itself against
The infrastructure for it to build → test itself → make fixes → repeat
This has been coined as ‘loop engineering’.
But it doesn’t matter what you call it. The goal is to allow agents to work on your behalf. To do that effectively they need to have the necessary context, skills, tools, and understanding of the end state to run for multiple hours building, testing and pivoting until it’s achieved the goal.
Some interesting practices are coming out of this space - and again there’s no consensus yet.
Some teams write specs.
Others iterate back-and-forth with no document at all.
Or use prototypes rather than specs or PRDs (works well for a UX/front end product, not so well for platforms)
Some specs are dynamic using HTML.
And a few are even allowing the model to determine all the details and execute on their own (ideally with a clear goal and verification criteria)
3. Roles are blurring
This has been the most talked about change. How we’re all becoming “Product Builders”.
I covered the Product Builder concept in How Product is Changing in 2026, so I won't rehash it all here.
However the noise about it hasn’t matched reality.
Whilst all the interviews talked of roles blurring none said that they had completely collapsed to ‘product builders.
On the contrary, these frontier companies are hiring more product managers, designers and engineers than ever!
But there was some nuance.
Several engineering leaders talked about hiring engineers with product taste as well as product and design leaders talking about hiring designers and PMs who can code (at least with AI).
The closest practical application of a single ‘product builder’ role talked about was Forward deployed engineers (FDE).
The idea behind FDEs is that engineers partner with customers or stakeholders to work directly with them to quickly build what they need.
As we know well as product people, just blindly building what customers are telling you isn’t a great method. So you want your FDEs to have discovery skills. One of the clips I shared in the live stream talked to this and Marty Cagan's written a good piece on this as well (link at the end).
So whilst roles might be blurring there’s still a need to have the core competencies that great designers, product managers and engineers bring.
The way I think about it is:
If the only value you bring as a designer is your ability to move pixels around in Figma, then yes a PM with AI can do your job.
Similarly if as a PM the only value you bring is creating jira tickets and scheduling meetings…
And same for engineering. If the only value you bring is the ability to write in a certain syntax, then yes AI has replaced you!
But for really great PMs, designers and engineers that’s not true and these companies know that.
A really great designer is creative, they bring a depth of skills around user research, customer empathy, usability patterns, maybe even graphic design like typography, iconography, etc.
A great PM has the ability to look around corners, have a sense of what will resonate vs not. They’re also creative but have strong commercial acumen. They can break down complex problems, find what’s the highest leverage and focus a team on that.
Great engineers are expert problem solvers. They bring a wealth of knowledge around architecture, solution design, patterns, etc. They’re creative in a solution sense. Knowing what is technically capable they’re often the ones who come up with the most innovative solutions.
Which is why I sit on the side of not seeing these roles going anywhere soon.
I could go on but I think this illustrates the point.
That’s it for this week. Next week we’ll continue with part 2, taking a look at the skills in the AI era and what I’m seeing on the ground.
The four skills that consistently came up were:
Taste
Customer understanding
Judgement
Verification
We’ll dive into these and more next week!
One quick note before I close this post out.
Don’t just blindly copy these companies.
I’ve already talked about the misinterpretation of “shipping something every week” but it’s also dangerous because you don’t have their context. You’re not a frontier AI company building these LLMs. You might be regulated!
You also might not have the same level of talent or people - and that’s not a dig at you, here’s a practical example that we’ll talk more about in next week’s post;
If the engineers in your company need a jira ticket to be created, things to be clearly defined before they build it, then don’t be surprised if they struggle when you ask them to be either FDEs or to identify a customer problem and ship something end-to-end in a week.
Similarly (so I’m not just picking on engineers) if your product managers aren’t technical enough to understand how the product works technically or they’re not technical enough to even get themselves set up with Claude Code then don’t be surprised if they struggle to ship something.
It’s not as easy as saying “we’re all product builders now” there’s a lot of competencies and skills that you might not have historically nurtured in your company.
I hope this was insightful - stay tuned for next week’s continuation. that helps.
And a reminder of this week’s live stream - it’s in 3 days!
If it resonated, forward it to a product person who's being sold the 5x promise right now.
And as always, if you have any questions — hit reply, it comes straight to me.
Thanks for reading!
/Ant
FYI — I'm running a series of hands-on AI workshops over the next two months, exclusive to the Product Mentorship. We’ve already kicked off the first two workshops. This week we’re covering building your own product brain with AI, advanced AI concepts like Loops and in October we’re covering AI for discovery, strategy and delivery. More details on the workshops here.
Your OKRs don’t live in a vacuum.
Yet this is exactly how I see many organizations treat their OKRs.
They jump on the bandwagon and create OKRs void of any context.
Here’s what I see all the time…