Getting into Product Management – I

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…


A quick overview of what we’ve covered on “Notes on Product Management” so far – Overall: The PM RoleThe 4 key skillsRemote + Pandemic PM5 Decision Making frameworks/heuristicsProblem finding/solving with executives5 habits – high velocity product teams

– Skill #1 – Problem finding: Most important skillProblem statement and hypothesisBuilding StrategyValidating problem statements and hypotheses

– Skill #2 – Selling: Sales and MarketingWriting for executive audiences

– Skill #3 – Problem Solving: RoadmapProduct specs

– Skill #4 – Building effective teams: Knowing thyselfYour managerProduct team culture


I started writing “Notes on Product Management” nearly 2 years ago. The most requested post topic that I’ve received since then has been – how do I get in? 

I’ve waited all this time because I wanted to paint the picture of what the job is actually like before talking about how to get in. As a result, the past 17 posts have all about the 4 key skills required as an IC product manager – problem finding, problem solving, selling, and building effective teams. 

While the series is not yet done, I hope you have enough of an overview of the skills required to decide if you think you will be a good fit. And, assuming that is the case, I thought now might be a good time to talk about getting in. We will cover this topic in 2 parts. Today’s note will focus on the worst about product management and the 4 paths in.

(1) The worst about product management

I like to begin any discussion about getting in by laying out the worst about product management. The 5 biggest complaints I hear from folks at larger product driven companies are: 

1. I spend too much time attempting to align and influence large groups of people who all seem to have different priorities. Once I do that, I need to to influence my leadership to give me resourcing. Everything seems to political – it is exhausting. 

2. My manager/leadership keeps asking me to move faster. But, they don’t help with any of the alignment and they seem to keep changing their mind about about strategy and goals – this creates a lot of churn that I need to manage.

3. Some proportion of my cross-functional partners are either difficult or unhappy with me because they don’t feel as included in the product development process. Or, they think I’m making the wrong decisions. It is wearing me out.

4. I am in meetings all day. When do I get work done?

5. Does the product I work on really matter? I seem to be stuck dealing with minutiae about it every day and I’m not sure if it is improving the world in any real way.

And, the biggest complaints from those who are not in product driven organizations is – “How do I show the key function (typically engineering) that I can add value and that they should trust me?”

While they don’t show up all at once in every product team, they’re meant to paint a picture of the challenges involved in the product development process.

No alt text provided for this image

At this point, I’ll digress for a moment to talk about segmentation. The key lesson in segmentation is – you need to find segments that love what’s good about you and don’t mind what’s bad about you. It is great marketing advice. It also happens to be great life advice – in picking a significant other, a co-founder, or even a career.

That, in turn, gets to why I like starting out conversations by outlining the worst about the job. Product management is a “hot” career in technology right now. There’s a lot written about the opportunity to drive impact, make key decisions, and lead. While some of that is true, it is easy to buy into an incredibly rosy picture.

Like all careers, it has its positives and corresponding negatives. And, like all choices, just because it is “hot” may not mean it is the right choice for you. We spend all our waking time doing our jobs. And, spending those hours doing things we don’t enjoy or don’t want to get good at is a sure-shot way to be miserable. 

So, the question that follows is – what is your reaction when you see the list of complaints?

There tend to be (variants of) 3 responses:

a) I don’t like the sound of it. But, I’m still interested to get in because I want to make decisions/think it will be good for my career.

b) I get that this stuff is hard. I think I will find portions of it hard too – but, I think I will also make it through because the upsides – i.e. being able to facilitate the product development process – are worth it.

c) I love obsessing about bringing groups of people together and obsessing about things to build. So, I think this will be great.

a) is a red flag. b) can work – especially in organizations and teams with cultures that fit you. c) is a sign that you’ll thrive.

(2) Getting an interview – the 4 paths in

The way into product management is a pain for most people. This tends to be the case with any “hot” career simply because the list of people trying to get in is much longer than the list of people actually being hired. This is especially the case at successful companies/companies with strong talent brands. 

