PRODUCT MANAGEMENT 101: AN INTRODUCTION
If you’re a product manager, or if you suspect you may be playing the role of a product manager, chances are, at some point, you’ll be required to explain what you do to someone far less familiar with the field…
- Your significant other’s friend who got her first Facebook account mid-2016
- Your cardigan-wearing Luddite father who has not yet adopted an electric shaver
- Your sprightly grandma whose AM/FM radio is her most technologically advanced possession
Or maybe it’ll be your digital-native nephew whose mastery of countless apps has gotten him no closer to understanding how they’re made.
Without further ado, here’s a definition of product management fitting for all the friends, dads, grandmas, and nephews out there. We hope you and your colleagues might find it handy as well.
What is product management? A definition
In simplest possible terms…
Product management is deciding what to build next.
Products exist to solve problems in the world. That applies to physical products, like skateboards, as well as digital ones, like Facebook. These problems don’t just float around in the ether. They’re problems that actual people have. So for simplicity’s sake, we’ll refer to them as user needs.
User needs include functional needs like I need to get to class on time or emotional needs like I need to feel respected by my friends. A product like a skateboard could solve both of these needs, but then again so could a Tesla. The optimal solution for a need may vary from person to person depending on time or context.
In reality, it’s the features of a product that address users’ needs. The wheels of a skateboard permit it to transport its owner. The beautiful yet assertive contours of a Tesla make owning one feel like a form of self-expression.
Digital products are no different. Grandma has a functional need to coordinate meetups with her grandkids so she caves in and signs up for Gmail. (5 hours of training later and she’s sent her first email, written in all caps of course.) An intuitive authoring interface helps her succeed in composing her email. An embedded address book feature keeps her from memorizing her grandson’s email address (firstname.lastname@example.org). Meanwhile, her grandkids have an emotional need to be accepted by their peers and may choose to do so by cultivating online personas on social media products whose features are specifically tailored for that task.
The main thing that distinguishes physical products from software is that their features must be decided upon far in advance of being sold. Software, particularly web apps and mobile apps, are always evolving as new features and functionality are added for users to enjoy. In this case, it’s especially fair to say that the product manager’s job is to decide what features and functionality are added next.
So the next time you explain your work to your nephew you can say: “You know how Snapchat has that feature to transform your face into a dog’s? That’s a feature that was only possible because a product manager decided it was a good idea, and put blood sweat and tears into leading a team of people (i.e. designers & engineers) to bring it to life.”
You’ll even know what to say when your clever niece who just got accepted into Berkeley chimes in: “Well how do product managers decide if a feature is a good idea?”
When I get this follow-up, I always think back to Marty Cagan’s definition of product management in his book Inspired: How to Create Products Customers Love:
“Product management is discovering a product that is valuable, usable, and feasible.”
Ok so products (and the features they contain) are a good idea to build if they’re valuable, usable, and feasible:
- valuable in the sense that they have to solve a need someone has
- usable because people must be able to learn how to use them without giving up, and use them on an ongoing basis without growing frustrated
- feasible since new features can’t require too many resources (time, money, effort, physical materials) or the company behind the product will go bankrupt (or get beaten in the market by savvier competitors)
So to summarize, product managers decide what to build next, and they do so by ensuring the features they build are valuable, usable, and feasible. We’ll explore each of these in the sections to come.
Product managers decide what to build next, and they do so by ensuring the features they build are valuable, usable, and feasible.
We’ll also look into some of the other responsibilities product managers have that make the role so multifaceted, so easy to misconstrue, and so fun.
PRODUCT MANAGER RESPONSIBILITIS
Understand what users need
Before product managers decide what features to build next, they often start by considering what would be most valuable to users (and potential users) of their products. To do that they must develop a deep understanding of what users need. Remember, needs can be both functional or emotional, so this is harder than it sounds.
Consider the fact that we often don’t understand our own needs. We pay sizable sums of money for subscriptions we never use and products that don’t actually make us any better off (that fancy sweater you wore once last year). Meanwhile, some of the new products we do use every day we never knew to ask for. I, for one, didn’t know I had a need for gourmet coffee until I moved to San Francisco, and I didn’t realize how big of a hassle scheduling business meetings was until I had an AI-powered “assistant” schedule them for me. Regarding the latter, through a detailed analysis of my hectic worklife, a product manager familiar with the possibilities of AI identified this as a promising opportunity. In fact, she might have come up with a whole set of features that improve on my existing solution (frenetically emailing my contacts a handful of times that work until we settle on one, which I then manually add to my calendar).
Starting to see a pattern here? Product management is all about bridging the world of problems (user needs) and solutions. A core responsibility of the product management job is understanding the problem side at a deep enough level to decide what the best solution would be. And there are almost always many possible solutions because solutions come in many different forms. They’re not just fancy polished products. Sometimes they’re solutions that a user has set up for themselves (e.g. a grocery list written by hand). If you’re a product manager developing an intelligent grocery list app, it’ll need to be at least as good as the homemade solution. In fact, it’ll likely need to be 2x, 5x, or 10x as good if you want people to go out of their way to discover it, learn how to use it, pay for it, and develop habits around using it on a regular basis.
Product management is all about bridging the world of problems (user needs) and solutions.
Take a moment for this idea to sink in: for every problem or need out there, there are a handful of solutions, and it’s important to identify what problem you’re solving before you start trying to solve it. This might seem obvious but it’s the number one way most amateur product managers (and even many experienced ones) get lost. We humans have a tendency to focus on solutions (like a new PDF export feature) because they’re so concrete. We can picture what they look like, and how they’ll work. They’re much easier for us to think about than concepts as fuzzy and abstract as user needs (like the need to share data with my boss). But beware of focusing on solutions too soon! Even if a user requests PDF exports to share data with their boss, they might later agree that it would be even better to send it as line chart PNGs embedded in an email. Only proper separation of problem and solution gives you a chance to discover that. Failing to do so risks delivering a sub-optimal solution, or one that doesn’t end up getting used at all – even if you built exactly what the user asked for! Given how much effort your team puts into developing even the smallest feature (let alone a new interface that could take months of work and thousands of manhours) everyone wins when PMs take the time to analyze user needs carefully.
Later on we’ll talk more about the PM’s role in the process of identifying, designing, and developing optimal solutions, but for now the key question is…
How do digital product managers identify what users really need?
The best product managers regularly engage in all of the following activities:
- Set up systems & processes to collect incoming user feedback: Whether your team uses Intercom, Zendesk, email, or other tools to communicate with leads and customers, chances are there’s a way for them to voluntarily send feedback your way. PMs are in charge of setting up systems to actively seek out this feedback, as well as collect and triage feature requests, improvement ideas, bug reports, usability complaints, questions, suggested hacks & workarounds, and rave reviews for existing functionality. The key is to categorize these golden insights that users provide so they don’t get lost in spreadsheets, inboxes, or Evernotes of individual product managers on your team.
- Collect insights from customer-facing colleagues: Who knows your users better than your colleagues on marketing, sales, and support who spend all their time working with them? Encourage them to collect feature requests and ask probing questions so they can report back on users’ underlying needs. In this way, they act like an extension of your user research team.
- Get out of the building: Interview users in their natural environment, observe their existing solutions, watch their daily routines, and study their pain-points firsthand.
- Validate your ideas in front of users: Once you have some understanding of what users need, mock-up simple solutions – even sketches or paper prototypes could work – and ask “would this solve your need?” The goal here is to use potential solutions as a means of identifying whether you correctly understand what users really need. (#IDEO #designthinking)
- Interview the users you’ve lost: When users do leave your product to use some other solution, or decide not to become customers in the first place, ask them why. What solution do they prefer? What features (or lack thereof) had the biggest impact on their decision? Was something missing from your product that served as the dealbreaker?
Learn more: How to gather and leverage deep user insights (ebook)
Ok, so you’ve collected feedback, recorded interviews, validated ideas, and done some loss analysis. You’ve even spotted some trends around what users really seem to need. But there sure are a lot of needs. And that presents a problem in its own right…
How do digital product managers keep track of user needs?
Sadly, many don’t. The status quo has been to keep this kind of information in your head, even though this makes it nearly impossible to suss out the subtle and complex overlaps of needs that different users have.
More often, product managers capture solution ideas (that would solve those needs) in a lengthy feature backlog – a list of features you’d someday like to develop – often stored in a spreadsheet, task management tool (e.g. Trello, Asana), or dev planning tool (e.g. JIRA, Pivotal Tracker). If you hadn’t noticed the issue with this already, if all you do is capture solution ideas, you risk jumping to conclusions. All too often, you’ll get fixated on a specific solution idea before you’re even sure what problem it should be solving. That’s why it’s so important to have a proper system for logging the user needs you’re looking to address, and beneath them, relevant solution ideas (feature ideas).
Even when you begin capturing feature ideas, it can still pay to stay high-level at this stage. As we’ll discuss below, user experience designers and engineers specialize in developing the best solutions to the problems you help identify as being the most valuable to solve. Attempting to do their job for them isn’t a good use of your time and expertise. It may also cause unnecessary strain on your team and lead to suboptimal solutions.
Decide what to build (and plan when to build it)
So far we’ve taken a closer look at the process for deciding what features might be most valuable to build, based on what your users need. Now we’ll look a little more at the other core responsibilities of the product manager: ensuring features are usable and feasible.
Once you’ve organized the user needs you’re interested in solving and generated some feature ideas, you’ll want to begin deciding what to build. This phase is known as feature prioritization. If you consider the task of prioritizing hundreds, or even thousands of features against one another so as to decide which to go and build next, it seems pretty daunting. That’s why prioritization is best done over time, and not during a single session.
What do product managers consider when prioritizing what to build?
Here are some tips for setting yourself up for success when prioritizing what to build next:
Define your target user: Most products serve many different types of users with subtly varying needs and goals. Decide in advance who your target user segment is – the group of users who are most important to the success of your product. You can’t please ‘em all! When push comes to shove, it will be better if you can make prioritization decisions because they’re what’s best for your target user, even if doing so means forgoing the needs of others.
Focus on specific objectives: On top of how well features meet the needs of different types of users, there are strategic reasons to build certain features as well. Perhaps a new onboarding flow isn’t hotly requested, but it’s a great opportunity for driving acquisition of your product. Or maybe you decide to spend engineering effort on a growth hack to help existing users invite others from their networks to start a trial of your product. Decide in advance what criteria you’ll use for evaluating feature idea. What’s most strategically important to your product, and to your company, right now? Retaining existing users? Acquiring new ones? Improving user experience? Improving platform reliability? Your objectives may vary quarter to quarter, but you’ll want to focus on one or two goals at a time so your team is focused on achieving specific measurable objectives rather than floating around aimlessly unsure of the strategic purpose of the features they’re delivering.
Prioritize in phases: In an initial phase you might sort your feature ideas based on what users have requested most frequently this quarter. That might help you realize how many ideas relate to helping users get up to speed in your tool more quickly, and that in turn might inspire an initiative to improve onboarding this quarter. That in turn will help you narrow your sights on other features that support this aim.
Validate your assumptions: Even when certain feature ideas get prioritized as candidates – serious features you’re considering building – it would be unwise to send them right to designers and engineers to begin working on them. Carrying out high fidelity designs and writing production code involve time-intensive work from highly skilled members of your team. It’s always best to take the features you’re considering working on and run them by customers first – particularly those who requested them in the first place. Do they still need these features? Do you understand their need correctly? Do they envision the same final solution you do? If there’s a discrepancy, is it a sign of misunderstanding the underlying need? Try to answer all of these questions before beginning work on a certain solution.
Champion the users’ needs: Ultimately, the product manager and the user experience designer (or “interaction designer”) share the responsibility of deeply understanding users needs, as well as ensuring any proposed solutions will be usable given the user’s background knowledge, skills, and experience. Often this involves user testing specific solution ideas to ensure users easily understand how they work. This can often be done on prototypes before a single line of code is written. The product manager should be involved in this process whenever possible, as it’s often your responsibility to share user context with other colleagues on engineering and marketing.
Know when to ground your prioritization process in reality: It’s counter-productive to seek feature complexity estimates from a representative of the engineering team before you deeply understand the problem you’re solving, but once you’ve whittled them down to a select few to go and research further (a process often called Product Discovery), you’ll be ready to generate specific solution ideas. that means technical members of your team will be able to evaluate each in terms of how challenging they’ll be to develop. This isn’t always black and white. There are often contingencies attached. (e.g. Engineer: “If we have to support Internet Explorer when developing this new feature it will take 2 months. If we don’t, it will take 2 hours.”) The key is to make the tradeoffs clear so you’ll know when to cut corners, when to forge ahead building a complex feature, and when to skip it in favor of a simpler feature with even higher value.
Become familiar with popular product prioritization frameworks: There are many different ways of framing what criteria matters most and using it to evaluate which features to go build. For example, RICE dictates a specific formula for judging feature priority based on projected reach, impact, effort, and confidence. Another school of thought favors the Kano model, which divides features into those that satisfy basic needs (and could be a dealbreaker if your product didn’t offer them) versus those that actively delight users.
Clearly communicate context and constraints with designers and developers: As product managers prepare to send features into development, it’s important to ensure designers and developers understand what they’re building and why. This means that for each feature, the product manager must communicate the following details:
- Strategic objective
- Core user need to be addressed (and user segment being targeted)
- KPI (What metric will move and by how much if this feature succeeds?)
- User scenarios to be enabled by the functionality
- Constraints, requirements, and other success criteria
Traditionally this information has been presented in the form of a feature specification (or “spec”). It’s worth adding that in recent years there has been some backlash to this approach. Too many product managers treated specs as the be-all end-all of communication with their team, even though they lacked critical context that helped designers and developers understand the real user needs they were addressing – the real why behind the features they were working on. There was also just something inhumane about the process of “tossing specs over the wall” from product to engineering – detailing requirements in tens (even hundreds) of pages without bringing engineers in front of users to see the relevant needs with their own eyes. Of course, it’s not possible for engineers to interview every user, but there is a happy medium where specs are clearly detailed but embellished with more user context, and all teammates spend more time interacting with end users.
How do PMs plan when to build and launch functionality?
Release in phases to minimize risk: Sometimes features can be built on their own and provide a lot of value to users. This could be the case with a specific piece of functionality that comes highly-requested. Other times, complementary features must be developed and released together if you are to advance your product in a more substantial way. For example, you might develop an entirely new interface, composed of many features, to meet the needs of an administrator user role who needs to be able to better manage users in their organization if they are to succeed with your product. An entirely new admin console is required to help them manage their products at a basic level.
In this latter case, we’ve moved beyond one-off feature prioritization to evaluate an entire initiative. This is tricky territory because it requires the team to risk putting in substantial effort on developing many features before they’re tested on users. Always try to minimize this risk by developing and launching the smallest possible group of features – even if that’s a small subset of the greater initiative. That way, you’ll begin collecting feedback from users as early as possible and can change course if you learn something surprising (e.g. admins don’t actually need an audit log, they could get by without it if there was better versioning). You can always complete an initiative by releasing subsequent phases of functionality at a later time. This approach of releasing the smallest amount of functionality as early as possible so as to maximize learning and minimize risk is known as the minimum viable product. It is central to the lean methodology and applies to most every aspect of prioritization and planning.
Align your team
So far we’ve reviewed how product managers are responsible for ensuring products are valuable, usable for users and feasible to build. While much of this work takes place upfront, the product manager’s job isn’t done once a feature specification is sent to engineering. As soon as development begins, a range of questions will arise around the best way to design a certain feature based on the user’s needs. Even the best written spec of all time won’t cover every contingency. It’s the product manager’s job to champion the user’s needs at every step of the product design and delivery process, ensuring the finished product meets the user’s needs, ships on time, and is launched successfully. Likewise, there will also be unforeseen hurdles and roadblocks that the product manager must clear so the team can be as productive as possible while bringing new features to life.
Note that this execution phase is the one most associated with project management, a discipline that may sound similar to product management, but is really just one part of it. After all, product managers must understand what users need and decide what to build before they manage the process of delivering it. Still project management can be a specialization in its own right, and some organizations hire project managers (focusing on execution) to work alongside product managers (focusing on prioritization). But in most organizations, product managers are still on the hook for project managing a feature through to its launch, and ensuring all teammates are aligned around why that feature is being built.
What kinds of deliverables do product managers need to manage?
Here are the deliverables product managers must often manage as features evolve from idea to finished, launched product:
- Feature specification (PM)
- Mock-ups & prototypes (UX)
- Final designs (UX)
- Development (Engineering)
- Documentation (PM & documentation)
- Marketing collateral (Product marketing)
- Sales enablement materials (Product marketing)
- Notifying stakeholders of upcoming changes to the product (Product management, account management, support)
Rally everyone around the product roadmap
How do you lead your organization using influence, not authority?
One of the greatest challenges of product management is the responsibility of fundamentally deciding the fate of your company’s product – the root of all revenues that pays everyone’s salary – without having any explicit authority over any of your colleagues. (Despite what the word “manager” means in many contexts, in this case, you’re not the boss.) In other words, your decisions affect others greatly, and they don’t have any reason to follow along unless you give them one. There lies the importance of influence, or actively rallying your colleagues behind a common vision for the future of your product, even when it doesn’t align perfectly with their own inclinations for where the product should head. For example, how do you convince a salesperson who was specifically hired to work with your company’s SMB prospects that targeting Fortune 500 companies with new enterprise functionality is the company’s best bet for long term success? His bonus, even his job security, may be on the line. But it’s still your job to win him over to your line of thinking if it’s in the product’s, and company’s, best interest. No one ever said this would be easy!
One key to successfully winning buy-in from colleagues is to seek their input early and often. From the earliest phases of the prioritization process you were likely collecting user feedback and feature ideas from customer-facing colleagues across the organization. Now it’s time to show them all of their contributions weren’t in vain! Share your plans with them and help them understand the criteria you used to make complex prioritization decisions and difficult tradeoffs. What are your biggest goals for the quarter? What initiatives will you be working on to address them? What phases will different groups of features be released in? When will they be available to users? How will this impact user behavior?
Depending on the type of product you work on, even prospects and customers will be interested in seeing the roadmap – particularly for complex b2b products with extended sales cycles, where end users are more likely to be highly involved with the intricacies of your product. In the case of a product like a marketing automation system that helps marketers manage their funnel, their livelihoods may even depend on it. Offering transparency into the decisionmaking behind your roadmap is a great way to excite users about the future of your product while collecting early feedback on features yet-to-be-developed.
Engage your customer community
As product managers, we might sometimes flatter ourselves thinking users’ lives revolve around our products. In reality, they are inundated with other commitments and distractions. So when it comes to asking users to invest time and effort in helping us improve our products (for their benefit), they may not bite unless we’ve taken active steps to engage our customer community. Doing so gives you the chance to convert active customers to loyal fans.
Show users they’ve been heard
When you collect user feedback, make sure you’ve logged who needs what, so you can thank them for their input down the road. Have an important customer call? Show up prepared, having reviewed their recent inputs in advance. They’ll know you’re listening!
Share ideas you’re considering, and what’s planned
Seek user feedback on ideas you’re considering, and feature’s you plan to build. They’ll provide valuable input that can help you validate your ideas, so you know you’re solving the right problem, and solving it in the right way. Meanwhile users will become more invested in your product, and may suggest additional enhancements on their own. Users should know where they can submit brand new ideas they have, even when you haven’t solicited specific feedback.
Celebrate what you’ve launched
Your team works hard on the new features they develop. Don’t forget to promote what’s new! Offer colleauges and customers a way to see all recently launched features, so they can stay informed around what new functionality is now available. Plus, when you see it all together, you might be surprised by how much your team has gotten accomplished in recent months! With all the kudos they’ll be getting, your team will feel proud of all they’ve accomplished?
If product management is the most misunderstood role in the company, it’s because it involves many skills and responsibilities that span disciplines. In our proudest moments, we think of ourselves as mini CEOs, and in our worst… product janitors cleaning up messes so the team can stay productive and on-task. But anyone really fit to be a PM loves these moments as well. There’s no other role that would demand the type of thinking involved in high-level strategic planning one minute and then a granular debate over several pixels in the UI just minutes later. It’s the variation that keeps things exciting and makes product management the dream gig for generalists everywhere.
What mindsets do successful product managers share?
For a closer look into the many mindsets product managers assume in order to succeed, take a look at the chart below:
How do I learn more about product management?
If you could only read one book on product management:
- Inspired by Marty Cagan
If you could read five more books:
- Product Management by Intercom (e-book)
- The Lean Startup Eric Ries
- The Four Steps to the Epiphany Steve Blank
- The Design of Everyday Things Don Norman
- Influence: The Psychology of Persuasion Robert Cialdini
If you could only read five articles on product management: