Learn before you Build

The order most teams get wrong in the hardware product development life cycle

The problem is Building before Learning. Teams approach functional proving as if they are building for mass production. Every test becomes a rebuild of the whole product, so each lesson costs months and lakhs of rupees. Nobody is being careless. It is the order their training taught them.

A team can build something right the first time only when its people have made that kind of thing work before, in their own company or a previous one. Without that, they build on assumptions they cannot list in advance, let alone answer correctly.

The belief underneath is that a high-quality build means high functionality. That is true at the end of the development cycle, not at the start.

Progress gets measured in parts made, not in things learned. So a week spent learning looks like a week with nothing to show.

What a delay actually costs

The cost of a delay is the burn rate multiplied by the extra months. For example, if the burn rate is Rs 25,00,000 a month, three extra months cost Rs 75,00,000, and the tranche, pilot or launch date moves with it.

Why more engineers do not fix it

More engineers add capacity, but they follow the same order. Two people, ten or a hundred hit the same wall. It is not about team size. It is about whether the team learns before it builds.

A senior hire also takes 4 to 6 months to land, and months are what a stuck team is short of.

The solution

The solution is to Learn before you Build. You have to understand why something is not working and what would actually make it work. That helps you fix it in weeks instead of months.

Five rules, and the problem each one answers

1. Teams rebuild the whole product to test one idea.
   Build only what touches the problem. A minimum test piece or rig, not a full product.
2. Teams design the frame first, then force the working parts to fit it.
   Functional parts first, structure last.
3. Every new idea gets a new build.
   One rig, variants swapped through it.
4. A failed test gets counted as lost time.
   A failed test that tells you what to do next is a completed cycle.
5. Designing for manufacturing from day one produces a product like everyone else's.
   Function first, manufacturability after, by changing the components, not the whole mechanism.

Mechanism design starts with function

What is already easy to manufacture is what competitors already make. Get the function right first, then make it manufacturable by changing the components that fail manufacturability, not by giving up the mechanism.

What I cannot help with

Battery, electronics, control-system and certification problems are outside what I do. If the real problem is organisational rather than technical, I cannot help.

Why this matters

My mission is to accelerate hardware products in India so companies can turn their ideas into working products faster than ever.

Want to solve your hardware product problem?

We can learn what will solve your hardware product problem by running a Concept Sprint.

A Concept Sprint is an agreed number of short make-test-learn cycles on your problem, run with your own engineers. Each cycle tests only one thing with the least that has to be built, and ends with a clear decision on what to test next. Your team stops rebuilding the whole product for every test, which is where the months go. Your team keeps the work and also learns the method by running it. A Concept Sprint starts with a free 45-minute diagnostic call.