How to be a GREAT Product Manager

I originally wrote the following back in the summer of 2007 (Yes 2007. That’s not a typo). I had just started blogging a few months earlier. It was one of the first blog posts I wrote that got a lot visibility.

This post was originally written in six parts, but I think it flows well as a single longer blog post. The advice and observations have aged fairly well, and still offer useful insights. So here it is, with a few minor edits compared to the original. 2007 was 12 years ago. How long ago was that? Slack, Uber & AirBnB had not even been founded. Twitter was barely a year old and Facebook had about 40 million users. Yes. it was that long ago. :-).

Also published at https://www.transformationlabs.io on April 13, 2019.

There are a lot of good posts out on the Web about hiring product managers. One of the most popular ones that I’ve seen is entitled “How to Hire a Product Manager”. In it, Ken Norton writes that hiring managers should do or look for the following:

1. Hire all the smart people
2. Strong technical background
3. “Spidey-sense” product instincts and creativity
4. Leadership that’s earned
5. Ability to channel multiple points-of-view
6. Give me someone who’s shipped something

In summary, hiring managers should look for smart, technical and creative people with good instincts and leadership skills, who can assimilate multiple inputs and who ideally have been product managers before.

To put it even more succinctly, if you’re looking to hire product managers, then hire good people who’ve been successful product managers before.

OK, I may be need to give Ken some slack, as he does explain each of the points in good detail and provides sample questions to ask prospective candidates. None of the questions are too tough though, assuming the candidate has a decent skill set and done some reasonable level of preparation.

So that’s how you hire a great PM.

But, how can you be a great PM?

To answer that question, the following is a set of analogues to Ken’s list.

1. Don’t just sound smart, act smart and be smart

The vast majority of product managers are smart and focused. Or to put it another way: only a very small number of PMs I’ve encountered have been dimwits. But then honestly, in any group, there are always a few aren’t there?

In general, there is no shortage of brain power in the Product Management community. But the real issue is not sheer intellectual horsepower or the ability to articulate what should be done, but the capacity to turn all that potential into a kinetic form that does the right thing.

Nothing shreds the credibility of a PM more than the perception — let me repeat — the perception that he/she talks the talk but can’t walk the walk.

It doesn’t matter how much of anything you do. If you are not viewed as someone who rolls up their sleeves and digs into details, you’re fodder for the dart board.

If a development manager asks you to clarify a requirement, and you can’t give a sufficient answer, don’t try to hum and haw your way through it.

Tell them you need to research that question a bit more, then get right on it and get back with a clear and well-reasoned answer in short order.

On the flip-side, when it comes to providing information, know when enough is enough. There’s no reason to writeup a huge set of requirements when, because of development headcount or time constraints, only a few of those requirements have any chance of getting into the next release.

Who are you trying to impress? And if you didn’t know that only a few requirements could make it into the next release, you have much larger problem to deal with.

2. Be technical, without becoming a technologist

Product Managers need to focus on the “what”, and not the “how”. When working with Engineering, a PM needs to define what needs to be done to make the product better, faster, stronger, cheaper etc.

The “how” of doing those things is left to Engineering to figure out. OK, it’s not exactly that simple. Sometimes Product Managers have to worry about the how, but usually in the context of an implementation discussion with Engineering or resource allocations with Sr. Management.

But, thinking about the how during the requirements phase can be fatal for Product Managers. Don’t fall into the trap of putting yourself in engineering’s shoes until and unless it is absolutely necessary.

I’ve seen the following happen with technically savvy PMs. They decide (prematurely) that a requirement won’t be presented because of a (perceived) technical constraint in the current code base. Or that during a requirements review, an important requirement becomes less important because technical objections are raised by Engineering.

My question is:

Why would you, the Product Manager, even worry about potential technical issues, IF the requirement is sufficiently important?

