
The Great Unlearning: Why Your Agile Instincts Might Be Your Biggest Bottleneck in the AI Era
Learn how to lead in this new era by being willing to dismantle your own product manager toolkit.

The history of product management is a history of bottlenecks. For decades, the bottleneck was Engineering. We built elaborate processes (Agile, Scrum, Kanban) specifically designed to manage the scarcity of developer time. We learned to keep specifications lean to avoid the waterfall stigma. We prioritized working software over comprehensive documentation because manual coding was slow, expensive, and prone to human error.
But the paradigm has shifted.
At companies like Product People, where I’ve navigated complex landscapes from FinTech to HealthTech, I am seeing a new reality: Engineering is no longer the bottleneck. In AI-native environments, where agents write code, documentation, and tests in seconds, the bottleneck has shifted upstream. It’s now the Product Manager.
The greatest challenge facing product leaders today isn't learning how to use AI; it’s unlearning the traditional ways we build digital products. Our ability to adapt and to remain relevant depends on our willingness to let go of the best practices that worked in 2019 but are slowing us down in 2026.
From Working Software back to High-Fidelity Specs
For years, writing a 20-page PRD was considered a sin. We were taught that shared understanding was better than documentation. However, we must now unlearn our allergy to detailed specs.
In an AI-augmented workflow, your first input determines the quality of the output. If you are using tools like Claude Code or Lovable to generate the first version of your product, a lean spec results in a hallucinated product. Modern Product Management requires a return to high-resolution thinking. We aren't just writing for humans anymore; we are writing for LLMs.
This isn't a return to Waterfall. It’s an evolution where the PM acts as the Architect. By investing in detailed specs, evaluations, and feedback loops early, we provide the generative engine with the blueprints it needs to deliver in hours what used to take weeks.
Reimagining the Double Diamond: Build to Research
The traditional Double Diamond framework suggests we diverge and converge on a problem, then diverge and converge on a solution, usually through a long discovery phase of interviews and Figma prototypes.
In the AI era, we need to unlearn the idea that discovery must happen before build.
I propose a shift in the second diamond. Instead of diverging into more research, we should diverge into Generative Prototyping. Because the cost of building a functional, production-ready deliverable has plummeted, we can now Build to Research. Why ask a user what they might do with a mockup when you can ship three variations of a functional feature by tomorrow afternoon?
By using actual end-user feedback on live iterations, we converge on the final solution through real-world learning rather than theoretical validation.
Embracing the Embarrassment Metric
This shift requires a massive cultural unlearning for leadership. Many VPs and stakeholders are conditioned to fear brand risk and demand polished versions of everything.
But as Reid Hoffman famously said, if you aren't slightly embarrassed by your first release, you launched too late. In an AI-native world, late is measured in days, not months.
Strategic leadership now means managing the narrative. We must move away from viewing unfinished releases as risks and start viewing them as a culture of iteration. We have to coach our stakeholders to understand that the cost of a wrong turn is lower than ever in terms of developer hours, but the cost of waiting for perfection is an existential threat to the business’s speed.
The New Org Chart: Engineers as Mentors
We also have to unlearn our traditional view of the handover. In the past, the PM provided the "what" and the Engineer provided the "how."
Today, if we view AI Agents as Junior Developers, the role of the Senior Engineer shifts toward mentoring, reviewing, and providing feedback to those agents. The relationship between PM and Engineer remains collaborative, but the friction of implementation is dissolving. The PM becomes the strategic driver, and the Engineer becomes the architectural governor, ensuring that the speed of AI doesn't sacrifice the integrity of the system.
The Truth About Debt
The process nerds among us will worry about technical and product debt. They aren't wrong: speed creates mess. But debt has always existed. The trade-off we must be transparent about is this: quality is always at risk, but debt is manageable as long as it isn't ignored.
In a world where we can build almost anything instantly, the most impactful skill a Product Leader can possess is judgment. It is the ability to identify which opportunity is worth the investment and which failed experiment was actually a fast win.
The Path Forward
The tools we use (Figma Make, Claude, agents) are powerful, but they are only as effective as the person directing them. To lead in this new era, you must be willing to dismantle your own toolkit. The question isn't "what can AI do for my product?" The question is "what traditional beliefs am I willing to unlearn to let my product evolve?"
The bottleneck is gone. It's time to move.
Read More Posts

What is an MVP? Understanding MVP Meaning for Product Leaders

Beyond the Laundry List: Aligning Sales and Product for Long-Term B2B Success

The Power of Choice: Why Every Product Leader Should Focus on Being Empowered
.webp)
PLG Meaning: What Product-Led Growth Looks Like Today

Product Requirements Document: A Practical PRD Guide



