Writing for executive audiences – a 3 step process

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

We’ve covered the following topics so far in this series –

  • Defined the role of a product manager and outlined the 4 key skills required to do the job – problem finding (solving for value), selling, problem solving (solving for usability and feasibility), and building effective teams.
  • Skill #1 – Problem finding: We spent time working through why problem finding is the most important skill and how to approach building problem statements and hypotheses.
  • Skill #2 – Selling: We outlined why all Product Managers spend significant doing sales and marketing in their bid to drive the change they seek to make for their users/customers. Today’s post will focus on a core piece of this sales and marketing toolkit – writing for executive audiences.

Why is writing for executive audiences a core piece of the sales and marketing toolkit? As IC product managers, many of our opportunities to persuade tend to come from sharing our thought process in writing with internal stakeholders (typically executives in the product management org)- via strategy documents, issue investigations, product specs, and email exchanges.

I’ve intentionally picked an internal audience as the focus because that’s where the biggest challenges tend to lie. When the organization is aligned on the problem that is being solved, it is much easier to build and sell a cohesive solution to users/customers.

For the purpose of today’s post, I’m going to assume most of the longer form writing happens in long form memo-style documents versus PowerPoint presentations. I’m also not going to focus on product specs as that will form the core piece of skill #3 – Problem Solving – and will be covered in our next post.

So, today’s note will be focused on strategy documents, issue investigations, and email exchanges for executive audiences.

The 3 step process. My suggested approach to writing (and speaking) experiences is to work through the 3 parts of the process – 1) Content – start early and write down everything you want to convey, 2) Structure – rewrite your content and make it easy to consume with a logical flow, and 3) Delivery – tailor the final delivery to your audience.

1) Content – start early and write down everything you want to convey. Block 2 hours on your calendar as soon as you know you have a document to prepare and write down everything you want to convey. Don’t worry about logic or structure – simply put all your ideas down in one place.

As simple as this sounds, there is a common pitfall in this process that I’ve seen myself and others fall prey to – postponing the act of generating content because of a desire for the perfectly structured first draft.

If you are most people, your first draft is going to suck. That’s expected. Procrastinating at this stage ends up becoming very expensive because most docs require multiple revisions. Great documents are rarely written in a day. They are also rarely written by blocking out 2 days prior to your review. Instead, the optimal creation process looks something like this.

2) Structure – rewrite your content and make it easy to consume with a logical flow.

“For the average business or professional writer, producing more literate memos and reports does not mean writing shorter sentences or choosing better words. Rather, it means formally separating the thinking process from the writing process, so that you can complete your thinking before you begin to write.” | Barbara Minto, The Pyramid Principle

Now that we have followed Barbara Minto’s advice and completed our thinking in step 1, we are ready to begin to write. The key at this stage is to pick a logical structure that will help convey your ideas. There should be plenty of examples of good structure around you – just look to prior strategy docs or issue investigation docs that have been well received.

Figuring out a structure should not be rocket science. For example, a good issue investigation doc follows a version of – 1. What is the problem?, 2. Where does it lie?, 3. Why does it exist?, 4. What could we do about it?, 5. What should we do about it?

Similarly, most good product strategy docs follow a version of – 1. Problem statement (user/customer need), 2. Size of opportunity if the problem is solved, 3. Our hypothesis and key assumptions, 4. Principles, 5. Strategy (where do we play?, how do we win?), 6. Roadmap / Tests to validate key assumptions, 7. Open questions/Areas we need help.

The challenge in this step (at least in my experience) isn’t finding a good structure – instead, it is in building the discipline to keep iterating on our original draft. Again, Barbara Minto puts it nicely –

“Once you put ideas in writing, they take on an incredible beauty in the author’s eyes. They seem to glow with a fine patina that you will be quite reluctant to disturb.”

The first draft is simply the act of laying down our thought process. The act of structuring involves breaking up with that first draft and rewriting to make it easy to consume.

3) Delivery – tailor the final delivery to your audience. All the work we put into writing and speaking is to persuade our audience. So, this 3 step process involves moving from “what do I want to say?” to “how can I best make my case to the audience?”

