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" 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:
- Failure to separate research and development phases
- Failure to collect and document requirements
- 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 week, we’ll take a look at how misplaced focus can delay schedules and increase burn rates.