5 lessons – a synthesis of the Product Management series so far

I’ve been writing a newsletter on product management since Oct 2018. With 32 editions, I think we’re about the ~75% of the way there on this journey about IC/individual contributor product management. I have a few remaining topics* I’m hoping to cover in the next months – e.g., Career Conversations, Data, Leadership, Types of PM roles, Writing, IC and Management paths, Onboarding, Interviews. But we are definitely closer to the end than the beginning. After that, we’ll likely switch to managing PMs (a tentative plan :-)).

So it was nice to get an opportunity last week to share a synthesis of this newsletter to a group of graduate school students. The presentation was titled “5 lessons I’ve learnt from my time as a Product Manager at LinkedIn.” As with any synthesis, it is missing a lot of the detail that (hopefully) makes these articles useful – but it does instead help to tell the story at the highest level. 

I hope you find it useful. (click here for the slides)

As I shared in the presentation, putting this together filled me with a lot of gratitude – for the folks who’d given me a shot at learning and growing as a product manager and to those who had consciously and subconsciously taught me these lessons over the years.

And finally, thank you to all of you for giving me the opportunity to share these notes with you and for all your encouragement and feedback.

With gratitude

Rohan

*PS: If there’s a topic that’s top of mind for you that you don’t see, please just share in the comments/send me a note on rohan at rohanrajiv.com. Below is what we’ve covered so far. We’ll back to regular programming next edition.

Building a compelling design vision

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 design vision is a powerful tool. The ability to create one cuts across 2 out of our 4 core skills. They are primarily a “problem solving” tool as they help transform our ideas for a solution to visuals. But they are also key to our ability to sell/influence others.

The design vision brings our strategy document to life. It is critical – so much so that it is best to not ship a strategy doc without a link to the vision video that illustrates our roadmap.

A science-first approach to understanding design

Before getting into the details of the approach, I wanted to share some background on my journey. I had no training in anything related to design when I became a PM. I am not one of those people who naturally gravitated to art or design either. I knew I had decent (read: passable) aesthetic sense. But that was it. So, for the first eighteen months in my journey as a PM, I leaned heavily on my design partners and other PMs who seemed to know what they were doing.

But this part of being a PM gave me the “heebiejeebies.” Every time I was presented with a screen, I felt like an imposter who was going to be outed for not knowing how to do my job.

I then moved to working on consumer products, got lucky to get the opportunity to get schooled by a couple of product and design leaders who – through osmosis – helped me understand how to deconstruct a screen and what to look for. The approach I’ve developed since is an approach that emphasizes the science over the art – i.e., I take a very considered step-by-step approach. 

No alt text provided for this image

What I do know is that once you apply the science hundreds of times, you get glimpses of the art of looking at a screen and experiencing that niggling feeling in the gut that tells you something is wrong. Or when you are midway through the process of creating a design vision and just know it isn’t developing as it should be. Understanding the science has helped me get in touch with and appreciate the art.

With that said, let’s dig in. 

The 4 steps of the process

(i) Create an exploration OKR with an expectation for one of two kinds of design visions.

Both parts of this step are equally important. 

First, allocate sufficient time during the quarter to create a design vision – both on your calendar as well as your design partner’s calendar. Don’t expect your design partner to just cook something up in their spare time. That doesn’t work. Creating a design vision is a true exercise in partnership and needs dedicate time – ideally in sync with the creation of your strategy.

No alt text provided for this image

Second, there are two kinds of design visions. I differentiate them by their horizons:

Variant 1 – 12-18 month horizon: The primary purpose of this variant is to inspire. It needs lower fidelity designs (i.e., you don’t need to sweat the exact user interface or copy) and is useful when you’re charting the path forward for a large and ambiguous problem. 

Variant 2 – 6-9 month horizon: The primary purpose of this variant is to get the broader team excited about the product we’ll ship in the next 2-3 quarters. In this case, you need reasonably high fidelity (UI that is 80% complete, illustrative copy). This is more focused in scope.

It helps to align on the variant as you define the exploration OKR 

(ii) Kick off by aligning on value and creating a clear (and reasonable) timeline.

The next step is to kick off (see this post on kick offs) – this is especially important on a new product team. If the team is not new, it helps to do a light version of this. The key steps are:

 (a) Make sure everyone is aligned on the problem we’re solving and the value of the solution we want to build. This is where design visions can go sideways. Good problem statements help define what is not in scope and keep the group focused.

No alt text provided for this image

(b) Create a clear and reasonable timeline for 2 phases:

  • Diverge: During this phase – it can be done in 2-3 weeks – the design team should have plenty of space to brainstorm/organize brainstorms, gather inputs, and put a storyboard together. It is good to plan small group check ins once a week during this phase.
  • Converge: This phase – typically ~2x longer than the diverge phase – is when you begin iterating closely and rev-ing based on feedback. During this time, I’d recommend setting time very often – at minimum thrice per week and a check in with the broader team once a week. It isn’t uncommon to check in via a daily standup during this phase. If this sounds like an intense phase, it is. :-) But it is also among the most fun and memorable phases when you’re in the trenches with your design partner.

Note on timeline: Every once in a while, you will sprint and create a design vision in 2 weeks because of some external/executive pressure. While exhilarating if done well, it is definitely not a sustainable way to create these. I’d suggest reserving that energy for extenuating circumstances.

(iii) Learn to facilitate useful discussions by focusing on one aspect of the User Experience equation at a time

The best thing you can do as a product partner is to facilitate structured discussion. For example, it is tempting to just jump into providing random feedback on the colors and user interface. But that will just result in unproductive discussions and lost time. 

The basis for structured discussion on designs flows from an equation I shared before for the user experience:

No alt text provided for this image

Let’s break out the components:

  • User interface (UI) = Layouts, fonts, colors, illustrations, and copy.
  • Interaction design (IxD) = Effects of clicks, taps, and gestures – if you are building a feature as part of a larger product, the interaction design will be dictated by the design system in the product
  • Information architecture (IA) = How the entire app/website is organized – if you are building within a large app or website, your product/feature is just one part of the entire user experience. So, every other feature and product plays a part in the user’s experience.
  • Value = Both real and perceived value – real value is tangible and perceived value is often a result of the story/narrative/marketing. Both matter. Also, value is multiplied. This means if the value is 0, it negates any work on the rest of the user experience.

I laid out the equation in this way because our natural instincts when looking at designs move from right to left.

But much of life is acting in ways that are opposite to some of our natural instincts. And giving useful feedback works similarly. So, the equation should instead be written the other way around.

No alt text provided for this image

This means you spend a few days or week at a time working through each of these components in order: 

(1) Value: This is what you did in the kick-off. You’ll need to spend as much time as necessary to get clear on the problem you’re solving and the intended value of your solution to the user. 

(2) Information Architecture (IA): The IA should be the first stop as it requires us to make foundational decisions about how the user interacts with our product/feature as part of their overall user experience on our app. This involves working on questions like – how will the user discover our feature?, what are the key components on the screen?, what are the primary and secondary tap targets?

IA questions are the toughest questions to answer in my experience. It is worth taking the time to get this stage right. 

(3) Interaction Design (ID): The next step is to consider the interactions in detail. This involves understanding the impact of clicks or taps or gestures, experimenting with motion design, etc. This part of the experience dictates how the page responds to a user.

In my experience, this is typically dictated by the design system as you generally want to be consistent with the rest of the experience. If you are working on a smaller app/site and don’t have a design system, it is a great prompt to create one. 

