Every hardware founder has heard the advice: be lean, be agile, iterate fast. It sounds right. And for a software company, it mostly is. But if you take that playbook and apply it to a hardware startup without modification, you will spend a lot of money building the wrong product.
Before you can use these frameworks, you need to understand what they actually mean, and where they stop applying.
Lean Six Sigma Is Not What You're Talking About
When most people say "lean" in a startup context, they do not mean Lean Six Sigma. That is a process improvement methodology designed for enterprise manufacturing environments: think reducing defects in a Toyota assembly line or eliminating waste across a high-volume production floor. It is a legitimate discipline, but it is built for organizations that are already running at scale. As a startup, that is not your problem yet.
Lean manufacturing principles are similar. They are about optimizing production operations: reducing inventory, eliminating bottlenecks, managing throughput. Again, valid at scale. Not where your head needs to be at when you are still trying to figure out what you are building.
These are different definitions, and conflating them with lean startup methodology will send you in the wrong direction.
Agile Has the Same Problem
Agile development came out of software. The core idea is that you build one feature at a time, move through short sprints, and run a tight build-test-iterate loop with each new feature. In theory, this lets you stay close to your customer and avoid building things they do not want.
For a software team, this works. Shipping a new feature costs compute time and engineer hours. If it is wrong, you roll it back or ship a fix next sprint.
Hardware does not work that way. You cannot build one feature at a time. Each time you add or change a feature, you are spinning up a new revision of your physical product. That revision costs real money, and it takes real time. It might mean new tooling, new board spins, new enclosures, new certifications. The cost and timeline of a hardware revision bears almost no resemblance to merging a pull request. Fabricating a new fully assembled board can take weeks on its own.
So sprint-based, feature-by-feature agile iteration: not your framework.
What Actually Applies: Start with the MVP
Here is what does transfer, and where you should start: defining your minimum viable product.
The lean startup concept of the MVP holds up for hardware. But you have to approach it the right way, because the trap is everywhere.
Start by defining the problem, not the product. There is a distinction worth making between products built for entertainment and products built to solve a problem. Even entertainment products require you to get specific about what makes them entertaining, but for most hardware startups, you are solving a problem. That is the frame you need to operate in.
The trap most founders fall into: they get attached to their idea about what the product should be. They are trying to provide a solution before they have properly understood the customer's problem. So they spend months developing something, they go to market, and customers tell them it does not actually solve their problem. Nobody buys it.
You want to let go of your ego here. Assume that your concept for a product is wrong but know that it hints on an underlying problem. Then, talk to your customers. Interact with them. Understand what their core problem is and what the best solution looks like. And keep this in mind: just because you are solving a problem does not mean customers will pay for it. It also has to be economical, something worth buying. Both things have to be true.
What that conversation does not look like: asking customers if they like your idea. That is not customer discovery. That is fishing for validation, and you will get it whether you deserve it or not. Customers are not accurate judges of an idea in the abstract; their feedback only becomes reliable once they can actually interact with a solution.
What it does look like: asking how they currently handle the problem. What does their process look like today? Where does it break down? How much time does it cost them? You are scoping the problem, not pitching a solution. Never lead with the solution. The point is to understand the problem well enough that the right solution becomes obvious, and then go build it.
Customer discovery is not optional. It is the foundation everything else is built on.
EVT, DVT, PVT: The Hardware Iteration Framework
Once you have done that customer work, you translate what you have learned into customer requirements. From customer requirements, you derive technical requirements. This is where your build process actually starts.
EVT (Engineering Validation Test) is about verifying that what you built meets your technical requirements. Does it do what you designed it to do? This is the phase where rapid prototyping techniques earn their keep: 3D printing, breadboarding, cheap board spins, whatever gets you to a functional prototype quickly. You are not showing this to customers yet. You are validating the engineering.
DVT (Design Validation Test) is where you verify that your product meets your customer requirements for the MVP. By this point you likely have a full PCBA; you may still be 3D printing some enclosure or mechanical parts, but the breadboard is behind you. You might be producing a handful of units here, enough to get them in front of real customers and confirm that your MVP actually solves the problem you set out to solve.
PVT (Production Validation Test) is where things diverge sharply from anything resembling agile.
There is another trap in the DVT phase worth naming. When you share your MVP with customers, they will give you feedback. Some of it will be good. Some of it will push you toward features that are beyond your MVP. Your job is to distinguish between the two. Take the feedback seriously, but audit it: is this person asking for something that is core to the MVP, or are they asking for scope creep? You will need to iterate and update your customer requirements based on what you hear, but the point is to not over-scope your product. Stay disciplined. Cool features can be noted and added in the future once you've validated the core problem through sales.
PVT Is Where Hardware and Software Fully Part Ways
The PVT phase is about scaling into production. You are not starting with a million units. You might go from ten to a hundred to a thousand, and you will manage that progression carefully.
This is where lean manufacturing principles start to matter, but it is not agile. You are not incorporating new features. You should not be incorporating new features. What you are doing is optimizing your design for production: design for manufacturing, certifications, supply chain decisions. Those revisions are real, and they happen, but they are not about changing customer requirements or adding customer-facing functionality. They are about making the product you already validated manufacturable at scale.
Software deals with some version of this, but not like hardware does. The constraints are different in kind, not just degree.
The Real Iteration Cadence for Hardware
Once you have shipped your version one, your true MVP, you are in the product lifecycle now. You will go through iteration cycles: version two, version three. But the cadence is not a two-week sprint. It is more likely a new version every year or two.
Your first product does not need to be perfect. It is a basis to get you into the market and validate the problem. From there, as you gain traction, each subsequent version requires more research, closer collaboration with your customers, and more investment, because each spin is costly. But having done it the first time, the process becomes more established. You know your supply chain. You know your CM. You know how to run the cycle.
This is product lifecycle management (PLM): the ongoing process of tracking your product through its versions, managing your BOM across revisions, keeping your customer requirements and technical requirements in sync as the product evolves. This evolution once the MVP is established is the "agile" version in hardware. It does not happen in Slack threads and spreadsheets, not once you are running version two alongside version one and fielding questions from your CM about which revision of a component is current.
PLM is the system of record for your product. It connects your engineering data: your components, your BOMs, your change orders, to the decisions that actually move production forward. Without it, version control lives in someone's memory, supplier decisions get made from outdated files, and a CM question about which revision is current turns into a three-hour Slack thread. With it, your team has one place to answer those questions, regardless of whether you are on revision one or revision ten.
That last point ties back to where this post started. Staying lean as a hardware company means eliminating waste: wasted builds, wasted revisions, wasted time chasing down which version of a component is actually in production. Without PLM software, that overhead is constant. Every version bump becomes a coordination problem. Every supplier change has to be manually reconciled across files that may or may not be current. The process gets heavier exactly when you need it to be light. Good PLM software removes that friction so your team can focus on the next iteration, not on managing the artifacts of the last one.
Managing that lifecycle well is how hardware teams stay lean without losing control. oroForge is built to do exactly that. See how it works at oroforge.com.
