Iterating on findings

After testing you are left with a pile of findings. This lesson is about what you do with them: how to interpret the results honestly, what you change, what you keep, and how to avoid fooling yourself. To iterate is to repeat the build-measure-learn loop, a little wiser each round.

Interpret the results objectively

The first step is to separate signal from noise. One person's strong opinion is not a signal; a pattern across several is. Look for what recurs, not what shouts loudest. Be especially wary of findings that confirm exactly what you hoped — they feel right, and are dangerous precisely for that reason.

Go back to the hypothesis you set before the test. Did the data say yes or no? If the result is unclear, the test is often too small or the task too vague, not the idea good or bad. Then the answer is to test again, not to guess.

When you adjust, and when you discard

Not everything you learn means you have to turn around. Distinguish two kinds of response:

• Adjust: The users understood the value but stumbled along the way. Then you fix the flow, the wording or the step that stopped them, and test again.
• Discard or rethink: The users understood the offer but did not care. Then polishing the details will not help — the assumption itself did not hold.

The hardest trap here is the cost you have already sunk. Spending three weeks on a feature does not make it valuable. The money and time are gone either way; the only thing that matters now is what pays off going forward. Jonas scrapped an entire module he was proud of, because none of the firms used it. It hurt, but it saved him months.

The build-measure-learn loop in practice

The core of agile product development is a simple loop: you build something small, measure how people use it, and learn something you carry into the next round. The secret is not to make big leaps, but to make the loop so short that you can repeat it often.

After each test, ask yourself: what did I learn, and what is the next small thing I can build to learn more? Progress is measured not by how much you have built, but by how much uncertainty you have removed.

Avoid the confirmation trap

The confirmation trap is the tendency to notice what supports your idea and ignore what argues against it. It is strongest when you are tired, in love with the plan, or have promised someone that this will work.

A simple countermeasure: decide in advance what it would take to change your mind. "If fewer than two in ten complete the order, I'll rework the flow." When the criterion is set before you see the numbers, you cannot explain them away afterwards. Also invite someone to play devil's advocate — it is easier to see the truth when someone else asks the uncomfortable questions.

Keep the pace up

The value of iterating lies in speed. A small change tested tomorrow teaches you more than a perfect plan next month. Set short loops — ideally one round a week in the early stage — and resist the urge to pile up many changes before testing again. Otherwise you will not know which change made the difference.

But do not iterate forever

At the same time, there is a point where more tweaking yields no more learning. When the same signals point clearly in one direction, it is time to decide — either to commit fully or to lay the idea to rest. Endless polishing can be a way of postponing the scary decision. Iterating should lead you to a choice, not replace it.

Do this now

Take the findings from the user test and sort each into one of three boxes: keep, adjust or discard. For each "adjust," write one concrete change you will make. Then choose the most important change, update the prototype, and define in advance what it will take for you to count the next test as a success. Then run the loop one more time.