Five frameworks/heuristics for higher quality decision making

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), sellingproblem 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 –

    1. How existential/important is it?
    2. How reversible is it?

Using this framework, here’s how IC PMs typically fit in..

No alt text provided for this image

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.

No alt text provided for this image

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.

No alt text provided for this image

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:

No alt text provided for this image

Mapping this funnel/equation or its equivalent helps us have 2 kinds of conversations –

    1. 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.
    2. 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.

No alt text provided for this image

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 –

    1. 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”)
    2. 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.

Control in theory vs. practice – consumer product research

Every once a while, I observe myself using my iPhone and realize how much control I would want on my phone in theory/if I was asked and how little I need in practice every day.

It speaks to the challenge of getting predictive insight from conversations with users in consumer products where so much of the behavior is subconscious.

By asking questions that draw attention to a particular action or need, we unintentionally move it from the subconscious to the conscious.

And, in doing so, we lose its predictive value.

Schrodinger’s cat.

Attempting to build products remotely during a pandemic

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 –


If it isn’t evident from the title of this note, I’d like to make sure we start by acknowledging one thing – there is no playbook. Every one of us is figuring this out and this post is all about the process of “becoming” and not the “being.”

With that out of the way, I thought I’d start with the “why.” There are a lot of great articles out on the internet offering opinions on how long the unusual situation we find ourselves in will continue. I am not going to add my opinions to the mix. What is clear, however, is that we all likely have at least a few weeks of this ahead of us.

And, as this has been a sea change for many of us, I thought I’d share the best tips I’ve heard from others while also sharing what I’ve been observing and learning from my experiences over the past 5 weeks. Here are my 3 notes to self –

1) Take care of and be kind to yourself. I frequently think of the in-flight announcement that reminds parents to put their own oxygen masks before doing so for their children. The idea at the heart of it is – it is hard to take of others if you don’t take care of yourself.

This has been easy for me to observe – on days I’ve been frazzled and unsettled, I’ve checked in less with the team and thus been a less empathetic person.

So, how can we take better care of ourselves? Here are the 3 areas I think about –

a) Physical: 3 of the most popular tips I’ve heard from folks on our extended team – 1) Start the day with a workout, 2) Build in time for preparing and eating meals, and 3) Set clear boundaries to the workday to enable yourself to disconnect and rest.

While I think these are great, I’ll also share that these haven’t worked for me. In our case, we have been attempting to work while also filling in as pre-school teachers for our 3.5 year old and 2 year old. So, my variant of these have been – 1) Get out for a long walk/jog outdoor with the kids when you’re with them, 2) Order good home-style food if possible so you don’t have to worry about meals, and 3) Alternate early starts with days where you sleep in.

B) Mental/Emotional: This one is tougher. In my case, sleep has been the biggest needle mover of my mental/emotional health. The second has been finding the time to reflect and synthesize what I’m learning.

This is uniquely personal and I hope you’re carving out the time to take care of your mental health. For some, this means regular video calls with co-workers and friends. For others, it may involve therapy or for certain others – time spent writing. :-)

Regardless of how we’re wired, it helps to be kind to ourselves as we figure out how to be effective and productive. We need to begin by meeting ourselves where we are. Mental/emotional progress often looks something like this.

No alt text provided for this image

c) Environmental: 2 popular tips I’ve heard – 1) Wear your work clothes during the work day, 2) Have a designated working station – invest in a standing desk if necessary.

Again, my version of this is – 1) Do whatever it takes to get work done – after some testing with work clothes, I’ve settled into a comfortable shorts and t-shirt routine as it makes much easier to clean up after the kids, 2) Make sure both you and your partner split time between your more ergonomic set up and your dining table. :-)

2) Demonstrate care to your team both by checking in and by minimizing any churn. My favorite check in learning – Ask everyone on the call to share their 1-5 rating by simply raising their hands. Check in with folks who are a 3 and below.”

I’ve also heard lots of great tips on more frequent check ins, fun activities, and hangouts with the team. I can’t speak to this myself as I’ve maintained our pre-remote once or twice a week (depending on the project) stand up meeting schedule. I have a reduced meeting window at this time and get most of my time outside of normal work hours. So, adding meetings hasn’t been an option. And, that has admittedly been frustrating as I’ve not been able to do anywhere as much for the teams I work with as I’d like.

