It started with an unrealistic promise. The device we were building had technical challenges (like many new hardware products do). The only problem; our team underestimated the challenges. When a product requires small size, precise GPS performance, low power consumption and low cost of production and beautiful aesthetics, ALL in one. This is possible; and definitely many companies like Apple, Fitbit or any of your favorite wearable consumer electronics have made it possible. But they have the advantage of scale (to drive down per unit cost), a large engineering department full of experts in different fields working closely, and very deep pockets. A startup customer does not have any of those resources, and all of those challenges.
So to approach it you need to become extremely focused on the core features, so that the auxiliaries can be allowed to slip.

First Mistake: Didn’t Prioritize the Core Features Above Others

That’s where I and my team at Oxeltech made our first mistake; we approached the product MVP with “every feature is important”. And that meant, no one was. That led to progress on the easy fronts; but the difficult features (which were also product’s unique selling point), were not given the due attention. One example is getting high precision of GPS in small PCB space. If you’re experienced in development of GPS devices, you would know that size of the ground plan plays a major role in its accuracy. And smaller ground plane would require careful workarounds. That was not given its due attention, for example, since we were happy in developing the nice UX features (communication with the cloud etc.).

We found out after producing the 2nd PCB iteration, that GPS accuracy wasn’t good enough.

A core feature was not addressed 6 months until after the start of the project. An unforgiving failure on any engineering team’s part working in 2024.

Which brings me to the second point. Why would we find out about it in the second iteration, and not the first?

Second Mistake: Didn’t Pay Special Attention to PCB Design Review Process

We had a design review process, but it was dependent on one developer, who missed catching a few design mistakes. Unfortunately, one of those was pin connections of level shifter that communicated with the GPS tracker. So we couldn’t test GPS when the PCBs arrived. Another 6 weeks were wasted before the 2nd iteration of PCBs arrived and we could first test the performance of GPS (which unfortunately wasn’t working as expected).

Third Mistake: Didn’t Resolve Conflicting Requirements First

The beauty aspect of the device required round flexible PCB (we thought). So we went ahead with it. Only later did we realize, that this flexible PCB cost, even at large volume, will not be negligible. So after the 2nd iteration and asking multiple vendors, we faced this uncomfortable truth, that this PCB type will drive up the cost for small and medium productions. It may look nice in the casing, but we would violate the cost constraint, which would make it economically unfeasible.

Fourth Mistakes: Tried to Avoid Functional Risk in the first Iterations

Avoiding functional risks in the first iteration might seem like a reasonable approach, and that’s why it is difficult to assess how much risk of functional failure can be taken in the first PCB iteration. You want to build the confidence that the things work unoptimized first, and optimize them later in the final iterations. But that approach meant that several design decisions to reduce the size were postponed to the 3rd and 4th iteration.

For example, choice of size and cost-optimized chips for power and battery management. This could have been done in the first iteration by spending a few days upfront, it would have taken a few more days in the first iteration but would have saved considerable redesign effort. That’s one of the places where approaching the design carefully and with thoughtfulness and detailed analysis can save you effort later.

My takeaway: taking bold risks in the first iterations can pay off in the development of an innovative product. These risks don’t go away at later stages, so adapting those aspects later could mean further delays in case you face failure.

Conclusion:

Developing innovative hardware/electronics MVPs requires executing bold ideas early, a sharp focus on core features (while postponing the less critical aspects), and meticulous attention to detail to avoid costly mistakes. Unlike software, hardware development errors can set you back by months.

If you’re developing an innovative electronic product, you’ll need to take calculated risks, have good planning as well as detailed analysis. In case short time to market is important for you and you need support in the development of your hardware MVP, don’t hesitate to reach out to our team at Oxeltech for expert guidance.