Sachin Rekhi

Mastering the craft of product management is no easy task. Much of the literature that defines the role as the intersection of business, technology, and user experience isn't particularly helpful for practitioners who are left wondering what skills they need to learn versus the fine people they work closely with in actual business, technology, and user experience roles.

I instead define the role of a product manager as driving the vision, strategy, design, and execution of their product. Each of these four dimensions has specific responsibilities as well as skills needed to be great at it.

It's equally important for product managers to think about each of these four dimensions as having a concrete set of deliverables. Too often product managers perform the activities associated with each of these deliverables, but may not do so as rigorously as they could to maximize value. When you instead think of them as concrete deliverables you then can look for exemplars of greatness for each as well as hone your craft around each of them.

I wanted to share what I believe are the most important deliverables for product managers across each of the four dimensions of product management. In doing so I hope to help demystify what you actually do in the role, provide a framework for assessing what dimensions of the role you are already good at delivering against, and opportunities for improvement on each. While I could easily write an entire essay for each deliverable, I'll instead focus on introducing each of them and providing a perspective on why they are critical for PMs.

Product Vision
Most product managers realize that defining a compelling vision for their product is a core responsibility of their role. But what most get wrong is thinking they can simply get away with defining a simple vision statement. In my experience, those that do just that rarely find that their team is inspired or highly aligned on the future direction of the product. That's because in summarizing the entirety of the vision in a short and pithy vision statement, so much of the important context around it is lost.

Instead, I've found those that take the time to define a vision narrative are far more successful at rallying the team around a compelling future direction of the product. This written prose doesn't have to be long. It could be just a page or two. But being able to dedicate paragraphs to it allow you to provide all the appropriate context: the state of the world today, the value your product currently delivers in that world, how achieving your ultimate vision will materially change today's state of affairs, and a set of steps to ultimately get there.

The additional advantage of doing this as prose is that it allows you to explicitly refine the storyline. What part do you start with? What's the punchline? How do you best transition between the current state and the future state? What description of the future best inspires the audience? Since the primary objective of a vision is to articulate and inspire the team to understand how the world will be a better place if you achieve your ultimate goals, it's all about telling a compelling story and therefore these all become essential questions that you need to answer to succeed.

Here are a few examples of vision narratives from companies we've all heard of:

• Amazon.com - Shareholder Letter, written by Jeff Bezos in 1997
  
• Google - The Anatomy of a Large-Scale Hypertextual Web Search Engine, written by Larry Page & Sergey Brin in 1998
  
• Slack - We Don't Sell Saddles Here, written by Stewart Butterfield in 2013
• More...

Product Strategy
A compelling strategy details exactly how your product will dominate its market. The reality is that when you initially start working on a product, you have a set of hypotheses for how you'll win your market. But they really are just hypotheses at this point. As you progress, you'll refine or pivot each of them as you get direct customer and market feedback on what's working or what's not. And even when you think you've figured it all out, market dynamics inevitably change - a new competitor enters the market, a recession changes customer's willingness to pay, etc.

All of this is why I find the best way to articulate a strategy is as a set of product/market fit hypotheses that you are constantly iterating on and refining. I find that every business requires these 6 product/market fit hypotheses that make up their product strategy:

1. Problem to solve
   
2. Target audience
   
3. Value proposition
   
4. Competitive advantage
   
5. Growth strategy
   
6. Business model

When you initially document these, they should be pretty light-weight. Maybe just a paragraph for each for a total of one or two pages. But as you continue to iterate, you'll find that you'll be able to add significant detail to each based on what you've learned from the market.

For example, when we were building LinkedIn Sales Navigator, we knew that we wanted to target B2B sales professionals. But as we progressed in our customer discovery, we were able to refine our target audience hypothesis significantly by tightening the definition of our best customer to B2B sales professionals in large enterprises in the technology and financial services industries working in account executive or sales development roles. That level of precision provided incredible clarity to both our sales and product teams as we tried to build the very best product and sales engine for this very specific audience definition. And that's what refining your strategy is all about.

Customer 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. In early-stage startups, product managers are often responsible for executing all of their own customer research, while in larger organizations product managers often work closely with designers, UX researchers, or product marketers to accomplish this.

Regardless of the resources the product manager has at their disposal, they are solely responsible for ensuring their discovery efforts lead to unique insights that will shape the direction of the product, for summarizing and sharing those insights with the entire team, and then incorporating them into the product roadmap and product requirements.

Scott Cook, founder of Intuit, has the best perspective on customer discovery. "When a surprise happens, either upside surprise or downside surprise, that's the market speaking to you trying to tell you something you don't yet know, so you need to listen". 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.

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

