The Anatomy of a Great Product Leader

I have been seeing a number of posts and articles on social media about what it takes to be a great Product Manager, and what people are doing wrong. Some of them hit the mark, and many of them are plain, flat out, incomplete.

This is not going to be a primer on Product Management 101. This is a compilation of the greatest misses and how you can avoid them in your PM career.Brace yourself for a seriously opinionated read, and take away from it what you will.

Let’s define “Product Management”, shall we?

Wikipedia defines this term as: “the business of planning, developing, launching and managing a product or a service. It includes the entire lifecycle of a product, from ideation to development to go to market.”

My good friend ChatGPT 4.0 defines this as “the practice of strategically guiding a product’s development, launch and ongoing evolution by balancing customer needs, business goals and technical capabilities.”

There are other definitions based on where you look, that underscore customer empathy, technical strength and voice of the market. If you listen real close, you will hear the term “leadership by influence” whispered as well. None of these are wrong, but they are not exhaustive either.

Let’s break down the fundamental aspects a product leader is expected to drive (and if all of these are not on your radar, you are doing it wrong).

The ethos, the mission, the goal of a product leader — regardless of the stage they are in their career — is to have a clear vision into what the product needs to do, make sure they have deep insight into every aspect of the health of the product suite they own and are responsible for, and make it a success.

How do you measure the health of the product? Before you rush in and say “revenue” or “number of users” — I invite you to pause, and reflect on what health of the product means.

All products must have one thing in common — a clear success metric. What does success look like? Boil them down into 3 or less succinct metrics and make sure every person on your team knows that this is what success looks like.

Let’s back up a little bit — you know what success should look like — you are, after all — the killer PM for the hot new product. Your executive management is aligned. Your PM reports are aligned. Who else should be aware of this, and aligned with it? Engineering. Of course.

But if the answer stopped here, you would be wrong.

Where most product leaders tend to focus: The vision.

A vision without the surgical and deliberate intent and effort to execute it all the way to completion is a pipe dream.

I am absolutely not knocking this down — you need a clear vision, and that is the precursor to everything. It’s equivalent to the bones of the sailboat you set out on, and everything has to be built and must sustain itself on top of it. I have been continually disappointed by and surprised by the number of good PM’s who stop at vision, or make beautiful presentations with market research and perhaps go even farther to write down crisp technical requirements and stop there — and then wonder why the product is not the wild success they said it would be — how do they not see it coming? I am proposing one way to solve this, and I have personally stress-tested this approach numerous times with great success.

A product leader must develop these 5 areas to ensure the ongoing health of the product:

1. Distinguish between trends and truly disruptive technologies — Generative AI is a hot topic, so let’s use this as an example. There is no doubt that this is a truly disruptive technology. But the ways in which it is used — some are trends, some are disruptive. An example of the latter is image generation. An example of the former is using it for quick answers — the downside here is leveraging information that could be completely inaccurate.
2. Differentiating between user wants and needs (or worse, considering the company shareholder a user of your product) — Everything starts and ends with the actual user of the product. Being able to separate the user pain from the user ask is critical, and is the difference between a product with a strong vision that completely missed the mark, and a product that revolutionized the user’s world. It should go without saying, but doesn’t — so I’m going to say it — don’t piss off your users. They will hate you and you will lose trust. It doesn’t matter what the size of your organization is — when users love the product, they tell people about it. When they hate it — they shout it from the rooftops with a megaphone.
3. Stellar communication with the ability to context switch instantly (strategy, business, technical, empathy) — Are you communicating with an executive leader? Keep it short, simple, and to the point. Are you communicating with your team? Balance the 50,000 feet view with the tactical, get your hands dirty and ask the hard questions.
4. Keep an open mind — Input comes from places you didn’t think to prioritize or even look at the first time. Dismissing it is almost always a mistake. You cannot and should NOT prioritize every piece of feedback. The most unexpected source of useful data I received as a PM was from the deal desk — the final frontier where deals are closed or lost. At the very least, it validated the health of the revenue, and at its most useful, I got direct insight into the companies we lost to, why we lost several weeks before a formal post-mortem was conducted.
5. Understanding the importance of every role that contributes to the success of a product — All the people who contribute to the success of the products you lead perform different tasks, and many have no idea how their specific work can impact the overall product direction positively or negatively. My favorite example is the oft-overlooked documentation.If your documentation is hard to follow through, or doesn’t optimize for precisely how users navigate your documentation, your product adoption is going to suffer. This is the most commonly overlooked area, and why many good products have poor documentation — there is zero awareness on the part of the technical writer of the product success metrics, something a good PM could have easily rectified.