(4) User interface (UI): This tends to be the other area to spend a lot of time on. Again, fonts, colors, and illustration tend to be heavily design system dependent. But there’s tremendous opportunity to shape (i) layouts and (ii) copy.

(i) The function of a good layout is to establish hierarchy in the eyes of the user. It should be easy to understand what to pay attention to and what to do next. This is one of those things you learn by experimenting yourself and observing good hierarchy in other products that you use. Simpler is better. And that is easier said than done. 

(ii) Simple/clear instructional copy can have massive impact on your user experience. Copy could be the subject of an entire post or even a series of posts. So, I’m undoubtedly not going to do it justice in two paragraphs. That caveat aside, I’ve learnt two lessons about copy. First, partner closely with folks who are good at creating copy – lean on any copywriters in the organization along with your product marketing counterparts. Creating good copy is a team sport.

Second, invest in learning about using good copy – e.g., check out sites like this. The right subject line on an email, the right page header, and the right CTA text can drive significant lifts in your key metrics. It is worth investing your time in getting those words right.

(iv) Bring it all together with a video

There are two simple steps here: 

(a) Use a simple storytelling slide template. Here’s an example.

No alt text provided for this image

 (b) Record a video with narration and background music. Video helps for 3 reasons:

  • It avoids any presentation hiccups when you share out your design vision. Computers have a way of acting up and becoming slow just before key presentations. 
  • Uplifting music adds a LOT to the final presentation
  • The video file is easily shareable. That’s the outcome you want. :-)

——————————————————————————————————-

As you can tell, this post is as much about creating a design vision as it is about becoming a better partner to the design team. If I had to pick the highest impact habit out of all of this, it is learning to facilitate focused discussion on a screen.  

It is not just useful because it provides focus to the team (it does that). It is useful because it helps us hone our own skills. Every time we end up pausing and focusing on the IA/information architecture and discussing it in detail, we’ll learn from everyone else in the room. The same happens as we debate layout and copy.

And once we habitually approach design conversations with this sort of structure, it has an unintended side-effect. As the scientific approach provides a baseline amount of rigor, it then frees everyone in the room to appreciate and participate in the art of building a good product.

When that happens and when it comes together in a powerful design vision video that gets the team excited and inspired, it is magical.

Running effective team meetings (feat. written discussions)

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 quick recap on the 2 dysfunctions of a team

In the last post, I shared the 2 most common dysfunctions of a product team – 

(1) Absence of shared context. Everyone in the product team is paid to make decisions. It is impossible to make good decisions when you are missing context. A simple test – can everyone on the team confidently articulate the problem statement, our desired solution, and the key data points that give us conviction?

 (2) A lack of deep trust and care. If people in the team don’t trust others to make the right decisions, we’re going to frequently find ourselves in decision making bottlenecks. A simple test – would your Eng/Design/Data/Marketing partners trust you to make the right calls on their behalf? Would you do the same?

After laying these out, I shared 2 powerful tools to deal with these dysfunctions –

(1) Start the collaboration with an effective Kick off (previous post)

(2) Run effective weekly/bi-weekly update meetings (this post)

Kick Offs help us start our teams/initiatives off with positive momentum as they ensure we start our collaboration with shared context and an understanding of each other – which provides the foundations for trust. However, the power of a great kick off doesn’t last forever. An effective weekly or bi-weekly team meeting helps us keep the momentum going.

Let’s start with getting 2 things out of the way –

  • Who attends? For most IC PMs, it is helpful to invite everyone who is on the product team. This will typically include your cross-functional partners, any partner PMs, and all the engineering ICs. For senior IC PMs (typically late SPMs or PPMs) who are leading multiple connected initiatives and x-functional teams, it may not be possible to involve every engineering IC on a weekly or bi-weekly cadence. So, it might make sense to split the meetings into a monthly with all ICs and weekly/bi-weekly with the x-functional leads.
  • How often? Can be monthly or bi-weekly or weekly depending on how well you use the time/shipping cadence of your team. There’s no “right” answer. Similar note on length – they can last anywhere between 30 mins – 1 hour. I’ve personally found 45′ to be a sweet spot.

With that out of the way, let’s move to the elements of an effective weekly meeting.

The 4 elements of an effective weekly meeting

No alt text provided for this image

After years of experimenting with weekly meetings, my formula for a weekly meeting has 4 elements. Of course, we all operate in different contexts, cultures, and with different working styles. So, while some of the principles will hold, your mileage with specific tactics will vary:

(1) Clarify the purpose – for ourselves and others

Derived from the 2 dysfunctions of the team, effective bi-weekly/weekly meetings focus primarily on shared context and tackle deep trust and care as an ancillary benefit. 

The reason for this is that trust is a complicated beast and isn’t one we can tackle explicitly every meeting. Here’s why:

  • The best definition I’ve heard for trust is: “Trust is choosing to make something important to you vulnerable to the actions of someone else.”
  • We choose to trust folks when we know and understand them. That trust means we assume good intentions every time they act. That is why taking the time to get to know people while sharing what you’re all about is critical. When people understand us, they begin to trust us – or choose to make something important to us vulnerable to their actions – and vice versa. This is where kick-offs and introductory 1:1s (see post) help.
  • The trust that is built in us grows when the team sees consistency over time. This is the role effective weekly meetings play. Trust is thus the by-product of a good product.
No alt text provided for this image

(2) Keep a consistent agenda that ladders up to this purpose

This is definitely the area where your mileage may vary significantly. I’ve come to appreciate the value of consistently building an agenda with the following pieces:

(a) [Optional] Start with some form of kudos/recognition. These are useful because they help highlight individual work while also naturally helping everyone understand key milestones/wins. The only caveat here is that the effectiveness of this depends on the size of the team. It doesn’t work as an agenda item when the team is too small or too large. I don’t have a rule of thumb for what constitutes “too small” or “too large” – so, it is one of those things you’ll learn after you try it over 3-4 meetings.

(b) [Required] Share any context/updates from leadership or the broader org: If there is anything that impacts the team – e.g., a new strategic priority, an org change from a partner team, an important meeting, etc. – take the time to share this with the team so everyone has the context. If these were sent via email, it helps to share that with the group in advance as well in case there are any questions.

 (c) [Required] Go through key product changes and/or lessons learnt. This is the most important part of the meeting. It helps build shared context and ensures we’re operating well. There are a few things that help here:

  • Go through every key product change in sufficient details – this includes giving the team context on the problem we’re solving, walking through designs and hypotheses, and sharing any results. This helps others connect the dots and follow up where there are questions/disconnects.
  • Share insights from research/customer calls/user data, etc. Again, it helps folks connect the dots.
  • Finally, the insights/discussion from this meeting should go into the team’s weekly update and/or executive update. This ensures everyone is on the same page on what is being communicated.

(d) [Required] Understand impact or changes to key metrics/results. The products we ship are in the service of making a positive impact to users, customers, and the business – we measure this impact with key metrics/results. So, it is imperative that we spend time on a weekly basis talking about key metrics/results. In case of new teams where these metrics aren’t baked yet, it helps to have a clear ETA for when these metrics will be ready. In the meantime, individual experiment metrics can work. 

(e) [Optional] Leave time for “special topics” – discussions on key documents or decisions: This may not be a standing agenda item but it is helpful to carve out time for readouts on key experiments, strategy or design changes, and/or go-to-market updates.  

(3) Showcase urgency by standing up and by facilitating written discussions

 “Showcase urgency” is easier said than done. 2 things that I’d recommend –

