I think everyone generally agrees: Hardware (Hardtech) is hard to do well. I've been doing a lot of consulting around this topic and I want to start pivoting some of these learnings towards more systemic change that is shared with a wider group than just my individual connections.
So I thought I would start by compiling a list of at least a few of the reasons why this stuff is actually hard. Decomposing the problem is the first step toward solutions (what I actually care about).
Problems
Note: These are in no particular order. Thanks to those of you that contributed to this list either on social media or privately.
Managing the weight/cost/power budget of the design - Generally, during the detailed design process, something is known about the target weight and cost. It becomes important the track these quantities as the detailed design progresses to prevent big “gotcha” moments during integration or design reviews
A lack of credible information on actual engineering timelines and complexities for hardware (not consumer) products developed by companies. This often means funders and founders don't have the right info going into fundraising conversations and set up organizations and teams for failure from the beginning phases of projects
Not Enough Testing - Not enough people know what tests should be run. Not enough tests are usually run. Not enough time is usually allocated for testing. That’s it. That’s the bullet.
Supply chain planning - The global supply chain for everything is a mess right now, but even before the past few years, this has always been hard. Planning the supply chain can either make or break a product and product launch. Answering the following bucket of questions and then successfully negotiating the answers with different vendors is non-trivial: “Where do we buy parts? How many? How long will it take? Will all the parts be the same? Do we need to test the parts? Are we getting the best price?”
A lack of understanding of the massive gap between a functional prototype and a real product. A benchtop demonstration can be extremely compelling, but at this point, only 10-20% of the actual work has been done. It is incredibly hard, especially in a startup environment, to keep the whole org on board with the amount of testing that needs to be done. And incredibly hard to hold back salespeople who are chomping at the bit to ship product.
Misunderstanding of risk- How much is there, and what are its impacts (probabilities)? Risk has many different definitions: technical (can we do this?), safety (is it safe to do this?), schedule (when can we do this?), and cost (how much will it cost to do this?). Getting everyone to agree on definitions, stances on how much risk a product is taking on currently, and a plan to reduce risk over time is quite tricky.
Inertia/personnel paralysis Teams often get stuck trying to plan out what should be done. This can be due to both over-constrained (too many constraints), and over-scoped (trying to accomplish too many things with one widget) requirements.
Haphazard Product Launch - Perhaps even harder than building the product is actually supporting a successful launch to real users/customers. The list of things that must be planned and executed seems endless and it’s easy to neglect some of these things once the thing is “done”.
How to do system-level engineering -Should there be systems engineering? Should they be independent groups or part of component teams? Should requirements be developed and flown down before design starts? All of these are hard questions and there are seemingly few answers that people agree to work in published literature or case studies.
Design Process - When do design reviews happen, what do they look like, and what is their intended goal is tough to do in a lean, but effective way. It’s easy to drown a team in paperwork, without actually accomplishing your goal.
Setting key performance indicators (cost, mass, etc) for subsystems but also encouraging them to be beaten if possible (encouraging the team not to stop right at the threshold if there is more to be gained).
How to make decisions and structure responsibility/accountability - This problem isn’t really unique to hardtech, but it becomes much more important in hardtech than in other fields possibly. Tons of trivial or large decisions impact the work of different people due to the physical relation of items on the product (should this button move to the left 2 mm impacting both the electrical design, mechanical enclosure, supply chain, etc). Setting up clear decision structures and processes for making choices like this is key or your team will end up with everyone on every choice very quickly, leading to project paralysis.
So that’s the list! What do you think? Am I missing something? Leave me a comment or shoot me a message if so.