Product Development

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.

A Look at Ten Hardware Startup Blunders, Part 1: Process

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 first in our four-part series and focuses on process-related mistakes.

Process-related Mistakes

"Process" is a word that sends startup teams running for the hills. "Process" evokes feelings of shackles, big corporations, red tape, and slow development cycles. New teams will throw process to the wind and justify their actions by claiming they need to move as quickly as possible.

Teams that avoid the proven paths will find themselves beset by common and avoidable problems. Modern hardware businesses are extremely complex and involve the coordination of multiple moving pieces. Often, young teams don’t recognize this complexity and fail to realize that following even light-weight processes can help them manage the complexity and reduce risk.

“This is not ‘Nam. This is bowling. There are rules.” — Walter Sobchak, The Big Lebowski

Avoiding defined processes is also a major distraction: teams need to focus on building products and creating value, not reinventing basic business practices on a daily basis. Let's look at three process-related mistakes which new hardware teams frequently make:

  1. Failure to separate research and development phases
  2. Failure to collect and document requirements
  3. Lack of defined internal processes

Failure to Separate Research and Development Phases

The most common mistake we see new hardware companies make is failing to separate the research and development phases of new product development. Teams making this mistake are easily identified: they enter into the New Product Introduction (NPI) process with unanswered design questions, no requirements documentation, or an ever-changing product feature set.

The term “R&D” can make it seem like there is one combined research-and-development process. Conflating these two distinct phases leads to repeated schedule delays, stressed teams, and compromised products. The research phase must come first. Teams commonly conflate these two distinct phases because they don’t know exactly what the product will be until they try to build it. Investigatory efforts should happen during the research phase rather than during the development or NPI phase. The pressure of meeting manufacturing build milestones hinders effective research efforts and forces the team to continually make compromises.

Another symptom of this mistake is that teams tend to defer problems and open questions throughout the project. The deferred problems are often critical to the product’s design and functionality. Common hardware issues such as thermal management and wireless connectivity can drive the need for major revisions. Major software risk areas are deferred until late in the program, triggering last-minute fire drills and large-scale rewrites. Both situations result in delayed product ship dates and the necessity for additional NPI development builds. Saving the hard questions for later is never a winning strategy even if it may feel like it saves time.

Since the research phase involves the exploration of the unknown, teams cannot create an accurate schedule during this process. The team should set a target timeframe for the research phase and re-evaluate progress at defined checkpoints. Figure out the marketing requirements (MRD), and then translate those into engineering requirements (ERS) and a firmware/software/electrical feature set. Pick ten major product features and prototype the electrical and software systems to make sure they can actually work together as expected. Identify open questions and develop a plan to answer them within the research timeframe. Try alternative approaches, solicit feedback, and narrow your choices. It’s critical to make decisions at this stage in order for the engineering team to move forward toward an effective design.

The development phase can begin once the team has sufficiently answered the open design questions and decided on the major product features. When teams reduce a project’s unknown factors before beginning product development in earnest, they reduce the risk of discovering problems at last-minute and embarking on re-architecture efforts which delay the product's ship date.

To improve your chances of success, follow this basic process: define the marketing requirements, perform your research, develop the engineering specification for the product, and then begin design and integration. A team should only start the NPI process after they complete the research phase, answer major design questions, and document product requirements.

Failure to Collect and Document Requirements

When we request information about product requirements from young teams, we often receive investor pitch decks or product concept slides full of feature lists, hyperbolic claims, and vague descriptions of functionality. Occasionally we meet a startup whose investors forced them to create a Marketing Requirements Document (MRD) or Product Requirements Document (PRD), but these documents are often used as a one-time exercise and then left to collect dust.

Engineers need to have a sense of the entire product to effectively design the hardware and software systems. Requirements also serve as a metric that teams can use to evaluate the tradeoffs between design options. When teams attempt to build a new product without figuring out the requirements and feature set up front, they open the door to repeated re-design efforts and frustrated engineers. Systems without documented requirements are subject to strong winds of change from product designers. The ever-changing feature requests will lead to system restructuring. Ensure your team has a process for handling requirement change requests and communicating final requirements to the entire team.

