Product Thinking · Published October 15, 2026
Grading the Confidence Behind Requirements
Treating requirements as facts is the most common cause of delay. Requirements differ in how reliable they are.
When a client says users will definitely use a feature, that carries very different weight from saying the feature follows their existing approval policy. The first is a guess, the second a constraint. Yet requirement documents often write both in the same tone.
Three levels of confidence
Certain: driven by policy, contract or regulation, such as invoice formats and approval levels.
Likely: supported by historical data or current operations, such as how many transactions the current system handles daily.
Assumption: based on judgement or industry habit and needing validation, such as users being willing to fill in this form.
How to use the grades
Certain items go straight into planning. Assumptions get a minimal test, such as releasing to a single department.
Label each item in the document and spend review time on the assumptions, because that is where the risk sits.
Admitting uncertainty is professional. Treating uncertainty as certainty is not. Grading puts effort where judgement is actually needed.
← Previous post
Why Enterprise Systems Start to Age After Three Years
Next post →
Retrospective: Why Acceptance Took Half a Year
Want to apply these ideas to your project?
We are happy to go deeper into implementation details, or to discuss the specific questions you are facing.
Start a conversation →