Category: Product

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 IC PM Role, The 4 key skills, Remote + Pandemic PM, 5 Decision Making frameworks/heuristics, Problem finding/solving with executives, Managing psychology, 5 lessons (a 70% synthesis), Writing (this post)
• Skill #1 – Problem finding: Most important skill, Problem statement and hypothesis, Building Strategy, Validating problem statements and hypotheses, Exploration OKRs
• Skill #2 – Selling: Sales and Marketing, Writing for executive audiences, Product executive relationships, Learning to sell
• Skill #3 – Problem Solving: Roadmap, Product specs, Solving for Usability, Solving for Feasibility, PM<>Eng collaboration, Ramps and launch checklist, Design visions
• Skill #4 – Building effective teams: Knowing thyself, Your manager, Product team culture, 5 habits – high velocity product teams, Effective 1:1s, Kick Offs, Effective team meetings, Team events
• Managing your career: Getting in – I, Getting in – II, Picking your next role

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

We’ve talked about 4 skills as critical to the life of an IC/individual contributor Product Management – problem finding, problem solving, selling, and building effective teams. Over the past 36 editions, we’ve teased out how each of these skills break down into a series of sub-skills (e.g., problem finding requires empathy along with the ability to build strategy which breaks down further into a few sub-skills). At some point in this journey, I intend to lay out the entire map of sub-skills. But, in the meanwhile, it is time to spend time on a sub-skill that – along with empathy for the people who use our products as well as those on the team – is wins the prize for the most critical sub-skill -> Writing. 

There are 3 reasons writing is critical to a Product Manager’s job: 

(1) It improves our thinking: Writing is both reflective of and improves the quality of your thinking. The word essay comes from the French word essayer which means to try. When we write long form, we effectively try to figure something out. It is why most good documents take many iterations to get right. It takes time and effort to improve the quality of our thinking. That quality of our thinking improves the quality of our work and the products we end up building.

(2) It is how we build leverage: A well-written document or weekly update scales and is the simplest and most effective form of driving leverage in any given week. We’ve talked about leverage being the most important goal for a product manager as we aim to bring cross-functional teams together to solve valuable problems in ways that are usable and feasible – given our unique constraints (there always are many!).

Writing helps us share our point of view, bring people along, and replace ambiguity with clarity. This is especially important considering most of us spend some proportion of our time working remote. The more the physical distance between teams, the more important our ability to write. 

(3) It helps us write better copy. Learning to write better impacts our products too. The more we develop a spidey sense for what is good copy vs. what isn’t, the clearer and more effective our products become. 

Okay, you’re convinced – now what? 

There’s a unifying principle that brings together the steps we’re about to discuss. “Each person should write 5x more but write 5x less.” (H/T: Mike)

This means we all would benefit from writing a lot more than we do right now. But when we write, we also need to convey what we’re going to say in significantly fewer words. This dual push to both writing more while writing concisely is at the heart of honing our craft. 

Luckily, there are also 5 concrete steps we can take to become better writers. 

(1) Start early and leverage subconscious processing/the Zeigarnik effect.

The Zeigarnik effect – named after Dr Bluma Zeigarnik – identified our mind’s propensity to subconsciously work on completing tasks we started. This is why stopping a song half-way can get it stuck in our heads for the rest of the day.

The Zeigarnik effect is incredibly useful in our attempts to write better. Every time we realize we need to write a document or an update, open up a blank sheet and type in a few sentences. That act alone ensures we’ve started on the task. Whether we continue it the next day or the next week, our minds would have already progress thanks to subconscious processing. 

(2) Choose to develop a reputation for concise documents by adopting artificial constraints

A great document does not have to end in 1 or 2 pages. Nobody will sweat an extra half page. But adopting these artificial constraints go a long way in our ability to write concise documents. They force us to think creatively about communicating ideas and inspire clarity through brevity. They’ll also drive home a simple lesson – if we can’t make our point in 1-2 pages, what are the odds we’ll do it in 10?

As time passes, we’ll also get better at differentiating between content in the main 1-2 pages and supplemental content that goes into the appendix. For example, the appendix is a great place to document “FAQs” or frequently asked questions. As you share a doc and get a raft of comments in, it is easy to fill up this FAQ section with questions from commenters. 

