The situation
A founder we work with is developing a consumer product for kids that combines a physical device with a digital play experience. He had spent time researching the market, talking with parents, and testing early versions of the concept. The next step was a larger proof of concept with families.
To do that, he needed hardware that could support the experience well enough to learn whether kids understood it, enjoyed it, and wanted to keep using it. He could start developing custom hardware, but that would mean committing significant time and capital before answering those questions.
The plan
We started by looking at what already existed.
There are manufacturers producing wearables and other small connected devices with many of the same underlying technologies the product would need. If one of those platforms could be adapted, there was a chance to get to the proof of concept with less engineering.
We defined the initial requirements and started looking for manufacturers with platforms that might fit. The idea was to use as much existing technology as we could while preserving the parts of the experience the founder needed to test.
Where uncertainty remained
As we started talking with manufacturers, each conversation went in a slightly different direction. Some had platforms that covered much of what we needed but offered limited flexibility. Others could accommodate more of the requirements, though doing so started to require a larger development effort.
The recommendations also tended to reflect what each manufacturer already did well. One might prefer a certain processor or software stack, while another would suggest components or an architecture it had used before.
Those recommendations were useful, but they created another question: how much should the available manufacturing options influence the product we were trying to test?
What needed to be proven first
We kept bringing the discussion back to what the proof of concept needed to accomplish. The founder wanted to see how kids responded to the experience and whether they kept engaging with it. That gave us a clearer way to evaluate the options manufacturers were putting in front of us.
If an existing platform could support that experience, there was little reason to recreate everything ourselves. If adapting the product around a manufacturer's platform compromised something important to the test, the shortcut became less useful.
That distinction helped separate decisions we were making because they served the product from decisions we might make simply because they were convenient for a particular manufacturer.
The pattern
Manufacturers bring technology, engineering experience, and supply chains that can save a hardware company a lot of work. Early in development, that can make an existing platform worth exploring.
It also helps to enter those conversations knowing what the next version of the product needs to accomplish. Otherwise, a series of reasonable technical decisions can gradually shape the product around what a particular manufacturer is equipped to build.
At Hardware Velocity, this is why we define what the product needs to accomplish before deciding who should build it. It gives us a basis for evaluating a manufacturer's recommendations without letting their capabilities define the product.