Move Fast and Break Things? Sure. But Know What You're Breaking.

There's a debate happening on LinkedIn right now about prototyping speed in hardware development. I've been watching it closely, and I think both sides are missing something important.

One camp says prototype fast, iterate early, build an ugly first version and improve from there. The other says hardware is fundamentally different from software: physics doesn't care about your sprint cycle, there's no rollback on a shipped product, and "moving fast" without the right foundation doesn't save time, it borrows time at a very high interest rate.

They're both right. And they're both wrong. The issue is context.

The word "prototype" is doing too much work

When someone says "we need to prototype faster," what do they actually mean?

Are they talking about testing whether an idea has legs? Or are they talking about converging on a product that's ready for tooling, certification, and mass production?

Those are two completely different activities with completely different rules. But the word "prototype" gets used for both, and that ambiguity is where teams struggle.

Phase 1: Validate the What

In the earliest stages of product development, speed is genuinely your best friend. You're not trying to build a product. You're trying to answer a question: is this idea worth pursuing?

At this stage, move fast. Move cheap. Move ugly.

Cardboard and hot glue. Foam models. 3D printed enclosures that don't need to survive more than a demo. Off-the-shelf dev boards wired together on a bench. Whatever gets the concept in front of real people, or in front of real physics, as quickly as possible.

The goal is to vet out concepts, either technical feasibility or user-facing value, with the minimum investment of time and money. If you can test ten ideas with thumb tacks and a glue gun before committing engineering resources to any of them, that's not reckless. That's smart.

Don't think about manufacturing. Don't think about BOM cost. Don't worry about refined industrial design. None of that matters yet because you're not solving a product problem. You're validating a premise.

The "move fast and break things" philosophy was built for this kind of work. In software, most work is this kind of work, because iteration is cheap and reversible. That's why the mantra stuck.

The transition nobody talks about

At some point, if your concept validation goes well, you make a transition. You move from exploring WHAT the product could be to figuring out HOW you're going to build it.

This is where the rules change. And this is the transition that trips up hardware teams more than almost anything else.

In the "what" phase, breadth is the goal. Test lots of ideas. Diverge. Explore. In the "how" phase, convergence is the goal. Lock the product definition. Test specific implementations. Narrow the funnel toward something that hits all of your technical, quality, cost, and manufacturability targets.

The prototypes you build in this phase look different, cost different, and serve a completely different purpose. They're not about discovering whether the idea works. They're about proving that your specific design implementation will survive the transition to production.

Every build in this phase should answer a specific question. Can we hit the thermal targets in this form factor? Does the acoustic performance hold up with production-intent materials? Will this assembly sequence work at volume? Can we pass certification with this architecture?

If your prototypes in this phase aren't converging toward clear answers, you're not prototyping. You're just spending money.

Where "break things" gets expensive

Here's the math that most teams don't do.

In the concept phase, a failed experiment might cost you a few hundred dollars and a week of time. That's cheap tuition. You should be failing often and learning fast.

In the convergence phase of prototyping, you need to nail the fundamentals because a wrong turn costs orders of magnitude more when you go to the Realization phase. A design change after EVT can trigger re-certification, new tooling, new test fixtures. One unnecessary build cycle is 3 to 5 months of development time with a full engineering team burning salary every month. The cost of "breaking things" in this phase isn't measured in glue sticks. It's measured in hundreds of thousands of dollars and months of lost time.

And the costs compound. Every time the product definition shifts after it was supposed to be locked, ripple effects spread across mechanical, electrical, firmware, manufacturing, and test. The teams that get hurt aren't the ones who prototyped too slowly in the concept phase. They're the ones who carried a "move fast and break things" mindset into a phase that demands convergence and discipline.

The teams that get this right

The best hardware teams I've worked with understood this transition instinctively. They were aggressive and scrappy in the early concept work. They encouraged wild ideas, fast experiments, and cheap failures. Nothing was precious.

But when the program shifted into convergence, the culture shifted with it. Prototypes had clear objectives. Design reviews were rigorous. Changes were evaluated against the full system, not just the immediate problem. The team understood that the goal wasn't to explore anymore. It was to close.

That doesn't mean slow. Some of the fastest programs I've been part of were the most disciplined in this phase, because they didn't waste builds on things that should have been resolved earlier. Every prototype moved the needle. Nothing was repeated without a clear reason.

The discipline in the convergence phase is what actually shortens development timelines. Not by building faster, but by building fewer unnecessary cycles.

So which camp is right?

Both. Neither. It depends on where you are.

If you're in concept validation and your team is agonizing over DFM on a proof-of-concept, you're going too slow. Loosen up. Move fast. Break things. Learn.

If you're in convergence and your team is still treating prototypes as experiments rather than stepping stones toward production, you're going too fast. Tighten up. Converge. Make every build count.

The word "prototype" hides the difference between these two modes. And the advice that's right for one phase can be genuinely damaging in the other.

The question isn't whether to move fast. It's whether your prototyping strategy matches the phase you're in.

This is exactly the kind of strategic question I work through with founders and leadership teams. If you're trying to figure out where you are in this transition, or how to structure your development phases for speed and convergence, I'd love to compare notes.