I’ve been spending a lot of time building things and exploring with my team to understand the real impact of AI tooling on product development. What started as simple acceleration of repetitive engineering tasks has evolved into something that fundamentally challenges how we think about product teams and software development.

Note: This is very much a draft, I’d appreciate any comments or feedback!

Lets step back …

How do we do product development?

If we recall from Marty Cagan there are four risks we need to solve to build great products:

Four Risks

  • value risk: whether customers will buy it or users will choose to use it
  • usability risk: whether users can figure out how to use it
  • feasibility risk: whether our engineers can build what we need with the time, skills and technology we have
  • business viability risk: whether this solution also works for the various aspects of our business

The Product Manager is responsible for the value and viability risks, and overall accountable for the product’s outcomes.

The Product Designer is responsible for the usability risk, and overall accountable for the product’s experience – every interaction our users and customers have with our product.

The Product Lead Engineer is responsible for the feasibility risk, and overall accountable for the product’s delivery.

This leads to the idea of a Product Team

This leads most of us to create a product organisation with three core pillars (I will ignore supporting parts like data / research / talent / infrastructure for now).

A typical product team has a Product Manager, a Product Designer ( or UX Designer) and Engineers - typically lead by a team lead of some description, with an Engineering Manager typically supporting multiple product teams.

Of course there are then lots of different ways to configure this into team topologies / tribes etc. but the fundamental building blocks tend to be this.

This then connects to HOW we work

Again from SVPG; these teams tend to work best in rapid cycles of Discovery & Delivery

Discovery

First, discovering, in detail, what the customer solution needs to be. That includes everything from making sure there’s enough customers that even need this solution (the demand) and then coming up with a solution that works for our customers and our own company. Even harder, we need to make sure we come up with a single solution that works for many customers, and not a series of specials. In order to do this, we need to learn fast.

Delivery