Great sales and marketers understand that their success is dependent on their understanding of their audience. When they understand their audience, they can create the sort of resonance in their messaging that leads to action. So, as product managers, this means doing the work to get to know our audience and asking ourselves – Do you understand how to build an argument that will resonate with your key stakeholders?

If the answer is no, we need take the time to meet with our stakeholders and understand them better.

This content-structure-delivery process applies to presentations and emails as well. While we’ve focused on the creation of a document, this process works just as well for preparing a presentation, answering an email, or taking questions at the end of the presentation.

I had shared an illustration recently with a few folks on “good, better, best” for answering exec questions (in Star Wars lingo of course :-)).

As you’ll see, the same process holds. If you are responding to an email, write down your thoughts, rewrite in a logical structure that focuses on clarity over completeness, and seek to deliver the message in a way that anticipates any obvious follow up questions.

You have less time to work through this process in a live Q&A – but, the same idea holds -> understand your audience’s intent when you answer questions. And, if it is unclear, clarify.

While the purpose of the structure stage is to build a logical argument, the purpose of the delivery stage is to transcend logic and create emotional resonance.

While logic will help lead our audience to the conclusions we derive, it is emotions that will help us persuade our audience to take action to support us in our quest to build better experiences for our users/customers.

A career and life sidebar: As you’ve probably noticed by now, this approach is applicable well beyond exec communication. This post could just as easily have been called “Writing clearly” or “Communicating with clarity.” But, in the spirit of focusing on emotional resonance, I have come to realize that the term “Exec Communication” resonates better. :-)

The small things reminder

Timely reminder to self – we can’t always do big things, but we can do the small things with extraordinary care.

Just like consistent and sincere appreciation in our close relationships and thoughtful, valuable, micro-interactions/features in our products, the impact of these small things compound over time.

Complicated systems and complex systems

If you want to change the tires of a car, you can do so without worrying about the consequences of doing so. The average non-electric car is an example of a “complicated system” with 2000 parts. There may be a lot of parts but you can deal with them without worrying about the rest.

The human body, on the other hand, is an example of a complex system. You can’t just change an organ that isn’t working – you need to understand the whole body as parts of the system interact with each other. This is why we talk of the idea of balance with nature’s ecosystems – fixing them isn’t as simple as changing a part. But, when they work, they function as a whole that is far greater than a sum of the parts.

It turns out that learning to identify complicated and complex systems has powerful implications to shipping valuable products too – especially in larger organizations. If we are in a splinter group/”start-up” within a larger organization, we can treat it as a complicated system and just focus on optimizing our silo without worrying about much else.

But, on the other hand, if we are working with an ecosystem of functions and customer offerings, we make far more progress when we take small steps together because the interactions in the ecosystem magnify the impact.

This is why making progress in ecosystems can be slow (and why solving climate change won’t be straightforward). But, when done right, it is far greater than the sum of its parts.

The Product Marketing Sales Manager

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

We kicked off this series – “Notes on Product Management” – by defining the role of a product manager and outlining the 4 key skills required to do the job – problem finding (solving for value), problem solving (solving for usability and feasibility), building effective teams, and selling.

We then spent time working through why problem finding is the most important skill and how to approach building problem statements and hypotheses. The next high priority skill we’ll spend time on is selling. For the sake of simplicity, I referred to the process of persuasion using marketing and sales as “selling.”

Today’s note, thus, is focused on how to think about Marketing and Sales in the product management process.

Why Marketing and Selling are part of the job.

“If you need to persuade someone to take action, you’re doing marketing.” | Seth Godin

Marketing, thus, goes beyond price, ads, placement, and product. It is the story about what we do and why it matters. It begins with the product and extends beyond the product.

The popular adage that people don’t buy a drill and instead buy a nine inch hole is incomplete. They don’t buy the hole or even the photo frame they hang on the wall. Instead, they buy the experience that comes from looking at something they care about. Great marketing generally starts with great products. But, great products don’t guarantee great experiences. Harley Davidson motorcycles aren’t special because they’re the most technically advanced motorcycles (they aren’t). The Harley Davidson experience, on the other hand, is something else altogether. There aren’t too many other brands who get their customers to willingly tattoo their logo.