Adopting artificial constraints enforces a certain rigor and discipline in our writing process. I think that rigor/discipline creates consistently higher quality work. 

A note on formatting: I think of this discipline in formatting too. For example, every one of my documents has 0.5″ margins and uses Source Sans Pro x 10 point font x 1.15 line spacing. I use one of Google docs’ default blues for section headers and use italics and underlining sparingly to make points. That push for visual simplicity helps remind me to choose simpler language and shorter sentences. 

Also, this approach to constraints means “pageless” formatting is a deal breaker in my book. :-)

(3) Use simple and repeatable narrative structures

Most documents I write have one of 2 narrative structures:

(1) The strategy narrative: The flow is -0

• Problem and opportunity statement: Details the problem (user and need/job to be done) and the opportunity to solve the problem. The only key here is to have clear user data/insight that makes it unambiguously clear that it is a real need.
• Lessons learnt/Key insights: I look to share 2-3 lessons learnt or key insights – could be driven from the market or more commonly from internal data or research. Each lesson translates to a hypothesis that becomes a strategy pillar.
• Success metrics: Outline true north, signpost (i.e., metrics we expect to move that we think will move the true north metrics), and guardrail metrics
• Product principles: Key implications from organization-wide and project specific product principles.
• Strategy and roadmap: Detail key initiatives with projected impact in a simple table that share how they fit into the strategy. A key part of this table is detailing what we will NOT do. This is also where we link to the design vision/narrative.
• Risks: Because there always are some.

There’s more to talk about on the subject of strategy docs and the challenges with getting some of these sections right. We’ll aim to cover that in a future post. For now, though, the important part is having a simple and repeatable structure that enables us to focus on the content and articulation. 

Here’s the template that details the above.

Note on formatting: Every once a while, the nature of the text in the doc or the presence of images that describe certain sections will make it easier for the doc to be in “landscape” vs. “portrait” mode.

(2) Situation – complication – action (includes escalations): The other common narrative structure involves describing a specific problem and our plan to fix it. This follows a 3 part structure:

• Situation: Share the context/background – e.g., we need a particular API to deliver reporting to our customers.
• Complication: This gets to the exact problem we’re facing – e.g., the API has been unstable and is causing workflow breakdowns.
• Action: Here’s what we’re going to do to solve this problem – e.g., we’ll do x in the short term and y and z to solve this for good.

Here’s the template.

As you can see in the template, these can also be used to write out escalation documents with minor changes to the narrative structure.

(4) Develop a sense of pride in your ability to rewrite docs. Stephen King had a great quote to describe the writing process – “Write with the door closed, rewrite with the door open.”

Your documents start out with just you and your story or argument. But, once you get the essence of the argument out of you, it then belongs to everyone who you intend to read it and anyone who wants to read it and be influenced by it. Or criticize it. If you do your job right, more people will want to do the former instead of the latter.

I believe that happens when we develop a sense of pride in our ability to rewrite documents when we realize our intended message isn’t flowing through. Some documents can take 10 to 15 rewrites before we get it right.

That sense of pride replaces groans when we get feedback (the default state) with curiosity and enthusiasm about the prospect of landing our message better. 

(5) Write like you talk. Often.

Seth Godin shared an incredible post a decade ago called “Talker’s Block.” In it, he observes that nobody gets talker’s block. Why, then, is writer’s block so endemic?

As he shared in another insightful post, this word didn’t exist till 1940. Writing was a hobby for most people – so there wasn’t fear associated with it. Now, however, we all write. As a result, the fear has grown proportionally.

In Seth’s words – “We talk poorly and then, eventually (or sometimes), we talk smart. We get better at talking precisely because we talk. We see what works and what doesn’t, and if we’re insightful, do more of what works. How can one get talker’s block after all this practice?”

So, if we want to avoid writer’s block and get better at this craft, we just need to sign up to write like we talk. Often.

For Product managers, this means –

• Send weekly updates. Share something interesting about your product area, your target user, or even the market. Tell us what we should know about your work and why it matters. Get creative with the format to make it interesting if needed or mix it up. But send it consistently.
• Always work on that strategy doc. Strategy docs aren’t written on stone tablets. They need to be constantly iterated on. You might make major changes on a 12-18 month timeline. But you’ll want to keep clarifying those docs and iterating regularly.
• Ship 1 new doc every two weeks by writing every time you sense disagreement on confusion. If you take every opportunity to write, you’ll likely write one new document every two weeks. Some of these will just be for you. Others will make it to your team. Take every opportunity to write.
• Write about your side projects outside work. If writing documents at work is too much pressure, work on this skill outside work.

