Most descriptions of the product management role tend to either be overly vague (you are responsible for the product) or overly specific (you write product specifications). Or perhaps it will be described as "the intersection of business, technology, and user experience." Unfortunately, none of these definitions are particularly effective in helping people become great product managers. In this essay, I've tried to coalesce the best ideas from Adam Nash, Bubba Murarka, Elad Gil, Marty Cagan, and Sachin Rekhi into one comprehensive guide.

A lot of it is copy-and-pasted or transcribed from talks, but hopefully I added some value by synthesizing the ideas in a single document. Please see the Sources section at the bottom for links to the individual resources.

What is Product Management?

At a high level, product managers help companies define, build, and launch new products. Marty Cagan argues that product managers are ultimately responsible for ensuring that what gets built is both valuable and viable. This makes strong product managers force multipliers that can help cross-functional teams of great engineers and designers do their best work. Bad product managers, on the other hand, can lead to the wrong product being built.

Marty outlines four key skills needed when solving for value and viability:

1. Deep Knowledge of the Users and Customers. The product manager needs to be the acknowledged expert on the customer. This means both quantitative knowledge (understanding what customers are actually doing), and qualitative knowledge (understanding why users and customers behave the way they do). This is what informs the many decisions that must be made. Without this deep customer knowledge, the product manager is just guessing.

2. Deep Knowledge of the Data. The product manager needs to be an expert on how the product is being used. They must closely track usage and sales--and how the metrics are changing over time. The product manager may have a data analyst or data scientist to assist, but this knowledge is not something that can be delegated.

3. Deep Knowledge of the Business. This means understanding the needs of the various stakeholders, the business model, the dynamics of the ecosystem the product operates in, and certainly the economics of the product. Economics of the product includes how it is marketed, how it is sold, how it generates revenue, what the various costs are, privacy and security considerations, and ethical considerations.

4. Deep Knowledge of the Industry. The fourth critical contribution is deep knowledge of the industry the product is competing in. This not only includes competitors, but also key trends in terms of technology and customer behaviors/expectations. Industries are constantly moving, and we must create products for where the market will be tomorrow, not where it used to be.

These four skills provide a critical foundation for product managers to excel in their daily responsibilities. But what exactly are these responsibilities? My favorite way to frame the discussion around the specific responsibilities and deliverables of product managers comes from a talk that Sachin Rehki gave at Wharton back in 2016. He kicked off the talk with the following text on his opening slide:

Below is an amalgamation of ideas pulled from Sachin's essays (along with the ideas of Adam, Bubba, Elad, and Marty) that analyze the specifics of product management across these four dimensions.

The Four Dimensions of Product Management

Vision#

As a product manager, you must clearly formulate and then evangelize the audience you are targeting, the distinct problem you are solving, and how your unique solution will win the market. And to properly formulate this vision, you need to have a deep understanding of the target audience, the existing solutions and competitors in the market, and a compelling thesis for why your solution provides a 10x improvement over the existing alternatives. Simply summarizing the vision in a short and pithy vision statement will not suffice.

Vision Narrative

A compelling vision should articulate how the world will be a better place if you succeed and outline a path to get there. The best way to do this is through a customer-centric vision narrative. Jeff Bezos actually popularized this idea by requiring his executives to write a 6-page narratively-structured document before discussing strategic initiatives. The key idea underlying this requirement is that there is almost no way to write such a document without clearly thinking through all aspects of a problem. Bezos actually does this himself every year in his annual shareholder letters:

A vision narrative doesn't have to be super long. Just one or two pages should allow you to provide more than enough context on the state of the world today, the value your product currently delivers in the world, how achieving your ultimate vision will materially change today's state of affairs, and a set of steps to ultimately get there. One of the best examples of a compelling vision narrative is Elon Musk's "Tesla Master Plan". Google and Slack have great ones as well.

Product Walkthrough

To supplement the written narrative, product managers should also provide a visual representation of what the future could look like if the team is successful. This most often takes the form of a click-through prototype or concept mockups that show what a future version of the product could look like. While the future implementation might be very different, the mockups can be extremely useful to illustrate your company's ambitions to various stakeholders (e.g. investors, employees, leadership, customers, etc.).

Once again, Elon Musk provides an example of a masterful product vision walkthrough. This video from 2016 showcases the vision for SpaceX's Interplanetary Transport System which aims to bring the first manned crew to Mars. While this representation isn't intended to be implemented anytime soon, it showcases the kind of inspirational feeling a successful product walkthrough leaves your audience with.

Evangelize the Vision