So, what then, is the difference between marketing and sales? I’ll defer to Seth’s elegant distinction –

“Marketing tells a story that spreads. Sales overcomes the natural resistance to say yes.”

Marketing and sales are thus part of the job description of every educator, executive, and knowledge age worker. The proportion of the job involving marketing and sales might defer. But, they’re always key.

As far as the product manager goes, the importance of marketing and selling are self evident if they’re working on a (usually B2B) product that is sold by a sales team. But, these skills are just as vital internally.

It is common for marketing and sales to have a negative connotation when used in the context of the workplace. I’ve seen them used as a proxy for politics. That is unfortunate and is a result of a loss of purpose.

Good marketing and selling exist to make important change happen. Product managers who do marketing and selling right ensure their companies don’t ship their org chart. They use these skills to ensure good ideas that add value to users and customers are given a fair shot at changing the status quo. When marketing and selling is done right, the user wins and wins big.

On the other hand, when marketing and selling are used just for the purpose of career advancement, the user loses. The good news is that bad marketing and selling never survives in the long run – but, that is a discussion for another day.

How to think about marketing and selling in the product management process

As Product Managers, we are always attempting to persuade people to take action. We attempt to persuade our customers and users to use our products. We attempt to persuade our executives to resource our problem areas. We attempt to persuade our teams to do their best work. And so on.

My visual of this persuasion process is as follows.

We have 3 elements of persuasion at our disposal to make the change we seek to make –

(1) Direct marketing: This is everything that we do that is content led. When we combine easy-to-use flows and thoughtful in-product copy that attract “self-serve” customers, we’re doing direct marketing. Similarly, when we create a thoughtful strategy doc for a new initiative that wins readers over before the meeting, we’re being effective direct marketers.

(2) Sales: The other alternative is to employ the human touch. When we build a product that works and combine it with a narrative that inspires our sales team to be more effective, we are doing our job as effective salespeople. Similarly, when we facilitate an effective discussion that persuades our executive team to support that new idea that will massively improve the way we serve our users, we are selling effectively.

(3) Brand marketing: Brand marketing is the friction-reducing atmosphere in our persuasion process. When great brands deploy sales teams, they need to focus less on acquisition and more on customer success. Similarly, when we’ve acquired a reputation in our organization for someone who does great work on behalf of our users’ needs, it becomes easier to get cross-functional buy in.

The next step is to explore how we might get better at these skills – more on that in the next two posts.

A career and life sidebar: Our lives are an endless chain of persuading people to do things. And, while the process is hard enough when we’re dealing with adults, the difficulty level only goes up further when dealing with kids. While understanding how to apply these skills has a lot of obvious applicability in our careers, they extend well beyond work… making for a fascinating life-long learning journey.

Good PM = Problem Manager, not Product Manager

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

Over the past 6 weeks, I’ve made (and expanded upon) 3 points in this series on IC/individual contributor product management

1. A product manager brings together a group of cross functional stakeholders to build a product that is valuable, usable, and feasible.

2. Of these 3 outcomes, building for value is the most important as there is no substitute for it. The fabled “product sense” skill is the ability to consistently identify and build for value – I term it “problem finding.”

3. Thus, the four core skills of a product manager are – problem finding, problem solving (solving for usability and feasibility), building effective teams, and selling (internally and externally).

As I spent my last note explaining why product sense is simply the ability to build for value, today’s post will be focused on lessons learnt on how to build for value. And, the three tools we’ll discuss as part of our problem finding toolkit are problem statementshypotheses, and riskiest assumption tests. These are the first 3 and arguably most important steps of the product process.


Problem StatementsGood problem statements articulate 3 elements – i) audience – who are you building for?, ii) need/problem – what is the specific need/problem?, and iii) value – what is the value of solving the problem?

The worst case scenario for products is those that get built without a clear articulation of the problem. This typically happens when problem statements are written for the executive team or as a homage to the HiPPO / highest paid person’s opinion. And, the bad scenario is when product teams are unclear about who they are building it for. It is okay to be wrong about the target audience – that happens from time to time. But, it is poor form to start without a point of view.

