It's been hard to miss the recent AI engineering demos - describe a part or a change, and a model, drawing or analysis starts to appear. Having worked across software and hardware, I find the possibilities pretty incredible, but they also make me think about the people being asked to change how they work.

The ambitions extend well beyond generating a shape. Bananaz's recent announcement describes agents editing native CAD features, generating engineering documentation and carrying work through existing PDM approvals. It also describes engineers becoming system architects. Brainchild presents editable CAD alongside simulation, drawings and sourcing. These are the vendors' descriptions and I haven't independently tested either platform, but clearly a change is coming.

When AI Takes on CAD What Happens to the Engineers?

When most people think about a Bill of Materials, they picture a structured list of parts: part numbers, descriptions, quantities, suppliers and maybe some costs. That definition is still true, but it‘s no longer enough.

For startups and small hardware teams, the BOM is increasingly becoming something much more important. It is the place where design maturity, sourcing confidence, cost visibility and manufacturing readiness all start to come together.

The Startup BOM - A Product Readiness System

A few years back I sat in a room with the team conducting a lessons-learnt session where our mechanical team lead was describing a familiar and expensive problem: file naming and version conventions for our CAD system. At the time we were using vanilla Solidworks and managing our files in Dropbox. This is typical of what many small hardware teams do today. Every model file and drawing file we were using had the current revision hard-baked into the filename, except that in some cases they didn’t or they were wrong. In addition to that, we had identified that our design BOM, which was being managed in a separate spreadsheet, had some revisions that were no longer matching the CAD assembly. This was likely due to one or more manual updates that may not have been correct or complete. This was not because the team wasn’t on the same page, but just because in the hectic daily activity of a fast moving project something got missed.

This kind of failure happens more often than we’d like and anyone who has build physical hardware typically has a story like the one above. It’s usually because product data gets treated like files, folders and spreadsheet entries instead of first-class, connected, addressable entities. It was not long after our revision chaos experience that Onshape’s cloud-native CAD + PDM approach came to market and changed that architecture and the day-to-day reality for the teams that adopted it. Onshape’s most recent white paper - the 2024 State of Product Development - documented the tangible improvements in collaboration, recoverability and reduced time lost to file management due to the cloud-native PDM aspect. These benefits can be huge if you’re designing complex electro-mechanical hardware, but are still largely unrealised by many hardware teams.

How Cloud-Native PDM Solved Version Chaos and What’s Next

As per usual we were running against the clock trying to solve a key technical issue with our Alpha prototype. The team had already iterated through a number of concept variants for the subsystem in question and were confident based on the latest 3D printed parts that this was the final design to go with to solve the issue and meet our Alpha delivery timeline. We had now just got a “parts only” mold tool insert made for one of the parts (”parts only” was a low cost method of getting simpler injection molded parts made in low volumes) and were reviewing the 1st off tool samples. My mechanical lead was initially excited when the parts arrived, but as he inspected them his face turned ashen as he realised that these were not the latest revision of the part design. Somewhere along the line there had been a miscommunication in the details and the tooling supplier had used the previous revision of the part design to make the tool insert. We had also missed the differences in the tooling design because we’d assumed we’d sent the correct part revisions. We were now looking at a 6 week delay to rectify the issue and would now miss our Alpha launch date.

Many hardware teams, particularly startups and smaller design teams, often initiate the management of critical product data—including parts, Bill of Materials (BOMs), drawings, models, quotes, and purchase orders—using readily available tools like spreadsheets or scattered local storage. We were no different in this case and for teams like ours this approach seemed convenient and cost-effective at first glance. But as many teams have found, it quickly escalates into a "manual nightmare" as product complexity grows and design changes become more frequent and challenging to manage. Relying on such rudimentary systems can introduce a cascade of costly errors throughout the entire product lifecycle, acting as a barrier to growth and agility. We were experiencing the fallout of this first-hand.

The Dangers of Disconnected Product Data

When you’re building hardware at speed within a startup or a small focused team, clarity is a competitive advantage. Yet for many teams, product data quickly becomes scattered across multiple tools and files: CAD files on the desktop or somewhere in Google Drive, BOMs in spreadsheets, test results in personal folders, sourcing notes in email threads. The result isn’t just mild frustration—it’s hours lost, progress slowed and critical errors caught too late before an expensive prototype build has already started.

This is where the idea of a Single Source of Truth (SSoT) comes in. At its core, it means one authoritative, living system that connects your design, sourcing, and production data. Everyone works from the same version, with the same context, in real time.

Your Hardware Team needs a Single Source of Truth

Despite the advances in prototyping techniques and design software, getting a product from concept to customer has never been more challenging. Products tend to be more complex these days because consumers expect more and hence new product development (NPD) demands flexibility and innovation while delivering faster. However, the traditional practice of Product Lifecycle Management (PLM) has not kept up. PLM systems were built for rigorous change management and configuration control, ensuring compliance and traceability. But for teams focused on prototyping and rapid iterations, these processes create unnecessary bottlenecks.

