Speed Is Not a Strategy

Everyone wants to move faster. Faster research, faster prototypes, faster decisions, faster launches. AI is making that possible at a scale we haven't seen before. But speed only creates value when the direction is right. Otherwise, we are simply getting better at reaching the wrong destination.

Speed became the measure of progress

Somewhere along the way, speed became synonymous with progress.

• How quickly can we ship?
• How quickly can we test?
• How quickly can we respond?
• How quickly can we get something into the hands of customers?

These are reasonable questions. In a competitive environment, nobody wants unnecessary delays. But speed is only useful when it is applied to the right problem.

A team can move incredibly fast and still spend months solving something that doesn't matter. A product can launch ahead of schedule and still fail to create value. A roadmap can be delivered exactly as planned while the underlying customer problem remains untouched.

The brief is rarely the whole problem

One of the most important things design can do is challenge the brief. Not because the brief is necessarily wrong, but because it is usually a starting point rather than the complete picture. A brief tells you what someone currently believes the problem is. Research helps you understand what is actually happening.

I experienced this while working on a project in a remote rural region of Odisha, where customers were accumulating unpaid bills. The initial problem appeared straightforward. Customers weren't paying. The assumption was that affordability or bill collection was the issue. Perhaps people were unable to pay, or perhaps the collection process needed to become more effective. So naturally, the conversation started there.

But when we spent time understanding the situation, a different problem emerged. People were struggling to understand the bill. The bills were written in English, while many of the people receiving them primarily understood regional languages. They were also dense and complicated, making comprehension difficult.

The issue wasn't simply that people didn't want to pay. They didn't fully understand what they were being asked to pay.

That changed the problem completely.

When the problem changes, the solution changes

Imagine we had decided to move faster.

• We could have optimized the collection process.
• We could have introduced better reminders.
• We could have improved payment channels.
• We could have automated parts of the workflow.
• We could have measured the results and celebrated the efficiency gains.

And we could have done all of that very quickly. But we would still have been solving the wrong problem.

The real opportunity was somewhere earlier in the chain:

Comprehension → transparency → trust → payment

When the bill itself was difficult to understand, improving the collection mechanism was unlikely to solve the underlying issue. This is why problem framing matters so much. It creates the direction in which execution happens.

What speed hides

The danger of moving quickly isn't simply that we might make mistakes. It is that speed can make us more confident in those mistakes.

When something takes months to build, there are natural moments to question it.

• The research takes time.
• The design takes time.
• The engineering takes time.
• The testing takes time.

There are opportunities for someone to say:

Wait. Are we sure this is the right thing?

As execution becomes faster, those natural pauses disappear. We can move from a vague idea to a convincing prototype before the original assumptions have been properly examined. We can turn a weak brief into a polished experience. We can create something that looks like progress long before we know whether it creates value.

That is the debt speed can create.

AI changes the equation

This is where AI makes the conversation particularly relevant. AI can help teams research faster, synthesize information faster, explore alternatives faster and build prototypes faster. It can give an existing team capabilities that previously required several specialists.

• A researcher.
• An analyst.
• An engineer.
• A writing partner.
• A testing partner.

The result is powerful. Teams can explore more possibilities in less time. They can test concepts earlier. They can reduce the cost of experimentation and learn faster. I expect this to fundamentally change how innovation teams work.

But there is a condition.

AI doesn't decide whether the brief is good. It doesn't automatically know whether the problem is worth solving. It doesn't know whether a customer behaviour is a symptom or a cause. It can help us investigate those questions, but the responsibility for framing them still belongs to us.

The cost of being wrong is changing

There was a time when the cost of experimentation was itself a constraint. You couldn't build everything. You couldn't test every idea. You had to make choices. That constraint was frustrating, but it also forced prioritization.

AI is changing that equation. When the cost of creating another prototype becomes almost negligible, we can explore much more. That is a huge advantage. But it also creates a new risk.

If we can create ten solutions before lunch, we may start believing that the problem is solved simply because we have more solutions.

It isn't.

More options don't necessarily create better decisions. Sometimes they make the absence of direction harder to see.

The strategic advantage will not come from generating the most ideas. It will come from knowing which questions are worth exploring.

Direction before acceleration

This is where I think design thinking, problem framing and strategy come together.

• Before asking: How fast can we build this? Ask: Why are we building it?
• Before asking: How quickly can we test it? Ask: What are we trying to learn?
• Before asking: How do we scale it? Ask: What evidence tells us this deserves to scale?

These questions don't slow innovation down. They protect it.

The purpose of research isn't to produce a report. The purpose of prototyping isn't to produce a prototype. The purpose of AI isn't to produce more output. Each is valuable only when it improves our understanding or moves us toward a meaningful outcome.

Speed needs a direction

There is a subtle difference between moving quickly and learning quickly. Moving quickly means reducing the time between actions. Learning quickly means reducing the time between assumption and evidence. The second is much more valuable.

If we can identify an assumption today, test it tomorrow and change direction the day after, we are moving incredibly fast even if the final product takes longer to build. That is productive speed. It is speed applied to learning rather than simply speed applied to output.

This distinction becomes increasingly important as AI enters every part of the product development process. The teams that use AI well will not necessarily be the ones generating the most content, concepts or code. They will be the ones that create better learning loops.

The role of the design leader is changing too

This also changes what leadership needs to provide. When execution was expensive, leaders often had to push teams to move. When execution becomes cheap, the more difficult job may be deciding where not to move.

That requires judgment. It requires the ability to recognize weak assumptions. It requires asking uncomfortable questions. It requires creating enough space for teams to challenge the brief before committing to it. And it requires being comfortable saying:

We don't know yet.

That isn't indecision. Sometimes it is the most honest and strategically useful answer a team can give.

Don't optimize the wrong thing

One of the easiest traps in product development is optimizing something because it can be measured.

• Conversion.
• Speed.
• Engagement.
• Adoption.
• Completion.
• Efficiency.

These metrics can be valuable. But they are downstream measures. They tell us what happened. They don't always tell us whether we were solving the right problem.

• A team can optimize checkout conversion while making the overall shopping experience worse.
• A team can increase bill collection while leaving the comprehension problem untouched.
• A team can ship more features while reducing the clarity of the product.

The metric improved.

The outcome didn't.

This is why direction has to come before optimization. First decide what matters. Then decide how fast you can improve it.

The new advantage is not speed alone

AI will continue to make execution faster.

• Research will become faster.
• Prototyping will become faster.
• Engineering will become faster.
• Testing will become faster.

The organizations that benefit most won't be the ones that resist this acceleration. They will embrace it. But they will also become much more disciplined about what happens before acceleration begins.

• They will invest in problem framing.
• They will invest in customer understanding.
• They will invest in strategic thinking.

They will build cultures where changing direction because of new evidence is seen as progress rather than failure. And they will measure learning, not just output.

Because speed without direction creates activity.

Speed with direction creates momentum.

So what should we optimize for?

I don't think the answer is to slow down. The opportunity is almost the opposite. Use AI to move faster once you understand where you need to go.

• Research faster.
• Test faster.
• Build faster.
• Learn faster.
• Change direction faster.

But don't let the ability to execute become an excuse to avoid thinking.

The most important question is still the simplest one:

Are we solving the right problem?

If the answer is yes, speed becomes a competitive advantage. If the answer is no, speed simply helps us get lost faster.

And perhaps that is the real opportunity in this next era of product and innovation. Not to build everything faster.