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 everyday 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 part of the 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. That’s 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.
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 PMs (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 PMs of digital products identify what users really need?
The best PMs 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 environments, 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?
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 PMs of digital products 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 to 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.