My hardware product failed within 3 years. 6 lessons I learned

In 2015 I and my business partner founded an IoT start-up with the hope of bringing granular level retail analytics to the palm of merchants and brands. We built the product but failed to gain traction in time.

IoT was the buzzword back then. We had a big vision around a data play but things fell apart.

The product was a suite of sensors. Each sensor helps the retailer to track different kinds of engagements within their retail store. Sensors send data to a hub within the store that uploads data to the cloud.

1. Miscalculating true cost of R&D

I always liked the fact that we had a low competition or lack thereof. We were building something from the ground up. The technology was novel at the time so we had to go through multiple iterations to get the product right, which was expected.

But what I missed by a big margin was the cost of customer acquisition. When you are building something new, your sales funnel will have to spend significant time educating the customer. The more competition you have the more your market is aware of the problem and solution. Lesson learned, there’s always a level of “healthy” competition. To make things even worse we were in B2B space (B2B sales take time).

This is valid for any startup.

I finally understand why Mr. Wonderful hammer contestants when they have a lack of knowledge on customer acquisition.

2. Not understanding B2B sales

If you do a kickstarter campaign for the product it’ll give a chance to validate the product against the market and at the same time collect money for manufacturing. Not the case with B2B products. Companies want credibility and they want to see case studies. Thing is, companies don’t care if it’s hardware or software, they want solutions, and you won’t be able to go beyond a limited scale trial unless you have case studies. So even before you go big with sales, you have to build case studies to prove that “solution” actually works.

Luckily we figured this out early on and approached retail designers/consultants instead of approaching brands directly.

My thought was, approaching a boutique retail design agency can lead us to a couple of brands at once. Which was true. Also, our product had the “cool” factor so getting them interested in the product was not hard. Double win! But things fell apart after that. See, the agencies were interested. They liked it and understood that the product will help them to land new projects. But we underestimated the time it’s going to take for them to convince a brand and actually do a deployment.

Here’s what happened after we talked to an agency.

Step 1. Agency will convince a brand to do a trial. Not a hard sell since the product is new, just asking the brand to consider a trial.

This was harder than I anticipated. Brands were not doing a lot of new retail design projects, to begin with, and most of the things have already been planned when agencies started talking, some real effort is required to get a trial. Hard = It takes time.

Step 2. Once the brand is convinced, they will let the agency use the tech for the next small scale project.

Brands are working on a budget for their retail operations. This is a new expense. So, until the next budget meeting, the funds will not be allocated. If the agency pitched the product to the brand in the middle of the year and they said ok, it won’t happen until next year.

3. Manufacturing is expensive, go-to-market prototyping is even more expensive

Once a brand agrees to a trial, the next step is to prepare the hardware. Trial or not the enclosure had to look good in our case. The cost of electronics became cheaper than the enclosure. Before we made the actual enclosure we had to make a mold. In our case mold for a single sensor was between $8,000–12,000. As it didn’t make sense to manufacture enclosures for trials we used shapeways.com to 3d print high-quality enclosures. It was great, but the cost was ~$40 for a small enclosure. For comparison, the cost of the PCB inside the enclosure was around $1.

This was one of the reasons why we abandoned the suite of sensors and just focused on a single sensor.

4. Not focusing on the real value

We concluded a trial run using the first iteration of the product. We didn’t have the analytics platform built at the time so we manually generated the visualizations and sent them to the client. In this particular use case, customers wanted to see if there’s a correlation between engagement and sales, to our surprise there weren’t in some cases. This meant that engagement data will become a commodity to some customers, so it was important to target the customers who would really benefit from the data.

But on the other hand, the product was new and customers didn’t know what to do, so everyone we approached wanted to see data first. We were burning our funding for these trials and in a hurry to show results to investors. All we wanted to prove was “yes our solution can collect this data which you thought was impossible to track”.

We forgot to sit down with customers and explore how they could benefit once they had the data.

Pic from the very first deployment

5. Failing to manage resources

There came a point where our start-up couldn’t produce enough results to match the monthly burn it had. Our engineering team built out the initial product in record times so we can hit the waters quickly and get feedback but the long acquisition process resulted in engineers to become idle afterward. This made us improve the product based on just assumptions, just as a way to keep the engineers busy.

As engineers worked on improving the product we added more R&D expenses to our balance sheet. The thought process at the time was when we actually do mass manufacturing we will anyway have to do these improvements.

6. Taking the certification process lightly

In some cases when we were pitching the product and trying to get customers on-board some customers were very concerned about certification. The popular certifications test the product for potential fire damage etc. Even though we were absolutely sure that our sensors wouldn’t catch fire, customers weren’t convinced. We didn’t want to get certification until trial runs are over and we are ready to move to mass manufacturing, but even for relatively small scale trials, some customers didn’t want to move ahead based on this fact. However, we made some right calls to some extent to overcome this. For our central hub, we didn’t do anything new, we just used an existing Arduino that already had the necessary certifications. It’s hard enough to get a foot in the door, but when customers say no to a trial because of this, it really did put us down.

During my tenure, I’ve been talking to fellow hardware startup founders. One advice that stuck with me the most is; Don’t do hardware development in the first place, always try to reuse existing hardware off of alibaba/aliexpress. You can explore it below.

Startups in general is a race against time. It’s a cliche but I realized it even better with the hardware startup. Hardware adds a layer of constraint, unlike a pure software-based startup.

Pivoting is harder, the burn rate is higher. In a software startup, it’s easy to project your expenses, but in a hardware startup, R&D costs can screw an entire projection because of an iteration.

All said and done, if I were to do it again, this is what I would do.

1. Deconstruct the roadmap. A roadmap item I had when we started was “Talk to boutique agencies and set up a trial deployment — 3 weeks”. Today I would break this down to every single possible step I can imagine and challenge all the assumptions, the ones you are not sure, talk to experts. This has to happen across the board for the entire roadmap. It’s going to cost more time, but it’s still cheaper. This is a must for every venture-backed startup.
2. Fake it till you make it doesn’t apply to hardware startups. You need time to manufacture. Because of that I would talk to clients and try to sell a different product in the market that can at least solve the problem partially. This way I am building the network, getting to know potential common objections in the industry, and understanding the sales process. Example: we were in the retail analytics space. One close but a different product to our offering in the space at the time was “footfall analytics”, we were doing “product engagement analytics”. Former track how many people are coming to the store, later tracks how many end up engaging with the products on display. It’s intended for the same customer.
3. Look for products that can solve at least part of the problem in places like alibaba/aliexpress. We were so obsessed with the design of the enclosure and making it as small as possible while increasing the range. It wouldn’t have mattered in the beginning. This is partly because we approached big brands in the beginning. I should have worked closely with design agencies to find a trial use case where we could use an existing non-ideal sensor to solve the problem of “capturing engagement data” not “building a beautiful sensor that can capture engagement data so we can get x brand to do a trial run”
4. Only after doing above, I would build my product roadmap and assemble the engineering team. With clear risks in mind, I could have managed the resources better.