The Anxiety Problem: Are PMs Being Left Behind?

Bjorn opened the session by acknowledging what many in the room were feeling but few wanted to say out loud: the fear that AI is making their role irrelevant. Engineers are using copilots to generate code at unprecedented speed. Designers are prototyping with generative tools. If everyone in the room can suddenly build, what exactly is the PM contributing?

“We are not as PMs here with the goal of saying, oh we're gonna build something with a cool backend... no no no. We are here to think through what it is that our users would want.”
- Bjorn Vuylsteker

This reframe set the tone for the rest of the talk. The PM role was never fundamentally about coordinating Jira tickets or writing acceptance criteria. Those activities were proxies for a deeper function: understanding what users need and translating that into decisions about what to build next. AI accelerates the execution side of that equation, but it does not replace the judgment side.

The Spaghetti Code Paradox

One of the most memorable moments in the talk came when Bjorn shared a real exchange from his work at WeGroup. AI-generated code was functional but messy. The immediate engineering instinct was to rewrite it. But the counterargument was striking: if that spaghetti code is delivering value and customers are paying for it, is it actually bad?

“If something is written in spaghetti code, but it delivers value... is it actually not good?”
- Bjorn Vuylsteker

This is a deeply uncomfortable question for anyone trained in software craftsmanship. But it points to something important about the AI era: code quality as traditionally measured may matter less than outcome quality. AI will eventually refactor and manage its own code. Humans may not even be able to follow along at the pace it moves. The bottleneck is not writing better code. The bottleneck is knowing what the code should do.

infoThe Real Bottleneck

Bjorn's prediction: AI is moving far faster than humans can keep up with. We are the bottleneck in this story, not the machines. The question is what uniquely human capabilities we bring to the table.

If Everyone Can Build, What Is YOUR Value?

This was the pivotal slide of the presentation. Bjorn drew on Paul Graham's writing about taste to argue that in a world of commoditized execution, the ability to discern what is excellent from what is merely functional becomes the primary value driver. Taste is not about aesthetics alone. It is about having a refined sense of what users actually need, what details matter, and what tradeoffs are worth making.

Taste in problem selection: choosing which problems are worth solving at all
Taste in scope: knowing what to leave out, not just what to include
Taste in experience: understanding the difference between 'works' and 'feels right'
Taste in timing: sensing when the market is ready for a particular solution

This framing elevates the PM role rather than diminishing it. When building is cheap and fast, the cost of building the wrong thing drops. But the opportunity cost of building the wrong thing stays the same or increases. Someone still needs to exercise judgment about direction, and that someone needs exacting taste.

The Shift: From Managing HOW to Deciding WHAT and WHY

The core thesis of the talk crystallized into a clean transition: the PM's value is migrating from orchestrating execution to owning the decision layer. In the pre-AI world, a significant portion of PM effort went into managing how things got built. Sprint planning, technical tradeoff discussions, resource allocation, timeline management. These activities consumed enormous amounts of energy.

In the emerging landscape, AI handles much of the execution complexity. The PM who clings to process management will find less and less to do. But the PM who doubles down on the WHAT and WHY becomes more valuable than ever. What problem are we solving? Why does it matter to this user segment? What does 'good enough' look like for this particular context? These are judgment calls that require deep user empathy, market understanding, and yes, taste.

Two PMs, Same Tools, Different Outcomes

Consider two PMs at competing companies. Both have access to the same AI coding tools. PM A writes detailed specs and manages sprints meticulously. PM B spends their time talking to users, studying behavioral data, and making opinionated calls about what to build next. In a world where AI compresses the build cycle from weeks to days, PM B's skill set becomes the decisive advantage.

Cultivating Taste as a Practice

If taste is the new moat, the natural follow-up question is whether it can be developed intentionally. Bjorn's implicit answer throughout the talk was yes, but it requires a deliberate shift in how PMs spend their time. Less time in tools and processes. More time with users, with data, and with the product itself.

Use products obsessively. Not just your own, but competitors, adjacent tools, and products in completely different domains. Pattern recognition builds taste.
Talk to users constantly, but listen for what they struggle to articulate. The best product insights live in the gaps between what users say and what they do.
Practice making opinionated calls and track your hit rate over time. Taste improves through calibrated feedback loops.
Study the work of people with exceptional taste across disciplines: design, architecture, writing, cuisine. The principles transfer.

lightbulbTaste Is a Skill

Taste is not innate talent. It is a skill built through exposure, reflection, and deliberate practice. The PMs who invest in developing their judgment now will have a compounding advantage as AI continues to accelerate execution.