You’ve likely heard that “hardware is hard”; mostly because hardware startups have to deal with things that software companies don’t really have to worry about. That includes pesky details such as “physics” and “battery management” and “general wear and tear.”
Hardware development is complex and challenging. Physical parts have tolerances, both in size and material properties, and components get hot and their characteristics change when they do. Once you’ve designed a product, the manufacturing process itself poses significant challenges. Ensuring that components are produced with the required precision and quality demands careful planning and rigorous testing throughout the process. Hardware manufacturers often work with multiple suppliers and manage supply chain logistics, which can be resource intensive and time-consuming.
Hardware development is inherently a lot more costly than cranking out software. Developing a physical product requires substantial investment in materials, tooling, manufacturing and logistics. These expenses, combined with the need for multiple iterations of prototypes, can make the process financially risky, particularly for resource-constrained startups.
There are plenty of pitfalls, and as a hardware nerd myself (I founded a hardware startup, which I then spectacularly ran into the ground at high velocity, making mistakes that most experienced hardware folks would laugh at these days), I am always curious to learn how hardware entrepreneurs can avoid some of the common mistakes.
Sera Evcimen knows a thing or two about the challenges for hardware startups. She’s a mechanical engineer and worked at four startups, including satellite design, consumer electronics, doing systems integration in an R&D department for a fusion startup and working on ion thrusters. These days, she’s a technical program manager for a large company she can’t name, where she’s working on soft robotics for human interaction, and she’s an all-star mentor for the Techstars startup accelerator. She even runs her own consultancy to boot. She’s working on a podcast called The Builder Circle, where she breaks down the challenges and risks of building hardware companies. Like I said, she knows her stuff, and we chatted about things to avoid when building hardware.
Lack of focus
As a startup, you are an organization designed for learning, and learning is sensationally exciting. But it has its downsides: As you continue to learn, it’s tempting to try to chase every great opportunity that comes along.
The mistake is to fall for the temptation and lose focus.
“Oftentimes, this sneaks up on people because people have completely different systems that they’re trying to push forward,” Evcimen told me. “They’re saying, ‘Oh, this could work in this application, and this application and this application.’ Alternatively, a company may say, ‘Oh, it’s just the same thing, but bigger,’ or ‘It’s just the same thing, but smaller.’ I think it’s really important to know that each variation of a product is just an additional product line. Similarity doesn’t mean anything. Even if that is true, you still have to have individual designs; you still need to manage your supply chain. And … you even need to develop multiple supply chains.”
A smaller module might mean different chips. A different casing could mean different molds and tooling. Each small change can affect the whole product development timeline. Even something as simple as launching exactly the same product in a different color can create significant bottlenecks.
“Working on more than one version takes away from early learning because you’re trying to do too much at once. You’re already a small team, trying to operate with cost constraints and time constraints,” she said. “It also dilutes the understanding of the market: If you do your proper due diligence and your user studies and market research, you’ll start to get a sense of which one is going to be potentially the most lucrative, or which variant you can use to learn quicker. By giving up focus, you are going to start learning slowly on all of them. That means you need to bet on one, rather than pursuing one that has the most potential.”
And that can be a killer: Startups raise money, then make a bunch of products, trying to push them all forward at once. If something happens in the production process, they’re stuck with a bunch of half-baked products, sucking up funding along the way. It’s a spiral, and it’s not pointed in the right direction.
No systematic risk retirement
Building physical products comes with tremendous amounts of risk, but great hardware developers take a systematic risk retirement approach. In reality, as an early-stage startup, you’re solving three major problems at once: building a company, building a product and building a reputation. Designing a way to manage the risks inherent in all three is a crucial step toward building a successful company.
Some people are super risk averse and try to design all risk out of the process. That doesn’t work and is often a waste of time. Without a systematic risk retirement plan, where you’re saying “these are all of my systems, each system has this set of risks associated with it,” you can’t prioritize the risks or manage them.
When you go to a fully integrated system or a fully integrated product, if something is causing a failure, you’ll know how to attack the problem because you already have a map of all the risks and how they are connected.
“Without risk retirement, what could happen eventually is that you can’t really determine what’s causing the issue. And so you can’t solve it, which causes a huge delay and frustration, and you need to pull it apart and do your risk retirement kind of aggressively later. It means things start falling apart,” Evcimen said. “You take risks without knowing you are taking risks. When problems are identified, you have to usually go through some level of change orders, which at times can be super dramatic. That causes huge impact — time, money and reputation — because you risk the product failing. As an early-stage company, no one knows of you, so you can’t afford hits to your reputation. First impressions matter. I feel like this is something that oftentimes gets sidetracked because it falls more in the systematic program management category, which a lot of startups tend to implement later on.”
This can be avoided by creating a risk plan early on. Form an engineering team and create a system map, which includes an overview of all of the subcomponents of a solution. You pull it apart and map out the risks, whether they are manufacturing risks, lifecycle risks, wear and tear, or environmental risks.
Categorizing your risks, and then writing out everything that comes to mind, is a good place to start. From there, you analyze the risk of likelihood versus impact. In other words: How likely is this to happen? Next, you take your best guess on impact. If this were to fail, would it cause an entire system failure?
Ultimately, the point of the exercise is to get risks to a lower level — a level where the company feels comfortable — and that needs to be set by the startup’s leadership.
Letting marketing promises take the driver’s seat
Product development needs to be driven by technical requirements and customer research. Unfortunately, what often happens is that business development runs faster than product development.
“It’s super easy to use big words and exciting terminology to spark people’s interest. And then when that interest is sparked, then it’s really easy to fall into the trap believing there is much interest in this product, that you have to build it exactly the way you have been talking about it,” Evcimen said. “That’s a problem: It moves away from the actual problem-solving to serve an unvalidated customer base. The wrong assumption is that the business development function is going to the correct customers and talking to the correct people. That could very much not be the case.”
If the engineering team starts using the marketing premise as a technical requirement, that can shift the entire process, leading to underdelivering low-performing, delayed products that aren’t considering the needs of the target audience.
Assuming the problem the company is solving is valid, and that the solution is right for the target customer, the next step is to understand who the ideal users are. From there, validate the assumptions through conversations with these customers. That way, you’ll be making informed decision about what customers want and not catching up with what the sales team is trying to sell.
“Solutions should be market driven and not driven by marketing, ego or exciting buzzwords,” Evcimen said.
Over- or underconstraining
Another mistake hardware startups make is overconstraining or underconstraining the design through requirements or lack thereof. You need some constraints on what the product is and does, but depending on the experience of the engineering and founding teams, you may end up getting things wrong.
“When you have a product that’s predictable and has been done before, by all means, go ham on the system requirements so that you make it as perfect as you can as quickly as you can,” Evcimen said. “But in innovative products, which a lot of startups are working on, that’s just really not the right approach. You need to be able to assess what level of requirements is going to spark innovation and get the best and most efficient results.”
For example, people who have experience in designing military systems tend to overconstrain the problem, creating an extremely detailed map of every feature, function, limitation and specification of a product before they ever build a single prototype. That makes sense for some industries, but hardware has become a lot more agile than that.
But underconstraining can also be a problem. “If you have a lot of engineers and you have an open terrain where they get to frolic around and solve problems, they will brainstorm in every direction, and go all over the place. The problem is that people will be making systems that don’t interface with each other,” Evcimen said.
Building requirements that add a little bit of direction can be helpful, offering both creativity and predictability. “Start with what you are trying to build and what the customer needs. What problem are you trying to solve, and what are the limitations? For example: It needs to do this, it needs to not have a charger, it needs to be battery powered, and on and so forth. It’s simple stuff. From there, I let my engineers frolic in the open terrain.”
The brainstorming is helpful, because even bad ideas spark good ideas. Brainstorming helps narrow down a vision for the product, which leads to establishing requirements. You can then start validating those requirements. Is it important that the item is battery powered? Does it need to be waterproof?
“In the innovation space, none of the requirements are ever going to be known until you test them. So it needs to be a living document, and it needs to be a living set of constraints that you put on the system as you learn more,” Evcimen said. “Keeping it too wide loses focus, but keeping it too narrow means you build the wrong product. Understanding market trends and user input and tech should humble you: It’s OK to know that your requirements won’t be perfect.”
Starting development without verifying assumptions
Sometimes a project gains inertia and starts to develop in a particular direction without anyone pausing to think about why.
“I’ve seen this happen a lot as well, where people — whether they are engineers or biz/dev — hear something, and they start to take it as a source of truth and run with it without asking the question why. I encourage people to always start with their why: Always ask why and validate it. Test it if it’s necessary. Even if it seems obvious, perhaps especially if it seems obvious — that’s where a lot of pitfalls happen,” Evcimen said. “I think this is an engineering ego thing, where people assume they are asking a stupid question, or that it is stupid to ask if it’s already validated. But, no, it’s never a stupid question. It should always be asked.”
Sometimes, problems can be deeply embarrassing. I’ve been part of a design process where everybody was designing a consumer electronics piece in CAD and assumed that all components were two-dimensional. That makes sense from a schematic point of view, but it turns out in the real world, components have a z-axis. In this case, the electronics designers had chosen a component that was 24 mm tall, while the plastics designers had left 22 mm of space for components. Only when the prototype of the PCB arrived and was fitted into the 3D-printed case did the problem become apparent.
The result was a very expensive redesign process. We had to decide whether to choose components with a different physical shape (which had different signal pathway characteristics and would have triggered a full redesign of the electronics) or redesign the casing, which had a number of other knock-on effects.
Evcimen told me a a similar story:
“I was working in a team that was designing a really complex, large system. I asked the question ‘Hey, do we know our maximum build space?’ There was a lot of riding on this system, and it was designed to nest inside another system,” she said. “I realized they were tweaking it a lot, and I was wondering if there was a max of how large it could be. The reply I was given was that ‘this is the most important system; everything else will grow around it. Without it, nothing will work.”
That’s a pretty bold assumption, and she knew not to take it at face value. “I went to the top and explained I was on the design team and that I had gotten a cryptic response to my question. It turned out that, yes, this was the most important system, but there would be limits that hadn’t been communicated. The company ended up spinning up a whole systems engineering group to avoid this in the future. If I hadn’t asked my question, I bet that those assumptions would have continued for months, and they would have grown to each other system interfaces.”
For example, you might argue that the battery pack on an EV is the most important system. Maybe it is, but that doesn’t necessarily mean it gets to be infinite in size, weight and cost: It still has to fit into a physical compartment in the car; it can’t be heavier than the suspension systems are rated for; and if it costs 3x more than planned, it could make the car not viable at all.
“It is much easier to constrain these things at first, so you avoid having dependencies. If you define that the space can be three, and it turns out to be 30, can you figure it out? Yes, it may cause some headaches and a timeline shift, but the later in the process you make these changes, the harder it gets,” Evcimen said.
Failing to have development-driven budgets
Hardware development is expensive, but the ways it is expensive can be surprising, even to very experienced product manufacturing organizations. Often, when you are building up a supply chain and designing a product around that supply chain, you’ll end up with vastly higher costs than expected.
“Oftentimes it takes at least two to three times longer than you anticipated — and that is not even a conservative estimate. It’s usually four to five times more expensive, sometimes even 10 times more expensive. There are a lot of sneaky reasons for this. The current logistics problems in the world become a huge money sink. They won’t get the design right the first time, a lot of change orders will happen, you’ll get too low a yield, and so forth,” Evcimen said. “Sometimes, people think adding a 20% margin is OK. But that is rarely the case: When there are failures, and redesigns and production delays and quality concerns, it all accumulates to way more than that in the physical world. Proper contingency planning is important.”
Avoiding this boils down to doing your due diligence and talking to other founders and their experiences. Founders usually keep their cards close to their chest in public forums, but if you have connections, you can use them to get a glimpse of what other product companies have experienced.
Not working with the right contract manufacturers
Working with contract manufacturers is a huge challenge with enormous risks throughout. The problem is that fledgling startups rarely have enough leverage. Look at the huge graveyard of failed Kickstarter projects; of course, they fail for many reasons, but picking the wrong manufacturers is often close to the top of the list.
How Fictiv is making hardware manufacturing more like building software
“Startups are in a low-leverage position that causes failed negotiations, high cost per part and unnecessarily difficult management overhead. This is usually caused by a lot of people building products not quite within their domain, and so vendors tend to have higher leverage in this situation, because they see you as a risky investment,” Evcimen said. “They also have the experience card that they can continuously pull out and say, ‘Oh, you don’t know what you’re getting into. This is going to cost blah, blah, blah,’ and all that stuff. They’re pretty ruthless. There are some really amazing contract manufacturers that are very customer-centric, but they are really hard to come by. If you’re trying to move quick, trying to find the perfect fit is just not going to be feasible. So you got to work with what you have.”
One way to mitigate risk is to go down the manufacturing route with a spare manufacturer in your back pocket. Another avenue would be to have some in-house manufacturing capabilities.
“When you decide to outsource, dual production is really important to keep the leverage and to keep your suppliers humble. It also helps you understand if a quality problem or a failure is due to your design or production problem. It could be your design, of course, but might just be that the supplier is no good. And then doing in-house production trials to have data and due diligence on your own product is helpful. Then, when they pull out the experience card, you can pull out the ‘we have data on this, we’ve built this before and we know what we’re doing’ card,” Evcimen said. “Making sure that you have a variety of a supply chains and have redundancy is super important, even though it might not seem [so] at first.”
Comment