The requirement should be clear and compelling. Challenge the engineering team to come up with a solution, or work with them if your guidance is needed, but don’t give in simply because of technical reasons.

Market and customer needs, not engineering constraints should be driving requirements.

But given that many product managers are themselves former engineers, or come from highly technical backgrounds, it can be difficult to stop from crossing the border into “the Implementation Zone”. Once that happens, if you don’t catch yourself, you’re doomed, because it can be difficult to cross back.

I worked with a product manager, fairly young and much more technical than me, who would not only talk about the requirements, but then debate potential solutions in a requirements review meeting.

Given that he had a technical background and didn’t spend much time talking to customers/partners/prospects etc., what else could he provide? Needless to say, his tenure was short-lived.

When it comes to implementation, if a requirement is important enough, but you face resource or technology constraints, most rational organizations will figure out how to do the right thing as long as you present the case sufficiently.

I say “rational organizations” because not all organizations are rational; at least not from a business perspective, and will not necessarily do what’s right for the market. If that is the case in your company, then it may be time to find another employer, so can advance in your career and your energies and knowledge can be put to good use.

3. “Spidey-sense” instincts are good, hard data is way better

For a sport known for it’s statistics, major league baseball has always been a game managed by instinct. Managers viewed the situation, discussed strategy and made calls on batting order, pitching changes, fielding positions and more. This was the norm, until Billy Beanebecame manager of the Oakland Athletics in the late 1990s and literally changed fundamental assumptions of how teams should be managed. The story is described in detail in the book .

In short, Beane started using hard metrics in virtually all aspects of managing the team, from scouting for and recruiting undervalued players to deciding on what plays to run for any given situation of the game.

The result: a great winning record with one of the lowest payrolls in baseball.

For example, in 2002, the Athletics tied the mighty Yankees for most wins in the American League. Both teams had 103 wins that season. The high-flying Yankees had a total payroll of $126M that year. The Athletics had a payroll of only $41M. i.e. only 1/3 that of the Yankees.

Today many teams have picked up on Beane’s success and in fact the techniques used by Beane in baseball are spreading to other professional sports.

Software product management today is very much like baseball was before Billy Beane. Even though we have the ability to use metrics to optimize outcomes, we rarely collect, assimilate and mine hard analytical data in making product direction and functionality decisions.

Granted, it’s not always easy to get statistically valid sets of this data. In a startup or small company with few customers, the sample size of the data set may be too small to be meaningful.

But that shouldn’t stop us for trying where possible. In larger companies with larger customer bases and more resources, using analytic data to support and drive product decisions should be the norm. But sadly that’s not the case.

If Product Management is truly as strategic and important as we claim it is, then why do we enact it in ways that make it look adhoc and haphazard?

I can’t tell you how many times I’ve seen major product decisions made based on empirical evidence and personal opinions. Statements like “This feels like the right direction to go.” are spoken far too often in strategic planning meetings.

And let’s be very clear, there are hard costs to these decisions in terms of engineering investment, marketing campaigns, sales efforts, support calls etc. This of course does not include lost, or at best delayed, revenue because of incorrect prioritization of functionality.

Why is it that we hold groups such as engineering, marketing and sales to a higher standard than we hold ourselves?

If development teams planned their schedule on instinct, or marketing teams managed their programs the same way, or sales teams projected their target using gut feel, we’d replace the leaders of those teams instantly.

But when it comes to making product decisions, many of them are made without any significant effort to collect and analyze hard data. There are many excuses that are given for this lack of analytical acumen, but the fact that others aren’t asking you explicitly for hard data is not an excuse not to get it.

Set up a process to get the hard data that is needed to support or justify decisions. Not only will others be pleasantly surprised, but they’ll also have a hard time refuting your recommendations.

4. The Four Cs of leadership

Product managers need to be leaders; a truism no doubt. But what does being a leader really mean, and how can a product manager be a great leader? Let’s start by talking a bit about authority and responsibility. Both are words related to leadership.