Requirements gathering efforts must also look outside of the box of product features. For example, every technology company needs to consider data collection in their software design. Product designers want to learn how customers and testers are using and breaking the product. Developers want to access debug information when users report issues. We frequently find teams who only consider data collection needs near the end of the program, which trigger delays and software redesigns.

Your team should build the software with data collection in mind from the beginning. Answer the following questions when designing your system's data collection capabilities:

  • What parametric data related to customer usage are you interested in collecting?
  • What events do you want to monitor?
  • What data do you need to collect to make effective decisions?
  • What data do you need to down-select from available hardware/software choices?
  • What debug/failure information will you need to collect in the field?
  • How do you track the firmware versions used in the field?
  • How will you get your data?
  • Where will you store your data?
  • How long will you keep your data?
  • How will you parse and analyze your data?
  • Are you collecting only necessary usable data?

Answering these questions will help your team create a data collection solution that meets your product's needs. Teams should repeat this exercise for other supporting product development efforts, such as manufacturing tests, automated regression testing, build automation, and software updates.

Note that “documenting requirements” doesn’t mean your team cannot begin prototyping until they lock requirements. Serializing requirements gathering and prototyping efforts leads to another form of unnecessary schedule delay. The team can prototype different requirements to make sure they can meet them effectively, or begin work on important requirements which are already locked down. Your team will get some of the requirements wrong, and prototyping them is the best way to expose this early on. This process should be done in parallel with the research phase.

Spending time documenting and communicating product requirements (even just two weeks) is an essential task that will help your team focus on critical design details and avoid the need for re-architecting the system late in the development cycle.

Lack of Defined Internal Process

Modern businesses are complex, and hardware companies especially so. There are many moving parts involved in creating, building, shipping, and selling hardware products. Effectively coordinating these efforts requires planning and well-defined processes.

Can you answer the following questions for your company?

  • How are you tracking issues?
  • How do you evaluate and select a supplier, consultant, or contractor?
  • How do you keep track of what designs and requests you’ve already released to your suppliers and which are still outstanding?
  • How do you track when each design element will be received and can be integrated and tested?
  • How do you know whether you're hitting your sales and outreach targets?
  • How do you determine whether a new software build can be released to your customers?
  • How do you name, track, and version your parts, boards, and software?

Far too often, we find that teams have a hard time answering these basic business process questions. When an answer is provided, rarely is it documented or widely known by the team.

Companies repeatedly encounter and solve the same sets of business problems. In almost every case there are numerous existing approaches which will suit your company and situation. Keep in mind that your team's network is filled with investors, advisors, and other hardware companies that can provide you with valuable advice on the processes they use to manage their business.

When you encounter a new situation, research, select an approach, document it, and educate your team on the process. Don’t worry about perfection - you can adjust the process as you learn what works best.

With the proper processes in place, execution can be a breeze.

Next Up

Next week, we’ll take a look at how misplaced focus can delay schedules and increase burn rates.

Embedded Artistry's Technology Radar

I was introduced to the Technology Radar concept while at Bredemeyer Consulting's Software Architecture Workshop. The Technology Radar concept was created by ThoughtWorks, and they regularly publish updates to their own radar.

I immediately latched onto the concept as an effective way to track the technologies and techniques that we are investigating at Embedded Artistry. Our technology radar can also serve as a reference and source of inspiration for other embedded systems teams.

We’ve identified four categories that we plan to explore as an embedded systems consulting firm:

  1. Tools
  2. Libraries and Frameworks
  3. Platforms (both hardware and RTOS)
  4. Techniques

We've released the first-draft of our technology radar and will update it on an ongoing basis.

You can find our Technology Radar on the website under the Resources menu.

For more on technology radars: