Why Product Management?

Oct 16, 2020

Why does the product management function exist and what value can it provide a business? In its simplest form, product management exists to represent the needs of the customer. But what does that mean and how does that happen? This article intends to answer that question, by conducting a deep dive on product management.

I originally set off to write a primer to product management for a few of the first-time product managers on my team. I could have used a guide like this when I started my product management career several years ago. Call it paying forward.

First a few points around the content you're about to read...

Whether you're new to product management, a seasoned product professional, an aspiring Product Manager (PM) or just plain bored, I hope you enjoy this article. Also, this is not a quick read. To get through all of the content below in one sitting, block off an hour or two. I promise it'll be worth it!

This guide should be treated like a product, as it will continuously improve. We'd love your help with that. Does the guide help you? Do you feel something is missing? Confusing? Extraneous? Let's make it better together. Please - leave a comment below or email me.

This article is meant to be an introductory onboarding guide to the product job function. By no means will this article cover everything around the product function, as product can take on many forms depending on the company/team/industry. That said, this guide tries to hit the common denominators, those factors that are common across most PM roles.

In crafting this article, I polled many industry leaders and respected peers that I’ve had the honor of engaging with over the years. My goal was to not drown you in my opinions around product management, but instead lace in content (articles, videos, books) from respected, accomplished product leaders. Therefore, all of the linked articles, videos, etc. in this article should be considered critical elements of this article, not a reference. In fact, it is the underlying content that contain unique voices and key takeaways. Okay, phew. With that, let’s jump in!

First things first, what exactly is “Product Management”?

When I first began my Product career in 2014, I asked my manager what product management meant at our organization. He stared into the distance for a few seconds, deep in thought. Not sure if I was being terminated three days into my new career, I considered ducking under a table and crawling for the door. But eventually my manager came back down to Earth and delivered not just a definition, but the perfect definition. He said: “I expect the Product Manager to know which problem to solve and the best way to solve it.” As I think back on it, this simple definition effectively covers the two major responsibilities of the gig. It was - in my estimation - a spot-on explanation of what we do in product.

Now, let’s explore both parts of that definition.

“Which problem to solve”. At most organizations there are likely hundreds of problems to solve; so which do you focus on now? Which problem will the team defer to a later date? If you’re like most product managers, the resources that you have to solve problems are scarce, so choose wisely. The good news is that there are inputs for making this decision, it’s just a matter of seeking them out. So, you’ll likely depend on the insights and data from others in forming your decision on the problem selection. And as long as you’re good at sniffing out those inputs, you’ll be successful in this role. Oh and you’ll want to be focused. Don’t suffer from “Shiny object syndrome”, which is described here.

“How to solve it”. Great, you now know which problem to solve and why you’re solving it. Next, a good PM will know how to effectively solve it. This doesn’t mean the PM needs to code, know the right tech stack to deploy or even whether the problem solution requires building technology at all. But it’s up to the PM to understand how they will tackle the problem based on the correct inputs. And much like problem selection (mentioned above), it’s up to the PM to find the right inputs. Finally, it’s up to the PM to support the team who’s tasked with solving it.

What was one common denominator in the two paragraphs above? The inputs! As a PM, be prepared to doggedly, restlessly, tirelessly find inputs. The magic is stitching together the right data points, opinions, estimations, gut feelings, trends, etc. to make an informed, sound decision that mitigates risk and maximizes ROI (return on investment). It helps to be curious. It also helps to be collaborative as you’ll be working closely across the organization with various groups. To use a soccer analogy, you’ll be the midfielder in your org, racing around the field to offer help when necessary.

Here’s just a taste of how you might work with different teams across your organization.

Marketing. Understand competitive positioning, messaging, launch activity.
Sales. Understand willingness to pay, sales process and competitive outcomes.
Design. Develop the perfect customer experience around your product solution.
Support. Understand customer goals, support call drivers and customer journey discovery.
Engineering. Solve short-term and long term customer problems through technology.
Finance. Request funding or understand revenue projections for your product line.

Before diving more into the ‘why’ and the ‘how’, let’s take a quick step back and understand more around the role of a PM, as defined by other folks.

The holistic perspective of the PM is captured perfectly by Martin Erikkson in his article “What, Exactly, is a Product Manager?”. He states that Product sits at the intersection of business, technology and design, although depending on where you work and what you work on, the ratio may fluctuate at times.

