A Look at Ten Hardware Startup Blunders, Part 2: Schedule and Focus

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 second in our four-part series and focuses mistakes related to the team’s focus.

Focus-related Mistakes

Building a new hardware product can be an overwhelming endeavor. There are many facets to consider: mechanical hardware, electrical hardware, firmware, app software, server software, packaging, supply chain, manufacturing, marketing, and more.

Many new hardware teams go astray by focusing heavily on specific aspects of product development while ignoring others. A hardware company must design an entire ecosystem, and each aspect of the system must be properly considered for all the pieces to fall into place. Teams that focus too heavily on a subset of product development efforts while ignoring others will encounter late-stage re-design efforts and schedule delays.

Let’s look at four focus-related mistakes that send hardware companies astray:

  1. Skipping software architecture
  2. Prioritizing Mechanical Design
  3. Setting the schedule based on hardware milestones
  4. Heading straight to China for manufacturing

Skipping Software Architecture

Teams will regularly focus on industrial, mechanical, and electrical prototyping and design efforts before beginning software engineering and design work. When it comes to software, most new companies bypass software prototyping and architecture altogether. Teams dive right into coding, even before they understand the system requirements and product functionality.

The popular view of software is that it’s infinitely changeable and cheap to develop. This view ignores the fact that software, especially firmware, is one of the most expensive aspects of creating a new product. Software development efforts for most products will cost between $15-$45 per line of code. More complex engineering projects like the space shuttle may reach up to $1000 per line. For many projects, a mere 1000 lines of code will end up costing as much as a kilogram of gold. Simple projects might get away with a design involving 25,000 lines of code, while more intensive products will have hundreds of thousands.

Without performing software architecture and software design processes, startups significantly increase the risk of schedule delays due to design flaws. Hardware ecosystems are complicated and typically involve multiple interactive software components. Your firmware design and electrical design are tightly coupled, and selecting incompatible processor/storage/RAM which can’t support the true needs of the product will lead to significant redesign efforts.

Prototyping efforts are invaluable when building new products. Teams can quickly try out solutions, check the feasibility of features, and create product demos. These prototypes are quickly thrown together with little thought given to system integration, interface design, or interactions with other software systems. Time and time again we have seen prototypes transform into the shipping design, inevitably causing teams to enter into a never-ending cycle of patching holes in a sinking ship.

Dedicate time to intentionally designing the shipping software architecture for your product. Your architecture efforts should consider the hardware product itself, as well as the application software and server software that it will interact with. Once you have an architecture for the software, you can create a more effective product development schedule – you know what your team needs to build, and you can identify pieces that can be parallelized, outsourced, purchased, or licensed.

Working systems don’t come together by accident, and software architecture efforts are a necessary activity to ensure your system intentionally meets your design goals. Failure to spend time on software architecture will result in continual schedule delays due to redesign and debugging efforts.

Prioritizing Mechanical Design

Many teams begin their product development by exclusively focusing on the industrial and mechanical design. Teams want their product to look good, and mechanical design is satisfying: it exists in the physical world, and you can show off the prototypes to your investors and entice prospective employees. Often, mechanically focused teams only begin to consider electrical and software engineering after they lock the industrial and mechanical design. Locking mechanicals before considering software and electrical constraints will create design challenges for your team – some of these constraints will inevitably impact the mechanical design.

The mechanical design places constraints on MLB size and component selection. With today’s trend of miniaturization, our electrical designs must fit into smaller and smaller packages. This comes with a tradeoff in increased complexity of the electrical design, manufacturability concerns, and limits on component sizing. Cramming our electrical designs into small packages requires specialized layout expertise and often comes with an increase in signal integrity and desense problems. Teams may also find that the components that are needed to support the product’s features simply don’t fit into the package, leading to feature cuts or requiring the software team to mimic hardware features. Your product’s performance becomes limited by the components which fit within a limited size range. Perhaps the perfect component is larger than one your mechanical design will support.

The product’s thermal performance, another common design issue, impacts how the software and electrical hardware function and how long the product can operate. Thermal problems are best resolved with a mechanical design change, although many teams choose to implement difficult workarounds: software must support load monitoring and dynamic throttling, layout gymnastics must be performed to shuttle heat around the PCB, or features are limited because there isn’t enough thermal budget.

When teams lock mechanical and industrial design before considering the electrical and software requirements, a laundry list of mechanical change requests inevitably results. Management and mechanical engineers meet these change requests with significant pushback because the changes often necessitate new tooling or modifications to the look and feel of the product. This pushback creates team friction, requires feature cuts, and often results in schedule delays.

Your team should not lock down your mechanical design until they understand the full product requirements. Teams must design and prototype the full electro-mechanical-software system before committing to expensive tooling purchases. In many systems, thermal constraints are a significant design problem requiring mechanical updates. Oftentimes the perfect components for your design may require a larger form factor, or selecting smaller components results in an increased BOM cost or difficulty securing the parts.