That said, while check ins and compassion are great and important, I believe the best way we can demonstrate care is by minimizing churn. These are difficult times in most companies – there are legitimate concerns about customers defaulting, meeting payroll, layoffs, and such. In companies where cash isn’t as much a concern, there probably are plenty of discussions about whether existing roadmaps need to be changed or thrown out of the window to better meet the needs of users and customers.

These kinds of situations can be very challenging if the team feels unsure about product direction – it helps to have some certainties. These situations can also be frustrating for us as the emotions involved in the moment can result in some unhelpful and incomplete short term thinking.

In such situations, there are 3 things we can do to ensure we’re responding vs. reacting –

a) Make sure we’re requesting our leaders to communicate their priorities. Understanding their current thought process can help us better understand how we should adapt.

b) Communicate what we’re hearing and learning with the cross-functional team leads (and the team) so they are in the know. In challenging times where most things feel outside our control, we tend to operate with lower levels of trust. And, since the amount of communication required is inversely proportional to trust, we need to communicate a lot more.

b) Make sure we are applying problem finding fundamentals more than ever on any new “urgent” project we’re being asked to explore. When times get busy, the fundamentals of putting together a rock solid problem statement (who is it for?, is there a real need?, what is the business value?), laying out the assumptions for the question – “what would it take for this to work?,” validating them with data where possible, and outlining the success metrics matter more than ever. As a friend once said, it is okay to build incrementally – it is just not okay to think incrementally.

No alt text provided for this image

There is no dearth of meaningless projects that sound good but do nothing. As custodians of customer and user problems, it is on us to make sure we’re being rigorous in our thinking. And, the best time to catch ourselves from working on a meaningless project is before any work begins.

It is also a good time to remind ourselves of the cost curve of a typical project. If a meaningless project was costly before the lockdown, it is significantly more costly now.

No alt text provided for this image

3) Obsess about the 2 things that matter. Start and end every day and week with a clear list of the two things that matter. As you make your way through the day, ensure this list stays updated.

Given the extraordinary circumstances in which we’re operating, on some days, this list might involve duties outside of work. All we can do is focus on what we control and do our best with what we have.

This is one of those ideas that is frustratingly simple to understand while being incredibly hard to do. Consistent execution on this idea always ends up being game changing – for us, the team, and the users of our products.

 


My biggest struggles: As I shared above, writing is my form of therapy and I’m writing this on the back of a week where many things felt like they were going sideways.

In this case, I didn’t do a good job defining the 2 things that matter consistently enough. When I did do it, I found myself unwilling to make clear trade-offs and/or communicate my priorities clearly – leading to at least one unsavory situation. And, to top it all, I did a really poor job setting boundaries over the previous weekend and week.

Ergo these 3 notes to self. I’m hoping to do better next week. And, I hope they help you in your journey too.

(Added note: Making it through the work week – especially the last day or two that seemed to stretch forever – was thanks to some amazing cross functional partners. Thank you for your patience and understanding.)


A life sidebar: As I’ve been processing the events of the last few weeks, I’ve found it helpful to remind myself that we’re facing multiple crises all at once – a pandemic, a financial crisis, and various others depending on where you live and what you are going through.

In my attempts to make sense of what is going on, I think there are 2 seemingly contradictory truths to internalize –

1. Everyone around us is hurting from this epidemic. They may be hurting in different ways and to different degrees – but, they’re hurting nevertheless. While it is tempting to compare our pain versus theirs – cut by age of kids, marital status, introversion/extraversion, etc., – the truth is that these are all just marginal differences in the big scheme of things.

2. The real chasm this epidemic exacerbates is that between the haves and the have nots. If we have a) savings in the bank to see us through the next 6 months and/or b) a steady paycheck (likely from a job that can be done remotely), we are firmly in the have category.

This isn’t to trivialize any pain we’re going through. Our problems – even if they are first world problems – are still problems and it is impossible to serve others if we don’t take care of ourselves. And, the only way to make progress is meet ourselves where are, create the space to patiently respond, learn to be kind to ourselves and others… while also continuing to maintain that combination of physical distance and social connection.

Once we do that, however, it is on us to ask the question – what can we do to help those whose needs are far greater than ours?

It is perfectly okay if we aren’t there yet. But, in the spirit of reminders, this is one for when we are ready.