Here’s an example problem statement from Amazon in 2004. I wasn’t part of the Amazon team in 2004. But, given how beautifully they’ve nailed the online shopping customer experience, I’d assume they started with a problem statement in a 6 page memo that looked something like this.

We want our loyal customers (monthly actives) to have a delightful shopping experience on Amazon.com. However, our checkout experience data and user research confirms that this is not the case. Customers hate paying shipping costs and this either prevents them from completing their shopping experience or forces them to redo their shopping to minimize shipping costs – thus creating a stressful and unsatisfactory experience. Solving this problem for customers would be worth $xxxM in the first year alone.

HypothesisA hypothesis is a proposal to the meet the needs of the audience articulated in the problem statement. A hypothesis can be expressed as a collection of assumptions that can be validated using experiments or data  and can be thought of as an answer to the question – “What do we need to believe for this problem to be solved?”

Here is an articulation of the hypothesis of the Amazon free shipping problem statement above.

Our hypothesis is that offering free shipping to our loyal customers would result in a significant improvement in their shopping experience on Amazon.com while also greatly improving our ability to monetize customer engagement. This hypothesis is based on the following assumptions –

1. Free shipping will reduce the stress and anxiety that comes with shopping online and will translate to a faster, more efficient, check out experience.

2. Customers who are offered free shipping will have higher lifetime value – making it well worth the investment cost.

3. Our customers will be open to paying for a monthly/yearly subscription that offers unlimited “free shipping” for a reasonable price point

The Riskiest Assumption Test or RAT: The natural next step is to figure out how to test this hypothesis – ergo a “riskiest assumption test.”

The riskiest assumption in the 3 assumptions laid out above is (1) as it makes the case that free shipping has high customer value (2 and 3 are focused on value capture). And, we can now imagine tests to validate this. We could design an A/B test with “free shipping” in the treatment group or analyze existing data to plot the correlation between check out time and shipping costs.

As you can see from the flow from problem statements -> hypothesis -> RAT, a problem well stated is indeed a problem half solved.

How is an RAT different from a MVP? The main problem with the “MVP” term is that it is ambiguous and that has led to to memes like the one below (and articles like this).


(Image credit: Applico)

FWIW, I think the principle behind the “Riskiest Assumption test” is the same as the principle behind the “Minimum Viable Product.” These memes just underscore the importance of thinking about the customer user/problem (i.e. transportation) before thinking about the product/solution.

But, given my stated purpose in the series is to simplify how we think about product management, it means discarding more ambiguous terms like “product sense” and “minimum viable products” and replacing them with “problem finding” and “riskiest assumption tests.”

The case for problem management instead of product management. A consistent theme that has hopefully become evident through this series is the importance of focusing on problems instead of products. To that end, I recently came across a tweet by Isaac Hepworth, a PM at Google, that I thought was on point.


Companies that get disrupted are those that focus on owning product solutions instead of owning customer problems. I thought it was fitting that we used an Amazon example as we worked through the problem finding process. They are the textbook example of a company that has done a phenomenal job focusing on customer problems that are, in Jeff Bezos words, “things that do not change.”

A career and life sidebar. There’s a lot of conflicting advice on perseverance out there. We are led to believe that entrepreneurs who succeed never quit. But, we then hear stories of those who knew exactly when to quit and “pivot.” When do we persevere? And, when not?

Applying what we’ve learnt today, the wrong kind of perseverance focuses on the solution while the right kind focuses on the problem. Problem finding, thus, isn’t just a valuable product management skill – it is an incredibly valuable career and life skill.

Product sense = The ability to build for value

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

Product managers who consistently build good products over time are said to have good “product sense.” It is one of those sounds-insightful-but-it-really-is-vague terms that is thrown around a lot when product managers are assessed and evaluated. I think the use of the word “sense” makes it natural to equate product sense to “spidey sense” – something a tad more extraordinary. :-)

Product sense is simply the ability to consistently build for value. This note is going to be about why it matters so much and how it manifests itself in the process of building products.

For starters, let’s go back to what an IC (individual contributor) product manager doesa product manager brings a team of cross functional stakeholders together to build a product that is valuable, usable, feasible.

