6 December 2018 by Phillip Johnston • Last updated 14 December 2021

At Embedded Artistry, we’ve spent countless hours meeting with founders, working at startups, and swapping war stories with fellow engineers. After enough iterations, we started to notice a repeated set of critical strategic missteps made by new hardware companies. These missteps result in compromised designs, increased development costs, and continual schedule delays.

We’ve selected ten mistakes regularly observed at new hardware companies which fall into three general categories: process, focus, and team. This article is the final article in our four-part series

1. A Look at Ten Hardware Startup Blunders, Part 1: Process
2. A Look at Ten Hardware Startup Blunders, Part 2: Schedule and Focus
3. A Look at Ten Hardware Startup Blunders, Part 3: Team

A Review of Our Top Ten

Mistakes made at the beginning of a company’s or product’s life can have long-reaching effects.

The beginning is the most important part of the work.
— Plato

The impact of the mistakes we highlight are not immediately apparent. Like cancer, the damage slowly builds up over time until there is no going back. Your company will have to undertake painful exercises to get back on course, and if the damage is too great your team may not fully recover.

When the problems are finally big enough that your team must face them head on, they are often so far removed from the causes that it feels like an inevitable consequence of building a new product. Keep an eye out for signs of these common blunders and make a course correction before it becomes too painful:

1. Failure to separate research and development phases
2. Failure to consider data collection requirements
3. Lack of defined internal processes
4. Skipping software architecture
5. Prioritizing mechanical design
6. Setting the schedule based on hardware milestones
7. Heading straight to China for manufacturing
8. Committing to a schedule before having the execution team
9. Hiring junior or mid-level engineers and expecting senior-level work
10. Attempting to build a full-stack engineering team

None of these challenges and missteps are new. You can read about some of these observations in engineering classic written in the 1940s. So why are we repeatedly encountering the same basic problems?

Jack Ganssle, an embedded systems consultant, highlights our lack of learning while reflecting on “NASA’s lost software engineering lessons“:

And today, 49 years later, we still haven’t learned those lessons. Large software projects are routinely plagued with the same sort of problems we “learned” to avoid half a century ago.

Jerry Fitzpatrick, a software consultant and author of The Timeless Laws of Software Development has this to say:

Collectively, we don’t seem to be learning from the past. I don’t know if this is due to an education shortfall, the influx of so many new developers, the acceleration of business expectations, or other factors. I suppose if the reasons were obvious, there would be fewer mistakes.

After all this time, the only thing that has changed is that we expect our engineers to produce faster and faster, even though we haven’t fixed our fundamental attitudes and processes. We can change the trend and learn from companies who have gone before us.

Further Reading

Here are classic works related to software project management, scheduling, requirements, and estimation:

1. The Mythical Man Month, by Fred Brooks
2. Applied Software Project Management by Andrew Stellman and Jennifer Greene
3. Software Requirements by Karl Wiegers and Joy Beatty
4. Software Estimation: Demystifying the Black Art by Steve McConnell
5. The Economics of Software Quality by Capers Jones

For a straightforward approach to software project estimation, try the Wideband Delphi technique described in the Karl Wiegers’s paper “Stop Promising Miracles”.

We frequently write about product development on Embedded Artistry:

• Building a Team that Delivers Business Value
• Musings on Tight Coupling between Firmware and Hardware
• Embedded Artistry’s Technology Radar
• The Mythical Man Month
• The Timeless Laws of Software Development
• Leadership Advice from the Tao Te Ching
• Cargo Cult Science
• Shipping Mindset

The following websites provide excellent product development and manufacturing advice that can benefit new hardware teams:

• Dragon Innovation Blog – focused on manufacturing
• Bolt Blog – a hardware VC fund that publishes articles related to product development

Jack Ganssle, a veteran of the embedded systems industry, shared his own “Top 10 List for How Embedded Projects Run Into Trouble”. He’s also published a series on embedded.com which covers each point in further detail:

• Not Enough Resources Allocated to a Project
• Jumping into Coding Too Quickly
• The Undisciplined Use of C and C++
• Bad Science
• Crummy analog/digital interfacing
• Weak managers or team leads
• Writing optimistic code
• Poor resource planning
• Quality Gets Lip Service
• Unrealistic Schedules

Thanks for Reading

Thanks for following this series. We hope that you will be able to identify and avoid these common blunders on your next project. We must learn from our mistakes to avoid repeating them endlessly. Wouldn’t you rather solve new and interesting problems instead of rehashing the same old ones?

Would you tell me, please, which way I ought to go from here?”
“That depends a good deal on where you want to get to,” said the Cat.
“I don’t much care where–” said Alice.
“Then it doesn’t matter which way you go,” said the Cat.
“–so long as I get SOMEWHERE,” Alice added as an explanation.
“Oh, you’re sure to do that,” said the Cat, “if you only walk long enough.”

• Alice’s Adventures in Wonderland, Chapter 6