5 steps to building our Product Roadmap

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 –


In our last post on Notes on Product Management, we covered how we’ll build our strategy. Thanks to the experience of going through the strategy creation process, you and the product team understand where you need to focus. The next step is to translate that into a product roadmap.

A product roadmap is a high level summary of what we will build to execute on our strategy. I’ve laid out the 5 steps that I’ve found helpful below.

Unlike prior posts, this post will very tactical and, thus, long. I’m going to do my best to share rationale – but, in many cases, there’s a lot of learning from various iterations (read: stumbles and missteps) baked into these notes. So, please feel free to ask questions in the comments and I hope you find it helpful.

Step 1 – The Roadmap brainstorm: The first step to building the team’s roadmap is a brainstorm with the entire product team.

The best scenario is when every person on the product team is present in-person. Co-location is very powerful. Even in the case of a largely remote product team, it is worth waiting to have everyone together as part of a team event to do one of these. A good brainstorm session can take anywhere between 2 hours to 4 hours. These can be shorter – but it is generally worth the time. (If you’re wondering about the remote version of this given the circumstances, don’t worry – I’ve got you covered below)

For details on this step, I’m going to get very tactical (forgive me):

i) Invite everyone on the team – below is a snapshot of the folks who may be on your invite list

No alt text provided for this image

ii) Book an airy room with a view – It is worth booking the best room in your building well in advance. You may even want to consider taking the team offsite to do this (you will just need a white board).

iii) Agenda –

a) Objective: This meeting will be successful if…. a) we get to know each other, b) align on context – strategy, data, and user feedback, and c) brainstorm product ideas to execute on our strategy. I also share that my success metric for this meeting is “% of shut laptops.”

b) Fun intros: Invest in doing something beyond having folks introduce themselves. Fun facts, 2 truths and a lie, interesting questions, cross introductions, etc., are ways to make this fun. Time invested in getting to know each other is always well invested.

c) Context:

i. Strategy: Remind everyone of the strategy.

ii. User research/feedback: Request the “Voice of user” team to share a 1 slide synthesis of user research/feedback

iii. Data: Similarly, request the “Voice of data” team to share a 1 slide synthesis of data

d) Brainstorm:

i. Prompt: Share the prompt – What are 3 features you would prioritize for us to successfully execute on our strategy?

ii. Brain-writing: Give everyone 5 minutes to write their individual ideas down on post its – this will ensure every member of your team (especially the quiet ones) have time to think

iii. (optional) Group brainstorming: Split folks into teams of 3 or 4 and ask them to discuss for another 5 minutes and further hone their ideas

iv. Summarize ideas: Go to a whiteboard and ask every person to share their ideas with their reasoning – as they share their ideas, cluster similar ideas in groups as themes will inevitably emerge

v. Prioritized vote: Next, and most important, ask every member to vote for their top 2 across all ideas and tally the top themes. Inevitably, 3-4 high priority areas will emerge.

It is impossible to over state the importance of the prioritized vote. It is the step that separates a successful brainstorm from a failed one. Failed brainstorms have organizers take back sheets or photographs of un-prioritized ideas. In successful brainstorms, the entire team walks out with a shared understanding of the few things that matter.

e) Next steps: Promise to synthesize the results of the brainstorm in a roadmap sheet that you will share with the team.

An outcome I’ve observed over the years – a team with shared context always converges on the right set of big ticket items that matter. This is the most magical part of well run brainstorms. You don’t need to pre-alignment meetings to get alignment within your team. Setting context will do.

And, if you are remote, there’s a way to do this remotely too. You just need to set up a spreadsheet where everyone can vote. Below is a screenshot and click here for a sample spreadsheet.

No alt text provided for this image

Step 2 – Organize your plan to ensure you are taking a portfolio view: The next step is to go through your plan and organize your bet into a portfolio view. The 4 buckets I’ve found helpful to use are –

    1. Foundational: These are bets to strengthen technology foundations, remove tech debt, improve experimentation, and developer productivity. Some of these bets can have surprisingly large impacts on metrics that matter because they improve sitespeed/latency and remove other performance issues.
    2. Core: Items in the Core bucket directly and immediately impact the metrics that matter.
    3. Strategic: Strategic bets are those that work toward a mid-longer term plan – they will likely not have immediate metrics impact but are either likely to pay off in the mid-term or make it possible for other high-value “core” bets to work. Features that improve user delight or improve NPS often fall into this category.
    4. Venture: Much lower probability of this working out – but, possibility of large reward if it does.

