I went to ProductCon expecting a dozen variations on "AI changes everything." What I got was more interesting and more uncomfortable: a room full of product leaders quietly agreeing that the thing we spent the last decade optimizing (shipping faster) is mostly solved, and that almost none of us have rebuilt our organizations, our metrics, or our judgment to match.
Across twelve sessions, one argument kept surfacing from different stages, in different words, from people who hadn't coordinated. The engineering bottleneck has flipped. When building is cheap, the constraint moves upstream: to deciding what's worth building, to the organization that decides it, and to the data and judgment that make the decision defensible. That's not a new idea to me; it's the spine of both pieces I published this spring. But hearing it confirmed live, with numbers, changed it from a thesis I argue into a pattern I now expect to see everywhere.
Here's what landed, and where it rubs against how I already think about the work.
"Should we build it?" beat "Can we build it?" all day
The clearest version came from the SaaS-native panel (Enterpret, Kviva, Contentsquare, Lucid). Their framing was that the "SaaS apocalypse" is the wrong word: it's a revelation. AI didn't kill software; it exposed who has a real moat versus who was renting stickiness from a nice UI. One line I wrote down twice: "Internal builds are not the enemy. They're the new bar." Your customer can now vibe-code a V1 of your product over a weekend. The demo will look great. And then, as one panelist put it, it will "fail quietly": month two, a data source goes stale, the answers drift, and nobody owns the governance, security, and maintenance that were the actual reason people paid you.
This is the exact argument I made in Just Because You Can Vibe-Code It Doesn't Mean You Should Build It ("buy the commodity, build the differentiation"), except the panel ran it from the other direction. I wrote it as a discipline for builders: don't own more than you should. They framed it as a survival test for sellers: if a customer can replicate you in a weekend, you were never infrastructure. Same coin. The litmus test they offered is one I'm stealing: don't wait for a customer to say "I could vibe-code this." Go try to build your own product yourself, and you'll hit the unglamorous plumbing that is your real value. I'd rather discover my moat is thin in a sandbox than in a renewal conversation.
The org chart is the unfinished work
If the first theme was strategic, the second was structural, and it's where I think most leaders (me included) are behind.
Mathias Davidsen from Miro made the point that stuck with me hardest: a 10x individual does not give you a 10x organization. We've been celebrating the engineer or PM who ships five times faster with AI, but if the org around them is still organized in functional relay handoffs (design throws to eng, eng throws to QA), the individual gains evaporate at the seams. He argued for "flow teams" and a maturity model where, tellingly, nobody is yet at the top stage. Carlos González made a complementary case with his "AI operating model": roughly 80% of teams are stuck at Level 1, sitting in the messy middle of a J-curve where productivity actually dips before it climbs.
Then Meaghan Choi from Anthropic described what the destination might actually look like from the inside, and it was the most concrete thing I heard all day. Fluid three-to-five person pods. Titles that, in her words, stop mattering: the designer ships code, the PM makes design calls, the manager still builds. Most striking, the decision about quality has moved. "We've now pushed that decision-making into live working code." They stopped gating quality at the PRD or the Figma mock and started deciding it by using the real thing. For context on why anyone should listen: she mentioned Claude Code did about $2.5B in its first year and holds roughly half the coding market. This isn't a thought experiment for them; it's operating reality.
Simon Kubica (Alloy) pushed the same idea onto the PM role directly: planner to builder, "stop writing PRDs," shipping at two-to-three times the old pace. I'll admit this is the part I sit with the most discomfort. My book, Building a Career in Product Management, is built on a ten-skill framework, and a fair amount of it assumes the PM as the person who defines and prioritizes rather than the person who ships. I don't think the framework is wrong, but it clearly needs a builder-era revision. The skill of deciding matters more, not less, when execution is cheap. What changes is that you can no longer hide behind a document; you're closer to the artifact, and your judgment is visible sooner.
Speed without quality is just faster churn
The counterweight to all the velocity talk came from a few directions at once, and I was grateful for it.
Jefferson Rabb (Business Insider) described the bottleneck flipping firsthand: engineering went from constraint to abundance, launches multiplied (he cited something like 20x on press releases), and the team's hardest question changed from "is this the best idea?" to "is this a good idea?" That sounds like a relaxation. It isn't. It's a direct challenge to how I've taught prioritization. My SU-RICE framework exists to separate the best bets from the merely good ones. When the cost of a wrong bet collapses, does that scoring discipline matter more or less? My instinct says more (abundance is exactly when undisciplined teams drown in good-enough ideas), but I owe that question a real answer rather than a reflex.
And then the contrarian. Eric Ries opened the day arguing that speed is essentially solved and that we're all admiring the wrong frontier. The unsolved problem, in his telling, is governance and integrity: being a "fiduciary to the customer," building organizations with the structural integrity to not corrupt their own mission once building is frictionless. In a room high on velocity, it was the lone voice saying the easy part is done; the hard part is who you choose to be. I keep coming back to it because it reframes everything else: if anyone can build anything, the differentiator isn't capability or even speed: it's restraint and trust. That's a Mountaineer's-Mindset idea if I've ever heard one. On the mountain, the skill that keeps you alive isn't moving fast; it's judgment about when not to.
The moat is the context layer
The last throughline was the most technical and, I suspect, the most durable. Several speakers independently located the real, defensible asset in the same place: the context layer.
Arnab Bose (Asana) talked about the "work graph" as the thing that makes enterprise AI useful, and dropped the "0% productivity paradox," the gap between how much companies are spending on AI and how little measured productivity has moved. His answer was that the model is a commodity; the proprietary, compounding context of how your organization actually works is not. The SaaS panel said the same thing in product terms: a three-layer contract where the UI serves humans, APIs and MCP serve agents, and a shared context layer underneath is the single source of truth. Enterpret noted a third of their users now touch their product only through MCP. Jaime DeLanghe (Slack) closed the loop on the operating side: "connect all systems," treat skills as codified organizational memory, and delegate to AI aggressively, but keep voice and judgment human ("don't sound like AI").
This is the part that hit closest to home, because it's literally what I'm doing. The personal LLM-wiki I described in The CPO's New Reality is a context layer, a compounding store of my own decisions, sources, and judgment that gets more useful the more I feed it. I built it as a personal productivity hack. ProductCon convinced me it's the same architecture that separates a real product company from a wrapper, just scaled down to one person. The lesson generalizes: the model is rented; the context is owned.
What I'm taking back to my own work
Three things I'm changing or writing about next:
First, I'm treating "the bottleneck moved" as a structural claim, not a slogan. The work isn't adopting AI tools. Most teams have. It's redesigning the org so a 10x individual doesn't dead-end in a 5x process.
Second, I'm revisiting prioritization for an abundance regime. SU-RICE was built for scarcity, where you fought for the best few bets. I want to write the follow-up: why the scoring discipline matters more when bad bets are cheap, not less.
Third, I'm leaning harder into the context layer, personally and in how I'd advise any product org. Buy the model. Build the data flywheel and the judgment around it. That's the moat, and it's the one thing a competitor can't ship in six months.
ProductCon didn't change my mind so much as raise the stakes on things I already believed. The price of judgment went up. The cost of building went down. The leaders who win the next few years will be the ones who rebuild their organizations (and their own habits) around that swap.
If you were there and saw it differently, I'd genuinely like to hear it.