Lock down your mechanical design only after the team understands the full system requirements and you have prototyped the production intent product. All members of the engineering team must have the opportunity to weigh in and confirm their ability to design to the requirements within the given the mechanical constraints.

Setting the Schedule Based on Hardware Milestones

Hardware companies tend to set their development schedule based purely on hardware milestones. The universality of the New Product Introduction (NPI) process and the defined build milestones make it easy for teams to throw together a schedule. The team picks dates for these milestones based on market timing (e.g. “We want to be in stores by Christmas”) instead of basing the dates on engineering accomplishments (e.g. “We’ve implemented the critical features and are ready to refine the design and ship to customers.”).

Teams with aggressive hardware schedules end up spacing development builds based on hardware lead-times. The team, typically small at a startup, focuses primarily on building the system. They do not have time to sufficiently review data, validate, debug, and improve the design before the next hardware build. Hundreds of thousands of dollars worth of development hardware is produced, most of it destined to become paperweights.

Aside from purely mechanical designs, hardware companies today are building complex ecosystems involving multiple interdependent systems:

  • Electrical hardware
  • Mechanical hardware
  • Firmware
  • Application software
  • Server/backend software
  • Packaging
  • Accessories

When companies rush through the various hardware build milestones, they generally learn that the ship date must be delayed because the software isn’t ready. Millions of dollars in capital is tied up in inventory that cannot be sold to customers while the developers are still completing the software. Weeks and months pass by while the developers finalize the software, and CM payment penalties start piling up in the form of storage and shipment delay fees.

Teams must base the product schedule on the development of the entire ecosystem, not just the EE and ME components. Your team needs sufficient time to test the designs, identify improvements, and incorporate changes for the next milestone.

In almost every case of a ship date delay that we’ve encountered, software readiness was the culprit. If you base your schedule on your total ecosystem and team’s capabilities, you will spread out your hardware builds. Your hardware team will have time to validate and refine the design, and the quality of your hardware will increase. The hardware team can also benefit from time to design and validate the accessories between major system builds.

Heading Straight to China for Manufacturing

New hardware startups tend to head straight to China for manufacturing their products. We even encounter teams that focus on building manufacturing relationships in China without even having a working prototype or list of product requirements.

In most cases, we believe that manufacturing in China is the wrong choice for new hardware companies. We suspect that companies head straight to China because they want to want to be like the big guys – Apple, Google, Amazon, etc..

Manufacturing in China places a significant burden on your company:

  • Your team does not benefit from the lessons learned during small manufacturing runs in a timely and effective manner due to language barriers and the long distance between your engineers at home base and your engineers in China
  • You must pay NRE costs for setting up the manufacturing process
  • You must pay for labor during development builds
  • You must pay for your employees to fly to China and stay in hotels
  • You must commit to build dates and build quantities, and if you do not meet those commitments you will still pay for the builds and parts ordered
  • You have to worry about customs issues for importing and exporting parts and products
  • If you build too few development units, you must wait until the next build event to produce more
  • If you build too many development units, you waste capital
  • Employees spend significant time traveling to/from China, taking away from product development time
  • Employee effectiveness drops due to jet lag and exhaustion
  • Employees frequently do not have access to the tools they need
  • Employee morale suffers due to frequent travel, long trips, and time away from family
  • Teams constrain their hiring to those employees who are willing to travel to China frequently

Until you have a product design that is ready for production at scale, finding a CM in China will only create unnecessary stress and financial burden. It’s best to focus on your piece part supplier relationships first.

Before you get there, take that NRE money and invest it in local design houses, prototyping shops, and fabricators to finalize your design. Plenty of local small-scale turnkey producers exist, and many of these producers can provide quick turnarounds on small orders. Instead of waiting two months to test your next design, you can have parts in hand within days or weeks. While your cost per unit will be higher, you will spend less money overall by getting immediate design feedback to your team. And your employees will be able to work toward the end goal more efficiently.

In the early stages, your team should be assembling your product in house. Your engineers will gain valuable learnings from assembling the product and seeing the problems first hand. You can build continuously to quickly iterate on the design – if there is a required change, you can get parts built and integrated without waiting for a full manufacturing event.

Start looking for a CM partner only when your team has finalized the product design and is ready for large-scale manufacturing. If you are still designing your product, there is no sense in committing to manufacturing deadlines and production quantities. With a final design you are much better armed to know your timelines and quantities and can focus on pricing negotiation. It’s difficult and costly to do both design and negotiation in parallel.

Next Up

That’s it for common focus mistakes. Next week, we’ll take a look at mistakes related to startup team composition.

One Reply to “A Look at Ten Hardware Startup Blunders, Part 2: Schedule and Focus”

Share Your Thoughts

This site uses Akismet to reduce spam. Learn how your comment data is processed.