How to Master The Discipline of Product Management (Not the job of Product Manager)
Note: Republishing this post I shared on the Medium paid subscription a few years ago. This was originally written in March 2015.
The Discipline of Product Management
This Evergreen collection of wisdom is not about being a product manager. It is about how to manage a product. How to craft something of value for customers and the artful decision-making required to do that successfully. What you’re about to read isn’t about a role — we will explore the Discipline of Product Management. Something that everyone involved in business can learn and benefit from. This is about understanding the skills necessary to craft a compelling product. (‘Product’ here is inclusive of services, goods, and experiences — anything produced by a company for sale.)
Here’s what we’ll talk about in the following sections:
Understanding the customers’ contextualization of your product
How to prioritize development of features
Communicating and creating unity around a vision
These are skills that are important in any business, and applicable for creating any product. Study and internalize them, and see that anyone whose hands or minds touch the product in your business are fluent in them as well.
The Customer’s Perspective of a Product
Your unique vision of a product is not what will determine its success. Quality products are conceived of by understanding customer’s context, and created to enable the customer to accomplish something. I’ve never heard that put better than it was by Kathy Sierra early in her talk, Building Badass Users. (Which I can’t embed for some stupid privacy setting reason.)
Watching even the first 7 minutes will give you a great new way to look at your product. Thanks to Greg Drach for the incredible recommendation! Here’s a transcription of the most relevant piece about customer context:
We’re all just a subset of something bigger — the user’s bigger context — the thing they really do care about. The thing that’s meaningful to them. The reason they’re using your product in the first place. It’s not just because they love your product.
[…]
They [customers] don’t want us for the tool, they want us for the thing they’re using the tool to do. That bigger context. We make the tool. Users want the bigger context.
Sustained success lives in the context, not in our tool.
So we should always be asking — what are we a subset of?
[…]
People don’t want to be amazing at our tool. They want to be amazing at the context. It’s not that customers say “I’m amazing at this camera.” It’s that they say “I’m an amazing photographer.”
Crafting the perfect tool is impossible without understanding the context of what a Customer is trying to accomplish. If we don’t enable them to accomplish something, our tool (the product) is of no use.
Asking the Right Questions (and Getting Fat)
To grasp the context, we need to ask a different set of questions. This concept is laid out in the framework from Clayton Christensen (of Harvard Business School), “Jobs to be done”
This article, Clayten Christensen’s Milkshake Marketing, is a great application of that formula. It shows the most important question to ask:
The jobs-to-be-done point of view causes you to crawl into the skin of your customer and go with her as she goes about her day, always asking the question as she does something: Why did she do it that way?
In the post, the question is: “Why are 40% of Milkshakes sold by McDonald’s sold first thing in the morning?” The solution came by asking ‘what job are they hiring the milkshake to do?’
If you’re curious about the horrifying reasons that some large percentage of Americans buy milkshakes every morning — you’ll have to check it out. It’s a short, valuable read about how to frame your thinking about the Customer’s Context, and how to discover what features of your product are important.
There’s always an Opportunity Cost
Some context is completely obvious, and universal. As Nathan Bashaw puts it in his excellent post on Medium, Navigating the Product Maze:
The core purpose of any product is to fill some human need. That much is clear. But what’s less obvious is that human needs are fractal: the closer you look, the more needs you find.
The post from Bashaw is unique amongst all the research that I read this week, in that it specifically mentioned Trade-offs, which is a crucial concept to understand in crafting products:
Every time you say “yes” to a new feature, you’re saying “no” to a million others — whether you realize it or not. That’s why I find it useful to think about developing a product in terms of “making changes” rather than “adding features”. It’s like yin and yang: the stuff you add is visible, and how this constrains you and changes the experience is invisible, but they are just two sides of the same coin: impossible to separate.
Pretending that there’s no trade-off in each decision you make is doing yourself a disservice that will ultimately be reflected in the quality of your final product. There’s always a trade-off.
Take 3 minutes to read Navigating the Product Maze, by my friend Nathan Bashaw. It’s the perfect transition into our next section…
How to Make the Hard Choices
A product is the result of all of the decisions that went into its creation. What’s unseen are the invisible possibilities of a product, what sacrifices were made in order to create this specific set of advantages. So how do we know which trade-offs to make? What gets left behind in favor of other features or benefits of a product? This is the process of Prioritization. (Read the Evergreen Edition on Prioritization here.)
There are many frameworks that can be used to assess prioritization, and we’ll take a look at a couple of great ones that were suggested this week.
Starting with the Basics
Prioritizing Product Features for Beginners, suggested by Aaron Wolfson, is a good place to start, even if you think you know what’s up. There are a set of possible demands to optimize for, along with pros, cons, and recommendations for how to tackle each kind of prioritization.
Gamechangers, Showstoppers, and Distractions
This post about The Three Bucket Model, by Slava Akhmechet, is the simplest framework for determining whether a feature should be developed. Here’s an excerpt from the post that explains the framework:
A gamechanger. People will want to buy your product because of this feature.
A showstopper. People won’t buy your product if you’re missing this feature, but adding it won’t generate demand.
A distraction. This feature will make no measurable impact on adoption.
Empirically, successful products have one to three gamechanging features, dozens of features that neutralize showstoppers, and very few features that are distractions. Your job is to build an intuition about your space to be able to tell these categories apart.
The obvious challenge is knowing ahead of time which features fall into various categories. Clearly this is not a trivial challenge, but those shortcomings can be addressed to strengthen the conclusions.
A ‘Checklist’ of Questions to Triage Feature Ideas
The most thorough prioritization framework comes from a post from Intercom, called Rarely Say Yes to Feature Requests. This post is centered around a list of questions to ask as you contemplate an addition to your product.
My favorite question of the ten is “Will Everyone Benefit from it?” because it’s the antidote to being distracted by a vocal minority in your customer base:
Beware the “fre-cently” bias. You assume the things you hear frequently or recently should without doubt be road-mapped. It’s a natural reaction caused by your inbuilt empathy for customers. It’s not nice to tell people “no” repeatedly and hear the same responses over and over, so when possible “fre-cently” is used as an excuse to reward yourself. “Sure we’ll build that, I’ve heard it twice today already,” says the founder with 4,800 daily active users, to the unbridled joy of 0.0625% of her customer base.
The danger of the fre-cently bias is that it gives you the illusion of analysis, the sense that you’ve done your homework and this is a rational conclusion you’ve come to. In reality you’ve made a lazy decision to satisfy the whims of a small sample of vocal users without taking a second to investigate how many people really want or need the feature.
While the examples are all based around software development, because of Intercom’s product, the questions themselves are extensible to any business, and any challenging problem about product development. Print this list out, put it on your wall, and give copies to everyone on your team. Use this framework, in conjunction with the others (and with your trade-offs in mind) to be sure you’re being efficient with your resources.
Thanks to Aaron Wolfson, Ben Eddy, and Visakan Veerasamy for recommending Intercom’s post!
Communicate Vision & Scale Discipline
It’s not enough for one person to have a sense of the product. Everyone involved in the process makes their own micro-decisions that will affect the quality of the final product, so communicating the vision of the product is crucial to scaling the discipline of Product Management throughout the team, and ensuring that everyone is working toward the exact same outcome.
Evergreen’s Collection on Internal Communication
To get the full lesson on Communication within a company, check out the previous Edition of Evergreen we did on Internal Communication. It’s overflowing with ways to get ideas across to your team, and mindsets important to communication.
Of course, I’m biased, but I think it’s a fantastic read.
How Amazon Communicates Product Vision
To get an idea of how this works in practice, Ian McAllister of Amazon gives us a detailed breakdown of how Product Managers communicate. They work backwards by using an internal press release with the details of the product. Importantly, this exercise forces the writer into the customer’s perspective, as we saw in the first section.
For new initiatives, a product manager typically starts by writing an internal press release announcing the finished product. The target audience for the press release is the new/updated product’s customers, which can be retail customers or internal users of a tool or technology. Internal press releases are centered around the customer problem, how current solutions (internal or external) fail, and how the new product will blow away existing solutions.
The details of how to write one of these ‘internal press releases’ are in the Quora Answer from McAllister. I love this approach and actually used it when conceiving of the original structure of Evergreen. It was helpful for me to crystalize my thoughts, even with no other audience than myself.
The Ultimate Product Communication: The Thesis
FThis is the very best piece that I could find about the specific challenge of communicating around creating a Product:How to Write a Product Thesis to Communicate Customer Needs, by my talented friendJason Evanish.
Jason details the exact things your team needs to know, and how to communicate them without getting lost in the details or distractions. He picked up this method from Josh Elman:
Fortunately, when I joined KISSmetrics, Hiten and I got to learn from Josh Elman, who worked on product teams at Twitter, Facebook, and Linkedin. Josh taught me about the Thesis, which is a lightweight way to communicate all the essential details your product team needs.
Now that I’ve used the Thesis on dozens of projects and tweaked it based on what I found worked best, I’m going to teach you how to write your own thesis for the next feature or product you build.
Use the Thesis to guide your own thinking, and then to craft your communications, and you’ll be sure to have your whole team in stride and get a quality product produced smoothly.
One Last Thing…
Of course, the greatest thing ever put to paper on the subject of Product Management was penned by Ben Horowitz in a moment of pure frustration at the lack of definition of Product Management in his company. It still stands as an incredible resource on the perfect Product Management Mindset.
Read it five times: Good Product Manager, Bad Product Manager
As before, while some of those points sound specific to the role or to the industry, most of the knowledge is generalizable and valuable no matter what the challenge. Many thanks to Jason Evanish and Greg Drach for making sure that Ben’s incredible piece was included in this collection.