A lot of product teams get stuck in one of two bad patterns when it comes to feature requests ...
Pattern 1: the teetering mountain
Say yes to everything, then try to collate and prioritise a vertical mile's worth of conflicting ideas. Try to ignore the fact that these ideas also happen to be very different in nature. Doggedly persist in comparing apples, oranges and semi trucks. Force yourself nevertheless to decide which one to "build" next.
Pattern 2: the oxbow lake
Create a process that forces feature requests through a framing gauntlet. Common culprits include the framing that requests are "stated as problems” or "come with evidence" before they can go into the queue for consideration. The requesters, sensibly seeking the path of least resistance, go around you and push their requests through friendly execs or account managers instead.
In either case, you'll end up burning months on features that don't get used – and you'll get the blame. Congratulations! You've landed slap bang in the Feature Request Trap. The result? Pain and confusion. It's dark, it's cold, and the walls are slimy AF.
Both of those patterns are borne from approaches that are totally understandable ... but totally miss the point.
Feature requests aren’t perfect information or directly instructive. Neither are they worthless or to be ignored. They're breadcrumbs that will lead you towards the thing behind the thing – if you follow the trail far enough into the undergrowth.
Seeking out the problemplex
The lure of feature requests is that features are relatively fun to think about – and relatively easy for the requester to talk about.
People imagine the features that they're able to imagine. They’ve seen dashboards in Notion, so they ask for a dashboard. They’ve seen map views in other apps, so they want a map view.
(If this sounds like we're being sniffy or holier-than-thou, it's not meant to. Lord knows we too are those "people" we speak of. We're all limited by the same set of cognitive constraints.)
Beneath any requested feature lies an intuition that said feature will help resolve a bunch of interconnected problems. Let's call it a problemplex.
People mostly can't just tell you about these interconnected problems. A problemplex is a helluva messy beast. It's got teeth on all fifty of its fingers and a bum coming out of its front ear, and an itchy rash that WILL NOT GO AWAY despite the daily application of steroid cream.
Plus, much is outside the feature requester's realm of understanding. They won’t understand your technical architecture. They can't explain their own situation in a neat problem-solution form for you, because their reality's not actually like that. And they don't understand your orgs internal constraints, or how existing features actually fit together. Features aren’t Lego bricks you can snap together just anyhow – they’re like parts of an organism, each part affecting all the other parts.
"How do you currently ... ?"
So, what to do instead of saying no to feature requests or sleepwalking into building them?
Treat every feature request as a reasonable placeholder for something more interesting.
Then use the placeholder to increase the level of granularity by breaking down the big request into smaller pieces. Specifically, into a chain of perceptions, decisions and behaviours.
A good way to do this is to ask the requester about how they imagine themselves interacting with what they've requested.
"OK, so you can see the dashboard in front of you. What's the first piece of information you look for on that dashboard? Great, what does that tell you? And what do you do next? Then what happens?"
The chain of perceptions, decisions and behaviours you're trying to get at is non-trivial for the requester to put into words. It may require several conversations. You might need to go get some of the data in question for real, so you can show real examples rather than hypotheticals.
The requester's decisions will depend on real-world triggers that show up in data. Sometimes you'll find that the anticipated chain of events falls to pieces and you discover that something apparently unrelated matters more. Expect surprises.
Again: the magic can't be found in the dashboard feature itself. Only by zooming in to understand what decisions your requester needs to make, using something-that-we'll-call-a-dashboard-for-now.
"You said response time is the critical piece of information you'd look at first. So what needs to happen when response time is, say, 8 seconds vs 3 vs 0.3?"
Keep following those tasty chunks of carbohydrate
NOW you're getting somewhere. But wait! Don't stop! There are yet more breadcrumbs to be ravenously gobbled up.
Next, get the requester to tell you how they're managing to do the thing that matters to them at the moment:
- "Now walk me through what it takes for you to get that done today."
- "What makes that so bad?"
- "What other approaches have you considered, and what makes THEM bad?"
- "What if you couldn't get this data at all? Play out what would happen."
The conversations you have with the requester off the back of these prompts will surface even more clues about the thing behind the thing – the invisible problemplex behind the feature request.
And you'll almost always be able to generate a bunch of simpler, easier-to-implement ideas that work even better than the requested feature would have. And the requester will be open to them because you've also really listened to their idea.
Pretty map make feel good
Here's an example from a conference talk we saw a few years ago.
Users of customer service platform Intercom were asking for a “better” map view. Naturally, the team had a guess about why. Surely the reason behind this request was a desire for geographic analytics?
But then they dug a little deeper.
In short, they learned that users were in fact pasting map screenshots into company slide presentations for conferences and events. The visual was a cute way to show off a company's global scale. Rather than for geographical analysis, as they'd first thought, the map was being used as a form of social proof.
They were able to dodge the misery of wasting months building unwanted analytics tools. All they did was redesign the map so it would look even more fabulous in a slide deck, and be easier to load at high resolution.
Bingo. Happy customers with a fraction of the development effort.
A place beyond the placeholder
When you break down feature requests into real-world behaviours by upping the granularity, you reliably find three valuable and delicious things:
- New, smaller, more focused ideas that are linked to measurable behaviours. You can often test these at small scale to check they're worth building.
Maybe you realise that the requester suggested a dashboard because they need a way to see one critical chart.
- The workarounds that people are already using. This is valuable intelligence! People going out of their way to get something done is one of the strongest forms of evidence that it's worth doing, even if they can't explain the real reasons why.
Maybe you find out that the requester has a team of people digging through reports and spending 2 hours creating this chart each week.
- Ideas that remix existing functionality instead of building from scratch. This is great because it's usually way easier to repurpose functionality you already have. This can deliver non-linear results, fulfilling your dream of low effort and big impact.
Maybe you realise that you could simply use your existing charting and messaging functionality to email the requester the chart weekly. Or pop it into Slack or an SMS. No need for them to go to a dashboard. No need for you to build one. Everyone's delighted.
One team we worked with turned a single “let's copy this feature from a competitor app” idea into at least 12 micro-improvements. All of which were more relevant and actionable than the original big idea.
OK, if you insist, here's another example
Let's take a feature request most of us will have heard before:
"We need search like Amazon."
Obviously this will depend on your context. But if you have the aforementioned conversations to break the request down into different sets of smaller pieces, the list of micro-improvements you come up with could end up looking something like this:
It's awkward to search using mobile keyboard
- add autocomplete to existing search
- or show a list of recent or popular searches
- or add voice search
- or ...
It's annoying when searches generate no results
- show suggestions when a search returns no results
- or create a mechanism for people to get notified when the gap is filled (like "email me when this is back in stock")
- or add "people who searched for this ended up here" to empty results pages
- or add a manageable list of redirects
- or ...
People keep finding old information and missing newer results
- sort search results by recency or trending popularity
- or temporarily bump recently added information to the top of results to test relevance
- or add "people who looked at this also looked at this new item" on results
- or ...
Searches are returning too many results
- add a filter (like price range, colour, department, ...)
- or ...
The team running the site don't know enough about what's being searched for
- send a weekly digest of trending search terms to sales team
- or ...
... and that's just a fraction of what might be going on.
This is how you tangle with a problemplex.
Stop acting on a falsely simple feature request. Start sensing a bundle of interconnected problems and designing multiple tiny options for how to mitigate each of them.
Reach for this alternative approach whenever you feel the urge to add a clog and a circus tent to the teetering mountain – or attempt to control the flow of requests with process barriers and cut yourself off like an oxbow lake.
That's when you know it's time to treat requests as clues, not commands, and follow the breadcrumbs to find out what the requesters actually need.
What’s your experience with feature requests? Have you found similar patterns?
Tom & Corissa x
P.S. Multiverse Mapping is an easy way to do all this ☝️ and you won't want to miss the next Multiverse Mapping Live! on 3rd September at 5pm UK time (it's free).
