A variant of the standard user story template — "As a [type of user], I want to be able to [do X], so I can [enjoy benefit Y]" — where Dan Olsen singles out the "so I can" clause as the problem-space rationale behind the feature. "I want to do X" names a solution; "so I can enjoy Y" names the underlying customer benefit. Auditing a backlog by checking whether the "so I can" clause states a genuine benefit — rather than restating X, or being left blank — is a quick test for Solution Pollution and for Problem Space vs. Solution Space conflation generally.
Olsen's rule for writing the "so I can ___" clause: start with a verb, not an abstract noun. Nouns like "security" or "privacy" hide what the product actually does for the customer, because they can be satisfied by countless different mechanisms; verb phrases force clarity about the actual value created — rewrite "so I can have security" as "so I can feel safe" or "so I can protect my information." Useful as a check when compiling a Benefit Ladder or a problem-space benefit list: if a benefit reads as a noun, push to restate it as an action before treating it as done.