The truth is, while PLM has its strengths, especially in industries like aerospace and medical devices where precision and compliance are paramount, it needs to adapt to other industries that demand more flexibility and quicker product cycles. Startups and small design teams, in particular, often find that they’re left between a rock and a hard place - using simple spreadsheets for NPD results in mistakes and quality errors, but moving to any of the current PLM solutions is not only costly, but puts a straight jacket on speed and flexibility. Here’s how we can simplify PLM to enable agility in product development without compromising on quality or losing sight of key objectives.

The Secret to Simple PLM for New Product Development

Almost everyone who has been involved in product development has felt the squeeze of getting a product to market on time and may have been pressured into cutting corners or releasing product that was half-baked or not sufficiently tested. Many of us have learnt the hard way that all of the small problems with the product that we were persuaded fix “later” end up coming back to bite us later. This pain is particularly acute when developing physical products as it is difficult and time consuming to resolve defects and rework existing product once it has been realized.

My own experience here has led to a general rule of thumb that the cost and delay to fix any defect during the design phase is typically magnified by 5-10x once the design is tranferred to manufacture and if the defect actually surfaces once in the customer’s hands then you can often double that again in terms of reputational damage to the company. Note that others will have their own multiplier here for different products and industries, but everyone will have their scars from the experience!

How to Fix your Hardware Product Maturity Problem (Part 1)

I was once asked to re-introduce a medical instrument to manufacturing. This was not a standard request, but rather a unique one. The product was manufactured for about 10 years before production came to a halt. Tools were destroyed, test equipment dismantled, and the manufacturing line shut down. Some years later, we have been asked to produce additional units. I thought to myself, what could go wrong, considering this was already a manufacturable design ? Well, lots did go wrong.

Traditional product development approaches call for a technology maturation process, starting from research and concept development, through prototyping and refinement, to finally implementing design for manufacturing (DFM) considerations before launch. In many cases the last mile of transfer to manufacturing is taking longer due to difficulties with updating design considerations late in the game. This post is about my journey, the lessons learnt, and is proposing an alternative streamlined approach for introducing a new product to manufacturing.

Streamline your Transfer to Manufacturing for Faster Delivery

In Part 1 of this blog post, we explored several common frameworks used to manage product maturity in hardware development, including TRLs, DTLs, and Bolt’s process. While these systems offer valuable approaches, we also highlighted three key shortcomings that can lead teams astray:

In this post, we’ll dive into how to address these shortcomings and create a more effective maturity tracking process. Plus, I’ll share a real-world success story demonstrating how these improvements can transform a project.

How to Fix your Hardware Product Maturity Problem (Part 2)

One of my biggest satisfactions during the days I worked as a software developer was the ability to execute and test my software on the spot. I was keen to quickly get a piece of hardware and demonstrate solutions to my clients, which has always provided great value and learning about the customer needs and assisted with refining our products. Years later, Agile methodologies came about and mastered the method for rapid and iterative software delivery. The agility of software development is inherent within the nature of its abstraction and has served me well with putting a solution in front of end users, learning the usability, and feasibility of the application, what works and what doesn’t work, and, more importantly, allowing to quickly addressing any end users concern with the flick of few keyboard strokes.

Fast forward, I have now been managing cross-discipline product development projects for over a decade and only starting to see the manifestation of software methods on the improvements of mechanical and electronics design to accelerate product realisations (software tools like Onshape or OpenBOM, for example). Yet as it appears, none of these seem to have effectively implemented the agile methodology into the mindset of hardware developers, and while they do solve design challenges and pose some evolution for the industry, they do not bring to life what software development methodologies have been delivering on for more than 20 years.

Accelerating Hardware Product Delivery

For start-ups and even established product development companies it can be struggle to handle risk well even though it is often critical for success. For small companies with limited resources, it is common to see an attempt at proactive risk management in the early stages of development that inevitably ends up in a loop of reactively responding to risks once they have already become issues. Fortunately, there is a better way and some companies have discovered that integrating a risk culture into their daily activities allows them to significantly increase their chances of success.

At my previous company I once asked the manufacturing team how they were progressing with their process risk management activities. They told me that things were in hand and proceeded to send me a spreadsheet containing their risk list on a standard process FMEA (PFMEA) template. It has been diligently filled out and to an untrained eye it looked like everything was under control. However, on closer inspection it was clear that this PFMEA was not what it appeared to be. There was only a summary pass of possible failure modes (only the high-level process steps had been considered), there were no links from the process steps to their impacts on critical design features and only some items actually had actions (which had not been addressed). The most telling aspect, however, was the “last updated” date on the spreadsheet indicating that had not been updated for 4 months. It was typical of many company’s approaches to risk management — fill out a spreadsheet, save it to a folder somewhere and then forget about it until at some later point when the risks come to fruition. It seemed that our manufacturing team had made this classic mistake and I now realized why we were seeing unexplained failures of our pilot product in the field.

