In this podcast recorded at the Agile 2018 conference Shane Hastie, Lead Editor for Culture & Methods, spoke to Jeff Patton about moving from project to product thinking; whole team product ownership and satisfying the real customer needs.
Key Takeaways
- “Project” and “product” are used interchangeably, yet they are two very different things
- If you are building a product that is sold to end consumers, then they are your customer, not “the business”; the focus on “the business” means we build products to satisfy the internal perceived needs, not the real customer needs
- When we start measuring outcomes, we realize that we’re wrong a lot and begin to embrace experimentation
- Implementing effective measurement takes engineering – instrumentation needs to be built into the product
Subscribe on:
Show Notes
- 00:27 Introductions
- 00:51 There are lots more product people in the agile world than there used to be
- 01:17 There is a lack of focus on product in the agile community
- 01:35 The way “project” and “product” are used interchangeably, yet they are two very different things
- 01:47 Projects end, products persist
- 01:57 Products need to be managed after a project is finished
- 02:18 Products are never done - features in products are continually evolving
- 02:27 “Done” means out of business for a product
- 02:46 The client-vendor anti-pattern
- 02:50 Describing the contracted service/project approach
- 04:05 The difference between a project and a product
- 04:23 In many organisations IT has been treated as a vendor rather than a part of the same business
- 04:50 Jeff’s experience as the XP “Customer” despite being the product manager
- 05:10 When the Agile Manifesto refers to the “customer” it refers to the business, not to the end purchaser of the product
- 05:32 Stop referring to “the business”, rather talk about “our business” because we work for the same company
- 05:50 Negotiating to get a “better” estimate when we are part of the same business only results in reduced quality
- 06:08 If you are building a product that is sold to end consumers, then they are your customer, not “the business”, the focus on “the business” means we build products to satisfy the internal perceived needs, not the real customer needs
- 06:54 We should all be working together as a product team, aiming to satisfy the needs of the end customer and is successful in the market
- 08:12 The most successful products are not the ones with the most features, they are the ones which most effectively satisfy the customer needs
- 08:41 The goal isn’t to deliver more stuff, faster – the goal is to deliver better stuff
- 08:49 The Scrum Product Owner role doesn’t fix the problem – it perpetuates the PO as customer mistake
- 09:25 The team is not accountable for product success, they are focused on pleasing the product owner
- 09:31 The product owner is a team member – the whole team should take accountability for product success. The whole team should have ownership of the product, not a single individual
- 09:57 Product teams own products, there needs to be a leader for the team but ownership is shared
- 10:28 You want a team which has people who can make good product decisions and can execute those decisions
- 11:48 Scrum is a product development approach – not a project management framework
- 12:23 In the original HBR article which Scrum is based on, there is no Product Owner role – it is a whole team responsibility
- 13:08 The HBR paper is about whole product teams working together to test and learn what the right product is for real customers
- 15:40 What do companies who are successful in this product approach do differently?
- 15:54 Success is not on-time delivery; value comes when people see, try, use and keep using the product
- 16:30 Measure product success in terms of outcomes rather than activities
- 16:40 Most products are not successful – accept this and be prepared to move on from a failing product
- 16:52 The failure rate for tech start-ups is around 80%
- 17:25 The proportion of features which are not used, even in successful products, is 60-70%
- 17:40 When we start measuring outcomes, we realize that we’re wrong a lot and begin to embrace experimentation
- 18:30 This is hard because it exposes the uncertainty in our decision-making processes
- 19:05 When you start measuring it’s like taking the red pill (Matrix reference) – you see reality for what it actually is
- 19:28 When you start measuring the results will be worse than you imagine they would be
- 20:34 Implementing effective measurement takes engineering – instrumentation needs to be built into the product
- 21:05 An example of using a subjective measurement approach as a starting point
Mentioned:
