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.

Directional answers and precise answers

I use simple a rule of thumb for the difference between attempting to convert a directional answer into a precise answer – 10x+ time investment.

Attempting to find a reasonably good pair of headphones might just take you 10 minutes on Amazon. However, if you’re looking for the best headphones you can find for your budget, you could easily spend 100+ minutes searching.

Similarly, if you want to predict the effect of your strategy on key metrics, you might be able to get to a directional range in 2 hours. But, if you want to isolate and understand every variable and its interactions, you’ll want to budget at least 20+ hours of work.

This is analogous to being a satisficer versus a maximizer. Attempting to maximize everything you do by getting precise answers is very expensive. Thus, the implication in conducting analysis as in living life is similar – assume you need directional answers unless it is clear that precise answers are the way to go.

Every once a while, you’ll realize that you’d have been better off finding that precise answer. But, thanks to this strategy, you’ll have enough buffer time to course correct. :-)