3 common questions that come up when discussing these buckets.

i) Is there a correct allocation between the buckets?: No. This is entirely situation dependent. If you are going through a massive technical migration, you will have a large allocation on “Foundations.” If you are under urgent revenue pressure, your “Core” bucket may be heavily stacked. So, use your judgment.

No alt text provided for this image

If there is a mistake to avoid, it is over-indexing on “Core” to optimize for short term metric wins. I’ve personally found a ~20%-40%-40% balance between Foundational, Strategic, and Core to be optimal as it ensures we’re making progress across the board. I don’t generally make allocations for venture bets because those allocations are best made at the level of a business unit vs. in an IC PMs portfolio.

2. Where do you allocate time for fixing bugs?: There are two kinds of bugs – blockers/criticals and everything else. All blocker and critical bugs need to be triaged, by definition, immediately.

Other bugs that fall into “everything else” bucket require judgment. Often times, non-critical bugs point to workflows that need to be re-engineered – these can be incorporated in the “strategic” bucket. The rest is up to you. Different folks have different philosophies on it and these also need to vary between enterprise products and consumer products. I don’t know if there is a right one – the only thing that matters is picking the philosophy that works for you, your team, and your product.

3. What is the best tool to use to create this roadmap?: I don’t know. Maybe there is one – then again, there may not be. I’ve found spreadsheets to be wonderful personally. But, I also tend to be a minimalist when it comes to tools. So, feel free to experiment… just remember again that there is no right answer. Find one that works for you and your team.

Step 3 – Figure out if you can accelerate progress via partnership or M&A: Building a product internally is just one way to achieve your goals with a positive RoI. You can also accelerate your progress via two other strategic options – partnerships and, every once in a rare while, M&A.

No alt text provided for this image

If you believe there is an M&A target or two worth considering, build a strong working relationship with your investment/Corp Dev team to build out the investment case. In such cases, make sure your investment/Corp Dev team members have full visibility of your strategy and roadmap (invite them to that brainstorm!).

M&A aside, more often than not, you will likely find ways to partner. There are again two ways to do this –

    1. External partnerships: Most mature companies have a Business Development team that can add a ton of value here and can even be central to your strategy depending on the product. In one of the products I worked on previously, our Biz Dev lead was a core member of our R&D team and a key voice in every product decision. Many a time, these external partnerships also end up being the pipeline for potential M&A.
    2. Internal partnerships: This is often overlooked – particularly at large companies where this can be incredibly valuable. Ever so often, there are internal teams who can help you significantly accelerate your progress toward your goal. They may have already built the tech you are seeking to leverage or may be able to enable you to broaden your impact. Such partnerships are a massive internal win because it ensures teams aren’t doing duplicative work while also ensuring your users get one consistent experience across the product. And, if you do your part in investing heavily with relationship building, generous sharing of wins and credit, these partnerships can be massive bright spots – both professionally and personally.

Step 4 – Share a high level visual in your strategy doc: Bring this back to your strategy doc with a high level visual that breaks your roadmap either in quarters or 6-months/halves. Enterprise roadmaps can go as long as two or three years. But, if it is a consumer roadmap, 18 months is about as long as it probably makes sense (it is unlikely you’ll go 6 months before changing it again :-)).

Use this visual to check if everyone is bought in and if the timelines makes sense – this is especially important if you are running an enterprise product with go-to-market commitments. Below is an illustrative visual – it tends to be helpful to bring cluster features within initiatives that seek to help us execute on our strategy and drive toward metrics that matter. These strategy pillars and metrics, in turn, hopefully map straight to the user/customer problems we set out seeking to solve.

No alt text provided for this image

5) Set expectations both externally and internally: Once the team is aligned, the final step is to set expectations.

a) External: Your GTM partners will now use the roadmap to create the customer/user education plan. This may involve previews, presentations, updates to client decks, and the like.

b) Internal: The more tricky part is setting internal executive expectations. This is especially important if you are planning strategic bets or key infrastructure upgrades that may impact your metric forecasts. This is the biggest area where I’ve seen folks make mistakes – and it is definitely the area where I have some painful war stories myself.

