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)
