Your intelligence consumer says 'just send me anything relevant' - how do you get real requirements out of that?

## What the request really is 'Send me anything relevant' is not laziness. It is a rational request for optionality from someone who does not know what intelligence can do for them, has been burned by irrelevant reporting, or does not want to be on record having ranked one concern above another. Taking it literally produces a firehose the consumer stops reading within a month, after which the intelligence function has no consumer at all and does not know it. ## Work backwards from decisions The elicitation technique is to stop asking about threats and start asking about the calendar. What do you have to decide in the next quarter? What are you being asked to sign off? What did you decide last quarter that you were uncomfortable about? For a head of plant operations at a mid-size manufacturer, that list is concrete: whether to force re-enrolment across a contractor population whose laptops you do not manage; whether to keep a remote-access route for a maintenance vendor; whether to renew a monitoring contract; whether an acquisition's estate can be connected before its own controls are verified. Each of those has an evidence question hiding behind it. Whether to force contractor re-enrolment turns on whether contractor credentials are actually circulating and whether the identity provider shows those accounts being used from places they should not be. That is a requirement, and it was extracted from the decision rather than from a threat landscape report. ## Make the consumer cut the list Draft more requirements than you can serve and present them ranked, each one page: the decision, the date, the question, the so-what clause, what it costs to collect and who collects it. Then ask the consumer to cut. This does three things at once. It converts an abstract 'everything' into a visible trade between their own decisions. It transfers ownership - a requirement the consumer cut down to is theirs in a way one you handed them never is. And it prices intelligence: collection is broker subscriptions, contracted provider hours and analyst attention, all finite, and the consumer needs to see that answering the fourth question means not answering the first properly. ## Arbitrating between consumers With several consumers the same logic scales, badly if you let it. Two heads of function will both want first place. Rank on the consequence and imminence of the decision each requirement serves, not on the seniority of who asked - and make the ranking visible to both, with the reasoning written down. Where they genuinely tie, the sponsor of the intelligence function arbitrates; the analyst should not be quietly absorbing that political call inside a prioritisation spreadsheet. ## Refusing to write a requirement The hardest and most valuable move here is declining. If a consumer will not name a decision, no requirement should be written for them. Writing one anyway produces the standing topic-shaped requirements that sit silent for years and consume collection nobody will act on. Say plainly, to the consumer and to the sponsor, that there is no requirement here yet, and offer to come back when a decision is on their calendar. This reads as risky and is in fact the opposite: it protects the credibility of the requirements that do exist. ## Failure modes to name - **Vendor-shaped requirements.** Writing what your subscription happens to cover, so the supplier sets your consumers' priorities. - **A list of thirty.** If everything is a priority requirement, none is, and collection follows whatever arrived most recently. - **The unread report.** Delivery is not consumption; if nobody can point to a decision the reporting informed, the requirement was fictional however well written. - **The analyst as consumer.** Requirements written for what the intel team finds interesting are the most persistent kind of dead weight, because nobody outside the team ever asks about them. ## Making it durable Run the elicitation on a cycle, quarterly is typical, and start each cycle by walking the previous set: which were answered, which decisions were taken, which lapsed. Consumers who see their last set closed out engage with the next one; consumers who never see the loop close revert to 'send me anything relevant'. Record, for each answered requirement, which decision it fed - not as a performance measure, but as the raw material for the next conversation about what is worth collecting.