Building Fast Is Good. Building the Right Thing Is Better.

Everybody wants it fast.

I don't think I've ever joined a digital project where someone said:

“Take your time. There's absolutely no deadline.”

Would be nice, though.

Usually, the conversation is closer to:

“How fast can we launch this?”

And that's completely understandable.

Businesses have targets. Projects have budgets. Competitors are moving. Management wants results. Developers have another project waiting. Someone has already promised a launch date before the design team even knew the project existed.

Things need to move.

The problem isn't wanting to move fast.

The problem starts when moving fast becomes the goal instead of getting somewhere useful.

Because there's a very strange thing that happens in digital product development. When timelines get tight, the first thing we often remove is the thinking.

Research? Maybe later.

Validation? We already know what users want.

Alignment? We'll figure it out while developing.

Edge cases? Phase two.

Everything becomes phase two when the deadline is close enough.

Then development starts.

Fast.

Two weeks later, someone realizes that two stakeholders had completely different interpretations of the requirement. Now design changes. Development changes. The API changes. QA needs to test it again.

And the project that couldn't afford two extra days of discussion suddenly finds two extra weeks for rework.

Funny how that happens.

Moving fast is useful when the direction is clear. Otherwise, we're just getting lost more efficiently.

Speed and clarity aren't enemies.

I actually like fast projects.

There’s something satisfying about a team that can understand a problem, make a decision, build something, test it, learn, and keep moving.

The difference is that good fast teams don't necessarily do less thinking.

They make the thinking more focused.

They know which questions need answers now and which ones can genuinely wait.

They know which part of the product needs to be excellent and which part can be simplified.

Most importantly, they know what they're trying to achieve.

Without that clarity, every decision becomes expensive.

A designer explores five directions because nobody agrees on what the product should communicate. Developers build something that gets revised because the business rule wasn't clear. Stakeholders keep adding things because there's no shared definition of what the first release actually needs to accomplish.

Everybody is busy.

The project is moving.

But movement isn't always progress.

This is also where “MVP” gets interesting.

I love the idea of an MVP.

Build something smaller. Learn quickly. Don't spend six months perfecting something before finding out whether anyone actually wants it.

Makes sense.

But somewhere along the way, MVP occasionally gets translated into:

“Just build whatever we can finish by Friday.”

That's not quite the same thing.

The important word in Minimum Viable Product isn't only minimum.

It also has to be viable.

It needs to be useful enough for us to learn something meaningful. It needs enough clarity that users understand what they're supposed to do. It needs enough quality that we're testing the actual idea rather than testing people's tolerance for a confusing product.

Otherwise, we don't really learn whether the product idea works.

We learn that people don't enjoy unfinished experiences.

Groundbreaking research.

Sometimes the fastest solution is simply doing less.

When a timeline gets shorter, the instinct is often to compress everything.

Same scope. Less time.

Design faster. Develop faster. Test faster. Sleep faster, presumably.

But there’s another option that I think is much healthier:

make the thing smaller.

Instead of asking how we can squeeze ten features into four weeks, maybe ask which four actually matter.

Instead of designing every possible scenario for the first release, maybe identify which scenario proves the core experience.

Instead of reducing the quality of everything, reduce the amount of everything.

That's a very different kind of compromise.

You're protecting the clarity of the product by being more intentional about what gets built.

And weirdly enough, saying “not now” can sometimes be one of the most valuable product decisions a team makes.

Of course, we can't think forever.

Designers are also very capable of going too far in the opposite direction. We can research forever. Explore another alternative. Run another workshop. Adjust the flow again. Maybe create one more version just to be safe. At some point, thinking becomes another way of avoiding a decision. Products need to ship.

Not every button requires user research. Not every assumption requires a three-week validation study. Not every disagreement needs a workshop with seventeen sticky notes and a very optimistic FigJam timer.

Sometimes we know enough. Make the decision. Build it. See what happens.

The goal isn't perfection before development. It's having enough clarity to move intentionally. That's the balance I keep coming back to.

So yes, let's make it fast.

I don't want this to become the designer's argument for why every project needs another month.

Sometimes another month won't make the product better. Sometimes constraints actually force us to make better decisions. A deadline can help teams focus. A limited budget can force prioritization. A smaller scope can make the experience clearer.

Speed isn't the enemy. Directionless speed is.

If we're clear about the problem, understand what outcome matters, agree on what we're building, and know which compromises we're making, then please—let's move fast.

That's when speed becomes powerful.

But if we're still debating what the problem is while development is already halfway through building the solution, maybe slowing down for a moment isn't actually slowing the project down.

It might be the fastest thing we can do. Because building fast is good. Building the right thing is better.