How to Build a Risk Focused Culture (Part 1)

In this second part of this post on building a risk focused culture we’ll have a look at how knowledge-first development can be incorporated into a lean planning methodology tuned to start-up development and natural risk management. Following that we will see how some other changes can then build a sustained culture of risk management in the company. Make sure to check out Part 1 of this post if you need a refresher.

One key aspect of dealing with risks that often not given enough consideration is the concept of proximity. Risk proximity simply means how close we are, in terms of time, to a risk occurring. Proximity is used to ensure that focus on risks is balanced with a greater emphasis on those risks that are likely to occur in the short term. Proximity can be used hand-in-hand with prioritization to augment any risk management approach. One effective way to do this is by using a planning technique called rolling wave planning.

How to Build a Risk Focused Culture (Part 2)

Six years ago as a newly minted CTO of an agtech startup, I had a great opportunity. Not only was I developing potentially world changing breakthrough technology, but I had a blank canvas in terms of how to go about it. There were minimal constraints (besides cash-flow of course!) in terms of approach or ways of doing things that might shackle the team or send them down rabbit holes. As a key decision maker in a young startup, it was a great time to re-invent ways of delivering value!

Head to Accelygen.com for more great product development insights and solutions.

How Cloud CAD Saved our Startup

This article is a follow on from my recent article How Cloud CAD rescued our Startup where I shared a story from my most recent startup about our journey into the world of cloud-based CAD. As an agtech startup that was re-inventing the way that cattle were fenced and grazed, it was a natural extension to also embrace a re-invention of hardware design using cloud-based CAD. No doubt many other hardware-based startups have also taken this path and, in many ways, there was probably no other viable choice unless outsourcing was considered.

Head to Accelygen.com for more great product development insights and solutions.

Solving Hardware Product Realisation

Over the last decade there has been an exponential increase in the use of software to solve key customer and societal challenges. This has been driven by the burgeoning startup ecosystem in Silicon Valley, Israel and other hotspots where VC money has poured into startups and scale-ups, creating a rapid evolution of product development techniques throughout the lifecycle of these companies. We’ve seen huge leaps forward in cloud and mobile technologies, bringing products to market faster and with higher quality and better user experiences than ever before and there is now a proliferation of apps and SaaS platforms solving every imaginable problem within B2C and B2B market verticals.

Along with these advances in technologies and tool stacks and Agile, DevOps and CI/CD methodologies, there’s also be a huge transformation in the way products are conceived and value propositions created. This has been characterised by the rise of the Software Product Manager (PM) and the establishment of Product Management as a craft in its own right and completely distinct from the historic Project Management roles that were common prior to Agile. The role of the software PM has been instrumental in creating the SaaS and mobile app revolution we’re in the midst of today.

What Happened to Hardware Product Management?

The continued evolution of consumer needs and expectations pushes companies to innovate and deliver products that not only meet but exceed these demands. To achieve this, many organizations have turned to design thinking as a framework for developing successful hardware solutions. Understanding design thinking and its intersection with hardware development is crucial for creating products that resonate with users. This article explores the principles of design thinking, its importance in fostering innovation, and its impact on the hardware development process. Additionally, it discusses case studies, implementation challenges, and future trends in applying design thinking to hardware development.

Design thinking is a problem-solving approach that emphasizes empathy, collaboration, experimentation, and iteration. It originated in the world of design but has since been embraced by various industries, including hardware development. At its core, design thinking focuses on understanding and addressing the needs of users to create meaningful and impactful solutions. By adopting a human-centered approach, hardware developers can gain valuable insights into user behaviors, preferences, and pain points.

Using Design Thinking for Hardware Development

In today's fast-paced world of hardware startups, the use of Excel for development is common practice. However, it's time for entrepreneurs to reconsider this approach and explore more efficient alternatives. In this article, we will delve into the limitations of Excel for hardware development, its impact on productivity and growth, and the benefits of switching to dedicated software. We'll also provide real-world case studies to illustrate the successful transition from Excel. So, let's dive in and discover why hardware startups should stop using Excel for development.

Before we delve into the reasons for moving away from Excel, let's understand why it became a staple in the hardware development process. Traditionally, Excel has been used as a go-to tool for managing data, creating spreadsheets, and performing calculations. Its familiarity and ease of use have made it an attractive choice for startups, even in the hardware industry.

Why Hardware Startups Should Stop using Excel for Development