Of the three outcomes a PM is responsible for, the most important is value. Building a useless product that is beautifully designed and well engineered is a waste of everyone’s time. On the flip side, if you get to build a product that is incredibly valuable, you can survive many iterations of poor design and/or technical architecture. And, if you need any convincing, look at the launch version of products you now love – they most likely started out looking ugly or suffered from “this site is down” errors far too often.

So, let’s begin to explore the notion of value.

Value = benefit to others. The value of anything we do is measured by the benefit others get from it.

How, then, do we “add value” in our jobs? There is only end recipient of value in our jobs – the customer (used interchangeably with “user” for consumer product companies). But, when we build or work on products, there are 3 broad ways we create value –

1. We build for basic user needs/what is considered “table stakes”: This constitutes everything a company does to serve its customers’ basic needs and match competitor offerings. While “table stakes” sounds simple, this is often really hard to get right and tends be the foundation on which companies build their differentiation. One example for internet products would be SEO or search engine optimization. While it is definitely table stakes as customers expect to find you easily when they search for you, it is still hard to get right.

2. We are enablers for our co-workers/partners: This includes all products targeted at improving the productivity of our co-workers as well as all the tools we build to enable partners to sell our products to customers.

3. We work on stuff that differentiates our company from the competition: Every successful company succeeds on the basis of some differentiation. While working on the “moat” sounds all hip and snazzy, this is often a result of a relentless focus on the customer’s problem or “job-to-be-done.” This is also rarely one thing – instead, it tends to be a combination of things a company does to elevate its status from what is considered “table stakes.” Think: all the small things that Ikea does to successfully serve anyone who wants to quickly furnish a home.

This all sounds pretty basic – why is it so hard to do when we are building products? Building for value is hard to do in the same way exercising, reading good books, and eating healthy are hard to do. This should be how everyone builds products. But, other stuff – typically corporate politics, bad organizational or product culture, and organizational inertia – gets in the way. This “other stuff” results in bad product management.

Bad product management involves product teams building products that put the needs of the company or executive team ahead of the needs of the customer.

All this brings us back to the 4 core skills of an IC Product Manager – problem finding, problem solving, building effective teams, and selling. 

Since product sense is about building for value, I believe that “problem finding” or the ability to define customer/user problems well is the skill that differentiates good product managers from great product managers. As my hope with this series is to drive clarity, I’ve intentionally stayed away from using “product sense” instead of problem finding or problem definition – even if product sense is common usage. And, in our next post, we’ll dig into developing our problem finding muscle – via problem statements, hypotheses, and riskiest assumption tests.

A career and life sidebar. For the life learning/career learning geeks out there, the notion of “value” goes well beyond building products. It has profound implications to success in our careers and our lives. Take the idea “success” as an example – we succeed (externally) when we create or offer something that the world wants or values. It is this value that generally translates into wealth.

For example, we communicate well when the others in the room understand what we say. Our clients and managers don’t appreciate us for the work we do. Instead, they appreciate us for the problems we solve for them. Like him or hate him, this was the magic behind Steve Jobs’ work. He had a deep understanding for the problems we wanted solved and for the stories we wanted to hear. He remains a great example of someone with great “product sense.”

The implication for us – we often orient our narratives around what we did – “I worked so hard” or “I did so much” or “I said so many times.” Unfortunately, such effort counts for little. Outcomes >>> Outputs. Our external success, instead, is a function of how well we understand the exact nature of the problem others around us would like solved. As we get better at solving these problems for our world, we earn the right to do the same for “the world.”

As we’ll explore over the course of future posts, most of the principles that enable us to build products (or build anything for that matter) are just as applicable to our lives. Thanks, as always, for your attention – I look forward to your notes and feedback.

Knowing thyself – the foundation of long term career progress (feat. user manuals)

We kicked this series off with a look at the 4 core skills of an individual contributor Product Manager – problem finding, problem solving, selling, and building effective teams. Then, we defined what a product manager doesa product manager brings a team of cross functional stakeholders together to build a product that is valuable, usable, feasible. Today, we’ll dive into that small matter of career progression and explore the foundation of long term career progress – knowing thyself.

Khe Hy, a blogger at “RadReads,” had a useful illustration on a general career arc.

