In May, I came back from ProductCon New York with one sentence in my notebook: the bottleneck moved. When building gets cheap, the hard part becomes deciding what to build, and organizing the people who decide.
ProductCon San Francisco took that sentence as the starting point. Nobody on stage argued that building is still the hard part. The arguments were about what comes next. Who has actually reached the judgment problem? Should product managers ship code themselves? And which parts of the work don't get faster no matter how good the models get?
Twelve sessions, five lessons.
1. You have to earn the judgment bottleneck
The talk I keep coming back to is Carlos González's, about Product School's own turnaround. He walked through five principles he had followed for a decade (delegate, speed is a commodity, PMs don't need to be technical, say no, buy don't build) and showed how each one quietly held his company back. His first move was a memo and a stack of purchased AI tools, and nothing changed. Things only moved when he and his leadership team did the work themselves.
His line: "You actually have to earn the privilege to be bottlenecked by judgment by unlocking speed first."
That corrects the New York consensus, and I think it's right. "The bottleneck moved" is true at AI labs and AI-native startups. Most companies are still arguing about what to build with speed they don't actually have yet. They skipped a step.
The companies that had earned it showed what that looks like. Webflow's Ben Haefele described a quarterly goal for every person in product, engineering and design to ship something to production, which they hit in July, plus a weekly company-wide Builder Day. Shiva Rajaraman described how MrBeast's team replaced off-the-shelf project tools with their own production system and now ships improvements to it every day. Someone flags a pain point in the afternoon, and the fix is live the next morning.
This is the argument I made in Transformation Is Earned in the Foothills. You don't train for Everest. You train up to it. Carlos gave that idea a sharper edge: speed is not the reward at the end of the transformation. It's the entry fee.
2. Should PMs ship code? The stage split
This was the most useful disagreement of the conference, and it happened between talks, not inside one.
Haefele's position: build backwards. Start from working code, react to it, design from there, and write the documentation last. He says the PRD now gets generated from the commit history after the fact. In his telling, this is what Agile always promised and never delivered: we had been running the same waterfall, just in two-week slices.
On the product development panel, Lucid's Phillip Badger took the other side. At his company, the PMs are the scarcest resource, so having them write production code is the wrong use of the bottleneck. Ohad Biron added a warning: some of his customers reached "backlog zero" and the business didn't move at all.
Jeff Chow from Miro sat in between: "Everything is a decision." Building the right thing was always the bottleneck. AI just removed the excuse.
My call: both are right, about different stages. A PM who has never shipped to production can't judge what's cheap and what's hard anymore, so every PM should ship. But a PM who measures themselves by what they shipped has picked the wrong scoreboard. The job is still deciding. Shipping is how you stay qualified to decide.
3. The org chart is finally catching up
In New York, Miro's Mathias Davidsen warned that a 10x individual does not make a 10x organization. San Francisco brought the first real answers.
Elena Verna from Lovable made the boldest one: "High IC is not a job title. It's an organizational operating system." If one person with AI can do a team's worth of work, the old rule that more direct reports means more impact (and more pay) stops making sense. At Lovable, new individual contributors and new VPs are hired at the same salary, so nobody has a money reason to manage. Verna asked 51 managers in her network whether they would go back to individual work at equal pay and status. Forty-two said yes.
Amandeep Khurana showed what the change looks like inside a team at Anthropic. Claude moved from answering questions, to owning tasks, to running a whole system, to acting as a teammate. His Monday staffing meeting used to lose its first twenty minutes to figuring out who was working on what. Now the agent keeps that picture current and chases people for updates. The moment that got a laugh: "And now Claude asks us questions."
Rajaraman named the missing piece directly: most companies have no memory unless everyone gets in a room. The organizations pulling ahead are building that memory as a product.
This is the same gap I wrote about in Access Is Not Adoption. A login isn't a capability. The capability comes from shared context, clear ownership, and a career path that rewards the new way of working. Verna's point about pay is the piece most leaders are avoiding, and probably the one that matters most.
4. Some things refuse to compress
The talks I learned the most from were the ones about what AI doesn't speed up.
Diana Kimball Berlin from Gamma said product-market fit now has to be re-earned about every three months. Her team ran a sprint where dozens of employees joined live calls with more than a hundred customers who had drifted away. Their rule: "Automate everything except the insight." Scheduling, recording and summaries were all automated. Watching a customer struggle was not, because a summary softens the pain, and feeling the pain is what points you at the right fix.
Courtney Lessard told the story of YouTube's NFL Sunday Ticket launch: 129 must-have features delivered in about nine months, with roughly 80 percent of the engineering owned by other teams. Her point was that AI can't walk into twenty teams' offices and convince them to blow up their roadmaps. Persuasion, rehearsal, and launch readiness are still human work, and they're where big launches actually fail.
Dheerja Kaur from Hims & Hers showed the other side: what you can make rigorous. Her team "treated our clinical protocols as code," with tests on every judgment the agent makes. The agent now resolves more than 80 percent of member questions end to end, and when a doctor does step in, the team designed it as a hero moment, not a fallback.
This is the idea behind Your Definition of Done Is Your Product Strategy. Whatever you write down as the check is what your team and your agents build toward. Enterpret's Vivek Kaushal said it on the panel: evals are the clearest statement of what a product is supposed to be.
5. Your next customer is an agent
Cisco's Jeetu Patel brought the numbers. Agents passed humans in token usage in early 2026 and now use about five times as many. Less than 2 percent of people are heavy agent users today, and he expects that to reach 30 to 40 percent within about a year. When agents sit between a brand and its customer, the product has to work for a reader that never sees your interface.
He was also the bluntest about the role. His claim was that most companies don't have product managers; they have feature managers. In his view, product has to be the one function that always runs like a founder, and "what you choose not to build is far more important than what you choose to build."
Replit's Amjad Masad added a twist: the newest models reward plain intent over micromanagement, which is why people who never learned to code are now competitive builders. More than three quarters of Replit's users are not engineers.
What I'm taking back
Check whether we've earned it. Before I talk about judgment as the bottleneck, I want an honest answer on speed. Can my team take an idea to production this week? If not, that's the real work, and it comes first.
Every PM ships, no PM is measured on shipping. Shipping keeps your judgment honest. Deciding is still the job.
Write the evals before the feature. Hims & Hers and the panel landed on the same practice from opposite ends of the market. The test you write down is the product you get.
New York told me the bottleneck moved. San Francisco told me you have to get there first.