The key here is to take the time to work through the first and second order effects of your planned roadmap. Ask yourself – what will be the impact to metrics that matter for each initiative? Then, think through what happens when all the initiatives roll out together – will there be any compound effects? Finally, think about initiatives partner teams are planning to undertake – do any of them impact your strategy?

When you go through that exercise, you will likely realize that there are a few curve balls that you need to further flesh out. If you are managing a business with revenue expectations, work through these steps diligently with your Finance and Ops partners so you know what to expect. Once you know what to expect, communicate and get exec support.

The better your own understanding of what lies ahead and the better you set expectations, the more freedom you’ll have to execute on your vision. Fail to do that and your roadmap will just be a spreadsheet full of ideas that never saw the light.


Building good roadmaps is a core aspect of an IC PM’s job. But, how these roadmaps get built is often misunderstood. It is the PM’s job to facilitate the conversion within the product team and use the team’s collective brainpower, insight, and perspective to create this roadmap. As a result, we can’t just walk into a new team and build a roadmap. Those kinds of roadmaps result in poor products.

Instead, we need to take the time to get to an understanding of the core problems, articulate them in clear problem statements, define a strategy with the team, and then build the roadmap. When we walk into a new team, we often have to do this in parallel with executing on an existing roadmap.

The outcome of a well run process is a team that is aligned and rowing in the same direction. And, a test of this is when they refer to the roadmap as “our roadmap” instead of “the PM’s roadmap” or “your roadmap.”

When that begins to happen (and it often takes time and a lot of reinforcement), good products and happy users/customers generally follow.

What is strategy and how do I build product strategy?

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 –


What is strategy?

The best definition for strategy that I’ve come across is that good strategy answers 2 questions –

    1. Where should we play?
    2. How will we win?

The “where should we play” question defines our target customer/segment/market and the “how will we win” question tackles how we will differentiate ourselves from our competition.

A clear and well articulated strategy makes it possible to do fewer things better by helping everyone on the team separate signal from noise and easily articulate the trade-offs involved. So, if you’re hearing about or feeling a lack of focus or alignment within your product team, it is likely because of the lack of a coherent strategy.

That said, a well articulated strategy is still just the first step. A well executed strategy is the next step. When a strategy is well executed, it becomes easy for the team to reflect that understanding in their prioritization – i.e. the team can go from understanding the trade-offs to living those trade-offs. A well executed strategy requires the leadership team to align incentives (success metrics, pay, recognition) in a way that makes it easy for folks on the team to make the strategy come alive.

A simple test of this is to ask members of the team a) what they are focusing on and b) what they are not focusing on and why. If you have coherent answers on both, you are witnessing an exceptional example of executing on a strategy.

An example

When Bob Iger took over the CEO of Disney, his strategic vision focused on 3 pillars –

1. Generate the best creative content possible

2. Foster innovation and utilizing the latest technology

3. Expand into new markets around the world

If your first observation is that this isn’t rocket science, you wouldn’t be wrong. That may just be the first takeaway as you’re thinking about strategy – it is easy to articulate a simple strategy. And, it also turns that good strategy is often simple.

Disney, at the time, had a flailing animation division and had fallen behind Pixar (with whom they had a failing partnership) in generating great creative content. They also didn’t have any technological edge to speak of. As a result, the acquisition of Pixar became a relative no brainer – in hindsight at least. Iger and team continued to acquire multiple creative studios with incredible IP – Marvel and Lucasfilm are great examples of this – to continue doubling down on the “best creative content” pillar.

Fast forward to the launch of Disney+ last year and you can see how this strategy came together. Disney+ was made possible by acquisitions above that gave Disney the library of creative content to become a formidable global streaming player right from the get go.

And, the Disney+ launch is also important because it offers a telling story about the difference between a clear strategy and a well executed one. In the year leading up to the creation of Disney+, Bob Iger needed every one of his executives to support this new bet. However, and this is the predicament most leaders of complex businesses face, it is impossible to change behavior when they’re already compensated on how well they manage their existing (successful) businesses.

So, Iger requested approval from the board to move all his executives’ performance based compensation from metrics based on the success of their existing businesses to an evaluation by him on how well they were supporting the Disney+ launch.