Lastly, it is important to keep in mind that vision narratives and product walkthroughs are not enough. As a product leader, you must constantly evangelize the vision to your team. And before you can convince your team of your vision, you need to build strong conviction within yourself that your vision will win in the marketplace. Without that, it will be impossible to convince your team. Once you have that though, it becomes important to craft your vision into a compelling narrative that your team can get behind. And then you need to focus on delivering this message continuously to your team so they never lose sight of it. A good litmus test is that when you ask a team member what the product is all about and where the team is going, they should be able to repeat your vision. If they can, you've done a good job of articulating the vision, inspiring the team, and letting it sink in.

Strategy#

A compelling strategy delineates exactly how you will dominate your market, and as Adam Nash puts it, it's the product manager's job to articulate two simple things:

1. What game are we playing?
2. How do we keep score?

Clearly describing the game you're playing and the metrics you use to judge success allows the team to sort through different ideas, decide which ones are worth acting on, and run in the same direction. Defining the game includes your vision for the product, the value you provide your customer, and your differentiated advantage over competitors. More importantly, however, it must include the way your team is going to win. And, assuming you pick your metrics appropriately, everyone on the team should have a clear idea of what winning means. This will result in an aligned effort, better motivation, innovative ideas, and products that move the needle.

The major difference between strategy and vision is that your vision should be stable. Strategy, on the other hand, needs to be constantly iterated on and refined.

When you initially start working on a product, you have a set of hypotheses for how you'll dominate your market. But they really are just hypotheses, and as you get customer and market feedback, you'll refine them. And even when you think you've figured it all out, market dynamics inevitably change (e.g. new competitors, technological shifts, recessions, etc.).

Product/Market Fit Hypotheses

When it comes to strategy, you don't need a business plan. Business plans give you false precision and the false belief that you have everything figured out. As soon as you start executing, you will quickly find out that many parts of it don't work. Instead, articulate your strategy with a ~1-2 page summary that captures each of your critical product/market fit hypotheses. These are simply your best guesses on what is going to work, and you should constantly refine them. Sachin Rehki finds that every business requires at least these 8 product/market fit hypotheses that make up their product strategy, but your specific business may have more:

1. Target Audience. Who is the ideal customer for your product? Don't think about the broadest possible definition of TAM. Instead think of who your very best potential customers are.
2. Problem You're Solving. Is the problem you're solving for your customer a vitamin or a painkiller? In other words, is your product a need-to-have or a nice-to-have?
3. Value Propositions. This is not the feature list, but instead the promise to your customer on the value you will deliver for them.
4. Strategic Differentiation. Why is your solution 10x better than the leading alternatives? The inertia to get people to switch products is so high that a slight improvement just won't cut it.
5. Competition. How does your offering compare to both indirect and direct competitors? How were your customers solving this problem beforehand, and how is your product improving on those alternatives?
6. Acquisition Strategy. How are you going to find and attract your potential customers? And how will you do so cost-effectively? What channels will you be leveraging? How does your cost per acquisition compare to customer lifetime value?
7. Monetization Strategy. What will be your primary and secondary monetization mechanisms? What is your customer's willingness-to-pay for your offering?
8. KPIs. What are your North Star metrics? What does success look like (e.g. number of customers, revenue, etc.)? This allows you to measure how your product/service is actually doing.

When you initially document these, they should be pretty light-weight (~1 paragraph for each for a total of ~1-2 pages). But as you iterate, you'll find that you'll be able to add significant detail to each based on what you've learned from the market.

Design#

A compelling design delivers a useful, usable, and delightful experience to your customers. And driving the design for a product involves determining the right feature set to achieve a 10x improvement over existing solutions, working with designers to ensure the user experience appropriately delivers on the vision and principles by which your product will differentiate, and authoring detailed specifications that guide developers to efficiently implement the finalized design.

Customer Discovery Insights

One of the most important responsibilities of product managers is to lead customer discovery efforts to help inform what product to build and how to build it. To do this, you must start by falling in love with the problem you are solving for your target customers (not the solution). This means steeping yourself into the actual problems that your customers are facing every day. What does their day normally look like? What other products and services are they using? Whenever you are surprised, it means you've collected a valuable insight. And the quality and quantity of these valuable insights is exactly what a product manager is optimizing for in customer discovery.

When working with designers the most important contribution that you can provide is a deep understanding of the user's goals, sensibilities, and psychology, plus existing behaviors and tendencies that the user has already exhibited via an understanding of the existing product metrics. This enables you to ensure the experience is appropriately calibrated for the exact user you are going after. One of the most important things you can do for this is simply increase exposure hours.

The task for the product manager then becomes how to leverage the many customer discovery methods at their disposal, including surveys, net promoter score, focus groups, pain point analyses, value proposition validation, card sorting exercises, usability studies, etc., to maximize the discovery of unique insights that'll directly influence roadmap and requirements.