I’ll share another seminal description of the PM. At most companies I’ve worked, I’ve had to learn how to connect to a printer, only so I could print out fresh copies of this handy article. Then, I hang it close by so that I can refer to it. It’s that good. Ben Horowitz - who’s most famous for his book “The Hard Thing About Hard Things” - wrote “Good Product Manager, Bad Product Manager” to describe which operating methods work best in this role. He warns at the beginning that his definition might not apply today, but I would disagree with that disclaimer. For the most part, more than 95% of the content here still rings true.

One quick item before we continue. Ben mentions that product managers aren’t Project Managers. This is really important. Speaking as someone who started off as a project manager, the two may sound the same but they’re actually quite different. The goal of the project manager is to execute a plan, communicating with key stakeholders along the way to guarantee success. If the project manager is responsible for the “when” and “who”, then the product manager must focus on the “why”, “what” and “how”.

A former coworker of mine once stated “at the end of the day, we’re all project managers.” That’s sort of true. Most goals aren’t going to be met tomorrow, thus require foresight and strategic planning of resources, similar to chess. In that sense, be prepared to do some project management but don’t believe that it’s your job. If you’re at a company that’s large, you’ll most likely have a project manager (often called a program manager) ushering your products to market. If you’re at a company on the other end of the spectrum, you may have to project manage your product to success. But that’s extra-curricular. Please never lose sight of your core responsibility: solving the right problems in the very best way. Both of these activities require a deep understanding of the customer and their pain points.

Which Problem to Solve

Before a product manager can decide “what” problem they’re looking to solve, they must decide “why” they’re choosing to solve it. What makes this problem more vital to the customer (or potential customer) than other problems? What is driving this decision? If you haven’t watched Simon Sinek's TED talk titled “the Golden Circle”, check it out. It’s lengthy (~18 minutes) but worth every second.

Adopting Sinek’s approach will undoubtedly help a PM craft and communicate a vision to key stakeholders, from Marketing to Sales to Engineering to customers to analysts.

In terms of prioritizing all of the why’s in an order that will be receptive to your organization, it’s helpful to have a scoring methodology that maps with your company’s KPI’s (key performance indicators) or corporate goals. If you’re not sure what a KPI is, check this article out. Note that defining KPI’s for the organization usually comes from the top down. If you don’t know, ask.

Another facet of prioritization is honing in on product outcomes. What outcomes within the product experience are you driving toward? Engagement? Utilization? Daily active usage? Teresa Torres provides a very good playbook here for measuring customer discovery to ensure that you're focused on the right outcomes.

Hopefully, your organization has a systemized process for curating the product roadmap. If not, there many different models a product team can adopt to rationalize and rank order what it should work on. No process is a perfect science, but having a consistent model will at least help explain why decisions were made and create a forum for discussion. For a very generic version of a roadmap scoring model, here’s one I put together. It’s overly simplistic, and will never be an exact science, but it should assist in directional prioritization.

Ultimately, roadmap scoring will come down to return on investment. If the team can work on a $100M revenue-generating initiative that only costs us $10, we’ll probably do that. Unless of course there’s a $200M opportunity that only costs $12. All of that said, how can one know that an initiative will draw millions of dollars? Isn’t it all just guesswork? There’s definitely guesswork involved, but discerning “willingness to pay” is perhaps the most critical skill in a successful product team’s arsenal. I carefully say “product team” because this exercise may not be your responsibility, but someone else in Research or Marketing. Nonetheless, it’s important to know that understanding your market’s willingness to pay for a product or service is vital to the success of your product. To brush up on the topic, I’d strongly suggest my all-time favorite book on product management “Monetizing Innovation”. It changed everything for me. If you don’t have the time to take on the full book, check out this interview with the author.

To summarize, staying close to the customer, being curious and collaborating with various sources will help achieve a commercially monetizable product for a very specific type of customer. This magic connection is often known as “product-market fit”. To understand product-market fit is to deeply understand your customer. What painpoints do they suffer from? What jobs do they have to do? What trends plague them today? What does the customer journey look like in terms of your business? Achieving product-market fit is probably one of the more difficult things to do for a company. Luckily, if you’re part of an established business, product-market fit is probably already established. Here’s a bit more around the elusive “product market fit”.

