What do users need?
Hint: It’s often not what they ask for
Working as a product manager at a young company without a support team, I spend a lot of time answering questions and collecting feedback from users on Intercom. Doing so has given me far greater familiarity with the needs, and the mindsets, of our prospects and customers alike. (And of course, since we’re building a system of record for product management, all of these users are also product managers!)
Discussing users’ questions, pain-points, and feature requests every day has made me more effective in my role at productboard. It’s also made me a better product manager. In large part that’s because Intercom let’s me have actual conversations with my users — substantive real-time exchanges that delve into what users really need. (This was far more difficult in the past when most exchanges took place by email.) It’s also because I’ve learned to ask the right questions in response to users’ requests — a marked departure from thanking a user for their input and moving along to the next request.
Take this question that I’ve received several times in the past week:
A fair ask! I’m even happy to +1 this feature idea on the user’s behalf.
And let’s say I do. As the weeks and months progress, our team watches the number of requests for this feature tick upwards. Here’s how that would look in productboard:
Now let’s say this feature is requested far more times than any other feature idea:
I might proceed to prioritize Feature voting and push it to engineering to begin working on its delivery. But if I did, there’s a good chance I’d hear from a colleague in UX, who’d ask:
“What’s feature voting?”
What do you mean?! It’s feature voting! It’s a portal where users can propose feature ideas and vote on the ideas of others! You know… feature voting!
Suddenly it dawns on me… Is that really what all of these users need?
If I’m lucky enough to have recorded which users had requested this feature, I could reach out to them and see. (Here, it really helps to have productboard.)
By doing so I might realize that different users had different needs all along, fitting into one of three categories:
- Source new ideas from a community forum where up-voting helps surface the most often-requested ideas
- Validate existing ideas by asking a select group of colleagues or customers to force rank feature ideas
- Prioritize existing ideas by allowing product manager colleagues to vote for feature ideas along strategic dimensions, indicating their opinion on the feature’s alignment with drivers like adoption or engagement
All of these constitute voting in some way or another, yet when users make feature requests, they tend to write in shorthand. When they ask us for feature voting, they envision the ideal solution for their own needs. Perhaps because we humans tend to assume our own needs represent objective, universal problems, we overestimate the ability of others to understand them. Why else would so many users be willing to take the time to compose a message, but leave out key details surrounding why they need the solution they’re requesting? (And if product managers make such shorthand feature requests, you can be sure that other types of users will as well.)
The point is, uncovering these distinct needs helps us see that users have actually been asking for three different solutions. And if I recalculate how many users need each solution, I might even decide to go build a different feature altogether!
Product managers ask “why?”
The big lesson here? You can’t rely on users to explain their needs to you. You need to sleuth it out yourself. And as we saw, this can have real implications on what you decide to build.
This was a hard realization for me as a first-time product manager in a past role. I sheepishly admit that the hypothetical above isn’t fictional. I’ve lived it. And while it’s better to realize conflated needs after prioritization than realize it after the feature’s ship date, it’s painful to make your team wait while you go do homework you should have completed in the first place. Fortunately, there are ways to preempt this situation entirely.
Always ask why, then ask why again, and sometimes ask it a third time, and on occasion once or twice more after that. The trick with the “5 Whys” is asking why in the right way.
Each follow-up question you ask should serve to dig one level deeper toward uncovering the core user need at play.
Uncovering needs is a multi-step process. It can be mentally taxing and time-intensive as well. But I never question whether it’s worth it because I know all the information I surface will actually be put to use when its pushed to productboard. Once there, it will be invaluable for helping the team research user needs and capture feature ideas, prioritize what to build, and design optimal solutions. For example, when designers and developers begin working on a feature down the road, they’ll be able to reference every piece of research and feedback that relates to the feature at hand. In other words, each Intercom conversation I have now will become a primary source for research carried out by my team down the road. Each clarifying question I ask now could inspire the eureka that influences our roadmap or impacts what we go on to build.
As much as Intercom fostered my 5 whys technique, it’s also helped me develop a core product management mindset — relentless curiosity. Nothing helps product managers uncover new user needs quite like a genuine fascination with the problems they’re solving for. And that’s something that gets built up one question at a time, over months or years of becoming an expert in a given space. With Intercom, I can mull over conversations as they’re taking place because there’s none of the pressure that exists in the typical meeting or group conference call. In those environments, customers are often in little mood to pause and reflect or be put on the spot while rattling off their requests. But Intercom offers buffer time for coming up with the next probing question, while allowing users to assemble more thoughtful answers.
With time, I’ve carried these skills over to the real world as well. I’ve improved at formulating questions on the fly during in-person meetings, and I’ve followed the lead of more seasoned PMs, putting users at ease by posing questions inspired by curiosity (not an impulse to push back on feature requests). By giving your user time to compose their thoughts, no matter the occasional awkward silence, you can set the stage for more interesting revelations, as you collaboratively uncover needs that until now, neither of you knew existed.
