Learn before you Build

The order most teams get wrong in hardware product development

The real issue 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.

Start from first principles, not from the last product

Most teams design by analogy. They start from how similar products are built and adapt that design. It feels safe, but it gives you what competitors already make, and when it does not work, nobody can say why.

Learning before you build starts from first principles: what physically has to happen for the product to do its job, stated without any mechanism in mind. With that clear, ideas can be judged on paper, and only the ones worth testing get built. Most of the speed comes from this step.

Analogies still help, but later, as a source of ideas, once the first principles are known.

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. I do not execute settled specs or follow someone else's process. If the real problem is organisational rather than technical, I cannot help.

Why this matters

I am working towards a future where hardware product ideas in India become sellable products within a year.

My mission is to help Indian hardware product teams learn their way through problems in weeks.

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 learns parts of the method while running it. A Concept Sprint starts with a free 45-minute diagnostic call.