The Better Way: Transformation principles for the
  • The Better Way: Transformation principles for the real world
  • Preface
    • Preface
  • Part I - The Big Picture
    • Introduction
    • Radical change
    • Rapid acceleration
    • Profound complexity
    • Part I Summary
  • Part II - The better way
    • Introduction
    • Principle one: Focus on customer value and adaptability
      • Applying the principle in practice
      • What good looks like
      • Common failure modes
      • Final thoughts
    • Principle two: Technology excellence is the strategy
      • Applying the principle in practice
      • What good looks like
      • Common failure modes
      • Final thoughts
    • Principle three: Choose product teams over project teams
      • Applying the principle in practice
      • What good looks like
      • Common failure modes
      • Final thoughts
    • Principle four: Divide and conquer
      • Applying the principle in practice
      • What good looks like
      • Common failure modes
      • Final thoughts
    • Principle five: Integrate governance, risk and compliance experts with product teams early and often
      • Applying the principle in practice
      • What good looks like
      • Common failure modes
      • Final thoughts
    • Principle six: Measure what matters
      • Applying the principle in practice
      • What good looks like
      • Common failure modes
      • Final thoughts
    • Part II Summary
  • Part III - Micro-transformation
    • Introduction
    • Step one: Design effective cross-functional teams
      • How it works
      • Why it works
      • Final thoughts
    • Step two: Create immersive working environments
      • How it works
      • Why it works
      • Final thoughts
    • Step three: Implement the Starter Kata
      • How it works
      • Why it works
      • Final thoughts
    • Step four: Thin-slice the work
      • How it works
      • Why it works
      • Final thoughts
    • Part III Summary
  • Conclusion
  • Glossary
  • Endnotes
    • Endnotes
    • License
Powered by GitBook
On this page

Was this helpful?

  1. Part II - The better way

Principle three: Choose product teams over project teams

PreviousFinal thoughtsNextApplying the principle in practice

Last updated 3 years ago

Was this helpful?

If the Lean Startup movement has taught established enterprises anything, it’s that you must learn before you earn. Traditional market research is ineffective at predicting product success. Instead, customer focused experiments are the best way to create world-class products that “cross the chasm” and achieve commercial success. But in order to do this successfully, your organization must shift away from project teams and embrace product teams.

In the Digital Era, products are the name of the game, which is why it's so incredibly important for transforming organizations to shift away from the short-term, project team model and embrace the long-term product team model. This is because unlike project teams, where performance against time, scope and cost are the key measures of success, product teams are driven to create long term value, using hypothesis driven methods to test, learn and adapt, in pursuit of validating customer outcomes that create business impact.

The difference between the two could not be more stark. Notable author and consultant Jim Highsmith captured this difference brilliantly when he wrote, “In a complex environment, following a plan produces the product you intended, just not the product you need.”

The reality is that most product ideas fail, at least initially. Success requires rapid and iterative experimentation, and a deep understanding of the customer problem space. This allows you to first find the right , then further experimentation will reveal a that is both sustainable and generates .

This means product teams start from a list of questions, rather than a list of requirements. The questions are meant to iteratively test their riskiest assumptions through targeted and measurable experiments that use leading indicators to gauge the likelihood of success over time.

At Rangle, we love this way of working because it not only helps tackle the biggest risks upfront, it also fosters collaboration and orients the core functions (strategy, product, engineering, experience and data) around customer problems rather than features.

But making the shift to product teams can be a big change for many established organizations, particularly for those with entrenched organizational and functional constraints, such as those we reviewed in . In the next section, we’ll explore the key changes that organizations must implement in order to make the shift to product teams.

product/solution fit
product/market fit
business value
Part I