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.

Committing to rewriting

When we write, the first draft is simply a crystallization of our thinking. The first draft, in essence, is for us. The challenge with writing well is rewriting that first draft with our audience in mind. Doing so helps us separate the process of thinking from the process of writing.

While this sounds simple in practice, this turns out to be very hard. As Barbara Minto articulately describes – “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.” 

This is true – at least in my experience.

One approach to solving this problem is to lay out your thought process on a piece of paper before writing. That, however, may not work for everyone. While I’m keen to test it, I’m not optimistic about my attempts to do this well.

The alternative solution I’m more hopeful about is to start writing by making a strong commitment to rewrite as soon as I complete the first draft. Setting this expectation will hopefully make it easier for me to not get lost in the “glow” of my first draft.

Here’s to experimenting with both.

PS: Thankfully, the tools we use today are perfect editing and rewriting. It is a pity if we use our current suite of editing tools like typewriters.

Don’t rush to be embarrassed by the first version of your product

The intent of good quotes is lost over time. So, they are often misunderstood and misused because they are applied out of context. Reid Hoffman’s quote – “If you are not embarrassed by the first version of your product, you’ve launched too late.” – is a great example of loss of intent.

I’ve seen this quote used as an excuse to justify a crappy v1/first version product. I haven’t heard Reid talk about this in person – but, I’m fairly certain that that wasn’t the intent.

There are two good reasons to be embarrassed about v1 (in hindsight). The first is the most common – you didn’t know better and/or couldn’t do better with the tools available. The first website I put together looked horrendous. I didn’t understand the basics of web design and it was also built on an early version of Adobe Dreamweaver. Now, however, I have slightly better design skills and, more importantly, have access to amazing tools. Thanks to the likes of Bootstrap and services like WordPress, it is very easy to build a good website.

The second is the result of prioritizing one killer use case/risky assumption for your product and ignoring everything else. You may still be embarrassed by the first version – but, you’ll still have served that basic user/customer need.

Source: Unknown – thank you to whoever made this.

The truth is that you’ll be embarrassed by nearly everything you ship. Over time, your skills will improve, the tools will get more sophisticated, and your understanding of the user/customer need will get better. So, you don’t have to work too hard to cut a few corners now to ship something you’ll be embarrassed by. Time will take care of that. The key, instead, is not to knowingly do something you will regret.

So, the two questions I’d suggest asking are –

  • Is what we are shipping helping us learn what we want to learn while providing value to the user?
  • Is this our best effort based on what we know/have access to now?

If the answers to both are yes, ship away. Even if you are eventually embarrassed about what you ship, this approach will make sure you will not have any regrets.