The Test to Run Before You Write a URS
Apollo was the Roman god of light, prophecy, medicine, and truth-telling, the deity you consulted when you needed to know what was actually happening, not what you hoped. A user requirements specification (URS) is the equivalent of a small prophecy, a claim about what the customer needs before anyone else touches the project. Apollo's discipline is the same discipline a Product Manager (PM) owes the URS: write down what's provably true, not what merely sounds convincing.
A URS survives if you can write the sentence that would prove it wrong. If you can't, you don't have a requirement, you have a wish wearing a lab coat.
The gap in most URS documents is that they're written in a way that sounds specific without being falsifiable. Call it benefit poetry: language that promises value without ever saying how you'd know if the value showed up. “Improved workflow confidence” may make sense in the initial review meeting. However, the true test of a well written URS is being able to answer R&D when they ask: what observable behaviour proves the URS was met.
You ran the site visits, wrote the concept statement, and the engineering lead is asking for a URS they can translate into functional specs by Friday. Thinking about it, you already know that several lines in the URS wouldn't survive someone asking you to prove it.
This is squarely PM territory. Once R&D takes a solid URS and writes the corollary functional requirements spec that tells engineering how to build it, that's their discipline to get right. What to watch out for is making sure that you've thought through how the URS is falsifiable.
The Falsifiability Test
This borrows a principle from outside product management. The philosopher Karl Popper argued that a claim only counts as scientific if you can specify what evidence would prove it false. A URS deserves the same test. If you cannot write the sentence that would prove your requirement wrong, you don't have a URS, you have a wish wearing a lab coat.
It's about making sure the outcome you're asking for is something a person could actually watch happen, or watch fail to happen. A testable URS has three parts, and all three have to survive being read by someone who wasn't in the room when you wrote them.
The first two parts make a claim precise enough to check. The third is where falsifiability actually happens: naming, in advance, the result that would prove you wrong.
Observed condition. What specific, watched behaviour does this address, not a stated preference, a workaround someone actually performed. “Researchers want more confidence in low-abundance calls” is a preference. “Three of four core lab technicians manually re-ran dPCR wells flagged as ambiguous rather than trust the auto-flag” is an observed condition.
Measurable threshold. A number, not an adjective. Not “high confidence,” but “a technician accepts the call without repeating the run in at least 95 percent of samples.”
Named disconfirming outcome. The sentence that proves the URS wrong. “If technicians repeat more than 5 percent of runs due to distrust in the call, this URS has not been met,” not “we'll know it when we see it.”
Two more things worth naming, since they protect the test above. State what the customer achieves, not how the product achieves it. “Reduce sample re-runs” is outcome-based. “Add an AI confidence score” is a solution masquerading as a requirement, it locks you into one implementation before you've confirmed the outcome itself is right, and if it fails, you won't know whether the need was wrong or just that technology choice. Keep it technology-agnostic for the same reason: name the outcome, and let R&D own how to get there.
Benefit Poetry vs. the Testable URS
Same intent, two different sentences. Only one of them gives R&D something to build against.
| Benefit poetry | Testable URS |
|---|---|
| “The dPCR software should give researchers confidence in low-abundance calls.” | Observed: three of four core lab technicians manually re-ran ambiguous dPCR calls rather than trust the auto-flag. URS: a technician accepts an ambiguous call without re-running the well in at least 95 percent of samples, verified across three assay types. |
| “The extraction kit should produce clean, usable samples.” | Observed: technicians at two of three site visits repeated the extraction protocol at least once a week after failed downstream sequencing. URS: a technician gets a sample pure enough to sequence on the first attempt in at least 9 of 10 preps, without a repeat extraction. |
| “The plate reader software should be easy to interpret.” | Observed: new hires in core facilities asked a senior colleague to confirm borderline results during their first two weeks on the instrument. URS: a first-time user distinguishes a true positive from background noise without contacting support, on their first plate. |
What an Untestable URS Actually Breaks
I've watched a PM hand off an untestable URS, “gives researchers confidence in the call.” R&D got partway into drafting the functional requirements spec before hitting the wall, they couldn't write a verification plan for “confidence,” because nobody had said what evidence would prove it true or false. The URS bounced back to the PM for clarification, a full review cycle spent discovering, at the FRS stage, what should have been settled before the URS was ever approved.
Before you hand a URS to R&D, try to write the sentence that would prove it false. If it comes easily, the requirement was already testable. If you have to think hard, or can't do it at all, that's the tell.
Write What's Provably True
Apollo's prophecy wasn't valuable because it was inspiring. It was valuable because it could be checked against what actually happened. A well-written URS earns that same trust, or it doesn't earn any.
So before you send the next one to R&D: if a stranger read only your URS, with none of the context in your head, could they tell you exactly what would prove it wrong? If the honest answer is no, you already know which sentence to go rewrite.
Frequently asked questions
How do I push back when a customer says something vague like “make it easier to use”?
This is the most common version of benefit poetry, and it usually isn't malicious, the customer genuinely believes they've given you something specific. Ask them one question: what would you watch a user do, or not do, that would tell you this requirement of “easier to use” had failed? Their answer is almost always more concrete than the original sentence, and it's the observed condition you were missing.
If a customer says “make it easier to use,” and the honest answer is “the lab director switches to a competitor's system after watching a new hire struggle through setup twice,” you now have a measurable threshold for your URS.
What if my VOC data doesn't clearly point to a number yet?
Then you don't have a testable URS yet, and writing one anyway just moves the problem downstream to R&D, who have less context than you. It's fine to flag a requirement as provisional, “threshold TBD pending three additional site observations,” rather than inventing a number to look finished. A provisional URS that's honest about its gap is more useful to R&D than a confident one that's quietly wrong.
How do I know if my URS is describing an outcome, or a solution?
Ask whether the requirement survives being achieved a completely different way. “Reduce sample re-runs” survives, dPCR, an assay redesign, a software fix could all satisfy it. “Add an AI confidence score” doesn't survive that test, if the outcome isn't reached, you can't tell whether the need was wrong or the technology choice was. Stay in outcome language, and the falsifiability test still works. Bake in a solution, and you've broken the one thing that made it testable in the first place.
