There’s a sentence that breaks a lot of designers: “We’re going agile.”

Agile is so often misunderstood, especially around what it means to “ship.” The popular myth goes something like this: Move fast, push things out, fix it later, and don’t overthink it.

For designers trained to sweat every pixel and think holistically about user experience, that sounds like a disaster. And honestly, sometimes it is one when teams get it wrong.

But here’s the thing nobody says out loud enough: You don’t have to ship it to everyone.

Shipping early and often doesn’t mean shipping everything to everybody at once. It means getting a working product in front of real users as quickly as possible so you can learn and improve it.

The three-layer release

Good agile teams don’t flip a switch and expose new features to millions of users overnight. They release in layers, each one designed to teach them something before going wider.

  1. Beta testers: Volunteers who opt in. They tolerate bugs and love helping. You’ll catch the big, obvious problems here: the things nobody wants to see in a full release.
  2. Partial rollout: Maybe 5–10% of real users, selected randomly. These are your average customers, not enthusiasts. They’ll surface the complaints you didn’t expect.
  3. General availability: Everyone gets it, but only once the earlier layers have taught you enough to feel confident. Sometimes you never fully flip the switch. That’s also OK.

What this means for you as a designer

This layered approach changes how you prioritize your own design work. If you know a feature is going to a small beta group first, you can ask, “What’s the riskiest part of this design? What do I most need to learn?” Start there. Design and ship that part first, while the audience is small and forgiving.

Design order matters. And the continuous release pipeline gives you a map.

Let go of perfect

Here’s the uncomfortable truth: What designers call “perfect” and what users call “perfect” are rarely the same thing. You can’t know what perfect looks like until users have actually used it.

That doesn’t mean shipping careless work. It means reframing the goal: Instead of asking, “Is this polished enough?” ask, “Is this good enough to learn from?” Those are very different questions, and the second one is far more honest.

Teams that learn from feedback and iterate tend to stress less. They know they can go back and make things better as long as they actually do it.

Warning: This only works if iteration is genuinely built into the culture. Too many teams use “we’ll fix it in the next sprint” as a way of never fixing it. If you’re going to embrace imperfection, build in the commitment to come back.

The article originally appeared on Substack.