Product Roadmaps
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 on the roadmap.

Over the years, I've built roadmaps in Powerpoint presentations, in Google Sheets, as well as in project management tools like JIRA and Asana. I find Google Sheets gives me the productivity and flexibility that I like, while allowing me to easily collaborate and share the roadmap with others. Inevitably I still re-create the high-level roadmap in presentations for All Hands meetings, exec reviews, and sometimes even customers. Ultimately, the more detailed tasks that the R&D team ends up working on make it to the team's project management tool. While this approach has worked well for the teams I've led, my recommendation is to just pick the tools that the team is most amenable to.

Given that teams rarely struggle with coming up with potential enhancements for their product, the critical challenge for any product manager is one of prioritization. While many PMs try to find a scoring framework like RICE that allows them to simply rank each and every feature to prioritize the roadmap, I find that developing a compelling roadmap is far more art than science. I instead prefer to apply 4 distinct lenses when coming up with the right roadmap: vision, strategy, customer, and business:

• The vision lens is all about thinking through your long-term vision for the product and determining when it makes sense to make meaningful investments to bring the product closer to your desired future state.
• The strategy lens is about identifying the gaps that existing between your stated strategy and where the product is today and coming up with initiatives to close those gaps.
• The customer lens is all about listening deeply to your customers through your various customer discovery activities and prioritizing the roadmap items that will have the most meaningful impact to the most important segment of users.
• The business lens involves understanding your product's acquisition, engagement, and monetization metrics relative to your goals, determining what metrics are the highest priority to improve, and figuring out the best product initiatives to enable you to do so.

Each of these four lenses produces very different and often conflicting priorities. The art then becomes thoughtfully combining them to come up with your ultimate roadmap.

Product Specs
Product specs (also known as product requirement docs or product briefs) 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 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 a coherent messaging & 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 so many others.

While I could share a generic product specs template, I find they are best tailored to your organization depending on who the primary audiences are for them and the preferred work style amongst them. I started my career in product management at Microsoft, where I often wrote 30-page specs for a single feature. These were painstakingly thorough with tables full of dialog copy, error messages, and more. Since moving to Silicon Valley, most of the specs I've written have been far shorter. Instead of detailing dialog copy and error messages, the designer would take a first stab at them, the product manager would suggest updates during the design reviews, and the copywriter would review and finalize it. This more agile work style can be a more efficient way of getting things done. That being said, I think most Silicon Valley teams have moved too far in the direction of light-weight specs and now miss the rigor that comes from specs being a forcing function for clarity of thought on the overall experience. That's why I think it's critical that every product spec at least contains a detailed description of the problem you are trying to solve, the target audience, the rationale behind the overall solution, and the success metrics on top of the experience details.

Metric 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 ineffectual. Building and reviewing metrics dashboard are certainly not the only analytical activities product managers are responsible for. They also design and report on A/B tests as well as conduct ad-hoc analyses to investigate certain user behavior. But the metrics dashboards are particularly important because they should be utilized by the broader product team as well to create a consistent understanding of the health of the product.

While each product needs to determine the right dashboards for their unique offering, I find that 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 offerings. At Notejoy, we've refined these 3 dashboards over time and made them accessible from any mobile device and they are the first three things I look at every morning when I wake up.

Team OKRs
Product management 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 I've found for accomplishing all of these things.

When everyone on the team feels like they understand what the most important priorities are, understand exactly what success looks like, and understand 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. Developing this clarity, however, is no easy task and requires investing in developing an effective OKR program.

OKRs are also important as the way you communicate 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 and thus communicating OKR progress regularly is one of the most effective ways of doing so.

Decisions
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.

The process by which a product manager makes such decisions can result either in an extremely well-functioning team dynamic or... quite the opposite. When it works 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. And even though the wrong decisions might sometimes be made, they know that when appropriate, they can and will be reversed. And while they may not always agree with the outcome of a decision, they trust in the team’s ability to make the right call more often than not.

One of the keys to establishing this healthy decision making culture is ensuring you broadly communicate decision rationales. While product managers often share decisions, they less frequently share the rationale. 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 need to now actually explain how you arrived at the final conclusion. Communicating the decision rationale can certainly be done face-to-face, but whenever possible, I encourage folks to document them. 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
It's important to always remember that the number one thing product managers are responsible for delivering is product wins: shipping products that solve the customer's problems in a delightful way all while building a meaningful business. All the other deliverables we talked about are simply tools designed to help you to 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.

When the product team ultimately does deliver product wins, it is important to celebrate these wins, regardless of how big or small they are. The team has worked incredibly hard for these moments, so make sure to relish them to help fuel the next iteration and remind folks why we do what we do in the first place.