This results in companies adopting some bizarre methods to filter people out. One such method that was in vogue for a long time was the Computer Science degree requirement. Another was the coding interview. And, some programs insist that you must start at an entry level position regardless of past experience – this makes it harder to switch if you aren’t early in your career. 

If you’re facing some of these hurdles, I feel your pain. The only consolation is that it isn’t personal. After watching folks go through this process for the past 5 years, I’ve learnt that there is one certainty. People who have both the drive and skills find a way in and have good outcomes. It may take longer than they expect but it tends to work out. 

And, it happens in one of these 4 ways. They are ranked from most probable to least probable with rough percentage estimates.

No alt text provided for this image

i) Internal transfers (50%): This is the most common path into product management.

Why it works:

– You can build a reputation internally that helps you find a sponsor within the product management organization who will give you a shot.

– You can work on an internal product before becoming a product manager. This already proves you can do the job and helps in the internal interview process.

– It is agnostic of company size. In start-ups, you get a combination of fewer available roles and more flexibility/lack of any internal mobility bureaucracy. In larger companies, you have to deal with more rigid transfer processes but also will have more opportunities come by.

Who it works best for:

– Folks who work in functions with strong proximity to product managers. Function that are closely involved in the product development team – e.g., Engineering, Design, Biz Ops, Data Science, Product Marketing – tend to be the biggest beneficiaries of internal transfers.

– It tends to work best for folks who find opportunities in areas that are adjacent to their skillset. For example, a marketer can be great for a product that is trying to find product market fit with customers, a data scientist can do great in a data-heavy AI product, and so on.

Why it doesn’t work: Internal processes can make switching painful. And, cultures that are less open to internal transfers can exacerbate the pain.

ii) University hiring and APM/RPM programs (20%): This is most applicable to folks interested in larger companies (Amazon, Google, Facebook, LinkedIn, etc.) with established programs.

Why it works:

– Such programs typically give you a clean slate/fresh start and typically offer a lot of mentorship along the way

– You are typically competing against people like you – so, you don’t have to deal with that company insider who has already been working on the product over the past 6 months

 Who it works best for:
– For folks in undergraduate or graduate school programs who either have companies come to them (campus recruiting) or proactively reach out to campus recruiters and potential hiring managers.

There are obvious exceptions to this. Amazon, for example, hires hundreds of MBA students every year but is famous for not being influenced by proactive reach outs to recruiters.

Similarly, Facebook’s RPM program is open to folks with experience in other functions (vs. just students). But, as a general rule, being proactive helps unless you’re sure your experience will stick out amongst a pool of hundreds of applications.

Why it doesn’t work: Lot of competition.

iii) Companies or hiring managers who are desperate enough to take a bet on you despite your lack of experience (20%):

Why it works: It is born out of need and it often sets folks who’re hired up for success because you’re hired to get a specific job done and can use the experience to build up PM skills.

Who it works best for:

– Companies with weak talent brands who are desperate to hire strong talent who would not break into PM roles directly elsewhere. (It is important to note here that having a “weak” talent brand isn’t necessarily a bad thing. Most startups, by definition, have weaker talent brands compared to a Google.)

– People with deep expertise in specific areas that a company needs – e.g. growth marketing, SEO, enterprise security, etc.

Why it doesn’t work:

– These tend to be more common in smaller companies vs. bigger companies. As a result, they are often more custom and built on existing relationships.

– As these roles are more common in smaller companies, they often come with limited mentorship/coaching that can cause problems down the line.

iv) Starting a company (10%):

Why it works: While the product manager is the “CEO of the product” trope gets old very quickly, there are many aspects of the PM role that are similar to building a company – especially one that is trying to find product market fit or scale beyond a niche set of users.

Who it works for: Startup founders/CEOs who either get acquired, acqui-hired, or look for jobs after winding down their startups.

