Does the Head of Product Need to Be the Best Product Manager on the Team?

I’ve had this blog post in my head for a couple weeks now. I’ve been thinking about how to lay out a strong case for what I momentarily thought was a controversial topic. I figured the post would be long and go to great lengths to help readers come to the conclusion that I have.

But guess what? None of that is needed. there is such an easy answer to the question: “Should the head of Product Need to Be the Best Product Manager on the Team?”

No.

So why did I go on this journey? It was a moment of weakness that I don’t mind admitting to. Recently, I’ve had a bunch of great conversations with founders preparing to hire their first head of Product (VP, CPO, HoP). To my surprise, more than one has directly said or strongly implied that they expect their new Product leader to be “the best Product Manager on the team.”

In every leadership role I’ve been in, I’ve had at least one team member that I believe to be a better PM than I ever have been, and I have always seen that as a good thing. At the same time, I also believed myself to be the best and most capable of leading the functions I was responsible for. I guess these chats with talented CEOs made me start to doubt myself and I began pondering this question, assessing my own skills and abilities.

I don’t believe that anyone expects a CTO to be the best software developer on an engineering team. We don’t expect the CMO to be the best visual designer on the creative team. Why would we expect the CPO to be the best Product Manager on the team?

This may be cliche, but I used a sports analogy to help me put this question to rest: Steve Kerr, the Head Coach of the Golden State Warriors NBA team was not the best basketball player on any of his teams when he was a championship winning player (not even close). Yet, today he is recognized as one of the best coaches in the NBA over the past 10 years. Kerr will one day be inducted into the NBA Hall of Fame, and it will be because of his coaching career, not his playing career. He is a talented and effective leader of players that are all better than he was.

Conversely, LeBron James can arguably play all 5 basketball positions at a high level, and he is considered by many to be the best basketball player of all-time, but we have no idea if he’d be a good coach. In fact, he probably wouldn’t be. If you look at ESPN’s top 40 NBA players of all time, you’ll only find three that have had some notable success as a coach, and not a single one even close to being one of the best coaches in any given year, let alone the history of the NBA.

Why is this? The job is totally different! The skills needed to be a top tier coach are completely different from the skills needed to be a top tier team member.

If Steve Kerr thought that he was the best player, and didn’t try to “hire” players better than him, I suspect that the Golden State Warriors wouldn’t have any of their four championship titles in the last nine years, and Kerr would have been fired long ago.

Just as the jobs are different in sports, the jobs are also different in software product management. A highly talented head of Product is focused on building and up-skilling the best team they can assemble. They create an environment and playbook that allows each team member to be their best and play the role the team needs them. They are the expert when it comes to the customer and the competitors. The head of Product connects the organization’s goals to execution in the area by setting, owning, and championing a strategy to build the right products, for the right market, with the right investment, at the right time.

If you haven’t been a Product Manager, it will be much harder to be great at the things a head of Product needs to do. You don’t need to have been the best PM, but you better know the job inside and out, have witnessed it done well, and have recognized when it was done poorly (even if that was you).

