While my company has certainly influenced a lot of my thinking in this area, it is important to note that the contents below reflect my opinion and not that of my employer.
In many ways, the role of a Product Manager remains an enigma. Many companies have only begun inserting the role into their organizations in recent years, and very few companies incorporate the role correctly. As a result, the role of a Product Manager has been misconstrued and practiced incorrectly by many in the industry. I am fortunate to be working for a company in Intuit that has truly mastered the art of Product Management over the years, and I wish to share my learnings so that others may improve their craft as well. After all, better Product Managers leads to better products, and we all win when we have better products in our lives.
I also want to clarify that the type of Product Manager I will be describing is one that generally works in the technology space, but more specifically, works with software products.
What a Product Manager Is Not
Before diving into what a Product Manager is, I think it is important to start by laying out what a PM is not. I see many people label themselves as PM’s, but when they describe their role to me it is far from being that of a PM. I cringe when this happens, because it further contorts the perception of the role in the industry. Here are a list of incorrect PM descriptions I commonly encounter:
A Product Manager is NOT a Software Developer or Engineer
If you spend most of your day writing code or building product, then you are a developer/engineer not a PM. You should rarely (if ever) be doing these tasks. The reason is that there are far too many other tasks that you need to be doing with your time, and they will not get completed if a PM does not own them.
A Product Manager Is NOT a Designer
Similar to engineering or development, design is a separate function of its own. While it never hurts to churn out some high fidelity mock-ups as a PM, this is a space that should ideally be owned by experience designers (XD). In some small organizations there may be exceptions, however in an ideal scenario this work should not be owned exclusively by a PM.
A Product Manager Is NOT a Software Architect
The how is not decided by a PM. It never hurts to have the technical expertise to keep up and make suggestions, however the high-level software design choices and technical standards should be driven by someone who is completely dedicated to this area.
A Product Manager Is NOT an Analyst or a Consultant
If you’re not driving a team that’s building product, then you are not a PM. Period. While there may be stretches of time where you do hands off research and analysis (say in the discovery stages of a product), this should not be the nature of your work for extended periods of time.
A Product Manager Is NOT Any of These Things Either: Customer Support, Marketing, Project/Program Manager, Data Scientist, Sales, etc.
For various reasons, a Product Manager is not any of the things listed above either. While a solid PM will interact with many of these functions, no single one of these areas should be commanding the majority of your time in the long run.
One last example…
A Product Manager Is NOT an Authoritarian Figure
As a Product Manager you have no authority over other people. While you do drive decisions and the product vision, you can’t force others to follow it. As a PM, you must lead through influence. One of my biggest triggers is when I see a PM trying to lead with authority instead of influence. Attempting to strong-arm developers or designers into doing what you want will always lead to poor products in the long run.
So what is a Product Manager, Actually?
Now that we have a solid understanding of all of the things that a Product Manager is not, let’s deep dive into what a Product Manager actually is. I’ve heard a lot of people try to describe the role in different ways, but perhaps the best analogy I have heard is the following:
A Product Manager is the Quarterback of a product.
I’ve heard the phrase “CEO of the product” tossed around, but I think it is a poor analogy. A Product Manager does not have authoritative control over a team, similar to how a quarterback does not control the football team. She can’t bench any of her teammates if they don’t execute the plays she calls, only the coach can do that. Another major difference is that unlike CEO’s, Product Managers are down in the trenches executing with the team. It is not merely a strategic role for setting high-level vision, since you have to get your hands dirty on a daily basis.
Another correlation between a PM and a quarterback, is that you need to be able to work with and have the trust of the entire team. Each drive, a quarterback may interact with the running back, offensive line, tight ends, and wide-receivers. It is not an isolated position that only has one focus. Similarly, a PM must gain the trust of the entire team and be able to work cross-functionally in order to guarantee the success of a product.
Ultimately, a quarterback is responsible for calling plays based on the information they see in front of them, and are required to make quick decisions on the fly to ensure that a drive is successful. In a nutshell, that is what a product manager is expected to do for a product.
What Does a Product Manager Do?
I’m sure there are some people reading this that are rolling their eyes right now, so I want to conclude by giving a rundown of what a Product Manager actually does.
This isn’t a simple explanation, since a PM’s daily work activities can morph depending on what stage of the product development life cycle they are in. Generally speaking there are 3 different phases that PM’s will find themselves in: Discovery, Planning and Execution.
Before a team can begin building product, someone must go out and discover what needs to be built. A Product Manager is tasked with finding the most important problems and defining which of them should be solved.
Generally speaking, there are two sources that PM’s can use during the discovery phase: Data and Customers. If you already have an existing product and are looking to build out new features or capabilities, data can give you clues as to where the product opportunities will be. Great PM’s know how to use analytics tools to access fingertip data and how to enlist the support of data scientists or analytics teams for deeper data dives.
Often times data is too muddy or small in order to draw product conclusions. That is why it is important to supplement quantitative insights with feedback from customers. Customer interviews are a great way to gain qualitative feedback from current or prospective users. Product Managers should seek to to spend a significant amount of time with customers during the discovery phase of the product life cycle.
After pouring through data and spending time with customers, it is up to a Product Manager to help prioritize which products or features are worth pursuing. Unfortunately, all companies have limited time and resources, so it is essential that PM’s define the right priorities for the company to pursue.
The larger the company a PM operates in, the more involved the planning phase will be. Because there are so many moving pieces, it is not always as straight-forward as picking the most data or customer-backed projects to pursue. Organizations must factor in other internal projects, technical requirements, time of year, budgets, risk factors, etc.
Due to the importance of the planning stage, PM’s will most likely find themselves in numerous meetings with leadership and other relevant stakeholders. During these meetings PM’s will present their findings and suggestions for the road map, while working towards gaining approval from leadership. More often than not, these meetings are taking place while the rest of the team continues to execute on the current initiatives.
Outside of discovery and planning, a Product Manager will spend the majority of her time in the execution phase. I borrowed the graphic above from a fellow PM at Intuit, because I think it does a great job of laying out where a PM sits during the execution phase of a product.
Starting with the build section, a PM is expected to work closely with the development and design functions. At Intuit we refer to this as the “product triad”. A PM will complete a number of activities while working with the triad including: working with designers to craft mock ups, defining requirements for developers, tracking development processes , and running usability tests with customers. The build cycle should never really end for a product, since teams should constantly be seeking to improve their products.
Once a product is built, it is important that a PM works with marketing and design to ensure that the product gets the right exposure in the marketplace. A PM is important to this phase as he will understand what aspects of the product need to be emphasized in order to excite potential users.
Lastly, a PM should be in close contact with Support/Operations to ensure that the product is functioning well at all times. Service outages, crashes, and bugs are all issues that inevitably arise with any software product. A PM must closely track these issues and ensure that they do not get in the way of a great user experience.
Unlike many other functions, if a PM were to stop coming in to work one day, the team probably wouldn’t feel the effects right away. However, over time the lack of PM expertise would shine through in the products that are delivered to market.
The truth is that almost any person can be a Product Manager, however very few people can become great Product Managers. The job is 90% effort & discipline and 10% raw talent. If you think you have what it takes, I encourage you to try!
Bonus read: Good Product Manager/Bad Product Manager