The world of hardware product development is constantly evolving, with innovation and speed to market being at the forefront of success. In this rapidly changing landscape, traditional methods of design and development often fall short of meeting the demands for creativity and agility. This is where rapid prototyping steps in as a transformative approach that redefines the way hardware products are conceptualized, designed, and brought to life. In this article, we will delve deep into the concept of rapid prototyping, its unparalleled benefits, and a comprehensive guide on how to leverage its power to create truly innovative hardware products that captivate the market.

Rapid prototyping is a paradigm shift in product development. It involves creating physical prototypes of a product using advanced technologies and methodologies, with the primary goal of validating concepts, refining designs, and fast-tracking the development process. The speed and agility that rapid prototyping brings to the table are nothing short of revolutionary, offering a plethora of advantages that traditional development methods struggle to match:

Unleash the Potential of Rapid Prototyping to Create Innovative Hardware Products

In the world of hardware product development, one crucial aspect that often gets overlooked is the bill of materials (BOM). While it may seem like just another document or spreadsheet, the BOM holds immense significance in the success of a hardware product. In this article, we will explore the fundamentals of a BOM, its role in product development, the benefits it offers, and some real-world examples of its usage. We will also delve into best practices for creating and managing a BOM to ensure seamless development and production processes.

Before we dive into the importance of a BOM, let's first establish what it actually is. In its simplest form, a BOM is a comprehensive list of all the components and materials required to build a hardware product. It outlines the exact specifications, quantities, and dependencies of each item, ensuring that nothing is overlooked during the production process.

Why is a Bill of Materials Important for Hardware Product Development?

In today's fast-paced and constantly evolving tech industry, agility has become a crucial factor for success in hardware development. Being able to adapt quickly to changing market demands and customer needs is essential for staying competitive and delivering high-quality products. In this article, we will delve into the concept of agility in the context of hardware development, explore the challenges faced in implementing agility, examine different agile methodologies suitable for hardware development, present case studies of successful and failed agile implementations, and discuss the tools and technologies supporting agile hardware development.

Before we dive deep into the world of agile hardware development, it's important to have a clear understanding of what agility means in this context. In a nutshell, agility in hardware development refers to the ability to quickly respond to changes and uncertainties throughout the development process. It involves fostering a collaborative and adaptive culture where cross-functional teams work together to deliver value to the customer.

Achieving Agility in Hardware Development

Introducing a new product into manufacturing can be a career defining moment. You may have spent months or even years getting to this point and now everything is on the line. Does your product meet its key performance requirements? Do you have a high level of confidence that it will actually deliver the expected value to customers? Is there a willingness to pay? As a designer, project manager and/or product manager, you’ve no doubt you’ve been focusing on ensuring positive answers to these questions. However, as you ramp up for transfer to manufacture, a whole heap of new questions are suddenly being asked - is the product manufacturable? Where will we source the components from at volume? Can we even make it at the target cost? If you don’t have confident responses to these questions, then it’s usually because you neglected a critically important aspect of the development - bill of materials (BOM) management!

Head to Accelygen.com for more great product development insights and solutions.

Agile Strategies for Bill of Materials (BOM) Management

One of the key challenges encountered in hardware product development that can completely derail your progress are loopbacks. Loopbacks occur when the development team make some kind of error in implementation that, once realised, requires a non-trivial amount of effort to rectify. Loopbacks can occur in software and hardware development, but in hardware they can be far more significant and costly in terms of delayed market entry or additional effort. The worst loopbacks occur when there are long development loops resulting in seemingly mature prototypes, MVPs or products that turn out not to be fit-for-purpose.

Head to Accelygen.com for more great product development insights and solutions

Find Flow and Avoid Hardware Development Loopbacks

A couple of years back my team were working on some breakthrough technology in the life-science space using a novel method of fluorescent detection. We had developed a mature and fully functional Beta prototype for the client and delivered 25 units to them for testing and evaluation. We’d solved many issues along the way and build a pretty solid product that we were confident would meet all their requirements. Acceptance testing with their team had gone well, but a couple of months later they came back to us with a problem. They had started evaluation with a number of early customers and despite generally positive feedback, there was one major shortcoming that kept coming up - the sensitivity of detection wasn’t good enough for what these customers wanted to do. This was something completely new for us as we had met all requirements around sensitivity, but apparently the requirements were wrong!

Our client had completed additional studies and concluded that the design needed to be substantially changed if they were to get enough customers using the product. This led to a whole new project for us to work through the change with our client, which on the surface may sound great. However, for our client it was a major setback to their progress. It also ended up being a project with substantial new complexity due to the need to retrofit multiple critical components within an existing design. The project ended up costing both us and the client more than USD 2M to resolve without even considering the cost of delay in getting to market.

Accelygen

When AI Takes on CAD What Happens to the Engineers?

Insights

Accelerate your learning

Search Posts

Latest Posts