Responsibility: n. a form of trustworthiness; the trait of being answerable to someone for something or being responsible for one’s conduct; e.g. “she holds a position of great responsibility”.

Authority: n. the power or right to give orders, take actions or make decisions; e.g “he has the authority to issue warrants”.

Responsibility is both a trust and a duty. Authority is something you are given or possess related to your responsibilities.

The two are clearly inter-related. If you have the responsibilityto do something (e.g. uphold the law), you are given the authority to do the things that need to be done to deliver on your responsibility (e.g. issue warrants, make arrests etc.)

In cases such as law enforcement, both the responsibility and the authority are explicitly defined. In the case of many business functions, particularly matrix functions such as product management, the responsibilities may be explicit, but the authority is implicit in the role. It’s up to the individual product manager to understand that and not get caught up by the lack of a hierarchical reporting structure with other teams.

In an early PM job, after a frustrating product strategy meeting with senior management, one of my fellow product managers let out the now famous line:

“Product Management: All of the responsibility and none of the authority!”

It was the first time I’d ever heard that line, and that afternoon, I couldn’t have agreed with him more. I had faced my own battles with the CEO over product direction issues.

The CEO had stopped me on the first slide of my product roadmap presentation. I had a quote from a well-known industry analyst whose services our company had paid for. The CEO said he disagreed with that quote can called the analyst “ an idiot in a monkey suit “. I knew right away it was going to be a rough meeting.

Another CEO would regularly play a game called that I called “ If you can guess what decision I’ve already made about your product, then we’ll be in agreement on that issue “. In both of these scenarios, it’s hard to feel empowered.

But, in the intervening years, I’ve learned a little bit about both responsibility and authority and don’t agree with that line anymore. The fact is that, regardless of whether you have a CEO (and/or management team) that “gets it” or not, you’ve got a job to do.

So what can you do to use the authority that you do have and be the leader that you must be?

Keep the four Cs of leadership in mind.

Credibility

Leadership begins with credibility.

credibility:n. the quality of being believable or trustworthy.

If people aren’t willing to believe you and trust what you say, then there is no way you’ll be given authority to do anything significant.

How do you become credible?

For a Product Manager, the best way is to be viewed as having the most knowledge in your organization of what is needed to help make your product successful.

That is what everyone is expecting of you (you are the product manager!), and if you can exceed those expectations, you will have more than enough credibility when you speak with people. Some things to put on your “How do I gain credibility?” checklist are:

1. Know your product as well as your users know it
2. Have deep understanding of customer needs and market dynamics through ongoing communication, interaction and research.
3. Collect more hard data about customer usage, issues and goals than your peers
4. Understand the needs and dependencies of your internal teams (sales, support, marketing, engineering) and factor those into your decisions
5. Help those others teams succeed in their efforts to make your product successful

Gaining credibility takes time. You’ll have a bit of a grace period when you start a new position, so use that period to get up to speed. Then, continue to work at it and ensure that once you have credibility, you don’t lose it.

Commitment

The second C of Leadership is commitment. The definition I like is:

commitment:n. the act of binding oneself (intellectually or emotionally) to a course of action

Look at that definition closely. The words are very specific: “ The act of binding oneself…” emphasis on “binding”. It’s a powerful word. It’s not a loose association with something, but a tight attachment to it.

You must demonstrate commitment to your product’s success. In your current job as a Product Manager, have you bound yourself to the success of your product? Or are you just going through the motions and simply doing “the job”?

People want to see a product manager truly care about product success and figuring out what is right and best for your products. If they don’t see that commitment to success, you will quickly lose credibility.

Communication

The third C of Leadership is communication.

communication: n. the art and technique of using words effectively to impart information or ideas.

No amount of credibility can be retained if communication barriers exist between a leader and her followers. Leaders must be able to communicate their thoughts, ideas, visions and strategies clearly and succinctly, and in such a way that those listening are inspired to want to be part of the plans the leader is proposing.