Every single role that has anything to do with contributing to your product in *any* way must be aligned and/or aware of how success is measured.

There is a difference between Alignment and Awareness, in this context:

Alignment: Getting agreement to move forward with the plan.

Awareness: Knowledge of what success looks like with specific actionable, trackable metrics (eg: increase downloads by x, or installations by y, or number of API calls by z, or revenue from x by y, etc.)

Both alignment and awareness have a purpose if you want to have a healthy, thriving product — you must get agreements from the stakeholders who need to either fund development, or develop the products. Awareness is to purely ensure that every action taken by the folks responsible for completing certain tasks all tie into moving closer towards achieving the success metrics of the product.

Let’s explore some of these personas for technical products:

1. Engineering (duh..!) — Aligned

Why: They are going to build your vision. There needs to be zero doubt on the value the product is delivering, how this value will be measured, how the features built will deliver this value, and transparency into why you are expecting the moon — to put it lightly.

2. Product Leadership — Aligned

Why: Overall strategic alignment, that is critical for joint GTM motions. Critical for hiring, justifying new head count, etc. Simply put — you will find it a lot harder to run off and build a spaceship when your organization is building trains.

3. Engineering Leadership — Aligned

Why: Everything I mentioned above + efficient use of resources. Reusing work done by a different team will drastically short circuit your time to launch.

4. Any product manager managing any part of the product — Aligned

Why: For larger, more complex products, its not uncommon to have multiple PM’s owning different parts of the product. There is no service mesh overlay here that does the hard work of keeping everyone on the same page. Wait — there is — you are it.

5. Developer Relations Advocates — Aware

Why: These talented folks are tasked with increasing awareness and driving developers to the product. If they don’t know what the product goals are and how you are measuring ROI, they are going to showcase the wrong thing. That is also a communication fault that could have been avoided.

6. User Experience Researchers — Aware

Why: This should be obvious.

7. User Experience Designers — Aware

Why: Designers literally work on giving a form or a visual of the experience your users will have with your product. If that is not aligned with your user goals, there is a glaring mismatch and gap in communication. This is the most common issue I have seen, and something that should never happen.

8. Privacy experts in your organization — Aware

Why: You should really be using them as advisors, or a sounding board even when you are deploying products that are sensitive, touch regulated industries, user data, or use AI. This will avoid a lot of heartache in the future.

9. Technical Writers — Aware

If your technical documentation is hard to follow through, or doesn’t optimize for precisely how users navigate your documentation, your product adoption is going to suffer.

10. GTM / Marketing — Aware and/or Aligned

Why: Again, a mystery to me why this misfires in many organizations. Overall organization GTM goals have to fold in the product goals (or, what success looks like), to ensure that the specific GTM actions that optimize for these goals are acted upon. Marketing is a science, not a shot in the dark. I continue to be mystified by anyone who treats it differently.

11. Field sales teams / Partners — Aware

Why: Applicable for B2B. If your company is in B2B technical sales with a laundry list of products to sell, your field sales teams need to clearly understand (a)the USP of your product/s (b)the fastest path to customer use and thereby revenue, which translates to sales commissions and payouts. Same thing goes for partners.

12. Support Teams / Customer Success teams — Aware

Why: They are a valuable source of insight into the problems your users face most frequently. Making sure the right data is captured is going to save you a world of pain and shots in the dark.

It’s not an easy task to ensure the product you worked so hard to will into reality continues to be healthy and thrive, but it is hardly impossible. Every wildly successful product that has endured and stood the test of time has delivered outsized value to the user and pivoted quickly when needed. Neither of these 2 things are possible if the key contributors to product success are not aware of or aligned with the overall success metrics.