That was a master stroke and a demonstration of the art of incentive management by the Obi-Wan Kenobi of CEOs.

So, how does all this apply to me as an Individual Contributor PM?

Your product team could do with a strategy. If you have a clearly defined strategy defined for your organization by your product leader that you are already executing toward, that’s great.

But, if you don’t or if that strategy isn’t yet directly translatable to your team, read on.

Let’s start with the obvious – ideally, every organization has a clear strategy. That strategy, in turn, would enable every product team unit to focus on doing things that ultimately move the needle and win.

But, it doesn’t always work out that way. That isn’t always down to leadership incompetence (though, sometimes, it is). The more complex and large the business, the harder it is for leaders to make statements about focus without risking de-motivation of the areas of the business that aren’t the focus areas at the moment.

So, if you are faced with situations where you are unclear about the strategy, there are 2 things you can do – 1) Ask the leaders (this is the obvious first step) and/or 2) Look at the metrics that matter.

The metrics used to measure success are the simplest manifestation of the strategy. Even when a strategy isn’t articulated clearly, understanding which metrics are emphasized over others helps understand what matters to leadership.

Assuming you have clarity on the organization’s strategy, it is now time to write your own strategy doc.

So, how do I write that strategy doc?

Here is a structure I’ve found useful.

I. Outcomes:

User/Customer Problem: Attempt to synthesize the top user problem you are seeking to solve. And, if you are representing a multi-sided marketplace, lay out the top problem for both sides of the marketplace. Stick to one overarching problem to avoid a laundry list – the purpose of this exercise is to bring focus.

Outcomes you are seeking to drive: Lay out the top 2 “true north” metrics you choose to drive along with a guardrail metric or two. 2 things to keep in mind when choosing these metrics –

1. The true north metrics would ideally be the metrics that matter to your organization. If you have no way of moving those metrics, add “Signposts” that you can move and that you believe will eventually move the true north.

2. Be thoughtful about guardrails/negative metrics and companion metrics. A negative metric if your strategy involves sending customers more email would be unsubscribe rate. Once you’ve got negative metrics sorted, take care to ensure you have companion metrics. Great metrics often work in pairs – e.g. depth and breadth metrics (Weekly active users and time spent per login), revenue and RoI.

If the outcome section reminds you of the problem statement, that’s exactly what it is. Product managers are problem managers.

II. Strategy: Let’s go back to the two questions we laid out when we started – “where do we play?” and “how will we win?” Outside of cases when IC PMs are hired to work on a venture bet, the answer to the “where do we play” question should generally be part of the organization’s strategy. This answer defines the audience whose problems you solve as part of your roadmap.

Our focus, then, is figuring out how to win. And, we do that by taking a stand on where we will focus our team’s energy. It is helpful to articulate these focuses in the form of 1-3 themes or pillars that all contribute to the desired end outcome. These themes work well when they connect to a journey – e.g. acquire -> retain -> monetize – or similar. They can also work well when they clearly ladder up to solve the top user problems you’ve set out to solve.

When done well, the strategy helps everyone understand exactly what we are doing and not doing. So, if you find yourself attempting to organize a catch all list of everything without needing to make hard, sometimes painful, trade-offs, that is not a strategy. That is just a list.

A great way to bring this section to life is to illustrate the user/customer experience 12 or 18 months later after successfully executing on your strategy. Doing so can help folks on the team clearly visualize what success looks like.

An important note – a collection of product principles is not a strategy: It is easy to confuse a strategy with a collection of product principles. Your strategy helps you create a focused plan to ensure you are the go-to solution for the problems of the audience you choose to serve. Product principles, on the other hand, are the values of a product. Product principles are best agreed upon at the level of the entire organization and are analogous to the values of a company. You rarely change them and they represent the choices you make without considering the trade-offs involved. You commit to them because you believe they are the right thing to do.

III. Roadmap: The next step is to lay out what this means in terms of feature ideas. The goal here isn’t to have product specs ready – not yet at least. Instead, the goal should be to get a low definition set of ideas that both feel right and have the team excited. (We’ll aim to cover roadmaps in detail in the next post)

Write all this out in a 1 page document. If you’re not able to synthesize your strategy in a page (with 0.5 inch margins :-)), then you don’t have a clear strategy.

