What you could learn from ‘Product Mastery’ by Geoff Watts (2017, 267 pages)

Posted by Max on April 25, 2017 in Book reviews | 1 Comment

In software development, the Product Owner is the ‘CEO of the Product’.  Product Owners (PO) outline the vision for the product, collate the input from the business, customers and the team and forge all of the requirements into a prioritised list of things that need to be built.  The PO is responsible that the product generates value for the business and the customer.

In his book ‘Product Mastery’, Geoff argues that Product Owners need to be DRIVEN.

• Decisive – POs need to carefully consider the who, what and when of decision making.
  • Who – complicated decision will need a consultation with experts, and some decisions will need considerable buy-in from others, needing a more collaborative approach.  The effort needs to focus on key stakeholders, rather than everyone.
  • When – the PO needs to balance delaying a decision to reduced ambiguity, with the need to make a decision to drive forward development
  • What – POs will face a number of decisions, one of the most important being what features needed to be included next.  Setting a clear vision is essential, as it setting clear criteria.
• Ruthless – POs need to ensure that only features that add value to the customer and/or (preferably both!) are built:
  • Prioritisation – examples of prioritisation criteria could include:
    • Cost reduction
    • Revenue increase
    • Market share
    • Ease/cost of implementation
    • Customer satisfaction (i.e., NPS)
  • No means not now – if a feature is ‘de-prioritised’, this does not mean no, it just means that other features are more important now.
  • Follow the vision – when in doubt about the value of work or features, always reflect on the vision.
  • Sunk cost – don’t throw good money after bad, fail early and fail cheap.
• Informed – a great PO needs to be curious about:
  • Team – what are the strengths and areas to develop, what ideas do the team have to improve the product (or how they work)
  • Customer – what are the latest trends in the market, how are customers using the product, how are they modifying it?
  • Competitors – what are the direct competitors doing and plan to do, what possible new substitutes or complementary products are being developed?
• Versatile – know when to be firm and when to adapt
  • Adapt your leadership style to context – you will need to adjust depending on your team and the problem
  • Adapt – POs need to be able to adjust to change in customers and the market and evolve their products
  • Be firm when needed – if people have underperformed you need to address it, if feedback it not in line with the product vision, then ignore it
• Empowering – people work best when they are empowered (with clear direction)
  • Guidance – be clear on the problem you want people to solve (what and why)
  • Autonomy – allow people time and space to complete their work and allow them to do it their way (how)
  • Balance – the balance of guidance and autonomy will change with people and problem, adjust when necessary but be explicit when things are changing
  • Vision – a clear, well-articulated vision provide a north start for everyone to aim for
  • Stories – clear personas and user stories allow people to empathises with the customer and make it clear the value the feature adds.  Use story spines:
    • Once upon a time (introduce character)
    • And every day they (introduce current situation)
    • But one day (explain how the situation changed)
    • And, because of that (impact to the character)
    • Until finally (introduce something that changes )
    • And since then (the character succeeds or fails)
• Negotiable – know when to negotiate
  • When to negotiate – when an idea or feature supports the product vision or will improve the performance of the team
  • When not to negotiate – when the idea does not support the vision or reduced the performance of the team
  • Use tools to build consensus – have an open discussion about features and use tools to take everyone’ss input.  An example may be allocating ‘fake dollars’ to people to spend to get their desired features

Product Mastery is a great book, covering much of the ‘non-technical’ and ‘non-design’ aspected of Product Ownership.  Read this book if you are a developer or designer seeking to make the transition to Product Ownership.

Link to Product Ownership on Amazon

Link to Geoff Watts website