As the final stage of setting the vision, we should work with our Product Owner to define how we will recognize success. This not only gives us a clear idea of what the expected outcome of our work is, but also helps us understand where we should put our emphasis.

It's also a time to consider any assumptions that might have been made and to put these out in the open, as ultimately this is what contributes to unmet expectations the most. For example, does this mission require rapid experimentation to see what works in a real-world environment, so we can then learn and build based on our results? Or is it a mission where we have already gained a clear idea of what we need via user research, and we need to build out something that is simple but super reliable?

In the first example, it may seem obvious to our team; they won't have time to performance-test the application. We will assume that performance testing will be carried out in the subsequent phase once the results of our experiments are concluded. However, a Product Owner wouldn't necessarily know or even have thought of this. 

They say the most common cause of a relationship breakdown is unmet expectations. This part of the liftoff is an excellent opportunity for the Product Owner to set expectations from the business's perspective, and for our team to contribute from a technical perspective.

A good starting point is the Success Sliders exercise, demonstrated as follows:

Set up the whiteboard to look like the following figure (note: all of the post-its are in the 3 column):

There are seven success criteria listed. The seven post-its represent the sliders for the corresponding success criteria. They can move between 1 and 5, but cannot be taken off the board. Each slider is currently set to a value of 3, and the Success Sliders are in equilibrium; this is a total of 21 (7x3). 

The following rules apply:

• We are not allowed to exceed a score of 21, so we can't move all Success Sliders into the 5 column as this would make a total of 35.
• We could leave all Success Sliders where they are, but this would not reflect reality. There is almost always a bias for at least one success criterion over another, for example, delivering on time over delivering all the defined scope (or vice versa).
• We are now free to move the sliders for any of the success criteria; for every slider that moves up, there must be a corresponding downward movement for another slider.

The intention of the activity is to find out what's important for the successful outcome of this mission. After conversation amongst our group, we should move the sliders to the position that reflects the best outcome for this work.

This conversation may be difficult, but it's intended to help us uncover any assumptions and discuss them openly. The following figure is an example of the completed activity:

Here you can see that the group has decided that delivering value is a higher priority than delivering all of the defined scope or delivering on time. Maybe the conversation has gone along the lines that they want to get to market sooner with only a core feature set so that they can validate their idea.

As with a lot of these activities, while the outcome is important for our team to base future decisions on, the conversation we have during this activity is just as important as it helps cement our understanding and clarify our purpose.