As Khe’s illustration demonstrates, there’s a lot to be gained from exploration early in the career as it helps us figure out what we’d like to be good at. Then, we invest in becoming specialists. And, finally, if we’re interested and able, we get to zoom out again as executives who oversee multiple specialist areas.

While these ideas translate well for product manager careers, my version of the the career arc for product managers would look something like this.

Individual contributor/IC PMs start with a focus on narrow features and small products. Over time, they take on larger products and product areas. Larger product areas are typically led by people managers (“Group”) or senior ICs (“Principal,” “Staff”). And, product executive teams typically oversee entire marketplaces and ecosystems.

Now, if we were to visualize this career trajectory as a building, the foundation would be self awareness. The deeper the foundation, the sturdier the building.

While this holds for careers across industries and roles, it is very pertinent to any role building technology products. Building a technology product takes a village – with team members across functions coming together to ship a finished product. Given the critical nature of teams and people in this process, emotional intelligence is a key asset. And, self-awareness/knowing ourselves is the cornerstone of emotional intelligence.

(Note: There is the alternative approach to building product teams which we can call the Steve Jobs v1.0 approach. This involves “my way is the highway” + some reality distortion + hopefully backed by once-in-a-generation product intuition. This post is for the rest of us.)

What is self-awareness and how can I get more of it?

There are two kinds of self-awareness –

i) Internal: This represents how clearly we see our own motives, values, passions, aspirations, fit with our environment, reactions, and impact on others.

ii) External: This represents our understanding of how others view us.

My observation is that external self awareness is crucial for career progression while internal self awareness is correlated with career fulfillment and happiness.

The challenge with both kinds of self-awareness is figuring out how to get more of it. Approaching this topic can feel very daunting. Ergo, my favorite tool to make this process easier – a “user manual.”

How do I creating my own User Manual?

Step 1 – Create a first draft user manual: Block out 60 minutes of your calendar next week and take a crack at a 1 pager that has some or all of the following –

1) Getting responses and work done: E.g. share your preferred work hours, preferred communication channels, and best times to schedule meetings.

2) My style: 3-4 must know characteristics about your working style

3) What I don’t have patience for: Focus on specific behaviors that drive you nuts.

4) How to best communicate with me: Share how you prefer to consume information – e.g. some prefer written memos or sketching on a whiteboard while others prefer verbal pow wows.

5) What people misunderstand about me: These typically involve flip sides of your signature strengths.

6) Things I’m trying to get better at: 2-3 improvement areas you are focused on.

7) Random Quirks: Something fun. :)

Step 2 Share with close teammates for feedback: Share with a few folks (/work friends) who know you well and see if this one pager accurately represents you.

Writing the first draft involved drawing on both your internal and external self-awareness. While very few can help you better articulate what you care about, feedback from close colleagues can help give you a measure of your external self-awareness.

Step 3 – Set up 30 mins to review with yourself every month: The power of the first draft of the user manual is that it marks the beginning of the journey. We never “achieve” self-awareness. We just get on the train with our first draft user manual.

As you spend more time with it, you will find yourself tweaking the user manual after every review and crystallizing your random thoughts (at least at first) into themes. For example, I ended up synthesizing the 3 aspects of my personal culture (hungry, thoughtful, learning focused) as I iterated on sharing “my style” as part of this process.

As a bonus step, you might even want to consider reviewing your user manuals jointly as a team. We did this on one of our cross functional teams recently and it turned out to be a very powerful team building exercise.

Conclusion: While short term career progress tends to be a function of good on-the-job skills, long term career (think: decades) progress tends to be correlated to our self awareness. The beauty about self awareness is that it is a skill that is foundational to better relationships – which has implications well beyond our time at the office. And, I’m a fan of using user manuals to aide the development of the skill.

If you find yourself stuck with creating that user manual and would like to see an example, please feel free to check out the Quartz article below for further reading. I’ll also be happy to share mine if that might help – please feel free to send me a note on rohan at rohanrajiv dot com.

Further reading:

i) Tasha Eurich, an organizational psychologist and executive coach, assembled a team to share her findings on both kinds of self-awareness. If you haven’t seen it, I’d recommend reading it here (you can also see my 5 point synthesis here).

