A requirement that cannot be tested is a requirement that cannot be verified as complete. A goal without a measurable success criterion is a goal that can be declared achieved at any point, for any reason, by anyone motivated to declare it. Both situations produce the same outcome: the team cannot know with confidence whether the thing they built is the right thing.
Testability is not a QA concern. It is a product discipline that begins at the point of writing.
When you write a requirement, ask immediately: how would I know if this was met? If the answer is not clear, the requirement is not yet clear. The clarity that testability demands forces a level of precision that makes every other aspect of the PRD stronger.
The simplest test for testability is this: can two people look at the product and agree, without discussion, on whether the requirement was met? If the answer is no, the requirement needs more specificity.
The difference looks like this in practice.
The second version has a clear condition, a clear measurement, and a clear timeframe. Either users completed the flow at that rate or they did not. Nobody needs to interpret anything. Nobody needs to have a conversation about what easy means.
Writing clear success criteria requires three specific practices.
If the team cannot look at the product after launch and determine clearly whether the feature succeeded or failed, the success criteria were not clear enough. Define them before development. Make them specific. Include guardrails. Do not move them after seeing the data.