Frontier Advice For Product Managers
What Product managers can learn from one of the frontier AI devs - Simon Willison
Simon Willison is not just any developer. He co-created Django, the web framework behind Instagram, Pinterest and Spotify. He coined the term “prompt injection.” He’s shipped over 100 open-source projects. He’s been a 10x engineer for 25 years.
And these days, he is one of the best devs driving AI use to the max and bing able to verbalise the change that’s happening. In one of my last posts, I looked into all the reports of how Boris Cherny and his team write software and came up with the term option storming. In the case of Simon Willis, it’s much easier to distill
how he works,
what it means for companies trying to get there and especially
what learnings are hidden in this style of working for PMs.
If you like to study the sources, here is the whole video.
Simon Willison is not great at what he does now because he learned a couple of new tricks and hacks. he’s good because he knows what good looks like, and he basing his productivity on 25 years of pattern recognition, architectural taste, and engineering judgment he now throws at these tools. As he puts it: “Using coding agents well is taking every inch of my 25 years of experience as a software engineer.” Without that foundation, he’d be another mediocre AI engineer producing mediocre slop, just at higher speed.
That’s the first thing PMs need to understand. AI doesn’t replace expertise. It amplifies it. People getting the best results aren’t the ones who learned the newest tool first. They’re the ones who brought the deepest judgment to the table. Just like Simon is a good AI developer because he always was a good developer, those PMs will be great AI-PMs who know the trade. Sitting in front of Claude Code do augment your PM work, teh first rule to be successful with Claude’s output is: you have to know what good looks like, else all you produce is trash. But lots of it.
Now here’s what that means for us. A couple of topics and insights, transferred to our jobs.
Code is cheap. Not software. Code.
Writing code used to be the bottleneck. You’d hand a spec to engineering, wait three weeks if you were lucky. Same thing now - three hours, max. Simon : “Today, probably 95% of the code that I produce, I didn’t type it myself. I write so much of my code on my phone. I can get good work done walking the dog along the beach.”
But cheap code is not cheap software. Cheap code just moves the bottleneck. It moves it in two directions at once. That’s really basic Theory of Constraints.
Down into infrastructure: testing, quality, reliability, security. All the things that make code actually usable in production. Someone still needs to figure out if the thing works. If it’s safe. If it doesn’t break what you shipped last week.
And, secondly, up into decisions: what to build, why to build it, for whom, in what order. Taste. Judgment. Strategy. That’s PM territory. And it just became the scarcest resource in the room.
and that’s why you now need to understand how AI sped up coding works now. It changes the interfaces. It changes how handover and connection between product work and engineering work is happening. You need to understand how engineering works to be able to best leverage it. And this is now fundamentally changing.
“We’ve taken the writing code bit and we’ve massively accelerated that,” Simon says. “Now the bottlenecks are everywhere else.”
And we are part of that “everywhere else”.
Hint: While it is true that job descriptions become more polyvalent and generalist (or: M shaped people) will be in higher demand, and thus Product Management has the chance to go into more tactical and strategic directions at the same time, you should beware to try to become a paid designer, analyst and developer at the same time. The mental will become unbearable and we talk about that later in this article.
Option storming: prototype more, decide after
A major shift is that prototyping is now basically free and that changes the PM approach drastically.
Simon - his strong suit was always prototyping, now this is meaningless, not a differentiator anymore. He now prototypes three different ways a feature could work. Not one. Three. Because it costs almost nothing. Then he experiments, tries them, sees which sticks. “Any sort of feature that I want to design, I’ll often prototype three different ways it could work because that takes very little time.”
That’s the real core designer task: “Look at this, a little more in this direction, a little more of that?”
Think about what that does to how we make product decisions. We used to filter ideas early because building was expensive. We had to be right before we built. Our “intuition” was really just a filter born from scarcity. We killed ideas not because they were bad but because we couldn’t afford to try them.
Now we can afford to try them. All of them. So we need less filtering upfront and more judgment after the fact. Less predicting which idea will work and more recognizing which one does work when we see it running.
I call this option storming. Don’t pick the winner from a list. Build several. Watch them. Let the answer reveal itself.
Think → filter → judge → build → iterate
has become
Build → judge → kill /iterate
“A UI prototype is free now,” Simon says. “Anyone who’s doing product design and isn’t vibe coding little prototypes is missing out on the most powerful boost.”
But at the same time, the complexity hits us a t a different stage: “You’ve got three options now instead of one. How do you prove to yourself which one of those is the best? I don’t have a confident answer to that.” His best guess? The old-fashioned way. Get a real human on Zoom, screen share, watch what happens. “You can tell the AI to simulate your users. I don’t think that’s credible.”
Intuition was always just bias mistaken for experience. Now you don’t need it as a filter anymore. You need it as a lens — to see what’s working → but only once you’ve built it.
A year of less focus, more learning
Simon’s New Year’s resolution of this year is different: “Every previous year, I’ve always told myself, this year I’m going to focus more. I’m going to take on less things. This year, my ambition was take on more stuff and be more ambitious.”
That’s counterintuitive. But it’s the right move when the landscape is shifting this fast. This is not a year for rigid plans and clean OKRs. This is a year for leaning into the tools, dealing with AI on the ground level, learning on the go. Not a ton of structure. More reps. More experiments. More surface area.
Because right now, the only universal skill is being able to roll with the changes. And that’s valid beyond Simon. Have fun planning focus this year.
This is draining. That matters.
The dark side of the new game:
“I can fire up four agents in parallel and have them work on four different problems. By 11am, I am wiped out for the day.”
Simon Willison. One of the most productive engineers alive. Wiped out by 11am. And he’s not alone. Steve Yegge, one of the other AI coding wizards, discovering all the new technologies, called it the AI Vampire effect.
AI is supposed to make us more productive. Give us more time. Let us sit around. Delegate Admin and focus on what matters, what makes us human. Instead, the people most into AI are working harder than they’ve ever worked. There’s an element of gambling and addiction to how we’re using these tools. People are losing sleep. Setting off agents at midnight. Waking at 4am to check results. While Boris Cherny and the Claud Code team hand us remote control, so we “g, touch grass”.
This is a massive context change. On the macro level: your entire industry is restructuring. On the micro level: every task you do feels different than it did six months ago. That’s draining in a way that doesn’t show up on a task list.
The smart companies won’t just fire people to “save money” with AI. They’ll figure out that the bottleneck moved to human cognition and attention. They’ll build systems that account for that. The ones that burn out their best people for short-term throughput will regret it. (While probably too late, again. Dumb before AI → dumb with AI)
On a personal level, this needs to be dealt with. Not pushed through. Dealt with.
The 90/10 split
Kent Beck said it best, already a couple of years ago: “ 90% of my skills now have zero, value, the other 10% have 1000x value”. Yes, and that’s Kent Beck.
As a society and as individuals, we need to figure out which is which. Most of what we did as knowledge workers was execution. Translating decisions into artifacts. Writing the spec. Building the deck. Formatting the report. Drafting the email. That’s the 90% that just got cheap and lost value to the LLMs- let them handle it. Proudly.
The 10% that exploded in value? Judgment. Taste. Knowing what to build, when to stop, what to kill. Reading a room. Understanding a user. Making decisions nobody else will make.
Which leads us to the one thing AI fundamentally cannot have.
Agency as the moat
“I would argue that the one thing AI can never have is agency,” Simon says. “It doesn’t have human motivations. Sure, you can tell it to make more money or whatever, but it’s never going to be able to decide on its own what makes sense for it to act on next.”
AI agents have no agency. Zero. They can execute brilliantly. They cannot decide what matters. They cannot care. They cannot commit to a direction when the data is ambiguous and the stakes are real.
That’s what we do. PMs, designers, Management, humans - we decide what problems to take on. Where to go. What to ignore. That’s agency. And it’s the one irreplaceable human skill in a world where execution is getting automated.
Invest in your own agency. The rest is tooling.
The middle gets squeezed
Thoughtworks gathered a bunch of engineering VPs to figure out who benefits most from AI. Their finding: experienced people and beginners. The experienced ones amplify and leverage on decades of judgment. The - AI native - beginners ramp up faster than ever — Cloudflare and Shopify hired a thousand interns each because onboarding that used to take a month now takes a week.
Who is in trouble? Mid-career. Not senior enough to have deep expertise to amplify. Not new enough to get the onboarding boost.
This is true for PMs and designers too. New people who are AI-native ramp up fast. Senior people leverage decades of pattern recognition. The middle is exposed.
So what do you do if you’re in the middle? Lean in harder. Embrace the new tolls and techniques. You don’t wait for the company to figure it out for you. You use these tools to take on more ambitious work, learn faster, build judgment faster. Close the gap or get caught in it.
What a PM should do now
What does all of this mean for a mid manager, a strategist, finally and foremost a PM? Learn a harness. Claude Code, Cursor, Codex — pick one or two. Get comfortable. The specific tool matters less than building the muscle of working with AI agents.
But know this: it’s not about the harness. Learning the tool is not about learning the tool. It’s about how you think with it. Simon doesn’t get great results because he picked the right tool. (He’s actually switching between them a lot.) He gets great results because he knows what to ask for, when to push back, and when the output is wrong.
We can now go downstream into coding and upstream into strategy. But just because you can doesn’t mean you should. Choose wisely aligned with your profile, your context, your ambitions. Becoming a paid developer is probably not the move. Becoming a PM who can prototype, test, and ship without waiting for a sprint? That’s the move.
Concretely, things Simon’s work suggests PMs should be doing now: prototype features yourself before writing a spec. Build three versions, not one. Use AI for the first two-thirds of brainstorming, then push past the obvious. Run your own research — feed context to Claude and let it synthesize. Hoard what you learn: techniques that worked, experiments that failed, prototypes that surprised you. Store them somewhere you trust. Feed them back into future work. “The AI is absurdly good at reusing context you make available to it.”
Test ideas with real humans, not simulated ones. “You can tell the AI to simulate your users. I don’t think that’s credible. I don’t think you’re going to get as good results from ChatGPT pretending to click around on your prototype than you would from an actual human being.”
Lean in, embrace that change, enjoy the ride and be ambitious. This is the year.
The dark factory: questions we couldn’t ask before
The Extreme idea.
StrongDM, a legitimate security company, ran an experiment.
Two rules:
Nobody writes code.
Nobody reads code.
Everything is AI agents. In production. → For security software.
They built swarms of simulated employees in a simulated Slack channel, making requests 24 hours a day. “Hey, could somebody give me access to Jira?” Thousands of simulated users testing the software around the clock. $10,000 a day in tokens. They built their own simulated versions of Slack, Jira, and Okta because the real ones have rate limits.
It’s insane. And it asks questions we couldn’t even begin to ask before: How do you know your product is good if no human is reviewing the code? How do you build quality without human eyes? What does a QA department have to look like when it never sleeps and runs on API calls?
These aren’t really engineering questions. They are also product questions. They are strategy questions. And they’re coming at us fast.
The Challenger disaster is coming
Simon has been predicting what he calls the “Challenger disaster of AI” for three years. It hasn’t happened yet. But the logic is obvious.
“Lots of people knew that those little O-rings (of the Challenger) were unreliable. But every single time you get away with launching a space shuttle without the O-rings failing, you institutionally feel more confident in what you’re doing.”
Or just as experienced Skit Tourers always get closer to the edge, because - hey, it worked out fine until here.
We’re doing the same with AI. Using these systems in increasingly unsafe ways. We’re still getting away with it, feeling more and more confident. “We’ve been using these systems in increasingly unsafe ways. This is going to catch up with us.”
His “lethal trifecta” for any product: private data plus exposure to malicious instructions plus the ability to send data back to an attacker. If your product has all three, you have a problem no matter what AI guardrails will reliably solve. “You can get to 97% effectiveness on those filters. I think that’s a failing grade.”
We will probably not prevent the disaster to happen. But we can be aware. And we can learn from it when it comes.
People want to augment themselves
Open Claw went from first line of code to Super Bowl ad in three and a half months. Hundreds of thousands of people set it up even though it’s non-trivial, not secure, and actually messy and not really fun (don’t ask!).
The signal is out there ein the open: people desperately want a personal AI assistant that can actually do things. Read their email, take actions, figure stuff out. They’ll tolerate terrible UX and real security risks to get it.
Give my AI those claws!!!
Look at Anthropic’s Claude — reacting in real time, taking actions, remembering context. Look at every company scrambling to build their own version. It’s not about fulfilling simple feature requests. They’re noticing the basic human needs expresses beneath: remote control over the complexity of your own life.
Just like the smart phone was not about smartness, but safety, reachability and ubiquitous information. Now these smart phones become really smart and they have claws.
For PMs, this is a goldmine of signals. What people tolerate tells you what they crave. The unsafe things people do with AI (like setting up OpenClaw unprotected and giving it root access, something you don’t give to your college normally) tell you what the safe version should be. “If you can build safe OpenClaw, that’s a huge opportunity. I don’t know how to do it. If I knew how to do that, I’d be building it right now.”
Read those signals. Build for those needs.
Agency and exhaustion
Let’s close where we started.
Simon Willison is one of the best engineers in the world. He’s shipping more than ever. He’s more ambitious than ever. And he’s exhausted by 11am.
The tools are extraordinary. What they demand of us is also extraordinary. Not typing. Not building. Deciding. Judging. Holding context. Making calls. Caring about whether the thing actually works for real people.
That’s agency. That’s what makes us matter. And it’s the one thing that doesn’t scale with compute.
Invest in it. Protect it. Don’t burn it out chasing the dopamine of one more agent run at midnight.
The AI doesn’t get tired. You do. And your judgment when you’re exhausted is worth exactly nothing.