One of the most useful tools is personas. Personas are fictional characters developed to represent the different archetypes of users of your product. A persona typically describes the goals, pain points, behaviors, and pyschology associated with members of a particular segment. To bring them to life, a name, a profile image, and sometimes even a background history are associated with them. A team usually develops one or more personas to represent the core audience of users they are optimizing their products for. Building a product for many different audiences is a challenge, and it is really helpful to understand your customers as individuals.

Prioritization & The Product Roadmap

Probably the most visible aspect of the product manager role is driving the product roadmap. The product roadmap dictates what gets built in the product and when. Roadmap items can span from new features, to bug fixes, to redesigned or improved experiences, to infrastructure or back-end related initiatives, as well as growth and monetization efforts. As long as it takes time from the product team, it should be reflected in the roadmap. As Elad Gil puts it, "Crisp product requirement documents can make a world of difference in driving concise agreement on, and execution of, the product. PRDs should clearly articulate primary features and product needs."

Given that smart teams rarely find it difficult to come up with potential enhancements for their product, the critical challenge for any product manager is one of prioritization. The question isn't what is the best list of ideas you can come up with for the business--the question is what are the next three things the team is going to execute on and nail. In many ways, the hardest part of design is determining exactly what is above the line for the next release. This requires an equal amount of art and science to come up with a compelling feature set and user experience. It's often better to err on the side of fewer features for the benefit of getting the product out sooner to optimize for learning. Fewer features also enables you to spend the time to appropriately optimize the experience for the remaining features.

You should be able to ask any product manager who has been on the job for two weeks for a list of the projects their team is working on, with a clear rationale for prioritization that the entire team understands and supports.

Product Requirements

Product requirements, or product specs, serve as both a forcing function to think through the experience details of your new feature as well as a critical communication tool with a variety of stakeholders. It helps designers understand the guideposts around the experience they need to design, it helps engineers understand the subtleties of the experience they need to implement, and it helps testers understand the expected behavior of the experience they need to test. Beyond the core R&D team, product requirements are also consumed by a variety of additional stakeholders, including product marketing who is looking to translate the capabilities of the feature into coherent messaging and positioning for customers, data teams looking to implement relevant dashboards for the new functionality, executives looking to understand the high-level vision and strategy behind the functionality, and many others. Each product spec should contain a detailed description of the problem you're trying to solve, the target audience, the rationale behind the overall solution, and the success metrics on top of the experience details.

Execution#

Relentless execution ultimately determines whether your vision becomes reality. And if you're not spending at least 60% of your time on execution, you're doing it wrong. It doesn't matter how compelling your vision, strategy, and design are if you aren't relentlessly executing. You need to convert these ideas into products and actually put them infront of your customers. This involves core project management responsibilities of breaking down the roadmap into concrete tasks, tracking the progress of these tasks, and triaging bugs and feature suggestions as they come up.

But execution is not just project management. It involves doing whatever it takes to win. It involves being resourceful in solving any blockers that come up for your team. This could be filling in the gaps on your team when needed, including design work, copy reviews, or even simple engineering tasks. Or it could be ensuring open product, design, and technical decisions get resolved in an efficient manner. Or it could be responding in real time to industry changes, competitors, or customer complaints. In The High Growth Handbook, Elad Gil points out several of the biggest ways a product manager can help the team hit its goals: (a) lobbying for resources or attention from engineering, design, and other functions, (b) removing or prioritizing features and providing a clear road map for execution, (c) asking "stupid" questions to see if it is possible for each function to reduce timelines or remove unneeded features or work, and (d) pushing back on extraneous requests, whether those are internal (design, sales, etc.) or external (customers, partners).

However, it's important to keep in mind that you also have to constantly be recalibrating to make sure you are pointing your team in the right direction. If you're executing like crazy but not heading in the right direction, that's not very helpful either. The challenge of execution is making progress against your stated goals while learning. To do this, product managers should create an execution loop:

1. Define your hypotheses (e.g. mock-ups, prototypes, etc.)
2. Validate each hypothesis (e.g. talking to customers, usability studies, engagement metrics, etc.)
3. Iterate based on what you've learned

You have to always validate your hypotheses to make sure that the direction you're going in is the right one. And then constantly iterate based on that validation. Once you formally state your hypotheses, your number one goal becomes increasing the velocity of this execution loop. By going through these stages faster, you can drastically improve upon the execution of your team.