(a) Stand up (i.e., physically): There’s something about standing up that helps us become more intentional about our time and bring a sense of urgency to the meeting.

(b) Facilitate written discussions (instead of “round-the-rooms”): Whenever you have a topic to discuss, default to written discussions.

No alt text provided for this image

What is a written discussion? It involves sharing a prompt with the group and having everyone share their point-of-view on a shared spreadsheet. Then, you go through the spreadsheet live, aggregate themes, and drive discussion around those themes. Here’s an example spreadsheet.

These discussions are more effective (you have an open discussion on themes in everyone’s POV and get to the best answer), efficient (you hear all POVs without going around the room), and equitable (the discussion is focused on ideas vs. who is most willing to speak up).

(4) Collect feedback/iterate

Every quarter, dedicate 15′ in your meeting to facilitate a written discussion about the meeting itself. Ask folks for 1 thing they appreciate and 1 thing they’d like to change about the meeting. Asking for 1 thing forces prioritization and any themes you notice in the feedback will be very valuable. 

A big part of running “effective meetings” for any group is to keep evolving them as the nature of work and camaraderie on the team evolves. Change is the only constant. 

Kick Offs feat. the 2 dysfunctions of a 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 – 

—————————————————————————————————————

Every few months/quarters in our time as Product Managers, we will find ourselves working on new problems with new groups of people. This can happen due to a multitude of reasons – change in scope/focus, new strategic priority, new data, and so on. Some of these are better reasons than others. Regardless, it is inevitable we will find ourselves in situations where we work on new projects with new sets of people. 

The two dysfunctions of a product team

The default way of working is to just get on with it. We get a few of our close partners together, begin writing up a doc, schedule a brainstorm or two along the way, and bring people along as and when we realize we need to do it.  

This default way of working is also suboptimal because it doesn’t address the two most common dysfunctions in a product team – 

No alt text provided for this image

(1) Absence of shared context. Everyone in the product team is paid to make decisions. It is impossible to make good decisions when you are missing context. A simple test – can everyone on the team confidently articulate the problem statement, our desired solution, and the key data points that give us conviction in our approach?

 (2) A lack of trust and a resulting deep care for the work and for each other. If people in the team don’t trust others to make the right decisions, we’re going to frequently find ourselves in decision making bottlenecks that get in the way of progress. A simple test – would your Eng/Design/Data/Marketing partners trust you to make the right calls on their behalf? Would you do the same?

It is tempting to think of product teams as complicated organisms with unique sets of dysfunctions. But, when we’re dealing with dysfunctional product teams, you’ll find that it nearly always comes down to one or both of these dysfunctions.

It is rarely about the politics of the situation or that one problematic character. While it helps if you’ve got a group of individuals who all get along, we rarely have that luxury. Product teams are fluid, and it helps to build muscles to be able to make the best out of most situations we are in. When in trouble and in doubt, look for an absence of shared context and trust/deep care.

So, what’s the solution?

Let’s start with the disclaimer – there is no guaranteed solution to all problems in life. We all have our own unique situations.

But, that said, there are two things we can do every time we find ourselves working on a new project/team that will solve these problems ~90% of the time:

(1) Start the collaboration with an effective Kick off (this post)

(2) Run effective weekly/bi-weekly update meetings (next post)

This is both ridiculously simple and hard. Simple because it is easy to know we should do it. Hard because it requires discipline to make the time to invest in these. It is always tempting to skip the Kick Off to make immediate progress. But that progress is always fleeting.

The 3 elements of an effective Kick Off meeting

No alt text provided for this image

An effective kick-off meeting has 3 elements:

(1) Get to know each other – deeply: We start by spending time getting to know each other. That knowledge will help accelerate our ability to understand each other and build trust.

 (2) Understand context: This covers the “why” we’re starting on this project (typically business context) and time spent to understand user problems and the current solutions (if any).

 (3) Get creative juices flowing with a brainstorm: Understand what is on everyone’s mind and tease the possibilities ahead. 

Let’s now dig into each of these.

(1) Get to know each other – deeply

I have a go-to “get to know” activity I’ll recommend as an example.

No alt text provided for this image
  • Break the group into pairs – ideally pairs of folks who don’t know each other that well.
  • Give each pair between 10-14 minutes (5-7 mins each) to get to know each other. Before they go out, remind them that we don’t care about their work history/resume story. We’d love to understand what makes them tick and their quirks. This is all about going deep.
  • They will then need to come back and cross-introduce their partners.
  • When they come back, just go around the room and have every person cross-introduce their partners.

At this point, we’ll already start to see something special emerge. We’ll often hear people saying – “Wow – I didn’t know this about you despite working with you for 3 years!” or “That’s crazy. Me too!” It is also lovely to hear someone else replay what they understood and felt. 

It is nice to keep these organic – e.g., encourage others in the room who know the person to add what they know. When these evolve into a celebration of the people in the room, the atmosphere can feel magical.

This activity can take between 1-2 hours depending on the size of the group. If there’s one thing I’ve learnt, it is to not cut this short. In the long run, this 1-2 hour investment is among the most important investments we will make. 

(2) Understand context

No alt text provided for this image

There are 4 kinds of context that are helpful to share (keep this to 1-2 slides per type for simplicity):

(a) Why/business context. Help everyone understand why this project or team exists. This is typically thanks to some combination of business objective and user problem. It is good to talk about both.

(b) Qualitative understanding of the user (research): Share a synthesis of all the qualitative user research available. A good kick-off meeting is creating in partnership with the team. And this is a great opportunity to prep with our design, user research, and marketing partners.

It is also a great opportunity to build empathy for our users. Having any clips/recordings of impactful user interviews go a long way in grounding the group.

(c) Quantitative understanding of the user (data): Share a synthesis of any data available on the user. This includes dashboards that measure user data, past experiments, or analyses. Again, this is an opportunity to prep with our data partners.

(d) Technology challenges: If possible, it is also great to give folks an overview of any key technology challenges/hurdles we might need to solve for. 

(3) Get creative juices flowing with a brainstorm

Again, I have a simple formula I’d recommend:

No alt text provided for this image
  • Give every 5 mins to think about a prompt like – what do you think are the most important problems we need to solve for our user?
  • After everyone has written their ideas, breakout into groups of 3-4 to discuss for 15 mins. During this time, the group needs to align on the top 2-3 problems that rise to the top.
  • Then, get every group to share the top problems and any context from their discussion. Write them all out on a board/shared spreadsheet (if remote).
  • Finally, ask every person to cast up to 2 votes on the problem that resonates most with them.  

At this point, this exercise would have given everyone a taste of working with each other, previewed the possibilities ahead, and hopefully gotten them excited.

9 times out of 10, a group with the same shared context arrives at the same set of conclusions. That early alignment then gives us the opportunity to begin writing our shared strategy doc/product spec.

———————————————————————————————————————————-

Here are 2 resources that might help bring this to life –

  • Kick off meeting slide deck: It outlines the above structure. Important to call out here that the tactics (e.g., the get to know each other exercise outlined above) matters far less than the reason for doing so (shared context, deep trust/care)
  • Brainstorm voting sheet: The act of getting the group to align on what matters is critical to making progress. A brainstorm with a set of unprioritized ideas is a failed brainstorm.

———————————————————————————————————————————-

This was a detailed dive into what a good kickoff meeting looks like. Done well, this single exercise provides enough positive momentum to move the team forward together for months. It helps ensure we start a collaboration with shared context and an understanding of each other which provides the foundations for trust.  

