good goals tend to be SMART: Specific, Measurable, Action-oriented, Realistic and Timely.

We assume that delivering that feature will change players' behaviour. Once the feature is delivered, we can track if the assumption was true or not.

Impact mapping helps to reduce waste by preventing scope creep and over-engineered solutions. It provides focus for delivery by putting deliverables in the context of impacts they are supposed to achieve. It enhances collaboration by creating a shared big-picture view for technical and business people.

most requirements models completely ignore this – they focus on what the software should do and not who will benefit from it and who will be worse off when it is delivered.

The role of testing becomes to prove that deliverables support desired actor behaviours, instead of comparing software features to technical expectations. If a deliverable does not support an impact, even if it works correctly from a technical perspective, it is a failure and should be treated as a problem, enhanced or removed.

Our products and projects do not work in a vacuum. They have an interdependent, dynamic relationship with people, other projects, the organisation and the wider community around them.

listing impacts on the second level of a map, we consider the desired changes in the behaviour of actors. This leads to better plans and helps with prioritisation.

visualises assumptions. Alternative models mostly do not communicate assumptions clearly.

Defining quality