BT

Facilitating the Spread of Knowledge and Innovation in Professional Software Development

Write for InfoQ

Topics

Choose your language

InfoQ Homepage News Jeff Patton on Fixing Agile Product Ownership

Jeff Patton on Fixing Agile Product Ownership

Bookmarks

At the recent Agile India conference, Jeff Patton gave a keynote talk in which he challenged the way agile development approaches product ownership. He holds that product management is a discipline which was around before the Scrum term "Product Owner" was coined, and the way it has been applied in most agile organisations is, at best, a watered-down approach.

He stated that:

Agile development has and is currently screwing up product management.
Agile development has fixed lots of problems in software development, companies using it consistently deliver working software more predictably than ever before. But, the software they make isn't necessarily better, or more successful in the market. Because the things we need to do to make a product successful aren't baked into agile development. In fact, strict adherence to common agile practice can result in even worse products.

He pointed out that common agile development approaches have left out a lot of the product management disciplines which predated the agile movement. He feels that "product people hate agile development because they don't talk to the customer". The Product Owner as a customer proxy is not an effective role and results in products which don't meet the customer needs. He said that a rift has formed between the product management community and most common agile approaches; there are a number of people (himself included) who are advocating for the inclusion of product management discipline into agile.

He stated that there are some important things that organisations using agile development need to focus on to ensure that the products they build are more successful and meet customer needs.

  • Stop focusing on delivering software faster; stop fixating on points and velocity – what matters is not the speed of delivery but solving problems for people.
  • Identify the intended outcomes (benefits to customers) and impacts (long term sustainable benefits for our organisations because of the customer outcomes) that building the product should have and measure those. Output is necessary (the product must be built) but outcomes and impact are what you should be aiming for.

He challenged the current situation where the development team is treated as a supplier by other areas of the business – this client/vendor relationship makes sense when negotiating with another organisation where the product being purchased is completely described and already built; in the situation where both the specifiers and producers work for the same organisation this is the "dumbest thing you can do" – it results in sub-par products that don't meet the customer needs. This pattern is baked into agile development – the product owner represents "the business" and is expected to understand exactly what is needed to create and prioritize the backlog; the team is responsible for time, cost and scope. This effectively creates a client/vendor relationship between the product owner and the team.

He contrasted this approach with Product Management where the product manager is expected to bring a wide variety of viewpoints together, and work with the team to identify the best way to solve the problem that results in a sustainable product which is valuable, useable and flexible. The product manager leads the cross functional team who have all the skills needed to deliver the product; this includes engineering, user experience, marketing, legal and compliance, security, quality assurance, and competitive analysis.

He says that the role of Product Owner does not make sense because "Teams own products, not people".

Product managers need to accept that the myriad ideas they receive in the course of exploring product needs are probably wrong – most new product ideas fail, and most features built into products are not used, so instead of attempting to define detailed requirements, needs should be expressed as hypotheses – "we believe that if we provide this type of person with this type of feature or capability then they will receive this type of benefit and that will have this impact on our organisation", then the team identifies how they will test the hypothesis, builds something which allows them to validate or invalidate that assumption in the shortest possible time, for the smallest possible cost. If it proves correct, then they amplify the capability and if not they discard it and explore the next hypothesis.

This hypothesis-driven approach requires that product managers and their teams get out of the building – they go and meet their customers in the environments where they will use the product, they need to understand the full depth of the customer's experience, empathise with them and experience their pain.

He ended by summarizing the five key pieces of advice from his talk:

  1. Minimize output, maximize and measure outcome and impact.
  2. Product owners and product managers lead cross-functional core product teams and involve whole teams in product decisions. Teams own products.
  3. Communicate your product "bets". Use small bets (experiments, tests and learning activities) to remove uncertainty from your big bets.
  4. Everyone must spend face time with customers to build empathy and insight.
  5. Discovery work is team work. Plan for it. Keep it visible. Review and reflect on it.

Rate this Article

Adoption
Style

BT