Escalating product decisions
The first in 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.
Background
In a previous role, I discovered that the org I worked for had a well defined run book of how PMs were meant to handle certain situations. The only problem was, the run book was never documented, and you only ever found out about what you were supposed to do when you failed to do so. Needless to say it was a fairly uncomfortable learning experience.
Now that I have begged, borrowed and stolen my own run book of behaviour patterns, I am capturing them here so that it’s easy for my product team to learn the lessons I’ve learnt, without the pain of how I learnt them. I’m also sharing it publicly in case it helps anyone else.
The subject of this piece is which product decisions I (as a manager of product managers) expect to be aware of, or involved in, as it’s an area where it’s easy to lose trust through misunderstandings or miscommunications. With a clear understanding of what I’m look for, and why I’m looking for it, my hope is it’ll be easier for my team to tick those boxes, freeing up more time to delivering superstar results.
Escalating product decisions
As product managers, we make decisions every day, and many thousands over the course of a year. The vast majority of them can be made easily and won’t have much of an individual long term impact if you get them wrong. That is to say, they can usually be reversed quickly if you discover they’re not beneficial and try a new approach. But some of them are big, some of them do have significant impact, and aren’t easy to reverse. Some of them will also have more of an impact than you may understand.
A major part of my job is ensuring that you are making good decisions. However, I simply don’t have the time, energy or mental capacity to be across all of the decisions everyone in my team is making. So, it’s a case of prioritising — and I’m reliant on you to do that prioritisation for me. I rely on you to show good judgement about the impact of the decisions you’re making, and to involve me appropriately.
If you can involve me in the appropriate decisions, at the right time, I’m going to have a lot of confidence that I can keep giving you bigger and more complex projects.
Here’s some guidance on the types of decisions I want to be informed about:
- Decisions that I need to provide input on
- Decisions that I need to be aware of
- Decisions that should have made differently
Obviously always use your judgement, and no guidance can account for every scenario, but it should give you a clear picture of what my concerns are.
Decisions that I need to provide input on
High impact decisions
First let me define what I call high impact decisions. High impact decisions often have one or more of these characteristics:
- Difficult/impossible to change once you’ve implemented them (non reversible decisions, AKA one way doors)
- Risk lowering customer trust or break a promise to customers that we’ve already made
- Unplanned non-trivial cost implication, eg. they impact a budget, revenue or other financial metric in a negative way
- Prevent customers/partners/suppliers accessing a service they desire, or expect, or currently access
- Will cause disruption to multiple teams or other projects
- The final decision will get made by someone in the C-suite
Now that you know my definition for a high impact decision, I absolutely must be aware if you’re involved in making one. Most likely this is obvious and will naturally happen, but it’s worth stating anyway. In general, I am likely to be an active stakeholder in the decision, but if I’m not, let me know about it sooner rather than later.
Other triggers where I would like to be involved are where:
- There is unresolved conflict between stakeholders or teams about the decision
- You have not made or facilitated this kind of decision before
- You feel uncomfortable / nervous about the decision
- You’re unsure about the best path forward, or the best option feels like a bad compromise
- You do not feel like you are the best person in the company to make the decision or guide the decision making
- You have been involved in this kind of decision before, but the process was hard, the decision was overturned at a later point in time, or you want to be able to do it better
- You don’t know if it affects other people / teams / projects
- I would be surprised to find out you were making the decision
For the majority of these scenarios, the reason I want to be involved is I want to support you when you’re performing at the boundaries of your comfort zone. If I can provide coaching and guidance at the appropriate time, you’re more likely to achieve a successful outcome and your comfort zone will expand again. Secondly, it’ll hopefully prevent any avoidable cock ups…
My expectations of involvement in most of these is that you will have done at least an initial exploration of the decision before talking to me. That means understanding the decision’s stakeholders, team involvement, priority, and the tensions and tradeoffs that you are trying to balance. How well you do this is an indicator to me of what level you’re operating at as a product manager.
When you involve me, make it easy for me to understand my role:
I need your input on DECISION because REASON (choose any of the above). The background to the decision is BACKGROUND (may just be the relevant project, etc). My initial thoughts are we should balance X with Y by doing Z and PERSON A, B and C agree/disagree. How involved would you like to be in the decision going forward?
From that I should be able to glean enough to know how involved I want to get in a decision, and we can take it from there. Most of the time my input will likely be just to support you in your recommendation, or help you get agreement, or determine the most effective path forward. Occasionally I will have visibility of something you don’t, and I’ll be able to provide that context so your decision can be a better one.
Decisions that I need to be aware of
My general rule of thumb for classifying a decision as one I need to be aware of is whether or not I’m going to look stupid if I don’t know about it. This is about appearance of the team (consider it trust at a team level). If I look stupid, or like I don’t know what is going on in my team, it hurts everyone on the team as our individual trust levels are influenced by our team reputation.
Here are some scenarios where I can easily look stupid if I don’t know about a decision:
- If one of my hierarchical peers is heavily invested in the decision and asks me a question about it
- If my boss is heavily invested in the decision and asks me a question about it
- Where some significant user behaviour / metric / major functionality has changed / is changing and I don’t know about it
- Where there has been a noticeably high level of conflict in order to reach alignment on the decision and I don’t know about it
Please try really hard not to make me look stupid (if that’s every required, I’m more than capable myself…).
It doesn’t take much to let me know, it goes something like this:
I’ve just made the decision that DECISION. PERSON A, B and C are onboard with it, and the impact of the decision is expected to be IMPACT. The reason I wanted to let you know is REASON.
In these instances, it’s much more of an FYI, with a bit of context as to why I need to know about it, rather than getting into the nitty gritty itself. I may choose to go deeper depending on what it is, but you don’t need to put time into preparing for that unless I ask.
Decisions that should have made differently
I don’t mean decisions that were the correct at the time, but new information has resulting in you changing your mind. I mean decisions where you’ve subsequently realised that you should have made or guided a decision differently at the time.
Please, please, please let me know when you think you could have made a decision better or would like advice on how you could have. I promise I won’t berate you, judge you, or otherwise make your life difficult (although I do reserve the right to gently tease you if you made a particularly avoidable mistake).
These are the golden moments where we can reflect, analyse and develop our judgment together. Improvement in decision making skills is largely proportional to the number of decisions you can recognise that you could have made better, so let’s use any opportunity you have for that. You will make my job so much easier if you come and talk to me about it, rather than trying to hide it, ignore it, or stick with a belief that you were actually right while others are wrong.
Part of my job is to develop you as a product manager, and I want to feel good about doing that. But help me out — development and performance conversations are often awkward, and I’ve got more than enough awkwardness for both of us already. Now, it’s rarely going to be an awkward conversation, but in my experience, we’ll both get more out of the conversation if you raise the issue, rather than me.
You’re going to be a lot more comfortable and open to learning when you initiate the conversation. It also shows me that you have both self insight, and a growth mindset. Finally, you will also be more open to any feedback I have to offer because you’re asking for it (by far one of the quickest ways to getting better at receiving feedback) rather than me providing it when you may not be in the right headspace to hear it.
As a side note, I’d love to guarantee I’m an awesome manager and will always strike the right tone no matter what feedback or advice I’m giving, but that’s simply unrealistic. I have bad days too. I get stuff wrong, and regret whatever just came out of my mouth, just like everyone else. Like most people, I don’t enjoy having to say things that I know may be difficult to hear, and I don’t always get it right when I do say them. If you’re initiating the conversation, I guarantee you’ll achieve a better outcome than if I initiate it.
If in doubt, it is better to err on the side of involving me rather than not. I will let you know when you can proceed without me. My one ask is that you do the appropriate preparation before you involve me, so I can help you as quickly as I can. There is a very good chance I’m already spread thinly across multiple projects and am nowhere near as deeply involved as you are in the project(s) you’re working on, so I need to be able to understand your situation quickly, give you the feedback you need and then move on.
Obviously, there are few absolutes in this world, and I don’t pretend that this guidance will cover every scenario, but it should give you a solid understanding of how I expect you to involve me in your decision making. As we work on decisions together, we can iterate on the approach and guidance, but this should give you guidance around my starting expectations.