That brings us to what I believe the head of Product does need to be the best at:

  1. Setting vision & strategy: As a member of the company’s senior leadership group, you play a pivotal role in setting and guiding company vision, while owning a product strategy that guides the organization towards achieving that vision. Good strategy considers current customer needs, where the market is headed next, and what the company’s long term vision is. All packaged so that it is clear to all what the priorities are, why, and how we’ll act in order to reach defined goals.

  2. Recognizing trends and opportunities: Product Managers and Engineers focus heavily on shipping products to satisfy a problem that exists today. While PMs are not exempt from seeing and planning for the future, I expect the head of Product to be the first to see where the market is going, to spot emerging trends, to find hidden opportunities, and then decide when and how much to invest today for big rewards tomorrow. Product leaders do this by being out in the market with customers (literally and figuratively), building user empathy, becoming a trusted advisor, and acting as a continuous student of the industry. The right team, in the right positions, with the right playcalling is a multiplying force that exceeds anything that a head of Product could ever be on their own.

  3. Recruiting & nurturing talent: Product orgs operate at their best when they have the right people, in the right position, with the right coaching. It's not just about finding the best fit, it's also about convincing them to join the journey, coaching them to be their best, while fostering interest and excitement in the work. It’s not just about having the right people with the right skills, the head of Product needs to foster an environment and process that invites partnership from engineering through the Product Manager’s effective communication around the “what,” “why,” and “when” of their priorities.

  4. Facilitating cross-team collaboration: Great product doesn’t mean much if it can’t be effectively marketed, sold, and supported. Engineering isn’t the only team that product managers must work well with. An effective product leader makes sure their team does not work in isolation. They expect their product managers to influence Marketing, Sales, Support, and other functions by partnering with the leaders of these functions and to set an example of collaboration and paving the way for two-way relationships that benefit customers and the business.

  5. Communicating well: Absolutely everything in this list is dependent on being a fantastic communicator. I often say that product leaders really only do three deceivingly simple things: They listen (to customers, data, colleagues, etc), they think (about priorities, investment levels, timing, visions, strategy, etc), and they communicate (to win support, create understanding, set goals, etc). Being an effective communicator means winning support for strategy because it is clear, relatable, and powerful. Being a great communicator means selling the org on taking the right risks, at the right time. Being a stellar communicator means getting the best talent to jump in the boat with you and give it their all. A mastery of communication results in strong ties to customers where trust leads to openness and partnership.

Curious to see my thoughts on other aspects of Product Management? See those posts here. To see the conversations on this topic from the r/productmanagement Reddit sub, head over here.

Is Product Management really all about the customer?

The last time I updated my resume, I wrote a headline that said “customer obsessed product leader.” it’s true, I LOVE engaging with customers and serving their needs, those are my favorite things about product management. I’m not alone, putting the customer first is what many product managers agree on. Customer focused Product Managers are what employers want to hire. Who wouldn’t agree that being customer obsessed is great?! There’s a problem though. This very true and appropriate focus may cause some other things to be overshadowed.

They other day, I had coffee with a colleague who said they had just read one of my blog posts on Product Management. That got us talking about stakeholders, one of the 9 things I said that great product managers have mastery of. Spoiler alert, the customer isn’t the only stakeholder product managers need to care about, and they may not even be the the stakeholder with the most weight, or part of the equation at all.

I believe that product management requires explicit consideration of 3 different groups of stakeholders: the current customer, your future customer, and finally the company vision & strategy. It is not good enough to simply focus on your current customer and their needs. That may be good, but optimizing for all three is great.

Product-Stakeholders.png

The Current Customer

Make no mistake, I am not minimizing the importance of your current customer at all! This is the stakeholder that allows your company to pay the bills, the stakeholder that advocates for you to potential customers, the stakeholder that trusted you over others and gives you more than just their money, they give you, the product manager, their time.

As product managers, we must meet this customer’s needs. Often that means solving the problem they came to you for, delivering on the table-stakes in your space, and providing a delightful user experience that allows them to easily accomplish what they pay you to accomplish. Sometimes they’ll come to you with feature requests and ideas that are related to your core. Listen to these. Work them into the product roadmap when they make sense. Keep this customer happy! They represent 1 of the 3 key stakeholders you must optimize for as a product manager, you’ll always do good work if you serve them well.

The Future Customer

If you are ready to do great work, this is where you begin to evolve as a product manager, when you look outside the current customer as your core stakeholder, and seek to serve more through your work. The future customer can be many things. It can be a customer in your target market, but one you haven’t won over yet. I might be the customer you have today but with needs well beyond what you do now. It could be the future of the industry, the way it works in the future and new problems it doesn’t have today. It may be a new industry you could enter, expanding the reach of your products and technology.

