Can AI really shrink your development teams from two pizzas to one? Peter and Dave explore the promise and reality of smaller teams in the age of AI agents. While AI can handle documentation, test automation, and other "hygiene" tasks teams often skip, the real question isn't whether you can reduce team size, it's whether you should. They dig into when one-person teams make sense (startups and greenfield projects), when they don't (complex legacy systems), and why the biggest gains might come from augmenting existing teams rather than downsizing them. Plus: why most AI initiatives fail and how to find the real business problems worth solving.

This week´s Takeaways

1. AI as Capacity Booster, Not Team Replacer: AI agents excel at handling the "hygiene" work that teams often skip: documentation, test automation, release notes. Rather than shrinking teams, this gives existing teams ephemeral capacity to tackle work that improves long-term system quality and maintainability.
2. Context Determines Team Size: One-person teams work brilliantly for startups and greenfield projects where you can build from scratch. But complex legacy systems in large organizations still need the diverse knowledge and experience that comes with larger teams to navigate technical debt and organizational complexity.
3. Solve Real Business Problems First: The biggest AI failures happen when teams focus on cool technology instead of actual business needs. Before experimenting with smaller teams or AI agents, identify genuine business problems that need solving; that's where you'll see real returns and organizational support.

In this episode, Dave and Peter sit down with Radhika Dutt, author of "Radical Product Thinking: The New Mindset for Innovating Smarter," to explore why iteration-obsessed product development is failing organizations.

Radhika shares hard-learned lessons from her 25-year career across diverse industries and five acquisitions, introducing the concept of "product diseases" like hero syndrome, pivotitis, and obsessive sales disorder that plague modern product teams. She challenges conventional wisdom around OKRs and goal-setting, explaining why they often create an illusion of performance while masking real problems.

The conversation explores why goals, targets, and OKRs backfire and what actually works instead. Radhika introduces her tried-and-tested alternative: a framework for puzzle-setting and puzzle-solving called OHLs (Objectives, Hypotheses, and Learnings). This approach helps companies develop a mindset that equips teams to experiment, learn, and adapt in a disciplined way, ultimately delivering far better results than traditional goal-setting methods.

The discussion dives deep into crafting detailed, hypothesis-driven vision statements that actually help teams make decisions, rather than fluffy corporate speak that sounds inspiring but provides no guidance. Radhika explains how to balance vision debt against short-term survival needs using her three-question puzzle-solving framework.

Key Takeaways:

• The importance of writing good hypotheses and understanding customer pain points deeply before defining experiments and measurements
• Organizations need to get much closer to their target customers to truly understand their behaviors and pain points, enabling better vision statements and hypotheses that resonate
• Effective vision statements must enable decision-making; if you can't make yes/no decisions based on your vision, and understand the trade-offs between short-term survival and long-term vision, it's not valuable enough

Free Resource: Download the OHLs template and toolkit: https://www.radicalproduct.com/toolkit/#OHLToolkit

When should you let AI agents loose on your processes, and when should you keep them on a tight leash? Peter and Dave explore the messy reality of using agentic AI for process improvement.

They dig into why the processes you can easily map might not be the ones where AI agents add the most value. From recruitment pipelines that need human intuition to DevOps workflows that demand zero variation, not every process is created equal when it comes to AI intervention.

This week's takeaways:

• Categorize your processes first. Look at your processes and start sorting them. Some need to eliminate variation (like DevOps deployment pipelines), while others benefit from exploring the edges and finding creative solutions.
• Not all processes are equal when it comes to AI. There are many ways AI can help improve processes, but you need to think about whether you want to reduce variability or increase intelligent flexibility in each specific case.
• Train AI to know when to hand off. What you want AI to do is recognize when it can't handle something and pass it to the right system - whether that's a math library for calculations or a human for complex decisions.
• Understand the difference between consistency and exploration. DevOps spent years eliminating variation to create stable, repeatable deployments. Other processes might actually want that variation because it gives you something unusual and valuable.

If you're wrestling with where to apply AI in your organization without breaking what already works, this episode offers a practical framework for thinking through the trade-offs.

Resource:

• Ethan Mollick's "The Bitter Lesson versus The Garbage Can": https://substack.com/home/post/p-169199293

Questions or thoughts? Reach us at feedback@definitelymaybeagile.com