An outcome is how you'll know a project is done. If people can't agree whether it's done, the outcome isn't working.
What a good outcome is
A good outcome is one user's goal. When it's done, that user has finished something they set out to do.
Good: "A customer can move a visit to a new time without calling us."
Not good: "Improve rescheduling." Nobody can check this. When is it improved enough?
Not good: "Add a Reschedule button." This is a feature, not a goal. A user could click it, and still not move their visit.
Four quick checks
Grove checks each outcome in four ways:
One user: does it name a user, such as a customer or a pro? If the product is the subject, such as "The app shows…", it's a rule. It goes in the requirements.
Ask why: "Why does the user do this?" If the answer is another outcome on the list, this one is only a step. Fold it into that outcome.
Ask how: "How is this done?" If the answer is all the other outcomes, this one is too big. It's the initiative's goal, not a project outcome.
Coffee break: when this outcome is done, has the user finished something they set out to do? Could they go get a coffee? If not, it's a rule. It goes in the requirements.
Who checks it
The product lead does. When the work ships, they try it, and tick the outcome when they see it working. See Shipped isn't done until someone checks.
That's why the outcome must be about what a user can do. Someone has to be able to try it.
Details go in the requirements
Exact rules, such as "the new time must be at least 24 hours away," belong in the project's Requirements, not in the outcome. See Requirements hold only what a coding agent can't decide.