The One Question That Saves Every PRD

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.