ii) This Quartz article on user manuals is a helpful starting point.

iii) If you are curious about more resources to figure out your motives and values – here are a couple of posts (motives, values and mission statement) that might help.

What does a product manager do?

A quick note for the new subscribers: I just started doing a bi-weekly series on my notes on technology product management (this is what I do for a living). As I write to learn, you’ll notice posts on the topics I spend most of my time thinking about on weekends. Thus, it is technology/product management on Sundays and parenting on Saturdays. :)

We kicked this series off with an attempt at answering the the most common question about problem management – “What is the day in the life of?” In doing so, we looked at the 4 core skills of an individual contributor Product Manager – problem finding, problem solving, selling, and building effective teams.

Today, we’ll tackle the other common question – “What does a product manager actually do?” As with the last post, this is focused on the individual contributor Product Manager vs. a manager/leader of product managers. We’ll build up to the latter later in the series.

So, what does a product manager do?: A product manager brings a team of cross functional stakeholders together to build a product that is valuable, usable, feasible.

This definition builds on Marty Cagan’s articulation of product management by explicitly calling out the role of the product manager in bringing a team together. I’m aware that there is definition out there that explains what the product manager does by describing a person who spends time at the intersection of technology, design, and user experience. While there are many problems with that definition, the most important is that it is output focused vs. outcome focused. The outcome that matters is a product that is valuable, usable, and feasible.

Inevitably, this discussion on what a product manager does takes us back to the 4 core skills of a product manager. Each of the 4 contributes to our definition –

1. Bringing together a team of cross functional stakeholders effectively requires us to build effective teams.

2. Building a product that is valuable requires problem finding and selling.

3. And, solving for usability and feasibility requires plenty of problem solving supported by selling.

Who are these cross functional stakeholders?: The typical list of functions a product manager works with is proportional to the size of the company and is dependent on the type of product. In smaller companies, multiple members of the team likely wear more than one hat. And, B2B products, for example, tend to have more cross functional involvement due to the concerted go-to-market efforts required. All that said, a list of the stakeholders who combine to become the product team would look something like this –


I have a long list of cross functional stakeholders listed in the “value” part because that is most challenging part of product management. Getting the “value” part right means finding that ever elusive product-market fit.

At this point, it is important to understand why a lot of the writing around product management tends to focus on the process of building products that are usable and feasible. That is a function of the fact that a large number of product managers are working on established products that have already found product-market fit – i.e., the survivors.

In such situations, building effective teams and problem solving through usability and feasibility issues tend to be the skills in demand. Established products do still go through the process of problem definition – every new feature still needs a problem statement and hypothesis. But, it is much easier to do this when you’re building on a successful product.

If, however, you’re tasked to build something new for an existing audience or target a new audience altogether, problem definition becomes the single most important skill (the ability to sell comes second). If you’re not building something that is of value to customers/users and that fits within the company’s strategic vision, the most beautifully designed/engineered product is useless.

What exactly is good problem definition?: Since I’ve spent a lot of time in both posts on the importance of good problem definition, I’d like to do a quick outline of what “good” looks like (detailed version to follow in another post). The two key steps in defining a problem well are generating a good problem statement and hypothesis.

Problem statement – Good problem statements clearly articulate i) the audience, ii) their unsolved need, and iii) the importance of meeting that need.

Hypothesis – A good hypothesis is a proposal for meeting the audience’s need articulated in the problem statement that can be validated/tested through experimentation or analysis of existing data. A hypothesis generally takes the form of a collection of assumptions that can be tested.

Getting the problem statement and hypothesis right are the first and most important steps of the product creation process.

Conclusion and a preview: This post was focused on defining what an IC Product Manager does – bringing a team of cross functional stakeholders together to build a product that is valuable, usable, feasible. As we explored this, we touched on cross functional stakeholders and problem definition. Understanding how to craft a good problem statement and hypothesis helps explain why product creation is less about “minimum viable products” and more about “riskiest assumption tests” – an idea we’ll spend time on in future posts.

