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 –

product-team

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.

Flossing and the power of great product design

Most of us know flossing is good for us. Getting to the area between our teeth is impossible with toothbrushes. Floss helps us with that. It makes sense. And, yet, I hated the idea of flossing. The traditional approach to flossing involved an elaborate dance with my fingers and I ended up finding excuses on most nights.

Then, I read about Listerine’s flosser and decided to give it a spin. Listerine ensured the product was designed with a handle and replaceable heads. It sounded great. And, it was.

One of the top reviews on the Amazon page of this product was “Habit forming.” I couldn’t agree more – that is what this did for me too.

This flosser, thus, has become a daily reminder of what great product design looks like. By virtue of thoughtful product design, it makes it easy for users to form a habit to do something that they both want to do and is good for them. It is exactly what the best products do.

Learn from the flosser, we can.

Attachment to principles versus processes

The biggest benefit of experience is better pattern matching. You’ve seen many of the today’s movies play out before and are equipped to deal with them. The downside is a growing attachment to processes versus principles. This when you say something like – “This worked before. This is how I do this sort of thing” instead of “This is why I do what I do.”

I’ve noticed this creep into my thought process from time to time when it wouldn’t have five years back.

Here’s an example – let’s say a rapid, iterative approach to product creation worked on your team in the last year. The process you could get attached to is “Rapid, iterative product creation is how to build products.” Instead, the principle probably is – “The best process to building products is dependent on the context, the company, and the kind of customer.” If you were attached to the principle, you might decide that slower, more thoughtful product creation process is what the current situation needs. Whatever the outcome, you’d consider the alternative.

The challenge with developing an attachment to a process over a principle is that the principle you implicitly choose is “Refusing to ask why means choosing comfort over growth and inflexibility over seeking the truth.”

That is the polar opposite of one of the most important life principles – change is the only constant. We either change proactively or are forced to do so by circumstance – an experience that is best avoided.

Principles first. Processes second.