How are product teams approaching remote work and collaboration in 2021?
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…
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.
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 (email@example.com). 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:
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.
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…
The best product managers regularly engage in all of the following activities:
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…
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.
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.
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:
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.
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.
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.
Here are the deliverables product managers must often manage as features evolve from idea to finished, launched product:
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.
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.
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!
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.
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.
For a closer look into the many mindsets product managers assume in order to succeed, take a look at the chart below:
If you could only read one book on product management:
If you could read five more books:
If you could only read five articles on product management: