It took two
Why the first prototypes were designed to answer questions about what should come next.
The situation
A founder came to us with an idea for a connected hardware product designed to improve safety in residential neighborhoods. The product would detect activity on residential streets, respond in real time, and collect data to evaluate its impact.
The founders had already spent time with potential customers and stakeholders and had received encouraging feedback on the concept. They had enough evidence to keep going, some capital available for development, and a broader goal of eventually putting a small number of devices into neighborhoods to measure their impact.
They were at the point where a lot of hardware companies start looking for engineers. Before doing that, we needed to get more specific about what they were ultimately trying to build and what they needed to learn before getting there.
The plan
We started by defining the market and product requirements. Who was the initial customer? Where would the product be used? What did it need to accomplish for that customer? What would eventually need to be true about its performance, installation, cost, reliability, and user experience?
That gave us an end state to work backward from. We could translate the requirements into a system architecture, identify the major technical and product risks, and determine how development should be staged.
The first meaningful development step became two working prototypes. These units could be larger, more expensive, contain more sensors, and require more maintenance than later versions. Their purpose was to get the system into the field and generate the information needed to make better decisions about the next build.
We then broke that work into milestones. The engineering team would select the major components and complete the architecture, demonstrate the sensing and data-capture functions on the bench, integrate the subsystems, and eventually deliver two complete systems.
Where uncertainty remained
The architecture gave the engineering team a starting point, but there were still questions that could only be answered by building and testing.
Component selection depended on the operating environment, installation constraints, and the information the system needed to capture. The team also had to work through sensing performance, connectivity, power, enclosure design, and how the various hardware and software systems would operate together.
Testing surfaced more questions. Environmental testing exposed limitations in the original power approach. Different approaches to detection produced different performance in the field. Additional processing created thermal issues that required another engineering change and more testing.
These were useful findings because they happened while the team was still working with two prototypes. Each one could inform the design before committing to a larger build.
What needed to be proven first
Over the following months, the engineering team worked through those questions one subsystem at a time. Individual components could be demonstrated independently before being integrated into the enclosure and tested as a complete system.
Eventually, the team completed two working systems that could move out of the lab and into the environments where the product would eventually be used. That created an opportunity to learn from the complete product rather than from individual components or specifications.
Some of those learnings are already affecting decisions about the next build. One open question, for example, is whether the system should remain as one unit or become two separate units working in concert. The team held that decision until there was experience using the prototypes in the field.
The product requirements and architecture can now be revisited with those learnings before defining the next stage of development.
The pattern
There is a limit to how much you can learn about a hardware product before you build it. Requirements help define what the product needs to accomplish, architecture translates those requirements into a technical system, and a development plan determines which questions should be answered first.
Building creates the next set of information. A component may behave differently outdoors, a technical approach may create another constraint, or using the integrated system may change how you think about the product itself. Those learnings should inform what gets built next.
This is why we work backward from the end state and develop hardware in stages. Each stage should answer enough of the important questions to make the next investment with better information.
If you're in a similar spot
If you've validated a problem and are preparing to start engineering, you don't need every product and technical decision resolved before you begin. You do need a clear picture of where you're trying to go, the assumptions that could change that path, and what the next round of hardware needs to teach you.
That gives the engineering team a defined outcome to work toward and gives you better information for deciding what to build next.