Regardless of how you define the future customer for the project or decision in question, considering this stakeholder will take you and your product to the next level. Serving the future customer allows you to grow with your market and customer base, rather than just selling it a little bit more. Serving this customer is how you become or protect your position as the leader in your space. Meeting this customer’s needs isn’t about paying the bills today, it’s about paying the bills tomorrow.

Keep in mind that serving this stakeholder doesn’t mean you are acting against your current customer. Instead, this is your opportunity to align the current customer with the future, to understand where they are going and get there before them. It could also be an opportunity to ask yourself how you might build for the current customer and show the the way to the future, at the same time. Solve a problem they don’t know they have….yet. Be the hero that solves it before the realize it.

The Company Vision & Strategy

There is one more stakeholder that you must consider, and in some ways it is the most obvious, but in other ways it is the most elusive. I believe that great companies have a vision and purpose that transcend the product, and transcend the market. They serve a higher purpose. Sometimes these visions and mission statements seem corny, but they are the hallmark of enduring companies. For example, at PagerDuty, they don’t serve oncall engineers, they serve anyone in a digital business doing real-time work. They don’t send alerts to the right responders, they empower people in moments of truth so they can elevate their work to outcomes that matter.

To be a great Product Manager, you must ask yourself what the company needs from you and your product. Most company mission and vision statements require inventive, focused, and considerate product managers to make them a reality. They leave enough room for the product manager to make decisions that not only align with the company’s vision, they also serve the current customer and position the product for success with the future customer.

This stakeholder can be elusive in a couple ways. If you work for a company with no higher purpose, with no vision beyond the current customer and their existing needs, you’ll feel as if there are not 3 stakeholders to consider, just two, since the company vision and mission are the same as the current customer’s needs. My advice here is to either help your company desire to be and do more, or get a new job. The latter is probably easier. The other way you may find this stakeholder elusive is all about you. If you can’t separate your current customer’s needs from the company vision and mission. Frankly this is easy to do. You see what you current do for customers, and you equate that to the company vision and mission. You take a bottom’s up approach, so to speak. To be great, spend some time thinking top down. In the example of PagerDuty, what could real-time work encompass? When do moments of truth happen? What are the possible outcomes that matter? If you give yourself space to take a top down approach, you’ll often find that there is so much more there than what your customer is ask you to do today.


This stuff doesn’t come naturally. It is so easy to consider just the current customer, and not the other stakeholders. It is hard to know how much weight to give to each. Do you have to consider all three, or can you serve just two? If you serve just two, is one required in a way others are not? These are all great questions, and you know what? I don’t know the answer! I don’t know because it depends on what you are building. I also don’t know because I’m not perfect, and I am still working on being a great, not just good Product Manager.

As I reflect on myself, I think I am pretty good at considering all three stakeholders as I guide, create, and decide. What I am currently struggling with is selling my vision to others, as one that considers all three stakeholders appropriately, for the maximum benefit of our vision and mission. If you have advice on how to do that, I am all ears!

More on Product Management (Part 2)

Recently, I published a post that outlined 9 principles that make for great product management (On Product Management; May 23rd, 2017). I enjoyed writing the post as it was helpful for me to get my beliefs in a single place, and I was lucky to attract a great audience. My readers had some valuable thoughts, insightful questions, and astute clarifications via LinkedIn comments, Slack discussion, and direct emails.

In this post, I want to address some of those points of discussion, clarify a few things from my original post, and explore a few more principles that make for great Product Managers.

If you haven't read my original post, take a moment to read it and come back to this one. Finally, thank you to everyone that contributed thoughts, counterpoints, questions, and praise...you've helped me become a better writer, and a better Product Manager!

More on the Product Manager's role with vision & strategy

I started my last post out by saying that the role of a Product Manager is to shepherd through a vision...the vision of a Founder, a CEO, or a Chief Product Officer. I went on to talk about the PM's role as a leader, rallying the team around a vision and strategy, and developing products that serve multiple stakeholders. A couple of my readers pointed out that my message might have contradicted itself, and could be taken as a statement that vision and strategy aren't the role of the Product Manager.

