November 01

Tags

Product leadership part 1 – making great decisions

Posted by on November 1, 2018 in Blog, product development | 1 Comment

Product Leaders (PL) need to ensure that teams are building the most valuable experiences for customers and the company.  To do this, you need to find the right problem and then find a pragmatic solution.  Whether the solution should be executed, will depend on whether it is more or less valuable than your other options.

Finding the right problem

  • The most important thing you can do is solve the right problem.  Spend time with customers until you can predict what they are going to say.  Involve customers services agents early and continuously, and don’t be afraid to be bold.
  • Understand the elements of customer value.  The Bain Value Pyramid is very helpful
  • You cannot solve traffic by analysing a single car – use systems thinking to broaden your approach
  • Understanding the type of problem you face, will often change how you approach it (e.g., intuition or rational analysis)
  • Separate strategic decisions from tactical decisions (see below), if you are a PL, you should probably escalate strategic decisions (see the table at the bottom of the page for more detail).
Strategic
Tactical
A strategic decision may be:

  • Difficult/impossible to test or pilot
  • Difficult/impossible to undo
  • A decision that may determine the future success or failure of Monese
  • Take a team over six weeks to build an MVP
 A decision that may be:

  • Easy test or pilot
  • Easy to roll-back or undo
  • Take a team less than six weeks to build an MVP
Examples:

  • Do we expand in North America or India?
  • Do we build a ledger or buy it?
  • Do we change our core partners?
 Examples:

  • Do integrate with Sofort or Paypal first?
  • What limits do we apply for cash-in/cash-out?
The decision should be:

  • Infrequent – every 3/6 months
  • Diligent – a high level of detail on cost/benefit/dependencies
  • Understood – how these decisions impact the whole of Monese
 The decision should be:

  • Frequent – re-prioritised every two weeks (not faster)
  • Understood – potential value, potential time to build & potential risks
  • 80% solution – good enough to learn by launching, or trialling with a small number of people

Solving problems

There are some excellent problem-solving frameworks, for example, McKinsey’s 7 Step Model.  Central to problem-solving is an excellent analysis.  Analysis requires both quantitative and qualitative data.   Barbara Minto also has excellent advice on analysis.

The level of detail for a solution should be determined by the potential impact of getting the decisions wrong (a strategic decision should have more consideration than a tactical decision).  The following should be considered:

  • Value – to customers and the business
  • Cost – money, time, people
  • Confidence – the certainty of your value and cost estimates
  • Risk – regulatory, business, reputational
  • Dependencies – internal and external
  • Assumptions – what would need to be true for this to work?

Prioritisation

Once you have found the right problem and built a pragmatic solution, you still need to establish if your solution is more or less important that all of your other opportunities.  A good prioritisation approach will help.

There are numerous frameworks for prioritising work (see below for some useful links), but teams must find something that works for them.  I have found that using OKRs at two levels work best.  Strategic OKRs, set by the leadership team, and tactical, set by PLs with their team.  OKRs should determine backlog prioritisation, but OKRs are a tool and not a rule – leaders need to be able to make decisions that may hurt their OKRs if there is a significant benefit to the company as a whole (e.g., taking two weeks to build a component library that will significantly speed up all teams).

Good OKR advice can be found in A Beginners Guide to OKRs.

Other prioritisation frameworks (use these for inspiration, not as dogma)