Second, we need to ensure we deliver a robust and scalable implementation that our customers can depend on for consistently reliable value. Your team needs to be able to release with confidence. While we never have 100% confidence, you should not have to “release and pray.”`

Using this model many organisations (including my own) have been able to turn slowly but surely from feature factories to teams that are really focused on delivering outcomes and value for customers as quickly as possible.

However, I think this is changing. Fast.

The rise of agentic AI tools

2025 will for sure be remembered as the year that agentic AI tools hit the mainstream, and went from tools that might help engineers, or generate images / basic designs, into something that can actually deliver (in the right hands) solutions that you can put in front of real customers.

The Bottleneck Shift

We already know that in most organisations that engineering isn’t the bottleneck anymore. The things that really impact end to end velocity and cycle time in delivering customer value tends to be things away from people at the keyboard.

  • Design sprints
  • Problem definition workshops
  • Endless alignment meetings
  • Finding customers to validate ideas
  • Finding or analysing data to support your hypothesis
  • Solution ideation workshops
  • Sprint planning meetings
  • More meetings about the meetings
  • … sound familiar?

The end to end cycle time is often longer for Discovery than Delivery, especially when you are working in an area where it might be challenging to validate with customers quickly or at scale. You then often end in a crisis of confidence, where the Product Manager + Product Designer lean towards “one more week” of discovery to ensure they are confident the solution direction alleviates their product risks, while Engineering is busy refactoring or reducing tech debt instead of working on customer value.

Use of Agentic AI for engineering makes this gap even more profound - we can spend weeks of discovery on something that takes days or perhaps hours to build. This is not sustainable.

So what to do?

The Value Pairs Experiment

Here’s an experiment that we will try:

Instead of the traditional PM + Designer + 5-6 Engineers team structure, what if we instead focus on leveraging the teams specific skills - empowered by AI - at key moments in the product delivery.

What does this look like?

We will still have an overall team, focused on a specific user job or domain:

  • It will have a core of 4 engineers, one can be a senior / team lead, but operates in quite a quite ‘flat’ heirarchy (Fred George would be pleased)
  • It will have a Product Manager and Product Designer available to the team (but not fully dedicated)
  • Work will be conducted always in pairs, actively leveraging AI tools

Note: The ‘greyed out’ role means they need to be aware of status and what is going on, and available to support as needed in that stage. This does not mean they are excluded, work should be visible, they should be able to support actively, but the reality is that having two people staring at OpenCode or Claude Code while it works is not effective, better to collaborate on the output vs during the process.

1

Discovery

3-5 days

We form a Discovery Pair - typically Product Manager + Product Designer, but can also include Engineers if appropriate to the task. They use existing knowledge, expertise, customer insight, and data to define a clear and concrete problem statement: a crisp articulation of the problem a product will solve.

They should actively use AI tools to explore, summarise, analyse, create prototypes, hallway test, explore with customers (real or via synthetic personas) if possible - accelerating and de-risking this phase. This must also be time bound, as while we want to address as much risk as possible here, the real risk will be alleviated in the later stages.

This is not about solutions at this stage. Focus here is on:

  • Customer value
  • Business viability
Product Manager Designer + AI Engineering
→
2

Delivery

3-5 days

We form one or more Delivery Pairs who take the problem statement as input. This could be 2 Engineers, Designer + Engineer, or PM + Engineer, depending on the problem nature.

They may choose to work individually (on different options, or different parts of the solution) but the pair is important to ensure that they can actively review each others work and output either during or after completion. AI tools can generate a LOT of code, and a traditional PR process is possible if work is chunked in very small parts, so by actively collaborating and reviewing the output as you go you can try to maintain a good balance between quality and velocity in the early stages.

Their goal is to rapidly iterate on different possible solutions:

  • Build working solutions (not prototypes)
  • Deployable in production at iteration end
  • Build multiple solution variants (not always required - but now possible)

This directly addresses feasibility risk and begins to address usability risk.

Engineers + AI Product Manager Design
→
3

Validation

1-2 weeks

The Discovery Pair validates the solutions with customers using appropriate mechanisms: invitations to insider programmes, opt-in in the site, internal testing groups, A/B tests or whatever is most logical.

The goal is to pick a winner from the options, or a combination of options, that can go back to the Delivery Pair. This closes off:

  • Usability risks
  • Customer value risks

Teams must maintain urgency to complete validation to avoid building up a large validation backlog, if we move from slow Discovery to slow Validation we have a different problem, especially given the speed with which we can deliver new features.

PM Designer Customers + AI Engineering
→
4

Final Delivery

1-2 weeks

The Delivery Pair takes validation feedback and ensures the solution is production-ready. This is the window to improve:

  • Observability and monitoring
  • Test coverage
  • Type safety
  • Accessibility
  • Design system compliance
  • Go To Market readiness

If initial guardrails are sufficient, the gap between initial and final delivery may be minimal or non-existent.

Engineers + AI Product Manager Design

Comparing Value Pairs with SVPG’s Empowered Teams Model

The Value Pairs approach shares DNA with SVPG’s empowered teams philosophy championed by Marty Cagan, but takes a radical leap forward by leveraging AI as a core team member. Let’s examine how each role is adjusted:

Product Manager Evolution

SVPG Model (Traditional Empowered Teams) Value Pairs Model (AI-Enabled)
Works as part of a "product trio" (PM, Designer, Engineer) Spans multiple Value Pairs simultaneously (3-5x leverage)
Conducts weekly customer interviews and continuous discovery Front-loads customer problem validation
Responsible for value and viability of solutions Back-loads solution selection from multiple working options
Deep involvement in daily problem-solving and feature definition Less time in solution ideation, more time in validation
Manages backlog and prioritization continuously Shifts from "what to build" to "which built solution works best"

The PM role becomes more strategic and less tactical—focusing on problem validation and solution selection rather than solution definition.

Engineering Transformation

SVPG Model (Traditional Empowered Teams) Value Pairs Model (AI-Enabled)
5-6 engineers per team with specialized roles 2 Product Engineers + Claude Code
Participates in discovery work alongside PM and designer Full-stack generalists with strong product sense
Responsible for technical feasibility AI handles boilerplate, refactoring, and technical implementation
Builds one solution based on collaborative discovery Builds multiple complete solutions rapidly
Code reviews, architecture discussions, technical debt management Peer programming eliminates traditional PR reviews

Engineers become “Product Engineers”—combining technical skills with product thinking, using AI to eliminate repetitive work and explore solution spaces rapidly.

Designer’s New Canvas

SVPG Model (Traditional Empowered Teams) Value Pairs Model (AI-Enabled)
Part of the core product trio Focuses on design system evolution and patterns
Creates detailed mockups and prototypes before building Provides guardrails and principles, not pixel-perfect screens
Conducts usability testing on designs Reviews and refines multiple built solutions
Works iteratively on one solution path Shifts from "design then build" to "build then perfect"
Owns the user experience from concept to delivery Becomes a force multiplier across multiple pairs

Designers move from prescriptive screen design to systems thinking—creating reusable patterns that AI and engineers can leverage autonomously.

Customer Interaction Paradigm

SVPG Model (Traditional Empowered Teams) Value Pairs Model (AI-Enabled)
Weekly customer interviews by the product trio Concentrated discovery phases with PM/UX
Prototype testing before building Testing with actual working software, not prototypes
Opportunity solution trees to map problems Multiple solutions tested simultaneously with real users
Continuous discovery habits embedded in the team Discovery separated from delivery
Build-measure-learn cycles on single solutions Learn from comparing multiple approaches

The customer sees real, working solutions rather than mockups—dramatically increasing the quality of feedback and validation.

The Philosophical Shift

Both SVPG and Value Pairs embrace empowerment, but they diverge on how teams achieve it:

  • SVPG: Empowerment through cross-functional collaboration and continuous discovery
  • Value Pairs: Empowerment through AI augmentation and parallel exploration

The SVPG model asks “How might we solve this?” through discovery. Value Pairs asks “Which of these solutions works best?” through rapid building. It’s a shift from convergent thinking (narrowing to one solution) to divergent execution (building multiple solutions).

Key Differences in Practice

Aspect SVPG Empowered Teams Value Pairs
Team Size 7-10 people (PM, Designer, 5-6 Engineers) 4-6 people (PM, Designer, 2-4 Engineers + AI)
Discovery Method Continuous weekly touchpoints Concentrated 3-5 day sprints
Solution Approach One refined solution Multiple parallel solutions
Validation Prototypes and mockups Working software
Cycle Time 6-12 weeks 2-4 weeks
Role Boundaries Clear specialization Fluid, overlapping responsibilities
Decision Making Consensus through discovery Data-driven selection from options

Note: The Teresa Torres Connection

Teresa Torres’ concept of the “product trio” and continuous discovery habits forms a bridge between these models. Her emphasis on:

  • Weekly customer interviews
  • Opportunity solution trees
  • Rapid experimentation

…remains valuable in the Value Pairs model, but the execution changes. Instead of using these tools to converge on a single solution, we use them to:

  1. Define crisp problem statements (discovery phase)
  2. Evaluate multiple built solutions (validation phase)
  3. Learn from parallel experiments rather than sequential ones

When to Use Each Approach

SVPG Model works best when:

  • You have complex, novel problems requiring deep discovery
  • Technical constraints are severe or unknown
  • Team maturity is developing
  • You need to build organizational buy-in gradually

Value Pairs works best when:

  • You have strong technical foundations (design systems, golden paths)
  • Problems are well-bounded but solutions are unclear
  • Speed to market is critical
  • You can afford to build multiple options (not always required of course but a possibility that can alleviate risks of premature convergence)
  • Your team is comfortable with ambiguity and rapid iteration

The Evolution, Not Revolution

This isn’t necessarily better or worse than SVPG’s model—it’s an evolution enabled by AI that wasn’t possible when Marty Cagan first articulated empowered teams. The core values remain:

  • Customer focus
  • Team empowerment
  • Outcomes over outputs
  • Continuous learning

What changes is the velocity and breadth of exploration possible. We’re not abandoning the principles of good product development; we’re accelerating them through AI augmentation.

The question for product leaders isn’t “Should we abandon SVPG principles?” but rather “How can we evolve these principles to leverage AI’s capabilities while maintaining customer focus and team empowerment?”

Are their foundations that are required to make this work?

This transformation requires some key ingredients:

  • Strong boundaries: Full design system with component library (to ensure AI doesnt get creative)
  • Golden path modules: Observability, config, database access patterns - core re-usable code around critical technical elements to ensure consistency, security and maintainability longer term
  • Consistent stack: TypeScript + React (well-understood by AI models) - if you are more divergent or unique this will slow you down
  • Continuous Deployment: A strong CI/CD approach to ensure that you can safely release code in a fully automated way without impacting customers
  • Clear patterns: Established architectural conventions that provide necessary guard rails

What Do You Think?

Are you experimenting with similar approaches? Have you found different models that work better? I’d love to hear about your experiences as we navigate this transformation together.