The case for organizing feature ideas by user need
If you’re a data-driven product manager, chances are you’ve long dreamed of being able to quantify the projected impact every feature will have on your users:
And if you’re interested in making product people want, you might just have dreamed of a way to zero in on a feature idea and see everyone who has ever expressed a need it would address, what they said about it, and how important it is to them…
These views are possible in productboard thanks to the links you and your team can establish between insights you uncover on the Research board and feature ideas you’ve logged on the Features board.
productboard even tracks the interlinkages and calculates the prioritization scores for you. Here’s what’s happening behind the scenes:
But there’s a key to setting up your Features board for painless prioritization:
Organize your feature ideas by user need.
This may come as a surprise if you were inclined to group features by where they belong in the product, or the initiative they belong to. After all, productboard offers considerable leeway in how you organize feature ideas with components.
Ultimately components are just folders and they can represent anything you’d like, but we recommend using components to represent the core users needs that underlying feature ideas address.
Organizing features by user need
Consider a popular messaging app for teams called Zlack. Zlack’s team strives to address a handful of core needs for its users, which they’ve added to their Features board:
Within each need, are sub-needs:
And those can be broken down into additional sub-needs, and finally, feature ideas.
Above we see several features logged beneath the user need Speak with colleagues with visual aids, which could include features like video calling or screensharing to help communicate more complex topics.
There are several advantages to organizing your Features board in this way.
Benefit 1: Track common user needs even before you’ve generated any related feature ideas
Organizing your Features board by user needs means that when you find new insights in user research and feedback, you can link them straight to the needs they represent (each signified by a new or existing component), even if you don’t have any solution ideas for it yet.
That means when a customer describes the pain of managing Zlack chat for internal communications in addition to using email for customer support, we can begin tracking this need right away.
Here a customer has voiced this very frustration, as highlighted in a research note:
When we first come across a new user insight like this, it’s not always clear if other users share the need or how we might address it with a feature. By highlighting the insight and linking it to a related user need (component) on the features board, we can keep track of it over time and see if others face the same issue.
As we learn more about this need and further clarify it, we can begin linking feedback directly to relevant feature ideas — either by selecting existing features from the product outline or creating new feature ideas on the fly.
User needs and feature ideas can be created on the fly while processing feedback on the Research board (see above) but you’ll have even more flexibility doing so from the Features board.
And that takes us to the second key reason to organize features by user need…
Benefit 2: Set yourself up to quantify (and qualify) user impact during feature prioritization
As we link more and more feedback to user needs over time, we’ll begin to get a full picture of what core needs are most important to users. Earlier we saw how the user impact score allows you to quantify how many people have which needs, weighted by importance. Because the Features board aggregates user needs up the hierarchy, rolling up low-level needs into high-level ones, we can quickly zero in on those un-met needs that are most pressing for users today.
And as noted earlier, we can always select a need or a feature idea to immediately see everyone who has ever expressed that need or requested that feature, exactly what they said, and how important it is to them.
This provides context that helps PMs, designers, and developers ensure they understand what problem they’re solving for as they build new functionality. Designers can even conduct user interviews with these users before completing final designs or kicking off development. Doing so helps prevent wasting effort delivering highly-requested features that still go underutilized. After all, different designs for the same feature idea may solve vastly different needs.
Benefit 3: Shift the team’s focus onto the user
Whether logged in productboard or on sticky notes, feature ideas are best grouped by user need because doing so emphasizes that your team’s primary goal is not to ship features, it’s to address user needs.
This organization doesn’t just impact the way you make key product decisions, it influences the data your team collects in the first place. After all, the way you structure information influences what information you gather.
It means the next time you’re asked by the tenth customer in one week for the ability to upload files to your messaging app, you won’t just add a +1 to an “upload files” feature and move on. You’ll immediately try to envision where this request belongs in your product outline.
And to figure that out, you’ll have to ask some follow-ups:
PM: Interesting, so what kinds of files do you intend to be collaborating over with your team?
User: Most all of them are mock-ups. I work closely with our designers and we collaborate over design iterations several times a week, but some members of our team would benefit from seeing these discussions without having to log into Invision.
PM: You use Invision? Instead of exporting images out of Invision before uploading them into Zlack, would it be easier to push them directly to our app?
User: I didn’t even think of that! Yes, I’m sure my designer would appreciate that since he often shares 10+ graphics at a time.
Armed with this new information, you can revise your hierarchy and, if necessary, add any new feature ideas the conversation inspired.
In closing
Structuring your backlog by user need encourages every product manager to become experts on the problem space. When user needs are top of mind, it’s less likely your team will blindly swoon over the next neat feature idea that’s in search of a problem to solve. And the next time you hear that request for a faster horse? You might just realize what your target user needs is to get from A to B in minimal time regardless of cost. Perhaps it’s finally time to deliver that nuclear fission jetpack users never knew to ask for! 🐴 🚀
New to productboard? Get started for free in under 2 minutes.
