Sometimes you’ll get a generic answer like “A Product Manager is the CEO of the product” or “The Product Manager is the voice of the user” or “The Product Manager is the hub between all our teams.” My favorite answer is “I have no idea, but they always seem busy!”
Product Management is a lot of different things to a lot of different people. What if I changed the question to “What is a PM?” Now things get even more confusing. Now we have to consider Program and Project Managers along with Product Managers. Then there are Technical Product Managers and Product Marketing Managers. There are so many titles out there it is a challenge to know how they differ.
With such a large variety of definitions of Product Management, trying to identify a good one can be challenging. Ben Horowitz answered that question 15 years ago in Good Product Manager / Bad Product Manager, but 15 years is a long time, so let’s revisit the question.
The History
According to Martin Eriksson’s article titled The History and Evolution of Product Management, you’ll find Product Management’s roots in the Consumer Packaged Goods (CPG) world in the 1930s. Procter & Gamble kicked off this role when they created (what today is known as) Brand Management roles. Their goal was to have people that would have full responsibility for a brand from sales, products, advertising, and promotions. Brand Managers (as they do today) owned outbound marketing, packaging, price, promotion and were responsible for sales and revenue.
HP then took this to the next step by trying to push decision making closer to the customer. This forced the Product Manager to channel the user/customer and be their advocates internally. They organized into product groups that allowed a Product Manager to become an expert on a specific set of customers. These groups were given autonomy in developing, manufacturing and marketing their products.
Fast forward to the technology age and you found companies trying to invent markets based on technology innovations. It wasn’t always a given that you had an established customer base that the PM could channel. Along with creating a new market, technology lowered the barrier to entry for the competition, moving the focus towards product development and matching roadmaps to customer needs vs the packaging/advertising side of things.
Today, any and all combinations of marketing, user perspective, development strategy and development management fall under the product management umbrella. With such a wide range of responsibilities, it’s no wonder there is confusion defining the Product Manager role.
The Present
It’s obvious that with such a breadth of responsibilities, a PM needs a variety of skills to be successful. Let’s categorize these skills to add structure to the PM role.
Product Strategy is the concept of channeling the user, knowing the market and managing finances in order to put together a vision and strategy for the product they are managing. This includes things like market research, user profiling, value mapping and defining business plans/models. As more and more products interact with each other this also includes defining a holistic experience focused ecosystem of products.
Product Definition is where the rubber meets the road between user needs and product development. This is where you create user requirements, manage release roadmaps and figure out how your product should actually work for your specific user group.
Product Execution is getting the product built. In an Agile world, this is taking the roadmap and breaking the features down into epics and sprints. Managing the sprint ceremonies and making sure you end up with a high-quality product.
Product Launch is the outbound marketing side of managing a product. The 4Ps of marketing (product, price, place, and promotion), roll out strategies, target markets, etc. In today’s app-based world, this includes in-depth knowledge of the major app stores and how to navigate your app through there.
The breadth of these responsibilities makes it impossible for a single person to lead all of these and still maintain any semblance of sanity. This is why companies often have specialty groups to own some of these and a major portion of a PM’s job is cross-functional leadership. Obvious examples include the design and engineering departments. Other groups could be PR departments and ad agencies for marketing material, market research departments for user background info, finance departments for margin and pricing input, etc.
Companies also try to limit an individual’s breadth of responsibilities by using different job titles. For example, Brand Managers, Product Marketing Managers, Technical Product Managers, Scrum Masters, Project Managers, and Program Managers all have a subset of the responsibilities I’ve described above (see Figure 1).
The Job
OK, now that we have an idea of what a PM does, what makes a good PM?
Is a good PM one that excels at strategy, after all strategy encompasses user needs and profitability? How about execution? Without execution, there is no product to deliver to the user. Perhaps its definition and launch, defining the right product and launching it well will bring in profits, right? All great thoughts, but no.
OK, let’s try it from the other way around, a good PM has to do all phases well! OK, unless you’re Steve Jobs, that’s likely not going to be you.
So what’s the answer?
- A good PM recognizes that nothing is or will be perfect! That includes him/herself, the teams around them, the user research that is going to be conducted, the final product that will be launched, etc. Good Product Managers understand when good enough is enough to push forward. Bad Product Managers constantly delay because just a little bit more time will resolve XYZ. Good PMs are comfortable working with imperfect information and filling in the blanks with educated assumptions. Bad PMs get stuck in analysis paralysis, needing to research every unknown before making progress.
- A good PM recognizes the strengths and weaknesses of the team around them and leverage the strengths and fill in the gaps where expertise lacks. A good PM will focus where focus is needed and use the help around them to shoulder the load where possible. A bad PM will be in the weeds of every single detail and micromanage even their best teams. A good PM will share an appropriate level of detail with their teams to keep them productive and motivated. A bad PM shares everything with everyone, bombarding overwhelmed teams with too much information, or shares nothing, keeping everyone in the dark and demoralizing the team.
- A good PM constantly looks ahead and removes hurdles before the team runs into them. A good PM will focus on unblocking the next set of challenges. A bad PM is constantly chasing down current blockers to allow the team to keep working. A good PM learns from a team miss and adjusts to avoid similar failures in the future. A bad PM wants to know who failed and expects them to avoid failing in the future. A good PM looks for solutions to risks, resource, timeline and technology constraints. A bad PM makes excuses for why something cannot be done.
The Example
One of the best examples of this I’ve seen was early in my PM career. My boss was in charge of a product ecosystem of TV everywhere (watch TV on your phone!) applications, which included web, iOS, and Android apps. The apps had the ability to watch live, recorded and on-demand TV, browse your TV guide and set recordings. He had a team of us PMs owning the individual apps in the family. Every day, you could see him utilizing these three traits in driving each app forward.
One of the things he would always harp on us make a plan based on the information you had and run with it. Making a mistake was OK, but doing nothing was not. With that philosophy, he would allow us PMs to come up with a hypothesis based on what we knew (analytics tells us X, competitive analysis tells us Y, users at a tradeshow all mentioned Z) and then execute on it. If the thinking was sound, he didn’t focus on whether the conclusion was exactly the same as his or not. He knew that we only had partial data, so multiple conclusions could be valid and instead of trying to find a perfect solution, his goal was to find a solution that was better than today and to go try it in the real world. We could always further iterate on it if needed, or do an A/B test if we needed more validation.
This allowed us to try a bunch of innovations quickly without burdening ourselves with making sure it was the perfect innovation to do. Some were well received (transfer recordings, auto-stream on launch) and others not so much (web-based pop-out viewer), but we were always ahead of the trend on TV everywhere apps.
Each app team had their own strengths and weaknesses, so with each of us, his involvement would focus on different aspects of the build. With the web app, the quality was a concern as features were being implemented, but things would easily break. So he would spend time testing and hammering on the internal builds and reporting bugs for that team. With the iOS product, he was getting a high-quality product with limited bugs, but the design and usability were lacking because it wasn’t taking advantage of some iOS native features. So he spent time with that PM and design team trying to get a better design and product definition in place. I owned the Android app and had a handle on the definition and quality of my product. So he focused on being the voice of the user and being a pain in my butt for making sure every detail was perfect. The speed and smoothness of scrolling on the TV guide was a point of focus for him because users often knew exactly where they wanted to scroll and he knew this would be a point of differentiation.
Again, he would take on a different role with each product, but it was exactly what that team and product needed to deliver the best product possible for their users.
With all of us, he would make sure we were always looking one step ahead. Did we have all of our launch criteria and marketing lined up and ready? Were our integration parties ready for our scale? Was the QA team ready to validate? New closed captioning requirements were just passed, have we prioritized work to stay compliant? Always ensuring that our focus was not solely on what was needed today, but what was coming down the road tomorrow or in the future.
All of this resulted in us releasing apps that consistently received 4+ stars in both the Apple App Store and Google Play Store and consistently were finalists for CES Best of Show awards.
The Punchline
At the end of the day, all the responsibilities that need to be done well to define, build and deliver a solid product to the market. However, it’s ridiculous to think one person can be an expert on all the tasks that need to be done. A successful PM has to be good at 3 things:
- Successfully work with imperfection
- Embrace their teams’ strengths and support the weaknesses
- Always be looking ahead for the next roadblock
With these in place, a good PM should be able to tackle any problem thrown at them.