A great kickoff won’t permanently keep the dysfunctions at bay. The next step to build on a successful kick-off is to run effective weekly meetings. More on that in the next post. 

Exploration OKRs – feat. The Law of Shitty Planning

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 – 


In many product teams, there are very noticeable repeating periods of stress.

That period of stress is driven by “planning.”

No alt text provided for this image

Most organizations beyond a certain scale have planning cycles that are either quarterly or half-yearly. Planning exists to ensure everyone is making the best use of the most valuable time in a software company – IC/individual contributor engineering time. The output of the planning process is typically some metric target for the team that is a by-product of the team shipping good products. In many organizations, this is done in the form of “OKRs” or “Objective” and “Key Results.” 

The stress is driven by everyone waking up from execution mode to realize that we need specs and designs to make accurate estimates of the scope of work. While some organizations/teams do a great job fostering a culture of thinking ahead, most others find themselves in a stressful quarterly scramble. 

The good news is that there is an alternative. Regardless of the culture of your team, a simple habit that can save you from this – and they are Exploration OKRs.

What are exploration OKRs? How are they different from “normal” OKRs?

When product teams set their OKRs, their OKRs are created based on how they’ll use IC/individual contributor engineering time. As an example, an OKR might be –

Objective: Create a frictionless checkout experience for our logged-in customers (pillar 3 of our 2022 strategy)

Key Results for Q4

  • Improve checkout completion rate by 10% (from 50% to 55%) by shipping Ux improvements xx and yy
  • Reduce checkout abandonment rate by 10% (from 50% to 45%) by launching checkout reminder emails

These are examples of “Execution OKRs.” Each Execution OKR involves us shipping one or many products and it comes with the expectation that we’ll stay close to progress via stand-ups with our engineering team, go-to-market team, etc. 

Exploration OKRs – on the other hand – are OKRs that do not involve IC engineering time (exceptions involve partnering with experienced tech leads). Exploration OKRs are created in collaboration with the rest of the cross-functional team to validate problem statements and hypotheses. 

No alt text provided for this image

There are 4 kinds of Exploration OKRs:

(1) User/customer/partner research: This could be a mix of qualitative research (interviews) or quantitative research (surveys) that help us better under our user/customer/partner needs. This is typically done in partnership with user research, product marketing, business development/partnerships, or sales teams

(2) Data analysis: This typically involves correlational or causal analyses of existing user date and/or available 3rd party/macro data. This is typically done in partnership with our data science or strategy/operations teams.

(3) Strategy: This involves writing up a strategy document. This is typically in partnership with the entire team. If done well, this typically only needs to happen once every ~4 quarters.

(4) Design: This involves getting to high fidelity mocks/prototypes. This is done in partnership with our design teams

Done well, exploration OKRs create a pipeline pre-planning that look something like a research pipeline for a pharmaceutical company. We start by building conviction around a problem/opportunity space, begin validating it by talking to users/customers or studying their behavior via data. Then, we spend time sharing our path forward in words – by creating or updating our strategy doc – and then in visuals.

No alt text provided for this image

This isn’t necessarily an illustration of the amount of time required. If we’re talking about a small feature, this process can be done in a matter of a couple of weeks. But it can take significantly longer for larger features. 

All investments here are governed by the Law of Shitty Planning – Any sacrifice in rigor before the planning process will result in 10x the heartburn after the planning process. 

This makes sense. Why is it hard to do?

It is hard to do because there is the classic urgency vs. importance trade-off. Execution is always urgent and takes priority in our calendars. But, exploration OKRs help us get ahead and smoothen the planning stress. And the good news is that there are 3 things we can do to make this work:

(1) Align on and share exploration OKRs as part of our planning document. This means explicitly aligning with our cross-functional partners on our commitments as team across the buckets – Research, Analysis, Strategy, and Design.

(2) Schedule time for exploration OKRs just as we do for execution OKRs. For every engineering stand-up on your calendar, we should have a stand-up with our design partners for that design vision or with our team for iterating on our strategy doc.  

(3) If we’re new, resist the temptation to “just ship something.” It is tempting to fall prey to the temptation to just put a spec hastily together to keep the IC engineers busy.

The unsaid problem with executing on poorly scoped ideas is that they will inevitably either not ship or will need to be rolled back. Every idea we decide to build brings tremendous cost with it – for us, the team, and the organization. Morale wins in the short-term will result in morale-loss in the long term.

The better approach is to buy time.

No alt text provided for this image

Three superior alternatives that we have at hand are:

(a) Invest in product craftsmanship: Read user support tickets, audit the existing experience, prioritize and fix all those “fast follows” that never got built. These often deliver more long-term business impact than we realize.

(b) Invest in data and technical foundations: Work through the tech leads’ wish list and set the team up for faster iterations moving forward.

(c) Help other teams who are hustling to meet a deadline. Pay it forward.

These will always be better decisions for the organization instead of engaging in low conviction busywork. 

Again, it is challenging. Very challenging. When we’re new, it is the opposite of “hitting the ground running.” And it always hurts in the short run.

But, taking the time to build conviction that we’re working on the right thing is what separates the amateurs from the pros. It is the difference between velocity and speed.

No alt text provided for this image

And, optimizations for speed are typically a result of prioritizing business and political considerations over user needs. When we optimize for velocity over speed, we recognize there are times when we need to slow down all activity to ensure we’re getting the direction right and investing in the highest leverage problems and solutions.

 That, then, gets to the power of exploration OKRs. By helping us build conviction in the direction we’re headed, they help us create execution OKRs that create meaningful impact for our users that stand the test of time. 

And, most importantly, they help us stay on the right side of the “Law of Shitty Planning” – Any sacrifice in rigor before the planning process will result in 10x the heartburn after the planning process. 

The challenges of managing our psychology – and habits that help

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 product manager’s role is to bring the cross-functional team together to build products that are valuable, usable, and feasible. 

A big part of the job – unsurprisingly – is about building product that is valuable, usable, and feasible. But, that tends to be the easy part. The challenge typically lies in dealing with the feedback from all the people involved in the process.

As we attempt to build the right products, we get a ton of feedback. This feedback is split between feedback on the product and feedback on our process. Therein lies our challenge –

(1) We need to synthesize the feedback on the product to facilitate building a better product

(2) We need to synthesize the feedback on our process, decide what applies, discard what doesn’t, and manage not to take it personally.

The common theme is synthesis – we’ll cover that in a separate post. Today’s post will focus on how to do (2).

In the absence of our ability to process all the feedback and synthesize it effectively, our emotional state feels like a yo-yo or, for the more geeky folks, a nicely scripted sine wave. Yesterday might have marked a high because our CPO mentioned our product in the All Hands. Today marked a low because our Eng partner told us our spec sucked.

No alt text provided for this image

Combined with our desire to hold it together, we then end up feeling like Louisa in Encanto (The “Surface pressure” song is genius).

I don’t ask how hard the work is

Got a rough indestructible surface

Diamonds and platinum, I find ’em, I flatten ’em

I take what I’m handed, I break what’s demanding

But

Under the surface

I feel berserk as a tightrope walker in a three-ring circus

Under the surface

Was Hercules ever like “Yo, I don’t wanna fight Cerberus”?

Under the surface

I’m pretty sure I’m worthless if I can’t be of service

No alt text provided for this image