Experienced product managers shift their focus to increasing the throughput of experiments their company can run as well as the number of experiments that can be run in parallel. Naturally, everyone thinks their own idea for an experiment is high priority when in reality it is more important to just get the company to run more experiments faster. To really affect the rate of experimentation, good product managers must focus on technical infrastructure that enables experiments, cultural norms around experiments, and prioritization frameworks for evaluating experiments. Almost none of these have direct ties to end user facing features so it can be hard to get a team interested in prioritizing them.

Great product managers improve the following three things:

1. Rate of execution
2. Rate of experimentation
3. Rate of idea validation

And in the process allocate resources more efficiently than everyone else. All companies are a function of how well they allocate their resources and how big the market is for their products. Thus, finding large new market opportunities as efficiently as possible is the best path to create outsized value.

Metrics Dashboards

Product managers are responsible for continually assessing, reporting on, and deriving insights from the health of their product, and metrics are one of the primary ways of doing so. The best product managers look at a consistent set of metric dashboards on a daily and weekly basis to keep an active pulse on the product, but also to build their intuition for the natural ebbs and flows of their product metrics. Product managers need to work with their data teams to continually refine these dashboards to both give them deeper insights into the various drivers of the product, but also to remove metrics that are no longer adding value. Too many metrics as well as too few metrics are both challenges that can make dashboards ineffective.

While each product needs to determine the right dashboards for their unique offering, most products need at least an acquisition dashboard (reporting on how well users are finding the product and signing up for it), an engagement dashboard (reporting on how often users are using the product on a regular basis), and a monetization dashboard (capturing how well the business is monetizing its offering). Ideally these dashboards will be refined over time and made accessible from any mobile device. They should be the first things you look at every morning.

Team OKRs

Product mangement is ultimately a leadership role and as a leader on the product team, you're responsible for driving focus, alignment, accountability, and an outcome orientation. Objectives & Key Results (OKRs) are one of the best goal-setting frameworks for accomplishing all of these things.

When everyone on the team feels like they understand what the most important priorities are, what success looks like, and who is responsible for each part, you get incredible leverage from each and every team member that allows you to accomplish way more than a team without this shared context.

OKRs are also important for communicating your team's priorities, progress, and milestones to senior leadership and the executive team. Since senior leadership is ultimately responsible for the resources allocated to your project, it's important to keep them abreast and aware of where you stand. Communicating OKR progress regularly is one of the most effective ways of doing so.

Communication, Decision Rights & Decision Rationales

Throughout the process of building and iterating on a product, there are hundreds of big and small decisions that need to be made. Product managers are responsible for identifying when decisions are needed and driving the decision-making process to resolution in the most efficient way possible.

One of the keys to fast iteration is clear delination of decision rights--who owns this decision? When everyone on the team understands who the ultimate decision maker is, everything moves faster. And great product managers establish themselves as the curator of great ideas--not the creator. Great ideas come from everywhere on the team (e.g. engineers, designers, executives, customers, etc.). The product manager's job is to make sure they have a process for soliciting ideas from the best places, evaluating the ideas in a way that makes sense, and bubbling up to the top the very best ones. When the product manager does this well, the team feels as if the best ideas, regardless of where they came from, get implemented. They know their input will get heard, and they have a clear understanding of how and when decisions will be made. This keeps the team inspired and moving fast.

Often the hardest part of communication is communicating the "why" behind the product road map, prioritization, and sequencing. While product managers often share decisions, they less frequently share decision rationales. It's the sharing of rationales that help the team feel heard, help the team trust in the process, and help the team understand the assumptions that went into the decision, which then creates clear guidelines for revisiting the decision. Having to communicate decision rationales also helps drive clarity of thought in the decision making in the first place, since you will need to actually explain how you arrived at the final conclusion. Communicating the decision rationale can certainly be done face-to-face, but whenever possible, they should be documented. Square does this by using the email alias notes@square.com to send out decisions broadly to anyone interested. It lets others learn from them and also gives the team the opportunity to revisit them in the future.

Product Wins

Finally, it's important to always remember that the number one thing product managers are responsible for is delivering product wins: shipping products that solve the customer's problems in a delightful way all the while building a meaningful business. All the other deliverables and tactics discussed above are simply tools that help product managers achieve this ultimate end in the most efficient way possible. But without achieving product wins, the intermediate deliverables provide no value. Beyond these deliverables, it takes relentless execution and hustle to make a product win a reality.

Sources#

• The Art of Product Management with Sachin Rekhi
• What is Product Management? by Sachin Rekhi
• The Top 10 Deliverables of Product Managers by Sachin Rekhi
• The Product Manager Contribution by Marty Cagan
• Behind Every Great Product by Marty Cagan
• The High Growth Handbook by Elad Gil
• Be a Great product Leader by Adam Nash
• The Three Great Skills of a Great PM by Bubba Murarka