What people ask for is not what they need

There is a move that keeps the evidence and drops the instruction, and it fits in one short conversation. It has three parts and they go in this order.

Restate the problem back. Not the feature, the problem. "So when the Monday numbers come out, you need to get them in front of four people who cannot log in, and right now that means screenshots." If you have it wrong, they will correct you immediately and enthusiastically, which is the point. If you have it right, you have just done something almost nobody does for them: you listened past the sentence.

Ask what they would do if the feature did not exist. This is the gentlest possible way to find the workaround, because it does not sound like a refusal. Sometimes the answer is "nothing, I would just keep screenshotting", and now you know the cost. Sometimes it is "oh, I would just ask Sam", and you have learned the problem already has a solution, which is a very different conversation.

Ask what happened the last time. One incident, with a date attached. "Last Monday I sent four screenshots and one of them was the wrong week, and the board meeting used it." That single sentence outranks a page of general description, and it hands you what better would have to mean.

Notice what has not happened. You have not agreed to build the print button, and you have also not said no to it. You have taken the request more seriously than the person expected, which is why this rarely feels like a brush-off.

Build everything requested. This is the popular failure because every individual decision looks reasonable and helpful. The effect is cumulative rather than immediate: you become an order-taker, which means the queue now decides what the product is, and whoever asks most often wins. The product becomes incoherent in a specific way, where each part makes sense to the person who asked for it and no part makes sense to anybody arriving fresh. Nobody can point at the meeting where that decision was taken, because it never was one.

Dismiss requests. This looks like the disciplined alternative and it is far worse, for a reason that is easy to miss. The requests were your cheapest source of evidence about where the product hurts. They arrive unprompted, they cost nothing, and they come from people doing the actual work. Dismiss enough of them and they stop arriving. The problems do not stop, you just stop hearing about them, and the silence is indistinguishable from things going well right up until somebody leaves.

The asymmetry matters. Over-building wastes effort you can see. Dismissing destroys an information channel you cannot see, and it does not grow back quickly once people have decided you are not worth telling.

The third move avoids both because it separates two things that got glued together: whether to take the request seriously, and whether to build the named thing. Those were never the same question.

The primary source was tracked down and read for this session. It is a keynote slide deck from a software conference in 2002, titled ROI - It's Your Job!, by Jim Johnson, copyright The Standish Group International. It is not hosted anywhere current. It survives in a Wayback Machine capture of the conference host, and that is the only reason any of this can be checked at all.

One slide is titled "Features & Function Usage". It is a pie chart with five slices: never 45%, rarely 19%, sometimes 16%, often 13%, always 7%. Those five numbers are what the slide says. The famous 45% is the first slice. The other famous number, "64% of features are rarely or never used", is 45 plus 19, from the same pie, on the same slide. Two figures, one source, and they have been travelling separately for twenty years as if they were independent confirmations of each other.

Here is the finding. The slide carries no sample size, no year, and no methodology. Not a footnote, not a caption, nothing. The deck does have a general methodology slide elsewhere, mentioning tens of thousands of projects since 1994, but that describes a separate body of success-and-failure research, not this pie. The pie itself follows another slide that is equally uncited.

Two later accounts of what was actually measured exist, and they disagree. One says Standish stated in 2015 that it came from four internal applications. Another has a 2010 Standish report citing an unpublished 1996 study of a hundred custom applications. Four applications or a hundred, 2002 or 1996: neither account could be corroborated against a primary document. The honest position is to state that the two accounts disagree and not to pick one.

So never call it a study. It is one unsourced pie chart in a conference deck. The figures are real in the sense that they are really on the slide. Nothing further is known.

In February 2019 Pendo published a Feature Adoption Report. Unlike the slide, it says what it measured: 615 subscriptions, all customers of more than a year, with usage aggregated over a three-month period, across banking, HR technology, education, logistics, healthcare and e-commerce. That is telemetry. Software reporting what people actually clicked, not a survey and not a recollection.

Its split is frequent 12%, moderate 8%, rare 56%, never used 24%. It also reports that 12% of features generate 80% of average daily usage volume, which is the part most worth carrying around.

Resist the urge to say this confirms the 45%. It does not, in both directions at once. Pendo's never bucket is 24%, which is a lot lower than 45. Its rarely-or-never total is 80%, which is considerably worse than 64. Different definitions of the buckets, different populations, seventeen years apart. Two numbers that disagree in opposite directions are not corroboration, they are two numbers.

And state the limit whenever you quote it. Pendo measured Pendo's own customer base: B2B software companies that bought a product analytics tool. Real telemetry, honestly described, and not a representative sample of software in general. No peer-reviewed replication of any of this exists, and no comparable published figure from another analytics vendor could be found. The absence is part of what you know.

Once the pile is grouped by problem, the tempting next move is to count. Resist it for one minute, because a raw count is almost always a measure of who is comfortable asking rather than where the pain is.

Three things to record next to each group, in this order.

Who asked. By name, not by department. A group of four requests that all came from one enthusiastic person is a different object from a group of four requests from four people, and a plain tally cannot tell them apart.

How many distinct people. This is the count that means something. Two separate people arriving independently at the same problem is a stronger signal than eight requests from one.

Whether they hold the job. The most important and most skipped. Is the person asking the one who actually does the work, or are they relaying, guessing, or advocating on behalf of somebody they last spoke to in March? A request from the person with the problem and a request about somebody else's problem look identical in a ticket queue and are worth wildly different amounts.

The quiet outcome of doing this properly: some groups shrink to nothing, and one group you had not noticed turns out to have three different people circling it with three different feature names.

Every pile has at least one. A request where, after honest effort, you cannot write down what problem it solves for whom. Not a hard one, not a vague one: one where the problem line comes out empty.

There are three usual explanations and they need different handling. Sometimes you simply have not asked yet, and the problem is real and obvious the moment you do. Sometimes it was copied from another product, because somebody saw it there and it looked professional. And sometimes it exists because it was on a list, and the list came from a meeting, and nobody in the meeting had the problem either.

The first is fixed with a ten minute conversation. The other two are the interesting ones, because they are how a backlog silently fills with work that will be built, shipped, maintained for years, and never used. Finding one of these in your own pile tonight is a genuinely useful outcome, and it is why the last stage of the build-along asks for exactly that.