This yo-yo/sine wave emotional state sucks. We lose all sense of self in the process and let ourselves being driven by our wounds and insecurities instead of optimism, conviction, and wholeness. We need to avoid it at all costs.

Here are 3 habits that help us with that.

Habit 1: Screwing up and the feedback that follows that is inevitable. So, once or twice a week (or some regular cadence), make sure you get the therapy you need.

By default, humans are better at complaining when things go wrong vs. appreciating when things go well. It is why gratitude is powerful. So, by default, you will likely get more feedback when you screw up vs. when you do things well. To compound this, negative feedback sticks in our memory longer and more effectively than positive feedback.

As screwing up is inevitable, you need a regular outlet to process your feedback. The first phase of this process is best done with a human (or humans). This may some combination of an actual therapist, your partner at home, a close friend, a trusted cross-functional partner, or your manager. A common miss here is to neglect your manager. Therapy is a key part of a good manager’s skill set. 

This friendly therapist will help you get through stage I – going from raw feedback to processed feedback by:

  • Removing emotions and any harshness: The act of sharing and discussing will help you separate the emotions from the facts by removing any feeling of harshness of the feedback. Typically, the harshness of the feedback reflects the harshness in the giver’s self-talk. It isn’t about you.
  • Getting to the 3 variants of content: Once you get down to the content, you’ll see three variants of content. The first is a reflection of the person giving it – e.g., their continuous discomfort with the stage of the product. There is typically little you can do here. The second is a factual improvement you could make to the process going forward. And, the third will be something about your style that could be easy or hard to change – depending on how connected it is to your core strengths. 

Getting here will help us get to stage II – the “gift” stage. Feedback isn’t always a gift we look forward to. But, once we get to this stage, the end result is a gift we can decide to keep or discard. This decision is best made solo – either on a walk, by writing, or when we’re occupied by something else.

No alt text provided for this image

In sum, make sure you have consistent access to the therapy you need when you need it. 

You will need it. 

Habit 2: Make peace with paranoia by consistently asking 2 questions – “why could this be great?” and “why could this suck?”

Every time you try to do something new or markedly different (e.g., pivot an established product), you will have both fans and cynics/critics. That’s just life.

After a point, you’ll realize that relying on feedback from fans or critics isn’t all that helpful. Nobody really knows. It is your responsibility to develop good judgment. Over time, few things will count more in the early phases of a project than the strength of your conviction. This will then be followed by your ability to execute to generate evidence to back up your conviction.

Given this, people can go 2 ways:

(1) The kool aid route. Pretend everything is awesome. Look at every datapoint or feedback as a way to just strengthen their conviction – typically by creating an underdog/seige mentality within the team.

(2) The “it is a disaster” route. Give in to the hundred obstacles that inevitably exist and flip-flop their way to doing nothing.

The middle path – as is often the case – is the hard path. On the one hand, it helps to both be constructive and surround ourselves with people who are constructive. That means we get rid of any time spent presenting problems and, instead, spend time asking – what would it take for this to have meaningful positive impact on our users? Then figure out how to make that happen. 

On the other hand, it is equally important to make peace with paranoia. Listen to the cynics and understand what the biggest reasons for failure might be. That dose of fear and uncertainty is healthy in reasonable quantities and will help us build better product. The example I think of is “Richard Parker” – the tiger in Life of Pi.

No alt text provided for this image

In the story, Pi Patel faces what feels like insurmountable odds when he realizes he has to survive on a boat in the middle of the ocean with a hungry and scary tiger. 

However, as he narrates his story, he says something powerful – “Without Richard Parker, I would have died by now. My fear of him keeps me alert. Tending to his needs gives my life purpose.”

That’s an example of the positive role fear and paranoia can play. It isn’t healthy to be driven by it. But, it is useful to embrace it along with optimism and conviction. 

And, one way to do that is to habitually ask 2 questions as we think about our work – “why could this be great?” and “why could this suck?”

They help us find the middle path and keep us grounded.

Habit 3: Invest in life and learning outside work to give you the perspective you need

This tends to be the hardest of them all – especially for all the type A over achievers out there. It is easy to give work our all, slump into what remains of the weekend with some Netflix, and then back to work. 

But, investing in a life outside work tends to pay massive dividends in the long run. When we invest in our health holistically – i.e., across physical, mental, emotional, and spiritual dimensions – we build character and resilience. 

But, I think most relevant to our psychology is that our life outside work gives us the space to gain perspective. This could be the work we do on our non-profit, learning a sport, deep conversations with loved ones, hiking, reading philosophy, strengthening our faith, building a side-project, playing with our kids or loved ones, or something else. Investing in 1-2 areas at any given time remind us that there is so much more to life beyond work. They remind us of our own mortality and thus remind us of a larger purpose and world of which we are a part of. 

This perspective helps us put our daily ups and downs in context. They reduce the amplitude of the swings. A good friend once told me that the graph of our emotional swings should look like an ECG’s reading. You want to avoid it being flat. You also want to avoid it being too high. Everything in between is normal.

No alt text provided for this image

 A story that I frequently think about and share on perspective is around a lesson someone shared with me when I was interviewing them – “You never know if a good day is a good day.” 

 In his first startup, a healthcare startup, they brought in a very experienced management team. It felt like a great day. 

A decade later, he worked for two years to acquire a company in Ohio. It fell through in the final stages. It felt like a bad day. 

But, looking back from when we spoke, the story was very different. The experienced management team made some decisions that led to the demise of the company. In retrospect, that was a bad day. 

And, when the deal fell through, he got recruiter to a start-up, saw them through a major exit, and went onto use the proceeds to become a successful angel investor and then venture capitalist. In retrospect, a great day. 

The takeaway – “One of the things I have come to learn is that you shouldn’t get too depressed on the downside, or too excited on the upside – just keep plugging away. Eventually, good things happen. You just never know if a good day is a good day.”

I’ve found this to be an enduring lesson. It is easy to get caught up in what feel like finite games with wins and losses. In truth, we are all playing infinite games where wins and losses are fleeting. In the final analysis, all that matters is being intentional about what game we choose to play and who we choose to play it with. There are few things worse than playing games we didn’t want to win. With people we never wanted to play with. 

Assuming we’re intentional about that, we just need to take care of our psychology and find strength every day to… just keep playing.

Effective 1:1s – a field guide

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 – 

Take a look at an IC product manager’s calendar and it is likely you’ll find a number of 1:1 meetings. These meetings are an important part of a Product Manager’s life. So, I thought we’d spend time on lessons I’ve learnt about 1:1s.

 We’ll do this by talking about the 4 types of 1:1s – (1) Introductory 1:1s, (2) Manager 1:1s, (3) Recurring 1:1s, (4) Ad hoc 1:1s. You’ll see 3 principles at play:

(i) 1:1 time is precious. Intentionality when we set them up and thoughtfulness/preparation when we show up to them go a long way. Between the two, I’d prioritize intentionality.

(ii) Go deep and talk about things that matter as quickly as possible as often as possible. This doesn’t mean you don’t kick 1:1s off with personal updates. It just means you talk about what you’re actually feeling/going through vs. the weather.

 (iii) Invest in ad hoc 1:1s with people in your broader organization (a.k.a. serendipity 1:1s). These often help you develop empathy for the challenges others face, help you connect the dots, find future collaborations, and can even the source of lovely friendships.

 With that said, let’s dig in.

 (1) Introductory 1:1s

 There’s a simple guideline with introductory 1:1s – meet people 1:1 before you have to ask them for something. So, as part of your onboarding into any new role or project, figure out every person you expect to work with and meet people 1:1 first. Do this early. It always helps.

