Product leadership part 1 – making great decisions
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).
|A strategic decision may be:
||A decision that may be:
|The decision should be:
||The decision should be:
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?
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)