After More Than 20 Years, We Have Become More Careful About One Thing: Time

Why “faster” is not always better when you are making a product

 

There is one question that comes up often in manufacturing:

“When can it be ready?”

It is a very normal question.

A customer may have a sales plan. Maybe there is an upcoming exhibition, a new market to enter, or an order that needs to be delivered by a certain date.

We understand why the date matters.

And of course, we want to move quickly too.

But after working in communication products for more than 20 years, we have gradually become more careful about one thing:

What does “fast” actually mean?

---

Giving a date is easy. Giving the right date is harder.

When a project is just beginning, many things may still be changing.

The product may need to be adjusted.

A hardware detail may not have been finalized.

Software may still be under development.

A sample may reveal something that nobody expected when the project started.

This is normal in product development.

The difficult part is that all of these things can affect what happens next.

If we say that a product will be ready in a certain number of days, we are not only talking about how quickly someone can work.

We are also making an assumption that the things before that point will go according to plan.

Sometimes they do.

Sometimes they don't.

That is why, as we have gained more experience, we have become less interested in simply giving the fastest answer.

We would rather understand what needs to happen first.

---

Some things can be made faster

This does not mean that we think slow work is good.

Quite the opposite.

There are many places where time can be saved.

If information is clear from the beginning, engineers can start earlier.

If different teams communicate well, there is less waiting between one step and the next.

If materials and production preparation are done in advance, unnecessary delays can be avoided.

Good organization can genuinely make a project faster.

Research on new product development also shows that development speed is not simply about asking people to work faster. How teams coordinate, how information moves between stages and when decisions are made can all affect development time.

This is the kind of speed we want.

Not rushing people, but removing unnecessary waiting.

---

But some things should not be rushed

There are also things that need their own time.

A sample needs to be checked.

A change needs to be verified.

A problem needs to be understood before it is fixed.

And sometimes, after making one change, we need to check whether that change has affected something else.

These steps can feel slow when everyone is waiting for a product.

But skipping them does not necessarily make the whole project faster.

Sometimes it simply moves the problem further down the road.

Then the problem comes back when the product is already closer to production, when changes can be more expensive and more inconvenient.

Studies of product development have also found that accelerating development can create additional rework and coordination costs when changes are made too late or when stages depend heavily on one another.

That is something manufacturers learn through experience.

---

We have learned this gradually

Twenty years ago, when the company was smaller, our work was more focused on manufacturing.

A customer often came to us with a relatively clear requirement.

We understood what needed to be made, worked through the manufacturing process, and delivered it.

Over the years, our work has become more involved in product development and communication solutions.

The questions are no longer always as simple as:

“Can you make this?”

Sometimes they are:

“How should we make this?”

“What needs to be changed?”

“Can this be ready for this application?”

And sometimes we don't have all the answers at the beginning either.

That has changed the way we think about time.

We now understand that the beginning of a project is also part of the schedule.

If something is unclear at the beginning and we pretend it is already clear, the time will usually come back later.

---

The fastest project is not always the one with the shortest first step

This is probably one of the more useful things we have learned.

Imagine two projects.

One starts immediately because everyone wants to move quickly.

The other spends a little more time at the beginning making sure the requirements, product direction and important details are understood.

The first project may look faster on the first day.

But if it has to go back and change something later, that early advantage can disappear very quickly.

In product development, the stages are connected.

A change made early may be relatively easy to handle.

The same change made after tooling, testing or production preparation has already started can be much more troublesome.

That is why speed is not simply about starting as soon as possible.

Sometimes spending more time understanding the beginning is what saves time later.

---

We still care about speed

This is important.

We are not saying that a product should take a long time to develop.

Our customers have deadlines.

Markets move quickly.

Products cannot stay in development forever.

We still look for ways to shorten unnecessary waiting and improve the way a project moves forward.

But after more than 20 years, we have become more comfortable saying something else when necessary:

“We can make this faster, but we need to check this first.”

Or:

“This part needs a little more time before we can give you a reliable answer.”

It may not always be the answer someone wants to hear.

But we believe it is more useful than giving a very fast answer that later has to be changed.

---

Maybe this is what experience changes

When a company is young, it is easy to think that being capable means being able to do everything quickly.

After doing this work for many years, we see it a little differently.

Experience does not necessarily make every project faster.

Sometimes it makes you more aware of where speed actually matters, and where it doesn't.

We want to respond quickly.

We want to solve problems quickly.

We want products to move forward quickly.

But we also know that some minutes saved at the beginning are not worth days of rework later.

So yes, we still want to move fast.

We just want to know what we are rushing for.

That is probably one of the small things that has changed in the way we work over the past 20 years.