Now that we’ve gotten that out of the way, let’s get to the purpose of the introductory 1:1. It is to help us get to know people well enough so we can begin to understand them. That paves the way for trust – and, in occasional cases, mistrust. Either way, it is in your interest to make this process happen fast.

No alt text provided for this image

I’ve found 3 questions to be particularly helpful in the introductory 1:1s –

(a) I’d love to get to know your story – from when you were born to how we’re having this conversation. This generally results in a chuckle as folks are used to introductions about their work experience. However, I prefer the story outside of the work experience. With the right follow up questions, this question helps get to what matters to them and why?

(b) If you had a few hours of free time, what would you do? Hobbies tell us a lot about what matters to a person too.

(c) What’s the dream?  The most common follow up question I get to this is – “Do you mean my work dream? or life dream?” To this, my response is always that it is intentionally ambiguous. Again, this provides more insight into what matters.

Typically, working through these questions takes a good 15-20 minutes. That’s perfect. It then flips over to us to share our story. And, if our story has everything we hoped to hear – starting with why we do what we do, our influences, and how we approach work and life – we’re off to a great start.

(2) Manager 1:1s

The sign of a good manager is someone who (i) wants to help you be the best PM you can and (ii) has the skills to help. If this is your manager*, your manager 1:1 is among the most important meetings in any given week. It is the time in the week when you invest in your own development and get unstuck.

(*On the same token, if the description above does not describe your manager (or in some cases your manager’s manager), it may be worth finding a new team/company. More on this in a future note.)

 So, given this context, how do you make the most of a manager 1:1? Ensure the agenda covers what is top of mind for your manager (which should align with your priorities) while providing all the context they need to be helpful. If possible, share a pre-read so they have time to process.  

Here is a template with the structure I use for my 1:1s. It is right out of Andy Grove’s “High Output Management” playbook where the 1:1 agenda is driven by the director report vs. the manager.

No alt text provided for this image

As you can tell, I do the following –

  • I share how I’m doing, review my development areas (typically from my last review), have a standing update on the top priorities we agreed on for the quarter (or month), and then add a collection of miscellaneous updates and questions.
  • I then use highlighting to call out what I want to discuss. Anything that is not highlighted is FYI.
  • I also end with a note of gratitude and call out any and all feedback that helped me learn.

The key with these 1:1s is giving your manager all the context you can for them to help you with help, direction and coaching. Successful 1:1s aren’t just a pat on the back (though these feel good from time to time :)) – they involve “aha” moments that help us operate better.

(3) Recurring 1:1s

Many product teams have an unsaid expectation about recurring 1:1s between PMs and cross-functional lead. And, while you can use a simple shared doc where you add in topics for the week to be productive, I’d like to add some more color on these 1:1s.

Early in our life as an IC PM, these recurring 1:1s help a lot. On the one hand, they help us understand and empathize with challenges that our cross-functional partners face. That understanding and empathy makes us better PMs – or in many cases, PMs. We don’t become PMs when we are handed the title. Our early cross-functional partners teach us to become so.

On the other hand, they also often give us much-needed connection in a job that can feel challenging and lonely when you’re expected to provide direction while you’re still figuring out what to do.

But, over time, these recurring 1:1s also become the biggest obstacle to enabling us to scale. This typically happens to folks when they begin handling the responsibilities of a senior PM. These responsibilities can include multiple engineering teams and multiple sets of cross-functional partners. When this happens, it won’t be feasible to have recurring 1:1s with all 12 of your cross-functional partners.

At this point, they aren’t just a sub-optimal use of time. They also get in the way of the flow of information. When you find yourself responding to the same types of questions 1:1, it is a sign that you need to get the group together more and ensure everyone has shared context.

No alt text provided for this image

When you reach this point, it helps to have a clear and empathetic response to anyone who requests a recurring 1:1. It goes along the lines of – “I really appreciate you setting this up. At this point, I’m not able to do justice to recurring 1:1s as they get in the way of me being able to deliver the strategy docs and specs that we need. But, more importantly, they also get in the way of us getting time when something comes up. 

The approach I’m trying right now is to remove all recurring 1:1s so I can make space for all the ad hoc 1:1s we need. So, please know that we’ll still be communicating plenty – across our team meetings, docs, async conversations, and ad hoc 1:1s any time we need it.”

 That then brings us to ad hoc 1:1s.

 (4) Adhoc 1:1s

Ad hoc 1:1s are among the most valuable uses of our time. There are a few kinds of ad hoc 1:1 – all of which are useful in their own way. 

There are the “Let’s discuss” or “We have a problem” variants with our close working team to quickly align on something important or straighten out a disagreement. Then there’s catch up variant. While these can be with our immediate team including with relevant executives, they’re very useful when we done with folks in the broader organization.

These conversations can give you fascinating perspective into life on other teams. That can result in future collaborations and also helpful insight into teams you want to join or avoid whenever you consider switching teams next. In rare cases, they can result in lovely peer-relationships or friendships. As you grow in your career, they also take the form of folks who come to you for advice and counsel.

I think it is helpful to be proactive about making sure you have these 1:1s on your calendar. And, while it is possible to overdo these, most folks tend to under-invest. As a guideline, I’ve found that having 1 or 2 of these “serendipity 1:1s” over the course of any given week helps a ton.

(BONUS) Facilitate get-to-know each other meetings for your team 

The magic of most 1:1s is the time spent getting to know and thus understand each other. A simple practice I try to invest in every time I join a new team is to ensure we all spend a meeting just getting to know each other. The process is simple –

(1) Split folks into pairs (or 3s) and give them 10 minutes to introduce themselves to each other. The guideline for these is – get to know their story and understand what matters to the other person.

(2) The pairs then cross-introduce each other to the group. There’s something very special about cross-introductions. They feel even more special when others in the group add what they know to these folks.  

Depending on the size of the group, this will take somewhere between 60 and 90 minutes (it is on you to manage time with some reasonable nudging). It will also be among the best investments you make. I’ve been in groups where folks who worked together for many years suddenly realized they had so much in common. And, by bringing the magic of a great introductory 1:1 to a group, I’ve seen sessions like this completely transform the mood of the group.

All this brings us back to the magic of 1:1s. A recent post from Seth Godin’s blog explained why. 

Time doesn’t scale

That’s why it’s worth so much. 

Sure, you can outsource. You can look for shortcuts. You can hire folks. You can use mailmerge. You can even send it to voice mail.

 But all of these time shortcuts fail to express the thing we want the most. 

Your time, my time, their time–we all get the same number of minutes per day.

 If you spend them on someone, they can tell.

 Indeed.

 1:1 time is precious. Let’s use it well. 

Learning to sell as a product manager

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 – 

Before starting this series, I spent a bit of time thinking about how I should articulate the core skills required to be a strong IC/individual contributor product manager. I had 3 criteria –

  1. Clear/mutually exclusive: I wanted skills that would stand on their own and, for the sake of this series, wanted to avoid umbrella words that spoke to multiple sub-skills (e.g. empathy)
  2. Memorable: This implied committing to no more than 3 or 4 skills to ensure they’re easy to remember
  3. Actionable: This meant choosing “problem finding” vs. “product sense” because of the action it implies.

Soon, problem findingproblem solvingbuilding effective teams felt right and were locked in. But, I debated whether to call the final skill influencing or selling.

