Draw a Hundred Sketches, Keep Two: Iteration as a Discipline, Not Agile Theater

Most teams say they iterate. What they actually do is ship a small thing, wait for numbers, then ship the next small thing. They call it agile. It feels fast. But it is one guess in sequence, dressed up as a process. You commit code, you commit a roadmap, and by the time you learn you were wrong, you are three sprints deep and stuck.

Real iteration is cheaper and messier than that. It means putting many rough options on the table, learning what does not work, and throwing most of them away before you build anything. This brief is about how to run that as a discipline your team can trust, not a slogan on a wall.

Shipping code is a slow way to learn

Here is the trap agile sets. It treats finished software as both the way to deliver value and the way to learn. Pavel Samsonov calls this out plainly: prototyping in production can only tell you "in what ways were we right or wrong," when the real question is what are all the ways it is possible to be right or wrong. You are testing one idea at a time, and each test costs a full build.

That is Waterfall wearing a new jacket. The only measure of progress becomes output shipped. Learning gets pushed to the back and turns into validation, where the team quietly hunts for proof they were right so nobody has to walk back a commitment.

So separate the two jobs. Delivery is one process. Deciding what to build is another. Do not make your delivery pipeline carry your learning.

Cheap options first, code later

The fix is older than agile and simpler. Sketch a lot, throw most of it out. Samsonov points to how Leonardo worked: he drew many poses and angles for a subject, then picked the best one, not the first one. Your team should be drawing a hundred sketches, learning what not to draw, then dropping them all to apply what they learned.

This is the heart of Lean UX, which trades thick specs and pixel-perfect mockups for whiteboard concepts and rough prototypes. The point is that the investment at each step is so small that killing an idea does not hurt. As the piece puts it, you can gut a prototype without it being crushing in workload or ego-bruising.

That last part matters more than it sounds. When throwing work away is cheap, people stop defending bad ideas. Ego drops because the stakes drop.

Fidelity should match the question

A rough prototype is not a lazy prototype. You still sketch, critique, test, and prototype. You just pick the right depth for the question in front of you. A napkin flow answers a different question than a clickable screen, and both beat a full build for speed.

The RITE method, built at Microsoft Game Studios, shows the cadence. You fix a usability problem the moment you spot it, then retest, instead of waiting for a whole study to wrap. Test with a handful of people, tweak, test again. One ad team walked a wireframe from a usability score of 66 up to 71 across three weekly rounds, raising fidelity only after each round confirmed the direction.

Start rough, add detail only where the data tells you to. Do not polish pixels on a flow you might delete next week.

Volume beats the perfect question

Teams freeze at the start because they want the perfect test. Skip that. The crew at Helio writes 50 hunches before they craft a single question, and they run several short surveys instead of one big one. Volume over perfection. More questions to more people beats one careful question to your coworker.

Who you ask matters more than how you word it. Partner with sales or support to reach real customers. Keep tests short and themed so people answer thoughtfully and you can actually make sense of the pile later. And present findings as you go, not in one final reveal, so stakeholders feel like part of the work instead of an audience.

Stay open to being surprised. Athena Lam frames iterative research as watching for surprise insights that point to a new direction, not just confirming the plan you already had. If your research can only ever agree with your roadmap, it is not research.

The deep cut

The thing that is easy to miss: throwing work away is the product of iteration, not a failure of it. Adam Maidment describes the loop as prototype, test, evaluate, refine, where successful ideas move into the final product and unsuccessful ones get dropped fast. The dropping is the work. A cycle that keeps everything is not iterating, it is accumulating.

This changes how you manage people. If your team is judged on volume of deliverables shipped, they will never kill their own work, because killing it looks like waste on a status report. So change what you reward. Praise the option that got cut cheaply and the wrong turn caught in a sketch instead of a launch. Ask two questions before any new build: how would we know if we are wrong, and what would we do about it. If the honest answers are "we can't" and "nothing," you are validating, not learning.

Three questions for your team

• Before we start this build, how would we know if we are wrong, and what would we actually do about it? If we can't answer both, we are validating a decision, not testing one.
• Where could a surprise insight change our direction, and are we set up to catch it, or is our research just checking the roadmap we already committed to?
• For the question in front of us right now, what is the cheapest artifact that answers it? A napkin, a wireframe, or three quick tests, before anyone writes code?