Hi Eric,
This is one reason I like the Outcome-driven innovation definition of an outcome: it’s a directional statement towards an ideal state. You can dig into what a user wants to achieve (desired outcome) even if there is no current solution that perfectly solves it. Those desired outcomes stay stable over time, even as different solutions may arise to address the desired outcomes to some extent.

These needs statements/desired outcomes are structured formed using the directional “minimize”. For example: “Minimize the likelihood my stomach will rumble in my afternoon meeting” “Minimize the likelihood I’ll spill all over my shirt”, “Minimize the time it takes to prepare” etc etc.*
Once you have a list of all the users’ desired outcomes surrounding the Job and under the circumstances, you can prioritize which are most important and least satisfied, and focus on those for designing the solution.
Focusing on outcomes apart from solutions is key because you’re not asking “how could this solution be better”, you’re asking “what’re you really hoping to get out of this” and only then working on designing a solution. This frees you from incremental improvement because you’re not just focused on making a snack bar that doesn’t have the weaknesses of existing solutions. You are actually working on something that is focused on helping the user achieve his success. Soylent comes to mind, for example..

*the key piece that is often missed is that not every user values these desired outcomes to the same extent — that’s ok, that’s how you segment your users. So just b/c some people don’t care as much about how long it takes to prepare the snack doesn’t negate it as a desired outcome. It just means that may not factor into the most important decision criteria for that segment.