Note that communication is both an art and a technique. Simply conveying information in documents or in rote form is not sufficient to be deemed communication.

People need to understand what you are communicating to them and realize why it is important to listen to you.

Put yourself in their position and think about what they need from you. Convey information in forms that those receiving it from you find valuable. This may mean a bit of extra work for you initially — not everyone needs (or wants) to read requirements documents — but once people see you understand their frame of reference, they’ll see the value in understanding your communications.

Keep in mind, people are bombarded with information daily, and they triage what they read and what they put aside. Make sure your information gets top priority by making it easy for them to consume.

Once you have credibility with your peers, show commitment to your product, and communicate vision and details clearly, you have the hallmarks of being a leader. But what can truly distinguish a good product manager from a great one is courage.

Courage

Welcome to the 4th and most challenging of the 4 Cs.

Courage n. to act in accordance with one’s beliefs, esp. in spite of criticism. to have the courage of one’s conviction

The difference between a leader and a manager is the leader’s ability to take risks, blaze new trails, and have people follow him or her down those trails. Leaders can be praised when they succeed, but will be criticized roundly when they don’t.

As a product manager, you are an agent of positive change in your company. Stand up for what you believe is right, but do your homework first and be able to support your positions confidently. Not everyone will take to your recommendations or initiatives, even if you are correct. But, over time change can happen, even in the most conservative or difficult environments.

In companies that are open to change, it is a continuous process. In other companies, it comes in the form of a revolution. Regardless of the type of company you work in, if you want to rise to be viewed as a great leader, then have the courage to take, as Frost put it so well, The Road Not Taken.

The last stanza of Robert Frost’s poem sums things up nicely in my mind.

I shall be telling this with a sigh
Somewhere ages and ages hence;
Two roads diverged in a wood and I-
I took the one less traveled by,
And that has made all the difference.

5. Be an integrator, translator and communicator. Don’t be a terminator

I’m sure you’ve heard the phrase that Product Managers are “the hub of the wheel”. I really don’t like that line. Who wants to be the hub of any wheel? That’s like saying someone is the hinge of the door or the latch of the hood. Boooring! And not true.

Product Managers are collectors, analyzers and dispensers of information. They are routers of information flow. And being a great product manager means understanding how to optimize the information flow so that other teams in your company who are directly or indirectly dependent on you for information get it in a timely manner and in a form they can understand and use.

The following image is a coarse example of the major communication paths that exists in a software company. The blue are internal teams and the red are external.

I say “coarse example”, because it really only represents a high-level view of how information flows. It’s meant to represent (not literally define) major communication flow. Not all links in the diagram contain the same amount of information flow; not all nodes contribute as much information as they receive; and to keep the diagram from becoming cluttered, a number of links that rightfully should be shown are not.

I call these communication pathways the Information Supply Chain. And as a Product Manager, you are directly or indirectly responsible for a lot of the product related information that flows throughout your organization.

How many times have you been asked if certain functionality is in an upcoming release? Or when a particular release is coming out? Or the details of a beta program? Or whether any pricing or packaging changes are being made to address market needs?

People are asking these questions because they are making decisions and need information to decide wisely. You can have a significant positive impact on those teams if you understand what information people need, when they need it, and in what form they need it?

If you can do that for them, they’ll be able to make educated decisions sooner, streamline their work and be more effective. Deliver meager, late or difficult to understand information, and the opposite occurs. There is a real top-line impact to poor information flow in a company.

If you really want be analytic about mapping out the flow, you can do that. You need to look at all the stages of the product development cycle, from conception to completion to launch and beyond, and map out what information different groups need and when they need it. One way to represent it is via a heatmap that may end up looking something like this.

The coloured cells represent areas where communication happens during the development cycle. The deeper the colour, or higher the number (from 1–3 in this case), then the more activity and information flow that happens.