The final test of a clear strategy is that it will make it easy for every member of the team to differentiate between ideas that matter and ideas that don’t. And, if that’s happening, we’re through with the first step.

How, then, do we move to the more important step – moving from well articulated strategy to well executed strategy if we don’t control the incentives of the product team?

By winning the team’s hearts and minds.

This, in turn, happens when we involve folks on our team early and often. Get started with the door wide open (i.e. ask everyone for opinions and ideas), then write your first draft with the door closed, and edit and revise with the door wide open again.

The more the team is (and feels) involved, the more likely it is to be successful.

Therein lies the magic of the strategy creation process. When it is done well, it helps get the entire team aligned and rowing in the same direction. That in turn magically resolves disagreements that might otherwise have showed up in future product specs and prioritization discussions.

If we’re then able to celebrate instances when team members execute in ways that support the strategy, we make it all the more likely that the strategic process we followed has ensured these ideas have now moved from theory to practice.

Do this often enough and the odds are good that we’ll end up building a track record that includes a run of valuable and successful products.


A career and life sidebar: The test of a good strategy within the product team applies just as well to our life and career. If we’re able to consistently articulate what we focused on alongside what we are not focused on, we’re making great progress toward being effective.

And, if we’ve picked focus areas consistent to who we are and who we want to be while being comfortable with the trade-offs we are making as a result of those choices, we’re on the path toward the only kind of success that can leave us feeling fulfilled – the kind that we intentionally chose for ourselves.

Gunpei Yokoi and the Lefty Rx

Gunpei Yokoi, then a creative game designer working at Nintendo in the 70s (before he became a legend), wasn’t the sort of person who was at the forefront of technology. So, he focused on creating games with an approach he termed – “lateral thinking with withered technology.”

Since he couldn’t count on himself being cutting edge, he’d simply look to put commonplace technology in ways that made games more affordable for Nintendo customers. One such technology he was interested in was remote controlled cars – then an expensive luxury in Japan.

Since these cars were expensive due to all the functionality required to control the car, he decided to simplify things by launching a car with just one button that could only turn left – the aptly named Nintendo Lefty Rx.

Its price made it easily available to a massive customer base who enjoyed racing these cars across circular tracks. Even when there were obstacles, you could left turn your way out of it – only adding to the excitement.

I love stories that demonstrate the power of simple, functional products that get the job done. The Lefty Rx is a great example of how simple can be very powerful.

The 80% experience

A question that has helped point to better product design every time I remember to ask it – what is the experience 80% of the users would want to go through? 

When asked, that question first reminds us that we must let go of all the complexity we are likely to introduce as super-users of our own products.

It then pushes us to simplify our flows to the few things most users care by removing any detailed how-to notes, unnecessary choices/steps, and excessive copy.

And, out of this exercise emerges a principle that applies just as well to product or process design as it does to effective communication – focus on clarity over completeness.

Your manager in the product team

A note for new subscribers: This post is part of a 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…

Let’s imagine we posed a question to a group of Product Managers – can you share the list of folks/functions on your product team?

What list would you expect?

When I’ve asked this question, I’ve received answers that I cluster into 4 groups (illustrative).

This turns out to be a helpful way to think about the product team as well… with one exception.

That exception is one that is often absent from lists that describe the product team – the PM Manager

I consider that a big miss because good PM managers play two vital roles to help IC/individual contributor PMs be effective-

A) They help provide the organizational context and feedback you need to be successful: This includes providing clear guidance on overall strategic direction that helps you align your strategy/metrics and also providing feedback on your plans based on their experience.

B) They provide air cover when you need it (and it is likely you’ll need it this week): This is the more critical role the IC PM manager plays. In cultures that hold PMs as the “DRI” or Directly Responsible Individual, the IC PM is accountable for the performance of the product without having any formal reporting authority over the product team. As a result, executing parts of the job may involve pushing folks/rubbing folks the wrong way (when the pushing is over done as you figure out the right balance) from time to time. In such times, air cover is key.

Air cover isn’t just about your manager being the voice of reason to balance your role on the team. It also helps provide the space to execute with confidence that you have the space to try things and fail. An absence of air cover almost always results in an absence in experimentation and, thus, growth – both of the product and the person.

Finally, there is no one else in the organization who is more vested in your success. So, it is a bit of a no brainer to invest in this relationship. And, I’d go as far as to say highly functional product teams rarely become that way without a strong PM <> PM Manager relationship.