Why it doesn’t work: As you can imagine, this definitely not a recommended path into product management as this shouldn’t be a reason to start a company. But, it is a path in nevertheless.


The purpose of today’s post was to provide a lay of the land as you consider product management as a possible career while also providing an overview of the common paths in.

Next week, we’ll look at the process of preparing for that first set of interviews as well as examine 5 practices that I’ve found to be helpful in breaking into that first PM job.

5 habits that help build high velocity product teams

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…


A quick overview of what we’ve covered on “Notes on Product Management” so far –


I’ll start this post with two assertions.

i) Moving with velocity should be an explicit goal for every product team. Velocity is different from speed in that velocity is a vector. Velocity combines speed with direction.

No alt text provided for this image

Making velocity as an explicit goal does two things at once. First, it puts the onus on the leads in the product team to provide the team direction and ensure the path is as obstacle free as possible. For example, executives who commit to velocity do their best to clear out any alignment issues with fellow executives well ahead of the first line of code being committed.

Second, it focuses every member of the team on shipping/iterating quickly. This focus on shipping/iterating quickly turns out to be the best thing we can do to ensure the long term survival of our product.

If our product team works at a start-up, velocity can be the difference between life and death. And, if we work at a large organization, velocity can save us from having a smaller, more effective company, eat our lunch.

ii) Velocity doesn’t scale linearly with resourcing. The bottleneck to higher velocity isn’t always resourcing – it may be so 50% of the time. But, pointing to resourcing when there’s a lack of velocity happens close to 95% of the time. :-)

So, spending all available energy to grow the size of the engineering team working on a product is an amateur’s game. That’s because lean, aligned, and focused product teams operating with high velocity can blow better funded teams away.

As a PM, this might require a bit of reorientation as it is easy to fall into the trap of optimizing for the size of the team. I’d instead wager that it is always better to be part of a team that is known to punch well above your weight.

This, then, leads to the obvious question – if velocity doesn’t scale linearly with resourcing, what helps?


I think there are 5 habits that can step change the velocity of the product team.

(1) Replace hub-and-spoke leadership and communication with tight knit circles:

Many product teams operate via hub-and-spoke models. The PM may be the hub for some members of the cross-functional teams, the Eng manager for the IC engineers, and so on. Information flows from the hub to these spokes. You’re “in the know” when you have 1:1 meetings with the hub.

While this can make folks at the center of the hub temporarily indispensable, it happens to be terrible for the productivity of the team. Trust and psychological safety are the keys to effectiveness on a team. And, hub-and-spoke models aren’t optimal because they create silos that aren’t conducive to building either.

The good news is that there is a better way.

No alt text provided for this image

There are 3 things we can do as PMs to help a product team move away from this model:

    1. Replace 1:1 meetings with team syncs: Remove recurring 1:1s with various members of the product team and replace them with team syncs and stand ups
    2. Document EVERYTHING: Enable every team member to understand the context in which we operate by obsessively documenting everything – from strategy to roadmap to individual specs.
    3. Ensure shared context in meetings: Make team syncs and stand-ups productive by focusing on shared context. Every member of the team should understand what outcomes matter and how their work ladders up.

I think of this this mode of operation as a tight knit circle. Every dot on the circle is key to the shape. And, the space in the middle symbolizes the space we create for the kind of conversations that build trust and psychological safety within the group.

(2) Replace small meetings with large meetings that are used to create alignment.

Imagine you are close to launching a feature you are really excited about. Just as you get close, you realize there is a dependent team who wasn’t on the same page. Now, your team is faced with many weeks of rework before this feature sees the light of day.

This needn’t just be a dependent team. It may be an infrastructure team that didn’t get the memo about your change. Or it could be that your marketing team didn’t have enough time to prepare customers. Or an executive who is opposed to it. And so on.

Whenever a team is forced to do a lot of rework close to or after the launch date, you can be sure the culprit is poor product management. “Selling” is a core product skill for a simple reason – it is key to ensuring folks around you understand what problems you are solving, what they should be doing to help you, and why it matters.

