Decision supervision
Part of a series of open essays to my team on how to navigate certain frequently occurring situations. If it’s stating the obvious, brilliant. If not, even better.
Let’s get to the heart of product management — decision supervision. Sometimes it’s your job to make a decision, other times it’s your job to guide others so they can make the best decision. Both roles are equally challenging, and important in achieving successful outcomes.
This isn’t an all encompassing guide by any stretch, but it does touch on a few concepts that may help you navigate and drive decisions forward. At a minimum, it may help you avoid some common pitfalls.
Concept 1: Match effort to impact
One of the biggest mistakes people make over an extended period of time is spending too much time on small decisions and not enough time on big decisions. You only have a finite amount of cognitive resources — it’s up to you to use them wisely.
Get the small decisions right, but the big decisions wrong, and you’ll go super fast in the wrong direction. Get the big decisions right, and the small decisions wrong, and you can course correct as you go.
Aside from poor results, on a personal career development level, rushing big decisions tends to catch the eye of the more senior people you work with, and may damage their perception of your capabilities. At the same time, getting caught in the details of trivial tasks reduces your output, and frustrates those working closest to you when you slow them down and become a bottle neck.
Optimise for quality on big decisions, and quantity on small decisions
High impact decisions should only be made after exploring multiple options in detail, considering a variety of inputs, and scrutinising decision making biases. Low impact decisions that can be easily reversed or won’t make a noticeable difference to a top line business metric, can be made on a much faster timescale, with a lot less rigour.
If you need an analogy to explain this to others, I like to think of it as being on a hike. The big decisions are the ones where you locate yourself on the map, identify where you want to go, set your compass, and head off in a particular direction. The further away the point you’re travelling to, the more important it is that you get your bearings correct. Heading off in the wrong direction will have a large impact on how quickly you get to your destination.
The small decisions are each obstacle you encounter on the way. Fallen trees, flooding streams, dense undergrowth, etc. You’re likely to identify multiple ways around each obstacle, however deciding the optimal path will likely take more time than just moving forward with one of them. Don’t spend 5 minutes deciding whether to go around or over a fallen tree when either option will take you 30 seconds, plus or minus 5.
Have you ever agonised over whether A or B should come first in the backlog, or spent time trying to prioritise a list of 50 bugs? Sometimes these decisions are important, but often we give them more weight than they deserve. Partly because it makes us feel important if we’re working on important things. We also bias toward thinking things are more different from each other than they actually are. If A and B are both going to get delivered within X months, and equally likely to succeed, but they solve different problems, does it really matter which you tackle first? Will you care 5 years down the line? Much better to spend your time thinking about what you can do that you will remember 5 years down the line, than lose yourself in giving artificial weight to arbitrary decisions.
Concept 2: High impact decisions need ‘narratives’
For big, hard, hairy decisions, you need to write down what you’re intending to do, and justify why you’re intending to do it. Once you exceed a certain number of factors or considerations in any decisions, it becomes too complex to keep in your head all at once. It’s far to easy to lose track of your own logic and be inconsistent without knowing it.
It is also too hard to communicate complexity to other people any other way. Slideshows are ambiguous. Verbal explanations make it too easy to agree on completely different interpretations. Designs can and should complement a narrative, but don’t answer the range of questions that need to be answered.
Narratives are becoming increasingly common in product management circles, but not everyone is using them yet. Amazon does it as a faux Press Release and FAQ doc as part of the ‘Working Backwards’ process. My experience is it’s the one technique every PM who leaves Amazon takes with them.
There are three key benefits to creating a narrative. The first is that you are forced to articulate your ideas when writing them, which drives out ambiguity — clear writing equals clear thinking. Writing down your rationale so it can be scrutinised is also one of your best defences against being influenced by cognitive biases that may reduce the quality of your thinking.
The second benefit is the review process. It is a structured way to solicit input and achieve buy in to your approach as you iterate your thinking — you can also iterate super fast when it’s just words.
Finally, you end up with a document that you can give to anyone on the team to give them the context of what you’re doing, why you’re doing it, and any boundaries, which dramatically reduces onboarding times for new team members.
Done the right way, the process of formulating narratives along side design reviews inherently builds trust with those involved in the project. They get to see their considerations reflected in the document, how your thinking has developed and why you’ve ended up where you have. This should makes it a lot easier for them to align with you.
I’ll go into more details about the ‘how’ of narratives at another time.
Concept 3: Have a north star
Keep in mind what your ultimate direction is. Going back to the hiking analogy, it’s not the bearing on your compass to your next waymarker, or your ultimate destination. It’s what you use to navigate when you’ve had an accident, you’re lost and disorientated, you can’t find your compass, and everything that can go wrong has gone wrong. At this point you don’t need exactitude. You don’t need a precision. You need a general direction to head in to keep things moving while you get back on top of things.
Your north star may not be for the entire org, it may be specific to your team. It’s quite likely to be an interaction metric, and it should be something that you’re confident that if that metric is going in that direction, you’ll be ok. For an e-commerce outfit, maybe it’s the number of products purchased. For a streaming service, the number of streams. Generally it will be something simple and obvious. So obvious that people can forget about it looking for more nuanced metrics.
When does this occur in real life? Think about changes in strategy, org restructures, complex migrations, delays on major projects and dependencies, failures of critical functions and features, or just really complex features… the list of imperfect scenarios is endless, and can often be a combination of two or more events.
As products mature, it’s very easy to get lost in the details of tradeoffs and compromises, or the finicky details of some complex implementation. Keep your head down too long, and before you know it, you can’t quite remember what your focus is and you’re following your curiosity to the next interesting thing.
Whenever you feel yourself getting a little bit lost, or unsure about the right path, refocus on your north star and check whether what you’re working on is moving you closer to that end goal. If not, is there something else you could be doing that would?
Whenever you’re stuck, at a stalemate, or blocked, revisit your north star and use that as a guide to unblock you if you can. Whenever you’re having trouble getting other people onboard with your approach, restate your north star and ensure you’re both aiming for the same thing. You may be surprised with what comes up from it, and what new pathways appear.
Being the person who can calmly bring people back to the purpose, and reframe problems at a time of crisis is one of the fastest ways to be noticed as an invaluable team member. It’s also your job as the product person, and if you don’t do it, folks will notice.
Concept 4: Have a viewpoint… and then change it.
Always have a view point. Then change it.
It’s the fastest way to move things along, and it’s the best way to ensure you never get too attached to one approach or solution. ‘Strong opinions weakly held’ is the name of the game.
If you hold off having a viewpoint until you’ve collected all the input you want, it’s very easy to over commit to the particular solution you develop at that stage. Unfortunately, you’ll always get new information and you’ll need to be able to detach from any solution that no longer fits the problem. If you are continually adjusting your thinking based on new data, you shouldn’t get too attached to any one single idea. So start evolving your thinking early to avoid making a single immovable decision.
Being less attached to particular ideas will allow you to be more open to feedback, and more curious about the root causes of the problem. Both good things to be when formulating a path forward.
In terms of speed, having a viewpoint gives yourself and others direction. The faster you can state a viewpoint, the faster you can validate or invalidate it, and the sooner you’ll receive concrete feedback on it.
If you’re concerned about being wrong, or having an uninformed opinion, one of the best pieces of career advice I was ever given was:
No one remembers your first attempt or where you start. People remember and judge you on where you end up and how fast you get there.
The secret sauce to mitigating uninformed opinions is to explicitly state where you are in the decision cycle, and your confidence in the decision at this stage. Add in a dash of the decision’s importance and you’ve got a reliable, repeatable template for how to communicate where you’re at. It will help prevent you from spending too much time on small decisions, and monitor progress with big decisions.
The sorts of thing I really like hearing, and give me confidence, are:
- This is a big decision. We’re at very early stages and the current view point is X. However that hasn’t been validate and our confidence that it is the right path forward is low.
- This is a big decision. We’ve iterated through X different view points, and the current thinking is Y. We’ve had input from A, B and C, and validated the approach by Z method. At this stage we think we have a 50% probability of success, based on similar decisions we’ve made in the past.
- This is a small decision. Our approach is X. We’ve not spent much time considering alternative options, so our confidence is low, however we’re happy to proceed at this stage as the consequences of a sub-optimal decision are relatively small. (Put another way, the additional effort to validate the thinking outweighs how much we could gain from a better decision)
Concept 5: Think statistically
Thinking about decisions in terms of probable success, or bets, is an approach that is becoming increasingly popular as we accept uncertainty is a constituent part of product development. When the future is uncertain, statistics is the best proxy we have for predicting what will happen.
[As an aside, I hated statistics at school and for many years I avoided them as much as I could. Then life happened, and like it or not, I needed to understand how the data I had in front of me could guide future endeavours. As a result, over time I’ve become fascinated by how stats can help you make better decisions.]
Let me give you an example of how you can use stats to guide your decision making. Say you’ve done 10 launches in the last 12 months, 3 were successful, and 7 failed. That means for any new launch, if you follow the same process, you can expect a 30% probability of success. Based on this, you can estimate that you’re likely to need 3–4 features for a high probability that you’ll move a particular targeted metric. Obviously that’s a very simplified version of events, and you can get a lot more sophisticated than that if you choose to.
That’s not really where the benefit is though. By stating the probability of success, you’re being explicit about the uncertainty inherent in product development. This can help create, or reinforce, a cultural mindset that allows people to get comfortable with risk, uncertainty and expensive learning as part of the product development process.
Ideally it also means you’re much less likely to come to an abrupt halt when something doesn’t go according to plan, and you’ll be much more adaptive and iterative in your approach.
Wrapping it all up, these are some of the more effective techniques I’ve learnt along the way, and try to consciously apply as I go. I say consciously apply because they don’t always come naturally, and it’s worth recognising this. This stuff is hard to do well, as it’s often counter to our impulses and instincts (impulses and instincts that also may have been contributed to your success so far). So if you only take one thing from this, it is just to try to be deliberate in how you supervise decisions, as without deliberate practice, you’re unlikely to improve.
