The one person who understands the requirement is the one person who never has time to write it down

Here is the week you already recognise. You have a purchase that turns on one technical fact. Does the platform handle the legacy authentication flow, or does it not. Everything else in the evaluation is downstream of that answer. And exactly one person in the building actually knows it, the senior engineer who owns that integration, the person whose calendar is a wall of thirty minute blocks with no gaps. You send the question on Monday. You send it again on Wednesday. By Friday you have a polite reply that says let me get back to you, and the reply never comes. The evaluation moves forward anyway, on a guess, because the deadline does not care that the one detail the decision depends on is still missing.

This is not a discipline problem and it is not a bad person. It is a structural one. The people who understand a requirement best are, almost by definition, the people who are most oversubscribed, because deep knowledge is what makes them useful everywhere at once. The buyer's process then asks the scarcest resource in the room to do the most expensive thing: sit with a blank document and author. So it does not get done, or it gets done badly, or it gets done by someone with more time and less knowledge. We wrote about that substitution in the spec written in fifteen minutes between meetings. This post is about the other half of the same trap: the expert who could fix it in five minutes if you never made them start from nothing.

Expert attention is the real bottleneck, not documentation

Procurement teams instrument the wrong scarcity. We measure cycle time, we measure number of vendors evaluated, we measure the length of the requirements document. None of those is the constraint. The constraint is minutes of attention from the two or three people who hold the load bearing knowledge. Everything else in the pipeline is elastic. You can add analysts, extend timelines, run more comparisons. You cannot manufacture more of the senior architect's time, and you cannot substitute for what is in their head.

Once you see attention as the bottleneck, most standard intake rituals look actively hostile. A requirements workshop asks eight people to protect ninety minutes on a shared calendar, which in practice means it slips three weeks and the one person you needed sends a delegate. A blank requirements template asks the expert to convert tacit knowledge into prose, which is genuinely hard cognitive work and lands at the bottom of every to do list. The workshop and the template both fail for the same reason. They demand authorship from someone whose supply of authoring time is close to zero.

So the detail arrives late, or it arrives filtered through someone who did not fully understand it, or it does not arrive at all and the team proceeds on assumption. That last case is the expensive one, because the assumption sits quietly inside the shortlist until a technical stakeholder joins in month two and reopens everything. We traced that exact failure in the architect pulled in late who reopens everything you already settled. The late correction is the same knowledge you needed on day one, arriving after the sunk cost is large enough to make it unwelcome.

Why the problem persists even when everyone knows it

Every buyer already knows the expert is the bottleneck. The problem persists anyway, and it is worth being precise about why, because the persistence is what a tool has to defeat.

First, the cost of asking is invisible to the asker. When you send the engineer a blank template, the effort of filling it looks like their problem, not yours, so nothing in your process pushes you to make the ask cheaper. Second, the effort is front loaded onto the hardest step. Authoring from nothing requires the writer to simultaneously recall the fact, decide what is relevant, and phrase it for a non expert audience. That is three jobs, and the expert has time for maybe one. Third, correcting is dramatically cheaper than creating, and no traditional intake exploits that gap. Show the same engineer a draft that is eighty percent right and wrong in one specific place, and they will fix the wrong place in ninety seconds, because recognition is faster than recall and reaction is faster than composition.

The whole answer sits in that third point. The reason experts do not fill in blank forms is that blank forms ask for creation. If you can convert the ask from create into correct, you move the task from the bottom of the to do list to something they will do while waiting for a build to finish. The design goal is not more expert time. It is a task shaped so that a very small amount of expert time is enough.

The platform motion: intake that drafts, expert that corrects

This is the specific job Vera is built to do. Instead of handing the expert a blank requirements document, Vera runs a short structured intake, a small set of targeted questions rather than an open essay prompt, and drafts the requirement from the answers. The draft is not the finished spec. It is a first pass that is deliberately close enough to be worth correcting and specific enough that the errors are obvious to the person who knows.

The intake is short by design because the whole thesis is that expert time is the scarce input. Vera front loads the recall problem by proposing answers the expert only has to confirm or overrule. It marks its assumptions rather than burying them, so the reviewer can see exactly where the draft is guessing and aim their few minutes at those spots. This is the same discipline that stops a request arriving as a product name instead of a problem, which we covered in the intake ticket already names the vendor. A structured intake forces the underlying need to the surface before anyone writes a spec around a guess.

Where the draft goes after the expert signs off

A corrected requirement is only useful if the rest of the pipeline consumes it. Once the expert has fixed the load bearing detail, that requirement feeds the benchmark comparison and the report set without a second round of retyping. The benchmark library covers 1,483 vendors, and the platform ships more than 25 report types, so the requirement the expert corrected in ten minutes becomes the frame against which candidates are scored rather than a document that dies in a shared drive.

Behind that motion the platform runs its heavier work so the buyer does not have to. Six specialist agents and ten inbox agents handle research and monitoring, and 30 background jobs keep the record current. The point for this problem is narrow and specific. The expert touches the one thing only they can supply, the load bearing fact, and everything downstream of that fact is done by the system rather than by another round of chasing.

What this does not solve, honestly

A drafted requirement is only as good as the intake it came from, and a short intake can miss context that no set of questions would surface. If the requester who answers the intake genuinely does not know the constraint, Vera drafts a confident wrong thing, and a confident wrong draft can be more dangerous than a blank page because it looks finished. The flagged assumptions reduce that risk but do not eliminate it. Someone still has to route the draft to the person who actually knows.

Vera also cannot force the expert to open the email. It makes the task small enough that a busy person will plausibly do it, which is a large improvement over a task that never gets done, but ten minutes of attention is still ten minutes someone has to give. If the organisation has no norm that a Vera draft gets a same day glance from the named reviewer, the draft waits like everything else, just closer to correct while it waits.

And a corrected requirement does not settle a disagreement between stakeholders who want different things. When finance wants the floor and the business wants everything, no amount of clean drafting reconciles them, as we argued in finance wants the floor, the business wants everything. What Vera does is narrower and worth being precise about. It takes the one input that is scarcest, expert attention, and spends it where it earns the most, on correcting a draft rather than authoring from nothing. The detail your decision depends on arrives on time because you finally asked for it in the shape a busy expert can actually give.

Want to be updated when major licensing and pricing changes land? One analyst brief a week: the price rises, metric changes and audit campaigns that move software costs. Work email only.