No alt text provided for this image

And, a habit that helps with selling and bringing people along for the ride is embracing large meetings. Here’s why – in the formative stage of every product, it helps to bring the entire cross functional team along. And, if you are partnering with other product teams, that means bringing every member of that product team along too.

Sure, you can shortcut this and aim to only sync with a few of the decision makers. But, I can guarantee this strategy will cause pain down the line. It prioritizes short term efficiency over long term effectiveness.

Being comfortable with running large meetings and using them to create alignment lets us become liberal with the flow of information and context. That, in turn, helps us move significantly faster in the long run. How?

    • We get more eyes and perspectives on our problem statements and hypotheses. The dissent and rigor this creates helps us get crisper and clarify our thinking.
    • When we bring partners along, we avoid duplicative efforts and ensure there is no wasted work.
    • When other teams with similar goals and complementary assets buy into what we’re doing, such partnerships result can result in the evolution of existing platforms and systems – thus creating massive amounts of organizational leverage. It is magic when this happens.

That, in turn, speaks to the power of broad information flow and more perspectives in the room. It moves teams away from a focus on efficiency to a focus on leverage.

No alt text provided for this image

If you want to go fast, go alone. If you want to go far, go together.

(3) Be a Lannister and pay off your tech debts.

When was the last time your team had an urgent bug? I assume you celebrated the folks who burned the midnight oil to solve it?

Acknowledging and appreciating such efforts is good. But, we provide more leverage to our teams when we use such issues to prioritize upstream/preventative bets. Attempting to squeeze every inch of engineering capacity in the quarter to move metrics is a short-term efficiency focused game. And, again, if it isn’t evident, our goal isn’t efficiency – it is leverage.

To enable high velocity product development, we need to free engineering time from constantly dealing with urgent issues. And, we can do do that by marking off a proportion of our engineering capacity for foundational efforts.

No alt text provided for this image

This investment turns out to be one of the easiest things we can do to help create happy engineering teams. Such efforts don’t just reduce painful on-call shifts (they do that). In addition, they are often source of intellectually stimulating work that can often provide leverage to other engineering teams as well.

Finally, while we can run with a ~25% allocation as a rule-of-thumb, this can go up in some quarters depending on the nature of the team. Typically, the more backend work involved, the more it is likely we’ll need to make large investments and ensure the engineering team has the space and autonomy to build scalable systems.

Be a Lannister and pay off those tech debts.

(4) De-risk big bets with many small bets – remember the pottery class A/B test. Every once in a rare while, we’ll work on a project that will require us to take one big not-testable-till-we-launch bet. But, in the majority of cases, we can de-risk big bets by taking plenty of small bets.

It should come as no surprise that the way to do this is with the help of crisp problem statements, hypotheses, and success metircs. The clearer the assumptions in our hypothesis, the easier it is for us to validate them.

No alt text provided for this image

However, the bigger benefit of taking plenty of small bets is that it builds the team’s muscle to become comfortable moving quickly. This is where the story of the pottery class A/B test comes in.

Two artists, Ted Orland and David Waylon, once shared the story of a ceramics teacher who found herself teaching a class on two separate days, neatly divided in half. She decided to try an A/B experiment.  

To the first half of the class she said what she’d been saying for years – “You’ll be graded based on the quality of your work. At the end of the semester, turn in the single best piece of pottery you created.”  

To the other half of the class, she said something very different. She explained to them that they would be graded purely on quantity – “Crank out as many pots as you can this semester.” 

At the end of the term, she noticed that the best pots – both technically and artistically – didn’t come from the quality group, they came from the quantity group. By making pot after pot after pot, they were learning, and adapting. They didn’t set out to make the best pots, yet they did. Meanwhile, the other half spent the semester aiming for perfection and falling short.

(5) Live rug free – prioritize discussing the biggest challenges and be willing to change your mind.

The final habit that helps with velocity is living “rug free.” This is the most abstract note on the list – so, let me explain further.

