Discovery before direction: why the first sprint should not produce screens

Teams often equate progress with visible output, so discovery gets skipped in favor of mockups. A backlog full of screens feels like momentum, even when nobody has confirmed the problem those screens are meant to solve. By the time a stakeholder asks whether customers actually want this, the interface is already too finished to question.

A discovery-first opening week looks unremarkable from the outside: conversations, not deliverables. We interview the people who will use or buy the product, map what they actually do today, and write down every assumption the team is quietly making. Most of those assumptions turn out to be wrong in some specific, useful way.

What this saves later is not time in the first week, it is the rewrite in month three. A five-day discovery sprint costs a fraction of a shipped feature nobody adopts, and it leaves the team with a shared, tested understanding of the problem instead of five individual guesses about it.