This topic gets at a phrase that is commonly thrown around around Product Management, that being a PM is like being the CEO of a Product. I like this statement because it alludes to the type of work that a PM does, and the level of leadership they must demonstrate. I dislike this statement because it implies that the PM is ultimately in charge, that they can do what they want and have no equal in the organization.

While I absolutely believe that Product Managers should influence and contribute to company vision and strategy, and they should set a vision and strategy for their area of responsibility, the truth is that most of us work as part of a larger organization. Most of us have a boss, have a leader we work with. Many of us work at the companies we do because we were attracted to the mission and vision that their leadership put in place. If the Product Manager is setting company vision and strategy, rather than the C-suite, there's a problem. Similarly, if a Product Manager isn't helping the C-suite refine, build on, and advance the vision, there's also a problem.

More on user stories and project management

In my first post on effective product management, I made what turned out to be a controversial statement. I said that effective Product Managers aren't JIRA jockeys. This raised a lot of eyebrows and had many readers asking "but if not the PM, who?"

I firmly believe that the greatest value a PM delivers is not in JIRA, Pivotal Tracker, or any other project management tool. Thats not to say that a Product Manager shouldn't spend any time in these tools. These tools provide value to the team, and Product Managers should be involved in the workflow that takes an idea and turns it into reality.

Great Product Managers avoid being JIRA jockeys by doing two things: they communicate effectively early in the product development process, and they share the responsibility of management and oversight with other leaders.

Effective, clear, and complete communication upfront avoids the need for a micro-manager in JIRA. I do this through a Product Requirements Doc framework that aims to give my teams enough information about the problem and desired outcome that they can create development tickets with much more involvement from me.

Product Managers aren't the only leaders on a team. If the PM is the 'CEO of the Product' then the Engineering Manager is the CTO. Strong Product Designers have been present on every great product team I've worked on, and they should be looked to for leadership and direction. Finally, at larger organizations, Technical Product Managers can work alongside Product Managers to provide direction, validation, and management of the development process.

I believe that the amount of time spent in JIRA or similar tools is a view into a company's culture and the effectiveness of a PM. Product Management does not equal Project Management.

Effective Product Management orgs report through the CEO

Something I didn't touch on in my earlier post was the placement of Product Management in the org chart. There are a two common reporting structures for Product Management: Through the CEO or through the CTO. While both can work, I believe the best results come from Product Management organizations that report through the CEO.

This preference of mine stems from the idea that Product Management is about more than engineering. Engineering groups are singularly focused on technology, whether its the technology that customers interact with directly, or the backend and foundations that the product is built on. Conversely, Product Management is cross-functional by nature, working across pricing, customer support, sales, marketing, and more.

While the Office of the CTO can effectively lead Product Management, reporting through the CEO is a better fit. Like Product Management, a CEO's role spans the entire organization, influencing all aspects of delivering a product. Reporting through the CEO avoids potential conflicts of interest, where tough decisions must be made and priorities identified, and more easily allowing for a solution that might not be an engineering one.

Product Management is about more than code

In my last post, I may have ignored a principle which I feel is so important. The product is more than your software. The product is the entire experience that a customer or user has with your company. From how they first learn about your product, to how they are sold to, how they are on-boarded, how they use the product, how they are supported, and even how they are 'off-boarded", so to speak. Its all your product to the customer, they don't put walls between your marketing and your code, or between sales and support.

Effective product managers influence and lead all aspects of the product. They think of things like user documentation as part of the product. They know that interacting with customer support is part of the value being delivered. Sometimes the best way to move a product forward, to move the needle on sales or net promoter score, is to fine tune the non-software aspects of your product. If a Product Manager doesn't take responsibility for a cohesive product experience, its likely no one will and each customer touchpoint will remain silo'd.