When there are no rugs in the team room, it is impossible to sweep things under them. And, if we can’t sweep things under them, we have to be willing to encourage discussion around challenging questions and encourage thoughtful dissent.

It is easy to prioritize such discussions on our best days. But, on days when we feel our insecurities gnawing at us, it feels easier to just avoid these discussions and talk about the weather or argue about something meaningless.

But, it is precisely on such days when we should:

    • Ask – “is this the most important thing we need to discuss” – in a meeting that is going nowhere
    • Push for a discussion about a broken working model
    • Ask an executive if we’re aligned on the problem statement before getting attached to a solution

The fascinating thing about pushing for these often uncomfortable questions is that they are generally on the minds of others too. So, as long as it is accompanied by a willingness to listen to the response and change our mind based on that response, asking these questions ALWAYS helps move things forward. They help us resolve disagreements, remove discomfort, and get to alignment without letting any unpleasantness fester.

The courage required to live rug free every day isn’t talked about much. But, it has the potential to step-change the velocity of any team we’re on by changing the culture of the team. Focusing on the most challenging questions creates helps us understand how we make decisions as a group and creates an environment with high trust more often than not.

No alt text provided for this image

It is the sort of thing that never gets easy or comfortable – no matter how often we do it. We just learn to recognize when it is more important to push beyond our fears.

And, it always is.

Validating our Problem Statement and Hypothesis

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…


A quick overview of what we’ve covered on “Notes on Product Management” so far –


If there’s a recurring theme in most notes on “Notes on Product Management,” it is about the importance of starting from the problem statement and getting it right. That’s because failed experiments are a very expensive way to learn and we save a lot of cost when we front load the risk in the product development process.

No alt text provided for this image

Thus, we save a lot of wasted team + organizational time when we get our problem statement right. And, we create winning products when we get the hypothesis right.

Given how important these are, the question that should follow is – how do we ensure our problem statements and hypotheses are the right ones?

The first part of the answer to this question is straightforward – we will never have 100% certainty. All our product initiatives are experiments. Experiments, by definition, can succeed and fail.

But, as with probabilistic outcomes in life, there are things we can do to greatly improve the probability of success. In this case, we can do that by running a good validation process.

I. Validating the problem space

When we first looked at problem statements, we broke a problem statement down into 3 parts:

  1. User: Who is it for?
  2. Need: Is the need real?
  3. Business value: Why should we prioritize doing it right now?

Asking these 3 questions alone helps us weed out poor problem statements. In some cases, the target user is poorly defined. In others, the business value is really not clear. And, then there are others where we may see clear business value but only find a vague user need. Working through these questions ensures we avoid creating problem statements out of some anecdotal comment from a user in an interview or because of email feedback from an executive/founder.

That said, asking the 3 questions alone doesn’t suffice. The most challenging part of this is evaluating the question – “Is the need real?”

Over time, I’ve come to believe that there are only 2 categories of needs worth solving for.

(1) Are your target group of users getting visibly frustrated with the status quo? (bonus points if this frustration is causing abandonment)

(2) Are your users hacking existing solutions to get their need fulfilled? (bonus points for the most creative hacks)

No alt text provided for this image

These become easier to grasp with examples:

(1) The original Amazon Prime problem statement is a great example of frustration leading to abandonment. Shipping costs frustrated users and resulted in abandoned shopping cards. Ergo “free shipping.”

(2) For an example on creative workarounds, I thought I’d share one from my recent experience. Our team recently built a product after we observed widespread “hacking” of existing features on LinkedIn. As the COVID-19 lockdowns began in March, multiple companies shared news of layoffs. We then began seeing posts on the feed from members sharing news of the fact that they’d been laid off and asking for support.

Many of these posts were heartfelt as these layoffs impacted financial security, immigration, and/or insurance. And these members were using their Profile headlines and feed posts to say they were “urgently looking” and needed support.