As you can see, Product Management is deeply involved in the information flow through all phases of the development cycle, but most heavily early on and in the middle.

Marketing and Sales, for example, really start toward the middle and have heavy information flow from the launch stages onward.

By understanding this, you can determine what information you need to produce and deliver to those groups to optimize their activities and decisions. Keep in mind that this is not solely a task for Product Management. Ideally all groups in the company use this analysis to optimize their communications.

But, if you want to apply an 80/20 rule (80% impact for 20% effort), then teams like Product Management and Product Marketing must be the first ones to optimize their information flow to other downstream groups.

As technology workers, we exist in an information economy. And just like the manufacturing world, where materials, parts and inventory requirements are optimized for efficiency and minimizing costs, information needs can be understood and delivery processes optimized for greater efficiencies. And because of our role in defining product direction and driving strategy, Product Managers can play a key role in optimizing the Information Supply Chain. The question is, are you up to the task?

6. Own the product from conception to completion and beyond

In my early product management jobs, I focused a lot on the process of product management. A CEO of a startup I worked for told me that my approach to product management was “very academic” in nature.

He viewed himself as a “get it done by any means necessary” entrepreneur, while I viewed myself as a “ get it done right” product manager.

The startup was a very sales/deal driven company, as many startups tend to be. Putting product management in place in such an organization is not easy. But having a process focus is very important for a product manager. Every other function, from sales to marketing to development to finance to HR implement processes.

But because product managers work across these functional units, people don’t realize or understand that even in small companies there must be a repeatable and scalable process to conceive, research, define, develop, test, launch, promote, sell, support and sustain winning products! 🙂

And while product managers have a direct responsibility in some of these 10 distinct areas and indirect responsibility in others, PMs absolutely have a core responsibility to oversee and align the activities of other teams across this entire process.

I’m not talking about managing those people directly or telling them what they should do. I’m assuming people know how to do their respective jobs. What I am saying is that if you want to be a great Product Manager, take ownership (not necessarily full control) over the process and lead the teams in alignment through it.

Get alignment from the very beginning

From the start, as you (and/or your PM team) are doing your research, clearly define the context and vocabulary necessary to effectively convey the research results to the intended audiences.

This vocabulary, whether related to personae/roles, business functions, consumer needs, product architecture or functionality or something else, will become key to bringing everyone into the same frame of reference.

This is important because it helps to minimize misinterpretations and miscommunication during the product development and launch process. If people aren’t aligned early on in the process, you are likely to see confusion or conflict later on as requirements are implemented incorrectly or with unacceptable constraints.

An example of missing alignment

As an example, before becoming a product manager, I worked at a company that was developing a fairly sophisticated reporting and visualization framework for business and financial data.

One of the engineers was tasked with the requirement to create a flexible means to allow users to format and display numeric and character text (including time, date and multiple international currency values) dynamically for display in pop-up boxes when on-screen entities were moused-over. Are you with me?

He went off, did some research and without a lot of internal discussion, implemented functionality to address the requirement. I was responsible for documenting the functionality. When I saw what he had developed, I was stunned. He had created a flexible — but incredibly complicated — formatting subsystem. Yes, it could do everything and more relative to the requirement, but I’m certain only the engineer and a few other technical people could actually use it.

The documentation alone for this functionality took 60 pages (out of a 600 page reference manual). When people in the company saw how complex it was, the functionality was removed from the product.

What went wrong? A number of things including lack of internal communication, lack of oversight, and lack of involvement from the product manager.

Where was he during all this? I don’t recall exactly, but I think he was out, working with sales and trying to close some deals. Helping sales is good-don’t get me wrong-but not when it comes at the expense of the product being built.

Get your hands good and dirty

During the development cycle, work to keep other teams such as marketing, product marketing, sales, sales consulting, support, channels, alliances and professional services informed and educated on the development status and product functionality. For smaller consumer products or websites, this may not be a difficult task, but for larger enterprise or data center software, this can be a daunting task.

