I spent a day at the Metropolitan Pavilion for Product School’s AI Product Conference. Twelve sessions, one stage, one question hanging over everything:
What does it mean to be a product manager in an AI-native world?
I went expecting to learn what the future of product management would look like. What I left with was something different—a recognition that many of the ideas speakers discussed connected to experiments I’d already been trying at work.
That’s not to say we have it figured out. None of us do. But almost every framing the speakers offered for “the messy middle” of AI-native product work mapped to something I’d encountered over the previous few months. The conference gave me language for it, along with a strong sense of urgency to lean further into what’s now possible.
Here were my key takeaways.
1. Context is the new competitive advantage
The most demo-forward session of the day was Jaime DeLanghe (CPO, Slack) running her CPO workday inside Slack: a Today View synthesizing her priorities, agenda-aware briefings before meetings, a Linear integration pulling live feature status, an AI-drafted Day 100 message for a new hire, and an end-of-day wrap-up of what got done and what carried over.
All of it depended on Slack having enough context about her, her organization, and what was happening that day to be useful.
Jaime put it this way:
“AI needs to know about you, your organization, and your context to be truly useful.”
Arnab Bose (CPO, Asana) made the same point from a different angle: filling out the business context available to AI makes workflows more useful.
Penny Szeto (Head of Generative AI, Amazon Games), demonstrating an AI judge in their party game Courtroom Chaos, argued that the model itself was becoming a commodity. The system around it was the differentiator.
The pattern across all three was the importance of what surrounds the model: what the AI knows about the business, the customers, and the work in flight.
I’ve encountered this in building my own Claude skills. Identifying the sources, explaining the terminology, and making the context usable takes work. It’s also a large part of why the result becomes useful.
2. AI moved the bottleneck to judgment
The line that stuck with me hardest came from Vinod Suresh (VP of Product & GM, GoDaddy):
“AI didn’t remove the bottleneck—it moved it.”
Jefferson Rabb (CPO, Business Insider) described engineers beating their estimates and asking for more work. In his experience, engineering capacity was no longer the primary constraint. Product clarity, judgment, and organizational alignment needed to catch up.
That lands as both opportunity and pressure.
Vinod described the PM role as the “80–100 game”: AI makes it easier to reach an initial version, while judgment, taste, prioritization, and alignment remain essential to getting something ready for customers.
For me, the implication cuts both ways. Engineering scarcity can slow down fuzzy goals, half-thought-through features, and work nobody really wants. When building gets faster, those ideas can move faster too.
The thinking has to clear a higher bar before the work starts, not after.
3. PMs need to build
Simon Kubica (CEO, Alloy) described a major shift in product management, then walked through how he shipped Scraply, a web-scraping product, as a PM working alone.
Meaghan Choi (Head of Design, Claude Code & Cowork, Anthropic) shared a related lesson from inside Anthropic: Claude Code began as a side project, built by people with the conviction and tools to make it real.
Her framing was that contribution increasingly depends on what you build, rather than your title alone.
Carlos Gonzalez de Villaumbrosia (CEO, Product School) described the same shift through six AI skills for PMs:
- Context engineering
- Vibe coding
- AI evaluations
- Agentic orchestration
- AI product strategy
- Product sense
Product sense remained essential alongside the newer skills.
This is the takeaway I’ve been writing about as a PM who doesn’t write code. Hearing speakers from Anthropic, Alloy, and Product School converge on the idea that PMs need to build was a real moment of recognition.
I’d already experienced how making a prototype could change a conversation. The conference pushed me to think more seriously about building as part of the role.
4. Shared context is the next team-level challenge
Mathias Davidsen (Miro) challenged the assumption that individual productivity gains automatically improve team performance.
He presented a finding that 76% of product leaders said current AI tools optimized individuals rather than teams. Individual gains can introduce coordination overhead that consumes the time saved.
He called one failure mode the Velocity Trap: fast AI-assisted delivery creating code without maintainers, features with low adoption, and technical debt accumulating faster than teams can manage it.
His diagnosis centered on shared context. Each person can have an AI assistant that understands their work, while the team still lacks a common understanding of the goals, decisions, and dependencies.
Carlos’s J-Curve described a related messy middle: individual productivity improves, but team coordination breaks down before the organization learns to work differently.
Jefferson called the blurring boundaries between product, design, and engineering “positive blurriness.” Some people experience that as freedom; others experience it as confusion about their role.
This is where my own experiments raise harder questions. A skill can make me faster while depending on context only I understand. Making that workflow useful to another person takes additional work.
The teams that address this will get more from AI than a collection of faster individuals. Without that effort, they risk producing more work than they can collectively understand and maintain.
5. Values need to lead what we build
Eric Ries opened the conference with an argument that stayed with me throughout the day: building is a moral act.
His book Incorruptible examines how products and organizations drift from their founding values through accumulated compromises. Explicit values and governance matter because good intentions alone don’t prevent that drift.
Ashley Nutter (SVP of Product, CNN) approached responsibility through architecture. Her principle of “composition, not conflation” meant giving each agent a focused job and designing a system that could evolve as needs changed.
The two sessions made me think about how principles become concrete choices: what a system is allowed to do, how its work gets checked, and who remains responsible.
This matters especially in fintech. AI makes it cheaper to build quickly. It doesn’t resolve whether we’re building the right thing or earning the trust people place in us.
For products connected to people’s financial lives, I want to ask more than whether something shipped. Will we still be proud of the decisions behind it in five years?
What I’m carrying forward
Across the sessions, I kept hearing variations on the same theme: the work hasn’t gotten easier; it has become harder in different places.
Judgment and shared context become more visible constraints as engineering gets faster. PMs have more opportunities to make something themselves, test their thinking, and learn from the result.
What gave me optimism was recognizing practices I’d already begun exploring:
- Prototyping before creating elaborate specifications
- Building reusable Claude skills
- Automating repetitive assembly work
- Organizing context so it can be reused
The harder question is how those experiments become useful beyond one person.
If building gets faster, the quality of our thinking gets exposed sooner. I left wanting to keep building—and to pay as much attention to the judgment, shared understanding, and values around that work as to the speed of producing it.