Building a great relationships with your manager: As in many matrixed organizations, the PM manager <> IC PM relationship can be a weird one. Depending on the nature of your product, you may be able to get by with little to no working overlap.

And, while there are a lot of folks who attempt to get by with that low touch relationship, my recommended approach would the opposite. So, here goes:

1. Invest heavily in getting to know and understand each other upfront. In a new role, spend time in your onboarding period to get to know and understand your manager. A simple way to do this is to request an hour to do a “user manual” session. Introduce yourselves to each other, share what matters to you and ask questions to better understand what drives them, understand how best to communicate with them, and what they’d love to see in a direct report.

The more you can get to know and understand each other upfront, the quicker you’ll enable trust to follow.

2. Share and involve them as much as possible – allow them to choose how much they’d like to be involved: With their permission, share and involve them as much as possible. Share early thinking/riffs on product direction/wireframes and invite them to brainstorming meetings/team meetings. If they show up on those docs and meetings, ask for feedback and act on that feedback.

I recognize this is sometimes viewed as contrarian advice. I’ve met with a few folk over the past months who’ve all shared situations that share a common cause – the absence of an open channel of communication with their manager. And, in every one of these cases, they were told by someone to only present “the good stuff” to their manager. So, they went through great pains to curate the good stuff and left aside topics that mattered – the pressure they were feeling, the challenges they were facing, and so on.

However, when they’re in the loop, they get to understand the challenges you are facing and how you operate. The better they understand this, the more they can provide specific guidance and trust you. And, the more they can trust you, the more context, scope, and air cover they will provide for you to steepen your learning curve and be successful.

There’s also limited long term upside in an out-of-the-loop manager. If you’re making big mistakes in doing your job, it is best you course correct at the earliest with help from the person who is most invested in making you successful. And, if you are doing your job well, that’s a really good thing for your manager to see.

And, if you don’t trust that your manager is invested in making you successful, it is likely time to leave.

Bonus tip: In the absence of your manager being able to participate in your meetings, a weekly 1:1 is a great forum to keep your manager in the loop. Keep a shared 1:1 doc, populate with the agenda in advance, and keep the hairiest topics right on top of that agenda.

3. For your part, do everything you can do make their life easier. Baseball executive Theo Epstein once said – “Whoever your boss is, or your bosses are, they have 20 percent of their job that they just don’t like. So if you can ask them or figure out what that 20 percent is, and figure out a way to do it for them, you’ll make them really happy, improve their quality of life and their work experience.”

There are many variants of this advice and they’re all valid. The principles at play here are as follows –

1. Everyone has a manager whose job it is to keep them accountable. Even the CEO reports to a board who, in turn, is accountable to shareholders. Understanding how to manage these managers is important for career success and happiness.

2. Become an incredibly valuable direct report and be the sort of person who removes more problems than you create.

These principles are, of course, equally applicable to the IC PM.

Managers make or break our experience. Aside from a few extraneous situations, it is highly unlikely we get anywhere if we have a poor relationship with our manager. In these situations, it is best to leave and find a new home.

On the other hand, if you’re considering a new role, it is worth prioritizing a connection with your prospective manager as among the most important criteria. When you choose well, you work with managers who appreciate your strengths and help ensure your weaknesses don’t get in the way.

And, every once a while, thanks to the power of incredibly aligned  incentives, these relationships transcend work relationships to become deep friendships.

When that happens, it turns out to be special – both for our career growth and our happiness.

Understanding the news and working with data

There’s a learning curve involved with understanding how the news works.

We might begin – as kids at least – with the assumption that the news is the objective list of everything of note that is happening around us/the world. But, we learn over time that a big part of understanding the news is looking beyond what is presented to us and asking 3 questions –

1. How was the information sourced/collected?
2. What have they omitted/chosen to omit?
3. What is the bias in their reporting?

Interestingly, the learning curve around working with data when we make product and business decisions is no different. The early promise of big data was that large amounts of data would solve any problem.

That promise didn’t pan out.

So, asking the above questions when we look at data/analysis and marrying a desire for data with a healthy skepticism for what it is telling us ensures we keep asking the questions that help get us closer to the truth.

As in the case of the news, better to replace “data driven” with “data informed.”