The technology industry has gotten incredibly good at building software that helps other people build software. There are countless coding Copilots, data logging and observability tools, and debugging programs that are multi-billion dollar companies in their own right. However, a glaring disparity exists when we look at the hardware development ecosystem. Why hasn’t hardware development experienced a similar revolution in supportive software?
A lazy explanation might be that the people building the tools (software engineers) are simply solving problems that they know implicitly through their roles. A more nuanced explanation might be that companies who built software have more fungible processes and organizational structures that can accommodate new software tools requiring a reconfiguring of workflows and team structures. Both of these points illustrate why supporting software tooling for companies who build physical products has been so lacking until recently.
At Northzone, we believe that hardware engineering in 10 – 15 years will look a lot like software engineering today: highly iterative, collaborative, and customizable. The buzz around transformer model’s capabilities presents an attractive GTM moment for an industry that has historically been tough to crack. The end-state result of this will be that hardware development cycles will accelerate, and we’ll see more specialized hardware tools, in the same way that we have an abundant supply of niche software offerings today. Supply chains and CapEx requirements will continue to be bottlenecks, but streamlining the design, testing, and manufacturing of hardware will nonetheless drive new velocity into the category.
But realizing this future requires a new batch of supportive software tools and painful organizational changes to match. After speaking with many potential customers within the industry, we have identified a few key characteristics that will define the next great software tools in the hardware industry. The next generation of companies in this space will be:
Let’s dive in and explore each component.
Hardware development workflow data is multimodal by nature. Key artifacts might be stored in a time management system, a CCTV feed, or a JIRA ticket. Tying together each of these pieces of data to create a coherent story of what is happening within a company is the first (and arguably hardest) step to helping create more efficient development, testing, and manufacturing processes. Yet this is challenging because teams that work on hardware development often work in silos. The design engineering team will work in JIRA + their CAD only to hand off their work to the simulation engineering team who will work in Smartsheets + their CAE. Meanwhile, there is a program manager who is trying to track all of their progress in JIRA or Excel. We are looking for teams that have a thoughtful approach to how to build a modular data architecture that can integrate these pieces of data to (1) assign them relevant context and then (2) eventually run models that can suggest actionable workflows.
A key element of this, specific to hardware, has to do with integrating IoT devices. As more of the physical world comes online via IoT functionality, modern “software for hardware” solutions will leverage this sensor data natively. Let’s imagine they are a testing process management tool. Instead of simply creating a testing plan, a sensor-native offering might automatically update the log to show every time a container fell below X value in pressure, temperature, or whatever variables the testing plan seeks to measure.
One of the most common refrains of executives is that they just wish they could speed up the transfer of knowledge between senior engineers who are about to retire and the new engineers entering the company. If they could have anything, it would be Stack Overflow tailored to their company. Each problem a junior engineer encounters has probably been solved in some shape or way before. Because of the poor tooling that has been built for the industry, this data largely stays trapped across engineer’s brains and scattered PDFs. We are excited about companies that can make this knowledge accessible, especially as more and more senior engineers retire in the coming years. The NLP-summarization use cases of transformer models will be well applied in this theme.
Source: https://info.augury.com/The-State-of-Production-Health-2024.html?utm_source=substack&utm_medium=email
To play devil’s advocate with our earlier point about integrating with as many key data sources as possible, the strategy can sometimes be a hindrance with GTM. Integration, security, and compliance complexity scales with the number of key data sources a company integrates with. While ultimately integrating with these sources will be necessary to unleash the full value of a product, we like to see companies that can show immediate value with an integration / implementation lite approach. We have found that the path to complete integration is shorter when companies can short-circuit the sales cycle with a lightweight wedge product.
The design process of an F1 car is a case study in hardware collaboration. Over 85% of a F1 car is changed over time, with over 150 models being run concurrently optimizing different parts of the car. Dozens of different teams work on each component. This level of collaboration and iteration would not be possible if each team had to request access to the source file, download the spec for their component, make their changes, request to re-upload it, and then reconcile their changes with everyone else’s. F1 has pioneered digital threading – an architecture that allows teams to access parts of a source file that are relevant to them, make changes, and seamlessly reconfigure that back into the core model. The problems F1 teams face are commonplace across the hardware engineering world, with more complicated products that incorporate components from third-party suppliers feeling this issue the most acutely. Successful companies building products for industries that require multiple stakeholders will have digital threading features that allow for seamless counterparty collaboration.
No company can (or should) try to achieve all these dimensions at once. But we also expect a lot of overlap: a company that excels at connecting multi-modal data will also be able search that data more effectively and deliver insights and action points to novice hardware engineers. A collaborative platform enabled by digital threads might also have the ability to search across all threads you’re permissioned on. There is a lot of opportunity for manufacturers to essentially “leapfrog” from outdated tools to an AI-enabled future.
If you’re building in the “software for hardware” space, we’d love to chat! @ Nick and Molly