This behavior was definitely against the grain of conventional wisdom on job seeking (don’t let hirers know you’re urgently looking). But, we were seeing tens of thousands of members share this urgency with all of Linkedin. And, most importantly, we were seeing hundreds of thousands of members support these members in the comments.

So, we debated how we might be able to help these members easily amplify this request for help and get support from the community. That debate led to the creation of “OpenToWork photoframes” which have been adopted by 3M+ members in the 3 months since launch – speaking to the intensity of the need.

No alt text provided for this image

In sum, take the time to lay out the a) user, b) need, and c) business value to validate your problem statement. The “need” is the hardest to validate. Visible frustration or creative workarounds/”hacks” from your target group of users are strong indicators that it is a problem worth solving. Powerful problems often have elements of both.

Beware solving problems where both of those are absent.

II. Solution space

Relative to validating the problem space, validating the solution space involves considerably more art than science. That’s because the source of inspiration for your solution can come from 4 areas (the first two will sound familiar):

(1) User complaints/frustration: We hear from our users via support calls/emails and when we conduct user interviews or research. The general rule with user feedback is to listen for the problem and ignore suggestions for the solution.

While that is often true with consumer products, it is bad advice if we are working on B2B products. Great B2B products are shaped by customer requests because B2B products have to solve for requirements beyond usability – legal, compliance, etc.

Thus, B2B product teams often have a long list of great problems + solution ideas from their customers on their backlog. The onus is on the product team to listen for these ideas, prioritize, and build them in the best way possible.

(2) Existing user behavior: We get to understand existing user behavior via analysis or experiments. The story of the hashtag is a great example of the power of following emergent user behavior.

Early Twitter user Chris Messina proposed using “#” followed by the name of the group to help users find related messages in 2007. Over the next 2 years, Twitter users increasingly began using these “hashtags” to enable others to search for tweets related to a particular topic. Twitter finally built in 2009 and the rest, as they say, is history.

(3) Competitor solutions: We learn about competitor solutions from various sources: i) our users/customers, ii) the news, iii) testing competitor products ourselves, and iv) via intelligence from internal teams (sales, business development, corporate development).

Few good competitor ideas go unnoticed. Great ones typically get copied. On occasion, we see exception ideas – those that can’t be copied by competitors despite their best efforts because they build on what is unique to the company.

(4) The team’s gut/insight, or specialized knowledge: These typically come from two places: i) pattern recognition from having solved similar problems before, and ii) knowledge of technology that enables a better solution.

Many many great companies – think of the likes of Intel, Zoom, Salesforce – have been formed by former employees who went on to solve customer’s problems better. Great products are built everyday thanks to an insight from a team member or an executive about a better way to solve a customer or user problem.

No alt text provided for this image

I’ve observed that it is a good sign if you’re arriving at a solution from more than one source. So, it helps to not get overly attached to one source for solutions and, instead, make sure we’re constantly collecting information, triangulating input, and synthesizing them.

Beyond that, the best we can do is to make our experiments as lightweight as possible so we can consistently learn from them and iterate.


A friend of ours is a poker enthusiast who loves teaching beginners how to play poker. The key tenet of his beginner’s poker lesson is to learn to separate the decision making process from the outcomes.

Sometimes, even the best decisions within a hand can lead to poor outcomes. That’s just a fact of life in a probabilistic game. But, in the long run, the probabilistic edge we gain from good decisions stands us in good stead.

Validation of problem statements and hypotheses works the same way. The reason to approach this phase of product development with an emphasis on a rigorous process isn’t because every product that emerges will be a hit. It is because the process helps us maximize the probability of hits in the long run.

And, besides, the core ability in the validation process is learning from every input – existing experiments, user and customer data/feedback, competitive data, insights from members of the team, and so on. That ability to learn stands us in good stead even when there are poor outcomes.

After all, it sometimes takes a Fire phone-esque failure to inspire the creation of an Alexa/Echo.

The Culture of 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…


A quick overview of what we’ve covered on “Notes on Product Management” so far –


