Common Connected Hardware Blunders

Over the last few years we’ve worked with a number of startups who have engaged with Viget for help designing or engineering some aspect of their connected product. Every product is unique, but it may surprise you how similar their challenges are. What is perhaps less surprising is the number of inventive ways we’ve seen solo-entrepreneurs, young startups, and even internal business units with firm foundations go about solving those challenges. I’ll take a moment to reflect on some of those challenges and specifically call attention to the missteps and follies we commonly see early-on in engagements.

Building the wrong prototype

Viget builds primarily two different kinds of product prototypes. A stakeholder prototype, which focuses on delivering desired functionality by leveraging as many pre-existing solutions as possible. And a functional prototype, which focuses on exploring production options by honing in on core mechanics and functionality. Both prototypes serve specific needs which often correlate with the natural phases of product development. Sometimes the prototype should support buy-in for an idea, other times it should help sell the path forward.

In both situations the prototype is the center of attention. The prototype is what you share with your team, your boss, investors, and your crowd-sourced customers (even your mom!). Because of the spotlight, it needs to behave in ways that put a good foot forward. This is why we’re so surprised when we come across cobbled-together assemblies that supposedly represent a product vision. It might only work because it gets cast alongside a tremendous number of conditions and explanation. I.e: 

“...ignore this part, focus on this, let me articulate this thing by hand to show you want it WILL do...”

We admire the gumption and eagerness to make things — especially from our clients — but instead, consider the alternative: a self-evident prototype. A prototype that stands up on its own and clearly articulates a vision. A good litmus test is what you’ll find when you crack open the enclosure of a connected prototype. Is it something you are proud to share? Or is it a rat's nest of wires with indeterminable purpose? Why not invest the extra time, and the extra money, and dedicate some effort to articulating an effective product vision? Build the prototype that serves its specific purpose and can survive being the center of attention. Anything less and you are wasting time by building the wrong prototype.

Waiting for perfection

Developing connected products, like anything, is a balancing act. Wait too long and over-build a prototype and you’ll become overly invested in one direction. A tempering thought to keep in mind: every day spent on product development is a day not on the market. Future you is absolutely going to miss out on that revenue.

Finding the right balance stems from experience. Very plainly, it’s important to figure out which features are necessary for achieving present business goals. This gets complicated, fast, because those objectives change. Connected products benefit from a maturing market which will support any number of value-add services, and businesses want the flexibility to explore and ultimately choose the right one.

Take a look at Helium as an example. This team has iterated for well over three years on a concept where the underlying technology has morphed just as often as their business. Over time they have developed strong relationships with their community, their customers, and their investors -- demonstrating an ability to not only deliver useful products to the customers they have today, but also develop products for the customers they want tomorrow.

Restless Bill of Materials

Another source of pain I see are business decisions which needlessly accelerate product evolution. A good example is the price of a bill of materials (BOM) conflicting with business or marketing objectives.

Consider a fully-developed production-prototype built on the back of specific MCUs, peripherals, toolings, and plastics. The cost of adjusting this BOM late-stage is significant, not to mention a collective headache. However it is a common occurrence because around the time that something is ready to enter production its total in-the-box cost can be scrutinized. It is around this time a product team will receive an email along these lines:

“We’re trying to keep the device costs down to x, we hit a snag here and so we’re currently at y, anything we can we do?”

The product team will take a good look at low-hanging fruit already earmarked as extravagance.

“We’re currently platformed on x but can go to y which costs z less. But it means we’ll need to re-develop portions of the firmware, re-route this, calibrate that, etc”

Unlike software, hardware is generally less forgiving to constant tweaks and adjustments. It’s an all around better thing to simply nail to the wall correctly the first time. But that is obviously a hard mark to hit, so what options exist?

1. Go to market regardless with the higher price point.
2. Go to market with the lower (desired) price point. Take it out of the margin, or eat it. Make it up with scale or an equally performant but lower cost v2 in the future.
3. Account for the long-term upside of value-add cloud services (subscription, etc).

I really like options two and three, businesses that maintain a price point and develop margins over time. This is complex to model, and more complex to convey to investors or other stakeholders. However, it keeps the right priorities in place: ship early, develop value-add services, cultivate relationships with suppliers.

Ultimately a restless BOM is indicative of teams not truly collaborating together. There are strategies to hurdle specific challenges, and even aid with hardware versioning, but if the BOM is constantly changing there is little opportunity to build valuable services on top a hardware foundation. And, based on our experience, those value-add services are what matter the most to a connected product businesses.

Hit a snag manufacturing your connected product? Tell us about it below or contact us.