Of course, part of the art of product management is saying "no" ... a lot. Both good ideas and bad will have to be turned down to make room for more strategic initiatives. For a first time PM, communicating cross-functionally (in all directions of the org chart) is a skill worth growing. Julie Zhuo provides sound guidance in her article titled "No No No".

How to Solve the Problem

If you’re a first-time product manager, then there’s a very good chance you will be working more on the execution side of the product delivery and less time working on the market strategy side.

It’s critical to understand how your engineering partners might solve the problem. As a starting point, it’s helpful to have a base-level understanding of two of the more prominent delivery methodologies: “agile” and “waterfall”. This article does a nice job comparing the two approaches. Note: There are many other methodologies and even an infinite number of variations of these approaches. That said, knowing the basics will get you far enough before adapting to your company’s development cycle.

For the purpose of this article, I will focus on operating in an agile scrum environment, which is very prevalent in today’s technology landscape. Note that scrum is a flavor of agile.

Agile consists of responsibilities and events in order to operationalize product development. To receive an introductory understanding of the agile methodology, this twelve minute video breaks down the various principles.

So what does the product manager actually do as part of agile? Depending on your organizational structure, it means you’ll be interacting mostly with an engineering team, probably as a core member of a “scrum” team. (This role is sometimes labeled as “product owner”.) It’s an essential role to the team and responsibilities are as follows:

Clearly define the “why” around what the team is building.
Manage and rank-order a “backlog” of requirements, features, bugs for the team.
Clearly define the “what”, being very specific around the requirements.
Help answer any clarifying questions around specifications as the team develops.
Craft and communicate the bigger picture for what the team is working toward (“the vision”). Note: this may also require managing a product roadmap.

In a typical agile shop, the product manager will be asked to submit user stories. A user story follows a very simple format that outlines who is performing the action or benefitting from the feature, what the feature is and why it exists. Below is a sample user story for someone creating a playlist on spotify.

As a listener, I can create a new playlist on the spotify platform so that I can categorize music for listening and sharing purposes.

A user story should serve as a feature request for engineers, designers and others involved in the development process to understand the desired feature. Typically a user story will be accompanied by “acceptance criteria”. Acceptance criteria add technical detail to the story, providing any limitations or clarifying details around how the feature should work. One of the more helpful assets I’ve come across around writing user stories is the INVEST framework, which is adequately described here.

Should you modify your communication style in how you work with engineers and designers? Potentially, but that’s based on the needs of the team. This quick, simple article about seven words to avoid when working with engineers and designers has always been a favorite of mine. In fact, I’d employ this approach with most everyone you interact with.

Probably the most important aspect of product management in terms of agile software development is the nature in which large scale features are built. In a waterfall process, the full feature is the goal and steps along the way are simply milestones in terms of reaching the end result. In the diagram below, it is the process on the top row. Conversely, agile development is providing customer value in increments so that feedback can be gathered along the way and customers can begin realizing value earlier. This process is diagrammed on the bottom row.

Much like the debate around waterfall vs. agile, there are scenarios where each method above is appropriate. However, the incremental development process of agile (the bottom diagram) allows for frequent engagement with the customer along the development path. This provides an opportunity to adjust your product planning accordingly. Therefore, there’s a very good chance that you’ll be asked to define the stages, or at the very least the first stage which is often referred to as the “MVP”, or “minimum viable product”. Simply put, the MVP is the smallest version of the product that can begin to provide value for the customer. In the example above, the MVP is the skateboard. Sure, it may not be able to transport you with the press of a pedal and the skateboard won’t be great in inclement weather, but it has value as opposed to the alternative, walking. On the top row, a frame has been built for wheels, but that machine alone won’t get you far.

Know Your Customers

Before we finish up, I’d recommend one activity over all others in being successful in product management: engaging with customers. The closer you stay to your customer, the more you’ll understand their problems. You’ll receive valuable feedback around potential solutions, from design to beta testing what the team has built. Once you’ve provided the skateboard, customers who confide in you will provide honest feedback and help you craft the product to perfection. It’s a surefire way to also gain the trust of your peers as they know that you’re the best person to represent the customer in decision-making due to the close customer relationships you’ve invested in.

That's it for now. Best of luck in your product management career!

Further Reading

As mentioned, I polled dozens of folks in the product field as part of assembling this article. They each recommended helpful content but not all of it neatly fit into the article. Below is a list of other articles that will be helpful to you as you grow your product management career.

Books