How product managers can identify what customers really need

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 customers 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 customers are also product managers!)

Discussing customer 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 lets me have actual conversations — substantive real-time exchanges that help me identify what customers 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 customer requests — a marked departure from thanking a customer 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 customer’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 customers 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 customers need?

If I’m lucky enough to have recorded which customers 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 customers 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 customers make feature requests, they tend to write in shorthand. When customers 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 customers 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 customers will as well.)

The point is, uncovering these distinct needs helps us identify that customers have actually been asking for three different solutions. And if I recalculate how many customers need each solution, I might even decide to go build a different feature altogether!

Identify customer needs by asking “why?”

The big lesson here? You can’t rely on customers 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.

To identify customer needs, 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 “five 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 customer 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 customer 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 five whys technique, it’s also helped me develop a core product management mindset — relentless curiosity. Nothing helps product managers uncover new customer 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 customers 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 customer 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.

.     .     .

productboard is a product management system that enables teams to get the right products to market faster. Built on top of the Product Excellence framework, productboard serves as the dedicated system of record for product managers and aligns everyone on the right features to build next. Access a 15-day free trial of productboard today.