The One Question That Saves Every PRD
Vague requirements become specific when you ask one question: 'How will we know this is done?' Here are real examples of how it transforms PRDs.
The Question
Every vague requirement I’ve ever seen can be fixed with five words: “How will we know this is done?”
That’s it. That’s the whole trick. When you force yourself (or your team) to answer this question for every line in a PRD, vague wishes turn into testable criteria. It’s embarrassingly simple, and it works every time.
Why Requirements Stay Vague
Product managers write vague requirements for understandable reasons. You’re thinking about the big picture. You know what you mean. The words feel clear enough when you’re writing them.
The problem shows up later, when an engineer reads “make the dashboard more intuitive” and has to turn that into code. What does intuitive mean? Fewer clicks? Faster load times? Different layout? Better labels? All of the above?
Without a clear definition of done, the engineer picks an interpretation. The PM had a different one in mind. The review meeting goes badly. The sprint slips.
One question prevents all of that.
Four Vague Requirements, Transformed
”The onboarding flow should be user-friendly”
Ask: How will we know this is done?
Becomes: A new user can complete account setup and reach the main dashboard in under 3 minutes without contacting support. The flow has no more than 4 steps. Each step has a single primary action. Drop-off rate between steps is under 20%.
Now an engineer knows exactly what to build. A QA engineer knows exactly what to test. A designer knows the constraints. Everyone is working toward the same target.
”Improve search performance”
Ask: How will we know this is done?
Becomes: Search results return in under 200ms for queries up to 50 characters against our current dataset (2.3M records). Results are ranked by relevance using the updated scoring algorithm. The first result matches the user’s intent for at least 85% of the top-100 most common queries.
“Improve” is the most dangerous word in a PRD. It means nothing without a number. The question forces you to define what improvement looks like, specifically.
”Users should be able to easily export their data”
Ask: How will we know this is done?
Becomes: Users can export all their data (projects, tasks, comments, attachments) as a CSV or JSON file from the account settings page. The export completes within 60 seconds for accounts with up to 10,000 records. The exported file includes all fields visible in the UI. Users receive an email with a download link when the export is ready.
“Easily” disappeared entirely. It was replaced by specific behaviors: what formats, what data, where in the UI, how long it takes, and how the user gets notified.
”The notification system should be reliable”
Ask: How will we know this is done?
Becomes: 99.5% of notifications are delivered within 30 seconds of the triggering event. Failed notifications are retried 3 times with exponential backoff. Users can see a log of all notifications sent in the last 30 days. Zero duplicate notifications per event.
“Reliable” is a feeling. 99.5% delivery within 30 seconds is a testable requirement.
How to Use This in Practice
You don’t need a new process or a new template. Just a habit.
After you write any requirement, read it back and ask yourself: if an engineer shipped this tomorrow, how would I check whether it’s right? If the answer is “I’d know it when I see it,” the requirement isn’t done.
Some practical ways to apply this:
In PRD reviews: Go through each requirement as a team and ask the question out loud. The discussion it generates is often more valuable than the document itself.
In ticket writing: Before a ticket leaves the backlog, add a “definition of done” section. Three to five bullet points. Each one should be verifiable without subjective judgment.
In design critiques: “How will we know the new design is better than the old one?” If you can’t answer that, you can’t evaluate the design.
The Uncomfortable Part
This question sometimes reveals that you don’t actually know what you want. That’s uncomfortable, but it’s better to discover that ambiguity while writing the requirement than during the sprint review.
If you can’t answer “how will we know this is done?” for a requirement, that requirement isn’t ready for development. It needs more thinking, more user research, or more conversation with the team.
That’s not a failure. That’s the question doing its job.
Frequently asked questions
What single question fixes a vague requirement?
How will we know this is done? Asking it of every line forces a wish into a testable criterion, because you cannot answer it without naming an observable outcome. If the honest answer is that you would know it when you saw it, the requirement is not ready to be built from.
How do you turn a vague requirement into a testable one?
Replace every opinion word with something countable. Improve search performance becomes results in under 200ms for queries up to 50 characters against the current dataset. The rewrite is longer, and that length is the requirement doing work the sprint review would otherwise do.
What are the most dangerous words in a PRD?
Improve, easily, intuitive, reliable and user-friendly. Each one describes a feeling the author already has and the reader does not. They are not banned words, they are prompts: whenever one appears, ask what would have to be true for it to be met, and write that instead.
What if you cannot answer how will we know this is done?
Then the requirement is not ready, and that is useful information rather than a failure. It usually means a decision has not been made, the user research has not happened, or two people are holding different versions of the same idea. Finding that while writing costs an hour. Finding it in the sprint review costs the sprint.
Where in the process should you ask it?
In PRD review, go through each requirement and ask it out loud, because the argument it starts is usually worth more than the document. Before a ticket leaves the backlog, make the answer a short definition-of-done list. In design critique, ask how you will know the new design is better than the old one.
Write it once. Have everyone agree.
Projan surfaces the unmeasurable success criteria and the untested assumptions, before your engineers do.
Start free trial14-day free trial. No credit card required.