Nike doesn't just sell shoes, they sell an identity. Blue Apron doesn't just sell meal kits, they sell time-savings and the joy of cooking. Software companies don't just sell access to code, they sell solutions to problems.

Am I living in a Product Management dreamland?

So am I crazy, or is my view on effective Product Management realistic? Truth is, its both. I have outlined a bit of a dreamland, a perfect world, but not a world that I've experienced at any single company or role I've held. That said, every philosophy that I've outlined is one that I've experienced personally or seen at other organizations. All of these philosophies are reasonable individually, and together they are a rare but special reality.

Some of these principles are ones that we can do on our own, as individuals seeking to be better at our jobs. Some of these principles require the mandate and support of our organizations and our bosses. If you desire more of a strategic and leadership role in your work as a PM, ask yourself two things. First ask if you are doing the things you can do with autonomy to be a more effective and efficient PM. Then, ask yourself if you are working for a company that wants and values leadership in a Product Manager.


This is part 2 of a 2 part series on effective Product Management. If you haven't read part 1, head on over to On Product Management for principles exhibited by great Product Managers.

Solve problems with "why"

In my last post, I talked about the importance of having a "hair on fire, pay anything to solve" problem when you are building a product or business. For a lot of entrepreneurs, this is hard to get to. You'd think it would be easy, but it's not and I get why. Entrepreneurs have passion, they have ideas, they have drive. All important qualities and a great way to start, but those qualities often lead to blinders that keep you from focusing externally on the customer and the problem you can solve faster/better/cheaper.

There is actually a very simple technique to help you find the real problem customer's will pay you to solve. It's a technique that comes from conflict resolution/problem solving. The technique is called "5 whys" and it's the idea of asking why 5 times. The theory goes, within 5 questions of "why," you'll get to the root of the problem or issue.

Let's look at an example that is common is many of your personal lives:

Your significant other (S/O): "I'm mad at you."

You: "why?"

S/O: "Because you didn't take out the trash."

You: "Why does that make you mad?"

S/O: "Because I shouldn't have to ask you to do some of the work around the house."

You: "Why is that a problem now when it hasn't been before?"

S/O: "Because you know I am working long hours this week at work, and the kids started school again this week so there is so much to keep up on."

Based on that interaction, with just 3 questions, you've learned that the problem isn't that you didn't take out the trash, the problem is that you didn't recognize your significant other's need for more help. They don't necessarily need you to take out the trash, they need you to have some empathy, understand the situation and be proactive.

If your significant other was a customer, they wouldn't pay you to take out the trash, but they would pay you to have empathy, understanding, and be proactive. The problem isn't the trash! Had you not asked why, you'd think it was the trash. Had you not asked why 3 times, you wouldn't know the real problem is empathy, understanding, and being proactive.

At this point, you might think I'm a bit crazy with this example, but it does have a direct relationship to you and your customers. The first problem you discuss is probably NOT the problem they'll pay you to solve. The problem they'll pay you to solve is often deeper, and understanding the real problem will lead to significant business and financial success.

The best way for me to drive this point home is to share a real life example. I'm lucky to be called an advisor to an exciting startup named TalentIQ. They are in the big data space, and can be described as a "people intelligence" company. They keep databases about people up-to-date with current and relevant information that can't be easily found, verified, or understood otherwise. They sell this value to talent recruiting, sales, and financial organizations. The product that customers pay for today is not the product the founders started with.

Sean and Henry originally recognized that hiring top talent is hard, in part because the best talent already has a job and isn't applying for a new one. So they built a sourcing tool, a search product that recruiters could use to easily find the best talent based on specific criteria, regardless of employment status. They had success with this product and dozens of customers, some household names, started using the software.