I chose selling because it felt a bit uncomfortable. I wanted to reach into that discomfort and spend time there. In the first post on selling, we framed the persuasion process as a combination of Direct Marketing (content led) and Sales (human touch led) – surrounded by Brand marketing (the friction in the process is inversely proportional to our brand/reputation).

No alt text provided for this image

The next post focused on our biggest direct marketing lever – writing. Many subsequent posts have either focused or touched on writing – e.g. the ones on product specs and product strategy.  

Today’s post will be focused on the other side – sales.

Why does the word “selling” make us uncomfortable?

I think there are many reasons. When we think of sales, many of us visualize pushy sales people who try to get us to buy something we don’t want. For some of us, it may even bring back memories of Alec Baldwin in Glengarry Glen Ross unleashing a torrent of verbal abuse on 4 salesmen while emphasizing the ABC of Sales – “Always Be Closing.”

No alt text provided for this image

No wonder sales feel uncomfortable.

To Sell is Human and the new ABCs of Selling

I felt similarly until I read Dan Pink’s book – “To Sell is Human.” Dan’s book transformed my perspective. He reframed selling by pointing to a simple idea – if you need to influence people as part of your job, you are in sales. 

He also reframed the ABCs of selling. Two decades ago, the internet didn’t exist. This meant there was large information asymmetry between buyers and sellers. And, as online ratings/reviews didn’t exist, selling felt like a series of one-time transactions. Both of those aren’t true today. We walk into a car dealership with as much information as our dealer. And, the dealer cares about that Yelp review we leave. 

That then brings us to the new ABC’s of selling – AttunementBuoyancy, and Clarity. For the rest of the post, I’m going to translate how I think we can use the new ABC’s to reflect on and improve our sales skills in our role as Product Managers. 

If you haven’t read the book, I’d recommend it. Here’s a quick visual summary in case that helps – hat tip – Jenny Trautman.

No alt text provided for this image

(1) Attunement:

Key question: Are we building trust in our relationships by seeking to understand?

No alt text provided for this image

Attunement is all about empathizing with others. Our ability to be attuned to a person follows from our willingness to get to know and understand them. The biggest implication is the importance of taking the time to get to know our partners. My approach to this has been to aim to start every relationship with an introductory 1:1 before jumping into ask/work.

Knowing the story of that cross-functional partner helps us understand them as we begin working with them. That understanding leads to trust in most cases (in other cases, it leads to mistrust – either way, it is important to know where we stand. :-)). That trust, in turn, helps us prioritize uncomfortable conversations and to be comfortable when we disagree. Uncomfortable conversations and disagreements are pre-requisites to progress.

Outside of cross-functional partners, the previous post on building relationships with Product Executives attempts to provide more structure on building empathy with our product leaders.

(2) Buoyancy

Key question: Do people walk away with more positive energy after spending time with us? 

Implications for us: In every interaction, we exude one of 4 behaviors. We are either –

  • Condescending – expressing superiority
  • Critical – showcasing disapproval or criticism
  • Constructive – building off existing ideas to make them better
  • Proactive – moving things forward and making them happen

Each of these impact everyone’s energy differently depending on where they are in the process. In general though, the impact looks like this.

No alt text provided for this image

The ability to show up with positive energy regardless of the way the winds are blowing is critical to our ability to influence the people we work with. So, learning to be consistently constructive or proactive makes a huge difference to our ability to influence others. 

It is important to call out that these are behaviors and not character traits. They become traits only when we consistently show up in one way. So, it is in our interest to choose and reflect periodically on whether we’re showing up as we intend. It won’t always work. Despite our best intentions, our intentions will occasionally be misinterpreted – especially when we meet with people who don’t know us. The goal is to keep increasing our ratio of hits to misses.

 The interesting thing about these emotions is that they’re as applicable to others as they are to us. For example –

  • How do we feel when we spend time with ourselves?
  • Are we critical every time we think of a new idea or are we constructive and solution focused?
  • How does this change when we’re going through a difficult time?

That, then, is the true test of our buoyancy – how we feel after we spend time about ourselves. The more we walk away feeling positive after spending time with ourselves, the more likely others will feel the same. 

(3) Clarity

Key question: Do we transform situations from ambiguity and chaos to clarity?

Attunement is about empathizing with our audience. This audience may be internal (our organization) or external (our users/customers). Buoyancy ensures we show up positively. Clarity, however, is the clincher – the key pre-requisite to closing the sale.

Everyone is dealing with more information and ambiguity than they know what to do with. So, the ability to consistently step into ambiguity and transform it into clarity is a core skill.

Transforming ambiguity to clarity is a 2 step process –

No alt text provided for this image
  1. Frame: A complex set of information needs an organizing structure or framework. The best ways to learn how to frame is to spend time with people who are structured and read books or articles by people who are good at what they do. The ability to simplify complex information is a sign of skill. This post, for example, is an ode to Dan Pink’s ability to reframe sales as attunement, buoyancy, and clarity. The other way to teach ourselves to frame is to constantly ask – if I had to boil this topic down into no more than 3 things, what would I say?
  2. Decide to simplify: Once you structure information, the next step is to decide what matters. The word decide comes from the Latin word “decidere” which means “to cut off.” The purpose of making a decision is to cut off options. So, when we decide what matters, we automatically simplify.

Attunement, buoyancy, and clarity, are each powerful in their own right. Attunement or empathy, for instance, is just as important in our ability to be good problem finders or problem solvers or even team builders as it is in our ability to sell. Buoyancy and clarity matter across the board too. 

But, when we’re able to bring these three together consistently, we step-change our ability to sell. While sales is important to our jobs as individual contributor PMs, it becomes more important as we evolve our role from individual contributors to leading teams of product managers.  

The good news is that selling is a skill. It is a muscle we all can get better at if we work on attunement, buoyancy, and clarity. 

And, the good news – channeling Dan Pink – is that to sell is human.

Two levels

Great Pixar/Disney movies operate at two levels. The story, characters, and visuals works for the kids. The humor in the dialogues works for the parents.

They need to do the job on both levels because young kids need their parents around to watch these movies and enthusiastically accompany them to the amusement parks.

Great products work the same way. They are simple enough for the newbie user but have layers of complexity that get the job done for the more advanced user.

It is easy for a product to work on one of the two levels. But, the challenge is to work on both levels while preserving the simplicity.

It is why building simple products is anything but simple.

Building relationships with Product Executives

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 – 


“How can I better influence my product executives to fund my projects?”

“How can I better communicate the impact I drive to <insert product executive>?”

“How do I build a strong relationship with <insert product executive>?”

Variants of these questions are common in conversations among product managers. If you were an alien listening in on some of these questions or conversations, you might be forgiven if you thought product executives are creatures from a different planet – full of mystery and intrigue. After all, you’re likely to hear some story about said person’s super human abilities in this or that.

The good news is that we’re not dealing with extra-terrestrial creatures. Every executive – product or not – is human. Just like us, they have goals, areas of strength, growth opportunities, insecurities, and fears. Most are good at keeping calm above the surface. But, like the proverbial duck, they’re all paddling hard underneath.

No alt text provided for this image

(H/T: Leslie Gail for this image) 

PM careers and scope

The PM career journey involves some dramatic jumps in scope as folks get more senior. 

You start with a narrow focus on features and products as an IC. This grows to product areas for senior ICs/people managers. While this jump is significant, it doesn’t compare with the jump from senior people manager (typically a Director or Senior Director) to an Executive. PM Executives typically lead entire marketplaces or ecosystems as product executives. And, in many companies, they may even go from leading a group of PMs to being a “General Manager” of a business with multiple functions reporting into them.