At this point, it is also worth taking a step back and asking why we didn’t begin this series with this post. Why not start with what product managers do and then follow it up with the skills required for the job? I think that flow gets to what is generally broken about hiring and PM hiring is no exception. Most hiring focuses on past experiences over skills and, thus, inadvertently prioritizes intercept over slope. There’s an opportunity in there for all of us – for those who are looking to hire great teammates and for those who are seeking to move into product management.

More to come on all of this.

Notes on Product Management | Day in the Life of

Writing on this blog every day is all about sharing my learning journey. As a result, this has meant sharing lessons learnt on starting (and quitting) a non profit, on life in graduate business school, and, more recently, Saturday posts on parenting. So, I’m excited to commit to writing more regularly – I’m shooting for bi-weekly – about what I do at work as a Product Manager at LinkedIn.

While I expect to delve into topics unique to product management about half the time, I expect the other half to be about lessons learnt on approaching work better – running better meetings, managing managers, and so on. I hope you find it interesting/useful.

Today’s post tackles the “What is a day in the life a Product Manager” question.

“What is a day in the life of <insert role you’d like to learn more about>?” is a common question when you’re looking to learn more about a role in a particular company. It is a surprisingly powerful question as you aren’t expecting the person on the other side to open their calendar and rattle out their schedule for the day.

Instead, the question behind the question often tends to be – “What are the skills required to do what you do?” That turns out to be a difficult question to answer because the skills required to a job well are rarely covered on the job description. And, my journey to understanding the skills required for my job as an IC/individual contributor Product Manager involved drawing extensively on the 3 sources of learning – books/synthesized information, conversations with other product managers, and my own experiences – to map out the product creation machine and the skills required for each phase.

This is the “clean version” of that machine.

I say “clean version” because the reality looks something like this.

All this takes us back to where we began – “What are the skills required to be an IC Product Manager?” While the nature of their application varies depending on the type of product (B2B vs. B2C for instance), I think there are 4 core skills –

1) Problem finding: This is arguably both the most challenging and most important skill. We are educated in systems that teach us to solve problems, not find them. So, it takes time to unlearn our natural instinct to “dive in” and, instead, take a step back and really understand what problem we’re trying to solve and for whom.

2) Problem solving: Iterative problem solving is at the heard of the building process. This is when we aim to balance value with usability and feasibility. We always have fewer resources than we’d like and this skill helps us make the trade-offs necessary to get a product out of the door.

3) Selling: I’ve intentionally chosen to use the word “selling” instead of the more common “influencing” because selling is a massive part of the job. We are always selling the value of our product – internally, externally, upward, downward, and sideways. Realizing this was a game changer for me. The other powerful learning that accompanied this was realizing how much of the selling I did was written.

4) Building effective teams: Great products are built by teams. Great products aren’t always built by great teams. But, great teams are always at the heart of great product building experiences. We don’t always get to build great products (they require luck and timing among other factors) – but we can choose to always create great building experiences.

More on all of this to follow on future posts in the series.

Optimizing roadmaps for breadth vs. depth – Peacetime and Wartime

In talking about successful leadership styles, venture Capitalist Ben Horowitz makes the distinction between peacetime leaders and wartime leaders. He explains the distinction as follows –

In peacetime, leaders must maximize and broaden the current opportunity. As a result, peacetime leaders employ techniques to encourage broad-based creativity and contribution across a diverse set of possible objectives. In wartime, by contrast, the company typically has a single bullet in the chamber and must, at all costs, hit the target. The company’s survival in wartime depends upon strict adherence and alignment to the mission. 

I’ve found the analogy of peacetime vs. wartime to be very useful in thinking about how we think about optimizing our product roadmaps and focus at work.

When everything we work on is looking healthy and growing, optimizing for breadth makes a lot of sense. We can take on a couple of venture bets and keep a portfolio of projects humming along.

But, when the weather changes and we find issues with one of our core projects, we must, just as quickly, be ready to hunker down and focus. That’s the time to shelve any extraneous work and focus on the pieces we know will drive impact – at the expense of others if necessary.

Effective leadership of organizations/teams/products/self involves understanding when to optimize for breadth vs. depth. And, the peacetime-wartime analogy is a great way to put the current situation in context and tailor our response.