A note for new subscribers: This post is part of a monthly series on my notes on technology product management (this is what I do for a living). You might notice that these posts often link to older posts in the series on LinkedIn even though they are all available on this blog. That is intended for folks who only want to follow future product management related posts. Finally, for all those of you who don’t build tech products for a living, I believe many of these notes have broader applicability. And, I hope you find that to be the case as well…
A quick overview of what we’ve covered on “Notes on Product Management” so far –
A product manager brings a team of cross functional stakeholders together to build products that are valuable, usable, and feasible.
In past notes, we’ve spent time on the 4 core skills that help us achieve these outcomes – problem finding (the most important), selling, problem solving, and building effective teams.
Our abilities in each of these 4 skills shows up in the quality of decision making we enable in our teams and organizations. And, that decision making quality is at the heart of the value we bring.
Typically, high quality decision making shows up in two important ways –
1) A track record of products that users/customers find valuable (and maybe even love)
2) A consistent ability to build high performing product teams that are happy and motivated (and maybe even inspired)
In sum, a simple way to think about our value as a product manager to our organization is to ask – what is the quality of the decision making I help facilitate?
The word “facilitate” is an important one because it isn’t just about the decisions we make. A big part of the job is facilitating high quality decision making within our cross-functional teams and in our organizations more broadly. That can only happen if we’re able to consistently bring clarity to the problems we attempt to solve. And, today’s post is going to be about decision making clarity.
Decisions – Existential and Reversible.
Jeff Bezos once shared that he approaches decisions based on how they show up across 2 axes –
-
- How existential/important is it?
- How reversible is it?
Using this framework, here’s how IC PMs typically fit in..
It is rare (maybe even disfunctional) for an IC PM in any organization to make decisions that threaten the existence of the company. That is what the C-Suite were hired to do. In the rare cases where we’re involved in reversible but existential bets, our role typically lies in helping craft the strategy and the reason for the bet.
Existential decisions aside, we do often make decisions that are hard to reverse – typically as a result of the effect our decisions have on product or technical architecture. Aside from ensuring we’re giving difficult-to-reverse decisions due consideration, our role is often to identify them and provide clarity on the trade-offs to the relevant executives who can then make the right decision with appropriate context.
That leaves us with decisions that are neither existential nor irreversible. While that sounds innocuous, the truth is that these decisions make or break the product. Even if each of these decisions may be small in impact, these are large in volume and have compound effects on the quality of the product.
Here, I’d argue that the single most important ingredient to getting to high quality decisions is a combination of high speed decision making combined with reflection.
And, a key enabler of high speed decision making is a set of frameworks/heuristics that help us both clarify our thought process and help us communicate/facilitate appropriate action. Here are five decision making heuristics I have found most useful.
(1) Start every meeting and every discussion about building product with the Fundamentals (Problem Statement -> Success Metrics)
That I am starting here should come as a surprise to no one who has been reading these notes. Everything begins with the problem statement. Clarifying the problem statement, hypotheses, and success metrics at the start of every meeting, strategy doc, and spec alone will step change the quality of our products and discussions.
I was reminded of this recently when I nearly derailed a meeting by making assumptions about what we were solving and took us down the wrong path. Luckily, a couple of others reminded me to go back to the problem we were solving. And, before we knew it, we were moving quickly toward a far better solution.
The power of the fundamentals is that they help us cut through the noise to focus on solving problems and driving outcomes for our users/customers.
(2) When faced with a strategy question, map the trade-offs into a 2×2 chart
A 2×2 chart is a simple chart with two important decision criteria in the X and Y axes. Just as we looked the existential vs. reversible decisions in a 2×2 above, there are many classic 2x2s – e.g. urgency vs. impact, breadth vs. depth, metrics vs. mission, scale vs. type of problem, etc.
2x2s can also be extra versatile by enabling you to capture up to 4 criteria when you add in the size and color of the bubbles (example below). You can also extend this optionally to 3x2s depending on the nature of the problem being discussed.
We often need to make facilitate discussions on key strategic decisions that involve trade-offs. Every time we attempt to have a conversation about trade-offs, we’ll likely be able to have a higher quality conversation if we mapped the trade-offs into a 2×2.
(3) Let every discussion on roadmap priorities be grounded by the funnel/equation
No matter what product you work on, there likely is a funnel or equation that maps what you drive to outcomes that matters. Here are 2 simple examples:
Mapping this funnel/equation or its equivalent helps us have 2 kinds of conversations –
-
- Where is the bottleneck?: There’s always one bottleneck that can help deliver a 10x improvement versus others where the potential may just be incremental. Understanding this helps us focus.
- Where can we simplify?/what can we clarify?: For consumer products, simplicity and clarity result in better outcomes. Internalizing our funnels helps us create products with intuitive defaults, fewer steps/unhelpful choices, and clearer copy.
(4) Become more effective at collaborating by accelerating the process “Know -> Understand -> Trust or mistrust”
In most organizations, trust is the single biggest determinant of a team’s speed. The trust between the executives involved determine how quickly organization level misalignments are resolved. Then, the trust between and within the working teams determine how quickly all the small/daily issues are resolved.
While there’s little we might be able to control in terms of executive relationships, we have plenty of daily influence on the relationship between and within the working teams.
So, what is trust and how do we get more of it?: The best definition I’ve come across for trust is – “trust is choosing to make something important to you vulnerable to the actions of someone else.”
We are trusted by others when they choose to make themselves vulnerable to our actions. In teams we are part of, this happens when our teammates share sensitive information, express thoughts and emotions that matter to them, and/or leave decisions in our hands. And, we earn or lose this trust by virtue of how carefully or carelessly we deal with what they’ve placed in our care.
While there’s no replacement to being worthy of this trust in the long term, there is one way to speed up the process of building trust. Invest in getting to know the folks you work with closely.
Once we know someone, it becomes easier to understand them based on their actions. As we have some context as to what makes them tick, it becomes easier to understand why they do what they do and how they make decisions.
And, assuming their approach is aligned with how we approach key decisions, we arrive at trust… or, if not, mistrust (let’s face it – it doesn’t always work out). Either way, the faster we get to understanding the nature of the relationship, the better we can operate.
And, we can get there by spending 30′ at the start of a project to do an introduction with everyone we will work with. Here are 3 questions I ask (as an example) –
-
- I’d love to get to know your story. Where were you born and what happened between then and this conversation? :-)
- What do you like to do in your free time?
- What is the dream?
As simple as this introduction process sounds, I can’t begin to explain the number of times I’ve run into trouble because I’ve skipped it – consciously or unconsciously – in the interest of moving quickly.
(5) Visualize the Peer NPS question and ask the two leading indicator questions to become a collaborator who is worthy of trust
As we work on building products, we often work with peers – fellow Product Managers on other teams and cross-functional partners. One of the questions I visualize asking these peers at the end of the project is the NPS questions – “How likely is it that you would recommend working with me to your peers?”
It becomes evident at the end of a project if we’ve left it with folks who are detractors, neutral, or promoters. The more the promoters, the better our reputation. The better our reputation, the easier it is for us to be effective in future projects because other collaborators start by assuming trust and good intent.
But, while asking the question at the end of the quarter is useful, it is more useful to look for leading indicators while we’re in the midst of execution. Outside of making good decisions as a product manager, there are 2 questions that tend to be good leading indicators of our ability to be good collaborators –
-
- Am I persuading my peers based on the merits of the argument? (vs. “I have decision making authority here” or “Executive X wants it done this way”)
- Am I going up my peer’s chain of command in my attempts to make progress and doing so without her/his knowledge or presence?
Checking in often on these two questions help us do two things at once. First, they help prevent honest mistakes. And, second, they help us operate in a way that makes us worthy of trust… and respect.
A Learning a Day 