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

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