The two week prototype
The prototypes looked like progress. Then they tried to carry them forward.
The situation
A founder I spoke with had spent about a year researching the opportunity for a new food robotics product before he and his co-founder started working on it full-time.
They had a clear picture of the market they wanted to enter. They had researched opportunities across several geographies, understood where existing products were falling short, and knew that the economics of the food business would put a ceiling on what their system could cost.
Both founders were technical, although neither had previously built a product with this much mechanical engineering, physics, and material science involved. They assembled a small team across mechanical, electronics, robotics, firmware, and PCB design and started developing the first version.
The plan
The founders wanted to work iteratively. They were accustomed to seeing software move quickly, and they brought some of that thinking into the way they managed the hardware team.
They wanted something new coming out every couple of weeks. Spending that time studying different approaches, working through calculations, or developing designs in SolidWorks didn't always feel like enough progress. They wanted to see things working.
So they started asking the engineering team to produce small working prototypes within two week periods. The team initially went along with it and produced prototypes that gave the founders something tangible to evaluate.
Where uncertainty remained
The difficulty showed up when they tried to carry those prototypes forward.
In subsequent sprints, the founders would ask the team to take what had been built and move it closer to something they could eventually produce. Some of those early prototypes couldn't make that transition, and the engineers began pushing back on the way the work was being sequenced.
Some subsystems also required more exploration before there was a sensible design to build. The dispensing system, for example, needed to handle ingredients with very different characteristics. The engineers had to explore multiple approaches before deciding what should be developed further.
After a few attempted sprints, the founders and engineering team began getting more aligned on how the development process needed to work. The engineers became more comfortable saying when a request needed more work before they could commit to a direction.
What needed to be proven first
Looking back, the founder said he would approach those early milestones differently.
Today, one of the things he considers is how difficult a decision will be to change later and how many other parts of the system depend on it. If changing one decision could force five other systems to change with it, his team spends more time working through that decision before moving forward.
He gave the heating system as an example. Choosing induction, microwave, or a combi oven affects space, layout, ventilation, shielding, moisture management, and other dependent systems. Once the team commits to one of those approaches for a product version, changing it becomes difficult. They move more deliberately around decisions like that.
Other parts of the system can be explored differently. For something like a dispenser, he described having people work on multiple concepts in parallel, compare what they learned, and then select a direction.
The pattern
One thing I found interesting about his experience is how the meaning of iteration changed as the team learned how to build hardware together.
Early on, progress meant having something new to see every couple of weeks. Over time, they started paying more attention to the decisions underneath the prototype: which ones affected the rest of the system, which ones would become difficult to change, and where they could afford to explore several approaches quickly.
The founder believes that with what he knows now, the team could have reached that first prototype in five months instead of eight months it took them. His takeaway was that setting the right milestones would have helped them use those iterations more effectively.
If you're in a similar spot
If you're developing a hardware product iteratively, it can be useful to look at what each upcoming decision will affect before deciding how quickly to move through it.
Some decisions leave plenty of room to explore and change direction. Others begin shaping several parts of the system around them.
Knowing which kind of decision you're making can help determine what the next development milestone should look like.