If there’s a theme in all of this, it is aiming for quantity. That quantity will help us develop our own style and inspire the quality we seek. It also will help us get to that quality much faster over time.

Write 5x more. We’ll then learn how to write 5x less. With high velocity. 

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

As with any craft, there are experts who’ve taken the time to share their advice. Here are a few books that have resonated with me:

(1) The Pyramid Principle by Barbara Minto: Barbara Minto’s book was a game changer. The two biggest takeaways from this book for me were – (1) Start with the executive summary/headline and (2) Expect high quality writing to show up after you rewrite that first draft that you created for yourself.

(2) The Elements of Style by Strunk and White: My grasp for grammar isn’t particularly strong. This helped.

(3) Several short sentences about writing by Verilyn Klinkenborg: This book was a beautiful reminder of the importance of starting with a focus on getting the atomic unit of writing – the sentence – right. It is also a critique of the heavy-handed Strunk & White school of teaching as it pushes us to identify and embrace our own way. It is nice to read it after “The Elements of Style.”  

In addition, I’ve been halfway through Stephen King’s “On Writing” for a long time. I do intend to finish it. And I’ve heard great things about “Draft No. 4” by John McPhee.

Perhaps, most of all, I’ve learnt from attempting to write myself. I’ve been writing every day on this blog since May 2008. This practice has been life changing. 

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.

• Overall: The IC PM Role, The 4 key skills, Remote + Pandemic PM, 5 Decision Making frameworks/heuristics, Problem finding/solving with executives, Managing psychology
• Skill #1 – Problem finding: Most important skill, Problem statement and hypothesis, Building Strategy, Validating problem statements and hypotheses, Exploration OKRs
• Skill #2 – Selling: Sales and Marketing, Writing for executive audiences, Product executive relationships, Learning to sell
• Skill #3 – Problem Solving: Roadmap, Product specs, Solving for Usability, Solving for Feasibility, PM<>Eng collaboration, Ramps and launch checklist, Design visions
• Skill #4 – Building effective teams: Knowing thyself, Your manager, Product team culture, 5 habits – high velocity product teams, Effective 1:1s, Kick Offs, Effective team meetings
• Managing your career: Getting in – I, Getting in – II, Choosing your next role

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 IC PM Role, The 4 key skills, Remote + Pandemic PM, 5 Decision Making frameworks/heuristics, Problem finding/solving with executives, Managing psychology
• Skill #1 – Problem finding: Most important skill, Problem statement and hypothesis, Building Strategy, Validating problem statements and hypotheses, Exploration OKRs
• Skill #2 – Selling: Sales and Marketing, Writing for executive audiences, Product executive relationships, Learning to sell
• Skill #3 – Problem Solving: Roadmap, Product specs, Solving for Usability, Solving for Feasibility, PM<>Eng collaboration, Ramps and launch checklist, Design visions (today’s post)
• Skill #4 – Building effective teams: Knowing thyself, Your manager, Product team culture, 5 habits – high velocity product teams, Effective 1:1s, Kick Offs, Effective team meetings
• Managing your career: Getting in – I, Getting in – II

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

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. 

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.

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.