No alt text provided for this image

No matter their title, they’ll continue to be responsible for the pixels you ship. So, it still matters that you have their buy in on your vision. It is important that they’re excited about the work you’re doing. And, they will continue to play a critical role in your ongoing career progress.

But, given their scope, building relationships with PM executives isn’t easy. Their broad responsibilities mean time is at a premium. And, asking them for frequent 1:1s or throwing out the “will you be my mentor” question isn’t the answer.

Strong relationships and contribution

Building strong relationships with product executives is no different than other relationships. They’re built on understanding and trust, and are sustained by contribution to each other’s growth.

The difference in these relationships is that we don’t generally have the time to spend hours working with each other to build the relationship. And, without that understanding, it is often hard to know how best to contribute. In the absence of us doing so, these relationships become one-way – we get (hopefully useful) feedback that helps us and our products get better. But, as with any one-way relationship, it ends up feeling more like a series of transactions than an actual relationship.

While every product executive is unique, there are some certainties (thank heavens). And, these certainties come in the shape of what matters to them – and thus areas we can contribute. I think of these in 4 categories:

  1. Impact (this is foundational)
  2. How you achieve this impact – in a way that is aligned with their product vision/principles/culture
  3. Team/org growth and happiness
  4. Their growth
No alt text provided for this image

These categories are stack ranked in default order of priority. But, their relative importance will vary based on the executive. Let’s dig into these.

(1) Impact

Most product executives are judged on outcomes. The primary outcome they’re measured on is typically revenue. In rare cases, it is a key driver to revenue – e.g. some user/customer value metric or engagement that contributes to Revenue.

Depending on how the team is structured, various PM managers and their IC/individual contributor PM reports will be accountable for outcomes that contribute to the executive’s outcome. Understanding our executive’s outcome, how our work contributes, and actually contributing to it is the minimum bar. 

We move past the minimum bar when we’re able to earn trust in our capabilities. That happens when we add being competent with being responsive to their questions/concerns and staying on top of the details/trade-offs. Trade-offs matter a lot as a product executive because their ultimate responsibility isn’t the success of their business unit – it is the success of the company. 

So, the more we’re able to do our job with their lens on the objective that matter, the more trust we’ll be able to earn.

(2) How we achieve that impact – the culture of the product organization

Product executives have very different styles. The 4 common areas they tend to index on (roughly mapped to our 4 core skills is):

No alt text provided for this image

(a) System/strategy/metrics (problem finding): Some product executives are strong system thinkers. They care about how the various pieces connect to the whole and how each team’s strategy and incentives are set up.

Practically, these executives check if – (a) you are measuring the right things, (b) you understand the levers to achieve your metrics, and (c) you are focused on the right problems to move those levers.

(b) Product experience (problem solving): This brand of product executive is all about the end user experience. They will go very deep on your understanding of the specific user problem, your hypotheses and validation for those hypotheses, and how it all shows up on the screens you ship. They will want to understand the thought process behind every pixel on the screen. No detail or line of copy is small enough to not warrant discussion.

(c) Communication (selling): This variant of product executive pays a lot of attention to how PMs communicate. While most folks associate communication with verbal communication, the typical form of communication they pay attention to is written. They care about a regular cadence of weekly updates in an agreed upon format, crisp documents that bring trade-offs and decisions to light, and strong email communication.

(d) People/stakeholder management (team): This final variant indexes deeply on alignment. They care that every stakeholder is rowing in the same direction and will check for that whenever they meet you or the other cross-functional leads on the product team.

Typically, product executives will index deeply in 2 out of these 4 areas. A rare executive may index on 3. I think meeting folks who index highly on all 4 is rare/unlikely. That said, the one thing that is common – regardless of style – is their desire for urgency.

What does this mean for an IC PM? Get to know your product executive. Learn their story and speak to folks who’ve worked with them in the past. They are typically not shy about sharing what they care about. You will also see it in the systems/processes they set up and the questions they ask. Once you understand their desired culture, be the change they want to see. 

(3) Team growth and happiness

Product executives are responsible for the well-being of the team. With their focus on the health of the business, this tends to be an area that they’ll have to carve out time that doesn’t exist on their calendars. This tends to be an easy area for IC PMs to have disproportionate impact – both on the executive but also, more importantly, on the organization. 

Broadly, you can think of the following areas to contribute toward the growth and well-being of the team.

  • Hiring – especially hiring diverse talent
  • Onboarding – or setting new PMs up for success
  • Learning – includes sharing know-how insights/regularly or contributing to training
  • Belonging – team socials and offsites
  • Norms – documenting/setting culture and values (these don’t happen often but can be very high impact)
No alt text provided for this image

Every one of these is an area PMs can contribute toward. I have learnt 3 lessons about these contributions: 

(i) You will never have spare time to execute on one of these areas. It is important to start here. You will have to carve out the time or find time beyond your normal hours to do it well.

(ii) Don’t try to be “strategic” – pick an area you are passionate about. Given you’ll never have spare time, it is thus important to not try to be “strategic” – i.e. picking an area that your Chief Product Officer or your VP works on.

You may make an exception to this from time to time depending on he need. But, you are better off focusing on what you care about – an area where making an contribution to the people in the organization energizes you. It will show in how you execute because it will feel like fun. You’ll run out of steam faster on things you don’t care about.

Besides, product executives change. They move on to different focus areas or teams/businesses. So, doing these with the sole objective of building a strong executive relationship typically backfires. 

(iii) Doing a good job on these “side projects” can have a disproportionate impact on your organization. Each of these areas can have a large impact on the culture, growth, and well-being of PMs in the organization. So, if you’re doing it right, you’re having a lot of fun while also having a tangible impact on the work lives of your coworkers.

(4) Their growth. Product executives don’t get to where they are by sitting on their achievements. Folks who do well will be focused on their growth. While they’ll rightfully look to their managers/other executives in the company to give them feedback, don’t underestimate the importance of providing useful feedback.

Useful feedback is thoughtful, constructive, and direct. 

Great relationships are built on a two-way flow of feedback. Ask them for feedback proactively. And, give them feedback too.

It isn’t easy to provide feedback to product leaders. Our interactions with them have disproportionate impact on our career growth. So, it is easy to not do this. But, it helps to remember that product executives rarely meet people who have the courage to tell them things they don’t want to hear. So, if you can be the person who speaks the truth and offers solution – without whining! – it can go a long way.


We started this note attempting to tackle building relationships with product executives. As with all relationships, chemistry matters. It is possible that you’ll just “click” with your product executive. Relationships can work like that. We’re all bags of emotion and irrationality after all. 

But, the goal of this is go beyond the chemistry and work through areas where we can have a positive impact on the organization and, by extension, our leaders.

While we’re at it, it is important to also share a disclaimer. If you do succeed in building a strong relationship with a product leader, use it carefully. Every once a while, you’ll meet PMs who do a phenomenal job building great relationships with product executives but struggle with earning the respect of their peers.

That happens because of one or both of these –

(1) “Name dropping” executives from time to time.

(2) Using product executive names/directives to influence peers – instead of the merits of the argument.

Both of these can happen in conversation or by forwarding emails to others that show off their relationships.

So, by all means, go ahead and build great relationships with your product executives. I hope it works out for you. And, in addition, as in Albus Dumbledore’s note to Harry Potter when he handed him his invisibility cloak, I’ll just say – “Use it well.”