"SSO" is a topic, not a request

Somewhere in your backlog there is an item called SSO. It has been there for a while. It has a priority, possibly an estimate, and at some point a team will pick it up.

Nobody knows what it means. It could be a single customer wanting Okta. It could be the enterprise deal that dies without SAML. It could be an engineer who once said the auth code was a mess. Those are three different pieces of work with different sizes, different owners and different answers, and the queue represents all of them with the same three letters.

The grammar deceives you

A queue displays one line per item, and a noun phrase in that line looks exactly like work. "SSO" sits beside "Reduce mobile checkout drop-off" with identical typography and the same affordances, so the eye treats them as peers. They are not remotely peers. One states an outcome; the other names a region of the product where something might happen.

The full set is familiar: reporting, onboarding, performance, mobile, search, notifications, the admin panel, tech debt. Every one of them will be in a queue near you, and every one is a subject rather than a request.

They accumulate because they are the honest output of a five-second thought. Someone remembers something during a meeting, types the domain it lives in, and moves on intending to come back. The intention is real. The returning is not.

The test

One question separates a topic from a request:

After this is done, what is true that is not true today?

"SSO" cannot answer it. "Enterprise customers can sign in with their own identity provider instead of a DeliverySheet password" answers it in a sentence, and in doing so quietly decides four things the three-letter version left open — who it is for, what mechanism, what it replaces, and how you would know it worked.

The test is better than "is this specific enough?" because specificity is a judgement and this is a check. Either a sentence exists or it does not, and anyone can apply it without knowing the domain.

It also fails the right things. "Improve reporting performance by 40%" is admirably specific and still a topic, because it does not say what anyone will be able to do afterwards that they cannot do now. Specific and empty is a real category, and metrics are its favourite disguise.

Do not fill it in for them

Here is where a well-run team goes wrong, and it goes wrong out of diligence.

Someone competent looks at "SSO", knows roughly what it must be about, writes a proper description, and moves it along. The queue looks healthier. A guess has just been laundered into a requirement — and once it is written in full sentences, nothing downstream will ever question it again, because it no longer looks like a guess.

This is how work gets built for a customer nobody has spoken to. Not through carelessness; through a thoughtful person doing a favour at the one moment where the ambiguity was still visible.

The alternative costs less. Send the question back to the person who has the answer, in the form that is easiest to answer: if we build this, what will someone be able to do that they cannot do today? Most people reply in one line. The ones who cannot have just told you something more valuable than a reply, which is that the request was a reflex rather than a need.

Keep the topic, do not launch it

None of this means deleting them. A topic is genuine signal — five items that all say "reporting" is a real fact about your product, and often a more important one than any single request.

What a topic must not do is enter the part of the process where dates get attached. It can sit in a list of things to look into, be counted, be grouped, and be raised at planning as a question: reporting comes up constantly, should we go and find out what people actually mean? That is a discovery task, it has an owner, and it is honest about being one.

The failure is not keeping topics. It is letting one get estimated.

Why it survives the first conversation

A topic that reaches planning tends to survive it, which surprises people.

The reason is that a topic is unfalsifiable. Nobody in the room can argue against "reporting" — there is nothing in it to disagree with. A specific request invites objection ("that only helps two customers"), so it gets tested, sharpened, sometimes killed. The vague one glides through and arrives at a team, where the ambiguity finally becomes concrete in the form of an engineer making a decision they were never meant to make.

Vagueness is not neutral in a prioritisation meeting. It is an advantage, and that is why unclear requests survive at a higher rate than clear ones.

How DeliverySheet does it

The intake assessment treats this explicitly. A bare subject word — SSO, dashboard, reporting, onboarding — is classified as a topic, never as a stated need, and the instruction is direct about it: a need is set only when the text actually says what should change or what is wrong. So typing "SSO" produces a recognised topic and an unmet bar, which is the accurate reading of what you typed.

What comes back is one question rather than a rejection, with the topic already understood, and the answer is stored as a clarification alongside the original text rather than merged into it. A month later the record shows both what arrived and what was asked — which is the thing that settles the argument about whether a requirement was ever really stated.

Two related pieces: the one-sentence bar for entering the process at all , and what has to be present before a request can be shaped .