A valued member of our product team recently shared they’re leaving. The logic was sound – an interesting career pivot opportunity came up and the timing felt right.

While I was happy for this teammate, I was sad for me.

When you work at a large organization, goodbyes are a natural part of life. For the most part, you smile, wish the person good luck, and go your respective ways. On occasion, the goodbye is accompanied by relief (often for both folks involved :-)). And, every once a while, you find yourself experiencing a jolt of sadness when you hear the news.

Those jolts of sadness are important moments as they signal how special that relationship/person was to you. And, as I was reflecting on what made this relationship special, I realized it came down to how I think about the culture of a product team.

The culture of a product team

Culture is the set of shared attitudes, values, and behavior of a team. It shows up in the decisions a team makes on behalf of the user/customer and the organization. It also shows up in daily conversation in refrains that implicitly say – “This is how we do things here.”

Every team has a culture. This culture, by definition, is different from the culture of the company because the culture of a team is most driven by the people and processes on the team. While companies with strong cultures can have a high degree of uniformity in decision making process and the kinds of people they hire, the influence is, at best, loose at the level of an individual team. The people in the team and the leaders on it determine the culture.

No alt text provided for this image

If culture determines how decisions are made, the team’s culture becomes the team’s strategy in the long run. So, thinking intentionally about the product team’s culture is among the most powerful levers we have as an individual contributor PM or IC PM.

How can an IC PM impact the culture of the team?

Let’s start with the obvious – there is no way an IC PM can walk into a team and make a proclamation on the team’s culture. :-) This is less about talking and more about doing. And, there are 3 things we can do to help influence the culture of our product team:

(1) Figure out the top 3-4 behaviors we desire in our product team – bonus points for articulating them in a way that sticks (e.g. “It is still day 0 at Amazon”)

(2) Set the right example by embodying these behaviors – bonus points for adopting a few quirks that draw attention to these behaviors

(3) Hire and celebrate members of the team who embody these behaviors and thus become ambassadors of the culture – bonus points for telling stories about these behaviors that are retold.

No alt text provided for this image

As ideas like this are easier to digest with examples, I thought I’d share how I attempt to implement these in my day-to-day.

One IC PM’s culture-shaping process

The 3 behaviors I’ve come to desire on a product team are:

(a) High velocity data-informed experimentation: 

A product team’s velocity is its super power. 3 quirks/obsessions that drive home this behavior –

(i) Problem statements: Velocity is different from speed because velocity also includes direction. We set the direction on the team with the problem statements we articulate. No project starts without every member of the team understanding what problem we’re attempting to solve.

(ii) A focus on experiments/ramps: We spend a lot of time discussing experiments, holding ourselves accountable around ETAs, analyzing results, and celebrating iterations. Very few of these experiments actually hit gold – but, with some thoughtfulness and a focus on rapid iterations, we drastically improve our odds

(iii) Team diligence on operational metrics (email/dashboards): We do our best to create daily email reports and/or dashboards that are sent to the team. And, we use these daily email reports and/or dashboards to ask questions and understand what is going on. A simple rule – whenever there is variance (week-on-week or year-on-year), it is always worth understanding what happened.

(b) Deep cross-functional collaboration:

The two biggest drivers of deep cross-functional collaboration are psychological safety and shared/aligned context – this section focuses on the latter. 3 quirks/obsessions that drive home the point:

(i) Making peace with/welcoming large meetings: Most meaningful projects involve large cross-functional product teams.

No alt text provided for this image

I’ve learnt that there is no chance of accomplishing deep cross functional collaboration if members of the team don’t feel they’re part of the journey. And, ensuring that happens means making peace with (and even getting good at managing) large meetings.

A key lesson around meeting size is that the decision is binary. Either choose a small and efficient meeting where you prevent the meeting invite from being forwarded (and possibly annoy a few people). Or, set the topic and agenda and don’t worry about the size. It may feel less efficient at first – but, the shared context generally leads to higher long term effectiveness.