(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:

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.

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.

 (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.

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 IC PM Role, The 4 key skills, Remote + Pandemic PM, 5 Decision Making frameworks/heuristics, Problem finding/solving with executives, Managing psychology
• Skill #1 – Problem finding: Most important skill, Problem statement and hypothesis, Building Strategy, Validating problem statements and hypotheses, Exploration OKRs
• Skill #2 – Selling: Sales and Marketing, Writing for executive audiences, Product executive relationships, Learning to sell
• Skill #3 – Problem Solving: Roadmap, Product specs, Solving for Usability, Solving for Feasibility, PM<>Eng collaboration, Ramps and launch checklist
• Skill #4 – Building effective teams: Knowing thyself, Your manager, Product team culture, 5 habits – high velocity product teams, Effective 1:1s, Kick Offs
• Managing your career: Getting in – I, Getting in – II

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

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

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.

(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.

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. 

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 IC PM Role, The 4 key skills, Remote + Pandemic PM, 5 Decision Making frameworks/heuristics, Problem finding/solving with executives, Managing psychology
• Skill #1 – Problem finding: Most important skill, Problem statement and hypothesis, Building Strategy, Validating problem statements and hypotheses, Exploration OKRs
• Skill #2 – Selling: Sales and Marketing, Writing for executive audiences, Product executive relationships, Learning to sell
• Skill #3 – Problem Solving: Roadmap, Product specs, Solving for Usability, Solving for Feasibility, PM<>Eng collaboration, Ramps and launch checklist
• Skill #4 – Building effective teams: Knowing thyself, Your manager, Product team culture, 5 habits – high velocity product teams, Effective 1:1s,
• Managing your career: Getting in – I, Getting in – II

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

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 – 

(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

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.

• 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

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:

• 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. 

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 IC PM Role, The 4 key skills, Remote + Pandemic PM, 5 Decision Making frameworks/heuristics, Problem finding/solving with executives, Managing psychology
• Skill #1 – Problem finding: Most important skill, Problem statement and hypothesis, Building Strategy, Validating problem statements and hypotheses
• Skill #2 – Selling: Sales and Marketing, Writing for executive audiences, Product executive relationships, Learning to sell
• Skill #3 – Problem Solving: Roadmap, Product specs, Solving for Usability, Solving for Feasibility, PM<>Eng collaboration, Ramps and launch checklist
• Skill #4 – Building effective teams: Knowing thyself, Your manager, Product team culture, 5 habits – high velocity product teams, Effective 1:1s,
• Managing your career: Getting in – I, Getting in – II

---

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

That period of stress is driven by “planning.”

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. 

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.

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.

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.

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. 

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 IC PM Role, The 4 key skills, Remote + Pandemic PM, 5 Decision Making frameworks/heuristics, Problem finding/solving with executives, 
• Skill #1 – Problem finding: Most important skill, Problem statement and hypothesis, Building Strategy, Validating problem statements and hypotheses
• Skill #2 – Selling: Sales and Marketing, Writing for executive audiences, Product executive relationships, Learning to sell
• Skill #3 – Problem Solving: Roadmap, Product specs, Solving for Usability, Solving for Feasibility, PM<>Eng collaboration, Ramps and launch checklist
• Skill #4 – Building effective teams: Knowing thyself, Your manager, Product team culture, 5 habits – high velocity product teams, Effective 1:1s,
• Managing your career: Getting in – I, Getting in – II

---

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.

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

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.

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.

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.

 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.

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 IC PM Role, The 4 key skills, Remote + Pandemic PM, 5 Decision Making frameworks/heuristics, Problem finding/solving with executives, 
• Skill #1 – Problem finding: Most important skill, Problem statement and hypothesis, Building Strategy, Validating problem statements and hypotheses
• Skill #2 – Selling: Sales and Marketing, Writing for executive audiences, Product executive relationships, Learning to sell
• Skill #3 – Problem Solving: Roadmap, Product specs, Solving for Usability, Solving for Feasibility, PM<>Eng collaboration, Ramps and launch checklist
• Skill #4 – Building effective teams: Knowing thyself, Your manager, Product team culture, 5 habits – high velocity product teams
• Managing your career: Getting in – I, Getting in – II

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.

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.

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.

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. 

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 IC PM Role, The 4 key skills, Remote + Pandemic PM, 5 Decision Making frameworks/heuristics, Problem finding/solving with executives, 
• Skill #1 – Problem finding: Most important skill, Problem statement and hypothesis, Building Strategy, Validating problem statements and hypotheses
• Skill #2 – Selling: Sales and Marketing, Writing for executive audiences, Product executive relationships
• Skill #3 – Problem Solving: Roadmap, Product specs, Solving for Usability, Solving for Feasibility, PM<>Eng collaboration, Ramps and launch checklist
• Skill #4 – Building effective teams: Knowing thyself, Your manager, Product team culture, 5 habits – high velocity product teams
• Managing your career: Getting in – I, Getting in – II

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 finding, problem solving, building 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).

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 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 – Attunement, Buoyancy, 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.

(1) Attunement:

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

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.

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 –

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.