Clarity Means Speed

Whenever a leader says, "we need to move faster," my instinct now is to pause and ask a slightly different question: what exactly are we trying to move faster toward, and why now? I know that can sound a little overly precise at first. In practice, though, I have found it is usually the most useful place to start.

A lot of teams talk about speed as if it is obviously good. Sometimes it is. But if the destination is fuzzy, the urgency is unvalidated, and the definition of done is unclear, speed can end up taking you off course faster. Over time, I have come to see clarity as one of the things that makes speed possible.

Not clarity as a vague virtue. I mean something more practical:

• clarity on the destination
• clarity on why this problem matters now
• clarity on the opportunity cost
• clarity on what "done" actually means
• clarity on what should not be moving yet

If those things are fuzzy, pushing for more throughput usually creates more noise than progress.

The wrong diagnosis

In one growth-stage product team I worked in, there was a recurring desire from leadership to move faster, ship more, and tackle a growing list of urgent problems. On the surface, that sounded reasonable enough. But I kept coming back to the same question: what has actually changed since the last planning cadence?

Was leadership truly unhappy with throughput? Had a customer problem become materially more urgent? Had the market shifted? Or were we mostly reacting to a general feeling that other companies seemed to be moving faster? I think teams often move past that step too quickly, especially when the pressure is real. They feel pressure, then translate that pressure into urgency, then translate that urgency into more work in motion.

What people often assume is causing slowness is something like:

• the engineers are not moving fast enough
• the team lacks urgency
• the tooling is not good enough
• there are too many meetings

Sometimes those are real issues. Over time, I have become more drawn to a different diagnosis: the team is often trying to move too many things in parallel without enough clarity.

You cannot usually decide to increase throughput overnight in any meaningful way. Teams do not work like taps that can simply be turned on harder. If the destination is still fuzzy, what you often get is more partially shaped work, more rework, and more confusion about what should have happened in the first place.

The headlights problem

The metaphor I keep coming back to is driving at night. You can press harder on the accelerator if you want. But if the headlights are weak and you are not fully sure which road you should be on, speed starts to become a liability. You might still be moving quickly. You might even feel productive. But you could be heading in the wrong direction.

That is how teams can end up mistaking motion for progress, even when everyone involved is working hard.

A concrete example

One of the clearest examples for me was a push to ship Feature X quickly. The pressure was understandable. There was genuine interest in getting something out, learning quickly, and not feeling slow relative to the market. My working hypothesis at the time was that shipping an MVP quickly would create momentum and help us learn faster. That was a reasonable hypothesis.

But we did not slow down enough to think through some of the second-order consequences:

• what this would do to the overall user experience
• how difficult it would be to iterate properly in a v2 or v3
• how much maintenance load we were quietly taking on
• what would happen once users got used to a v1 that we already suspected was incomplete

At the time, I was mostly thinking about the maintenance load and the cost of substantial iteration. A senior designer on the team was also good at thinking through the broader product and UX implications. Looking back, those concerns were pointing at the same underlying issue: we had not fully clarified what a good first version actually needed to be.

We shipped the MVP. Then we learned what, in hindsight, we probably could have anticipated more clearly: we had left parts of it undercooked and had to come back and redo more of the work than we would have liked.

That created a frustrating second-order problem. While we were tidying it up, the natural question from leadership became: why are we still working on the same thing instead of building the next thing? And that was really the point. We were still on it because the first version had not been thought through clearly enough.

What looked like speed upfront ended up creating drag later. I was surprised by how often this pattern showed up. The team had been trying to move quickly, but because the destination and quality bar were not clear enough, some of that speed was more apparent than real.

Throughput is constrained whether you acknowledge it or not

Another reason I care about clarity is that product work has real opportunity costs. Say a team has roughly 48 working weeks in a year. If a pebble-sized problem takes about a week, then in a simplistic sense you only get to solve around 48 pebbles that year.

The exact number is not the point. The point is that the system is finite, whether the team explicitly acknowledges it or not. So when someone says a problem is urgent, I think the next question has to be: urgent relative to what?

Because once you solve one thing, you are also choosing not to solve something else. If you do not explain that tradeoff clearly, the team can end up in a strange place where every problem sounds important, but no one can explain why this one should move now.

That is where clarity matters most. Not because clarity feels neat, but because clarity helps a finite team spend finite time on the right things.

What changed when clarity improved

Whenever clarity improved, the same kinds of things tended to happen:

• sprint planning got better
• there were fewer surprises
• releases got cleaner
• people had a stronger sense of what was actually being solved

None of that felt magical. It just felt calmer and less noisy. And that is probably another way of saying the same thing. Good execution often feels quieter than messy execution.

There is less guessing, less rescuing, and less explaining the same thing three times in three different ways.

My current view

My current view is that speed is only really useful when it is pointed toward a validated destination. If you know where you are going, why it matters, how you will know you have arrived, and what you are deliberately not doing yet, then speed becomes useful. If you do not know those things, speed often turns into thrash.

That is why I now think clarity is one of the most underrated forms of leverage in product work.

It is not bureaucracy. It is not overthinking. It is not the opposite of action. Quite often, it is the thing that lets action compound instead of unravel.

Three practical takeaways

1. Before asking for more speed, ask what has actually changed

If a problem has become more urgent, great. Be clear about why. If the issue is really that leadership wants higher throughput, say that directly and then talk about the constraints honestly. Pressure gets more useful once it becomes specific.

2. Reduce parallel work before demanding more throughput

A lot of speed problems are, in practice, too-many-things-moving problems. If the team is already spread thin, pushing harder usually increases partial progress rather than finished work.

3. Define the destination and the quality bar properly

Before pushing to ship, get clearer on:

• what success looks like
• what the first version actually needs to do
• what tradeoffs are acceptable
• what "done" means in practice

That usually saves more time than it costs.