The sales were coming in, but not at the rate they wanted. So they continued to interview their customers, and asked "what makes your job as talent recruiters difficult?" When they got an answer, they continued to ask "why?" They dug deeper. Then they learned that while customers did indeed have a need for their original software, they actually had a bigger problem. They had stale databases with thousands of past applicants, and the perfect candidate for a new role may be in that database. However, the information in that database was likely wrong...if for no other reason than it was old...out of date. Even better, TalentIQ's technology could easily solve that problem, it was an easy shift and was inline with their original vision.

Sean and Henry had their "ah-ha" moment, because they had the perseverance and humble nature to go beyond the surface, and dig deeper. They asked why. Over and over again. The sales started rolling in, at a rate even greater than they had imagined. Today they enjoy a rapidly growing business, with mind-blowing revenues that most companies would envy for the first year of their existence.

What Sean and Henry did may seem simple, but it's hard. Really hard. As entrepreneurs, we have to be open to changing the original product we envisioned, in order to meet our customers needs. We also need to remain unsatisfied with initial traction. It's easy for a few people, a few customers, to say our product is good. Great business aren't built on a few customers, they are built on hundreds, thousands, even millions. You won't get to that level unless you are willing to ask "why," over and over again. Get out of your own way, dig deep, and get to the real problem.

Don't just take my word for it, or the example of TalentIQ. Look at other companies. Uber's most popular product is UberX, but their original idea was town cars/limos driven by professional drivers (Uber Black). Twitter started out as a group text messaging concept, but I doubt anyone uses their text messages features today. These examples go on and on, as do the examples of companies that were never smart enough to dig deeper. Which category will you be in?

The startup problem

Recently, I had the rare and exhilarating opportunity to meet with 7 different startups in a single day. I heard seven product pitches. Seven teams of entrepreneurs so passionate about their companies, they are wiling to risk it all. Do you know what I didn't hear? Seven problem statements. Seven reasons the world needed what they were building. Seven reasons that the risk was worth it.

Its not that none of the seven were solving a problem, its that some of them didn't (or couldn't) articulate it. Instead, they focused on the solution. The cool new thing they were building. The software that would make something happen. Frequently jumping right into the what and how, without the why.

If you are a startup entrepreneur, your #1 job is to passionately and convincingly explain the problem you are solving. Can't do that? Stop everything you are doing, and obsess over this requirement. Your goal should be a 1-3 sentence problem statement. So clear that someone not familiar with the industry you are in, can understand it. I don't care if you are in the nuclear physics or open source software industries, you should be able to clearly explain the problem to the average person you encounter in your life.

Why does it matter? Because as an entrepreneur, you are always selling. Not just selling to your customers, selling to everyone. Selling the opportunity to investors and potential employees. Selling board members, mentors, and advisors on helping you. Selling your spouse on why its worth the risk to put it all on the line for this. Sell your friends on the reason you haven't seen them in ages. Selling the stranger at the cocktail party on the fact that you actually do important work, and aren't crazy.

Now, if you are a high growth startup entrepreneur, knowing the problem you are solving and passionately telling everyone about it is just the first step. The next step is to make sure you are solving a 10x problem. A 10x problem is one you can solve 10 times better than the alternatives, or solve the problem for 1/10th the cost of your competitors. You sell your product for 20% less than the competition? So what, thats not enough. Your product is 30% faster than the competition? Get out of here, not good enough.

Your customers have an alternative to your product. Maybe its not a direct competitor, but at the very least the alternative is the status quo. Doing nothing or continuing the way they've always dealt with the problem.

Now, you are asking them to make a change, to switch to your product instead.  The price of your product isn't the only cost to the customer. There is a switching cost. Not just the real costs to switch, but the inferred costs as well. The cost associated with taking a chance on you, the risk that you'll actually deliver on what you say you will. That you'll be around in the future and be able to grow with them. That you'll be the partner they need.

Customers won't switch to a startup for 20% cheaper or 30% faster. You need to be 10x better.

In my next post, I'll share with you a crazy simple technique to help get past the surface an opportunity, and down to the 10x problem.