“Feature Request” is one of my favourite rant inspirers of late.

Not that there aren’t plenty of good features/ideas/problems-to-be-solved that are suggested by customers, partners and colleagues.

But that it’s so hard to find the real gems in a pile of hay, and too much of what gets filed are “solutions with no clear problem statement”.

Why do I get so invested in this process? Customer has a problem, they’ve figured out a great way that would totally solve their problem, and now it’s just their challenge of coercing the vendor until they finally gets around to delivering it. Usually later than you wanted, and not like what you asked for, and couched in go-to-market-friendly language that makes for a fun guessing-game of “does this solve the problem I needed addressed?”

This dysfunctional interaction wastes a whole lot of execution and onboarding time. Why don’t we do it better up front?

Here’s my experience, after doing product work in four separate tech companies, where I’ve been focusing on building user- and developer-productivity features of existing platforms that are intended to retain satisfied customers for years:

• “feature requests” are often one-liner, “obvious” statements of something the customer is frankly frustrated we hadn’t already done – e.g. “add these three fields to the search API” – with no context why this isn’t simply a nice-to-have that someone heard and repeated up the channel, leaving us to over-pivot on low-priority items or assume that all such uncontextualised requests are likely low-pri noise.
• They’re a request for a big-F Feature – which is a solution to an implicit problem (e.g. “We need executive reporting”) – not a Job, or a gap, or an unmet Decision, any spin of which are much more oriented around problems to be solved (e.g. “I need to produce a monthly report for our CISO of unique malware found, to justify the monthly subscription cost to the Finance department”)
• They often assume a particular implementation and don’t tell us why other alternatives (that could well achieve the same outcome) are inferior – e.g. request comes in of the form “I need to export our threat intel feeds from this page”, when we have a very simple SDK that already has example scripts for doing just that. That there are gaps between one implementation and another are natural; the important bit is in how much unworkable friction the alternatives introduce.
• There’s no believable way from the telephone game of distilled need to gauge how critical this need is – and since you all know vendors are slow to respond, you must assume that we’ll only respond to emergencies and so you’ll characterise the request as a “P0” even if there’s no rush and no critical impact from its absence

By calling this artifact of indirect communication (from customer to “decison makers who can and might decide to insert this into planned execution”) a Feature Request instead of a Problem Statement or a Proposal For Discussion, it assumes this is the end of communication, there’s no need for further background or context, and that the fastest way to get the vendor to fix the problem is to boil it down to “what the solution looks like”.

It absolutely assumes and encourages “tell the vendor what to implement” rather than “tell them what problem you’re having, what decision or action you’re unable to achieve without a solution to this problem, and how this will significantly impact your business operations”.

Why is it even called a feature request? When did we start asking our customers what to build, rather than asking our customers what problems they have, and helping them find solutions? It’s especially important in our line of work, as curators between market and engineering, to find common problems across customers and market segments, and help engineers address those pain points to make customers delighted, productive and loyal.

These days I make an effort to engage with any feature request that isn’t (a) already aligned to solidly-planned enhancements and (b) isn’t clearly spelled out why this matters to the customer. Our “feature request” systems aren’t great for even indirect communication with the originating customer, so many of these conversations get delayed for months if ever. I’ll increasingly root around Salesforce and Slack to reach out to associated Success Manager or Solution Engineer, but that’s still lacking the fidelity of the direct conversation with the person-with-the-problem. It’s a journey.

So if you see me try to stifle rolling my eyes the next time you ask me for the likelihood I’ll deliver this customer’s quick Feature Request, please assume it’s nothing personal – and that I’m very amenable to conversations that increase the likelihood we’ll address the problem.