For a major release of a large product, a development cycle will last 12 months or more. There are many decisions that are made during this cycle that need to be conveyed to downstream teams to ensure they can plan ahead for the impact of the new release.

Don’t stop until adoption is clear

Once the product is released, you need to stay focused on the product. You can’t let up and simply go start gathering requirements for the next release. Stay engaged with early customers, partners and the customer facing teams such as sales and professional services. If early customers are upgrading to the new release from a previous version, track those upgrades and follow up with the customers to see how the upgrade went and what comments they have about the new release.

Join members of the sales team on customer and prospect calls and listen to how they are describing and selling the new release, and what the reaction is from the audiences.

• Are the salespeople on message?
• Are the sales consultants adequately trained?
• Do the demos hit on target?
• Is the market need that you researched and identified (oh so long ago), still as relevant and critical as it was back then?

These questions (as well as others) should be the focus of product managers (and product marketers) after product launch.

All too often, I’ve seen people work on a release, have it launch, and then essentially forget about it as they start focusing on the next release. Big mistake. If sales is struggling to sell the product, as the Product Manager, you need to take the challenge on and work to identify and remove the barriers.

Don’t look at it as someone else’s job because it isn’t. Would a CEO let a struggling VP of Sales flounder for a quarter or two? Absolutely not. As a PM, take your cues from the CEO and within reason, do what a CEO would do. Don’t wait for others to tell you what needs to be done. Take charge of your product, make sure it is built right and then ensure it trounces the competition.

Some last words.

There’s probably a lot more to write on being a great product manager. Aside from rising to the challenge on your own, there can be organizational, political or business hurdles hindering your path to success. The role of a product manager in a larger company is very different from the same role in a startup.

It can be very hard to make a big imprint in a larger company where strategy and major product direction decisions are often made at the senior management level, with product managers being tasked to execute on those decisions. In a startup, you’re likely understaffed with more to do than time to do it.

In either case, you can still rise above the noise and be effective.

Focus on the key objectives you need to deliver and ensure those get done in a timely manner.

Don’t be a “just-in-time” product manager. It leaves you no wiggle room if you meet unexpected delays and makes people depending on your rather nervous.

Beyond the key objectives, keep watch for places where you can help improve how the organizations builds, markets, sells and supports your products. If you notice that the evaluation process for your software is cumbersome and this is impacting sales, help identify and define the solution.

If you see that sales consultants aren’t adequately trained then work to get them the help they need. If you notice that customers are getting frustrated with the quality of support (despite what the results of the 3rd party customer satisfaction survey says), raise it with Support management or other executives. The point here is that beyond the literal product(s) you manage, identify ways to make the company better and be part of the solution team.

Be wary of internal power structures and political circles. It is far too easy to get encumbered by company politics or suppressed by hostile power structures. This is more often the case in larger companies, particularly those who’ve grown quickly and where many of the original or early employees have risen to management positions.

Dealing with and navigating internal power structures could be the subject of a series of blog postings (hmmmm), but all I will say for now is tread carefully and knowingly when in enemy territory.

In the end, there is no magic recipe to ensure you are a successful product manager. It takes a lot of effort, insight and thinking. But if you keep those 6 rules in mind and try to apply them wherever possible, you’ll certainly increase your chances of success.

Saeed

A little feedback please

Since you’ve read this far, why not give me a little anonymous feedback on the article. 3 short questions, it’ll only take a minute, and it’ll put a smile on my face. What could be better than that?

==>Click here<==

About the Author

Saeed Khan is a founder of Transformation Labs. He is a consultant and helps companies improve their products and product organizations to accelerate product success. He speaks regularly at industry events on the topic of product management and product leadership. You can contact him via Twitter @saeedwkhan or via the Contact Us page on Transformation Labs website.