(ii) Responsiveness on email/Slack/Teams to avoid communication bottlenecks: In organizations where the Product Manager has the privilege to be the hub of the product team, responsiveness goes a long way in ensuring others have the context they need to operate effectively.

I don’t recommend taking this to extremes as it means you’ll never find the time to focus. But, if team members know to expect they’ll hear back on questions and also know how to reach you when they need to get unblocked, it helps.

(iii) Emphasis on planning and documentation: This is another behavior that is key to everyone having shared context. The better the documentation, the more independently everyone operates.

Second, as we work on a larger and more ambiguous product areas, it is likely we’ll have to deal with plenty of conflict and disagreement in the product development process. There’s no getting away from it – especially in organizations with teams with different incentives.

In such situations, habitually starting with a document helps us quickly get to the source of the disagreement (e.g. do we disagree on the problem statement, hypothesis, or success metrics?) and move the discussion to productive conflict and alignment faster.

No alt text provided for this image

(c) Small things done with extraordinary care:

I first heard this idea a few years ago – “You can’t always do big things. But, you can do small things with extraordinary love.” It was love at first sight.

This “extraordinary care” idea isn’t easy to embody but here are 3 quirks/obsessions that attempt to do so:

(1) Invest in getting to know every member of the team: I do my best to start every collaboration with a 1×1 conversation where the only agenda is getting to know the other person. As part of this, I ask 3 questions – (i) Would love to know your story starting from where you were born to now (typically gets a laugh), (ii) What do you do when you have free time?, (iii) What is the dream?

It is amazing how much we learn about people from just one such conversation. More often than not, we just realize that we work with fascinating humans – and that we’d never have known if we hadn’t dug deeper.

(2) Collecting and responding to feedback: We aim to have at least one feedback conversation every few weeks. This is done casually – e.g. just a question in a stand-up about how everyone is feeling. Every one of these conversations tends to result in some pointed feedback that I/we aim to respond to immediately. The more folks understand they’re being heard, the more feedback I/we get, and the better we learn to operate.

(3) Appreciation: The lesson I’ve learnt around appreciation is that it is far more effective when it happens naturally. I’ve seen and attempted versions of “kudos” during regular meetings – but, somehow, forced appreciation doesn’t work anywhere as nicely as when we just learn to notice when folks do something good and ensure they’re celebrated for what they did. Frequently.


The quirks and notes above are all manifestations of my personality and what I care about. However, the core principle underneath it all is that it is important to be intentional about the cultural norms and behaviors we inspire. Culture is always being created – so, it is on us to consciously create one that we desire.

Now, of course, the above notes are all about actions we can take to shape culture. However, the far more effective method of shaping the culture of a group is by finding ambassadors who consistently demonstrate the behaviors we desire. If we find members in the group who exhibit some or all the behavior, we can both celebrate them and tell their stories. Doing so helps the rest of the group take inspiration from “how things are done here.”

Every once a while, we might even find ourselves fortunate to work with a “bar raiser.” Such a person doesn’t just exhibit the behaviors we desire, they do it in a way that raises the bar for everyone else – including us.

This was why the goodbye I mentioned at the start of this note was particularly painful. When I started working on a new set of products 9 months ago, I was blown away by this team member’s velocity, desire to collaborate and learn, and depth of care for all the small details. My time on this team promised to inspire me to set the bar higher for the culture of the team and also learn plenty along the way.

It lived up to its promise.

That, in turn, is the most amazing thing about being a student of culture. As it is a set of aspirational behaviors, we keep meeting people over the years whose behavior helps us better articulate what we desire and show us how we can set the bar higher. No matter their current title, these folks are the true leaders of any team. They lead by setting high standards and expect everyone else to follow – often by believing more in them than they do in themselves.

Working with someone who relentlessly raises the bar is often painful at first – especially if we’re one of those who needs to shape up. It might even seem as if it isn’t paying off for the longest time.

Until it does… big time.

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.