8 Must-Follow Tips for Software Companies Developing a New Hardware Product

Software companies are often used to using an agile design approach (often SCRUM) to design and develop software products, and they wonder if they can carry over the approach to when they need to develop a new hardware product to support their business goals, for instance, it may be an electronic device that runs their software such as a payment terminal or something similar.

Let’s explore if the agile design approach is helpful for software companies who’re developing new hardware products for the first time here. We draw upon the excellent book ‘SCRUM for hardware design’ by Prof. David G. Ullman and its illustration of the difference between hardware and software design, and share 8 tips for hardware design specially tailored to software companies…

Prefer listening to reading?

Listen to the audio here.

What’s the difference between traditional project management and the agile approach?

Traditional project management approaches like a city would use when planning, say, a new bridge focuses on tasks, timelines, resources, budget, etc. Software development tends to use a more agile approach or methodology with a set timeframe working on individual customer needs each time rather than having one grand plan from the start which gives very different results and is unlikely to go over budget and time like the traditional approach. (01:56)

Why is the agile design approach so popular with software companies?

When developing software it’s important to get feedback on how users will react to each function during the overall development, and users are given each feature to test and provide feedback on rather than the software as a whole. The feedback is then incorporated into changes in the developing software where required and helps to avoid the situation where users are provided with finished software to test where they may find features that they don’t need or like that much. One drawback is that in this fluid agile approach, documentation can be lacking in comparison to the traditional project management approach where everything is planned in advance. (08:18)

13 points about why hardware design is different from software design from the book ‘SCRUM for hardware design’ by David G. Ullman.

Applying the agile SCRUM methodology to hardware design isn’t easy, but it’s possible. In his book, David Ullman describes 13 key points where designing new hardware differs from software:

Less evident modularity: In hardware, this needs to be designed into it.
Longer design cycles: These are far longer in hardware and can be 6 or even 10 months.
Higher functional interdependence: Form, fit, and function need to work together in hardware in order to be able to test the product, whereas software modules can be independently functional before the whole is complete.
Poor refactoring opportunities: Lines of code can be rewritten repeatedly quite easily, but making changes to hardware once designed is very costly and time-consuming.
Higher need for specialization: Software coding can be done by a team of differing skill levels, but in hardware, you’ll need specialized design engineers with deep expertise in the design of a specific function, etc, and can’t divide it between them and, say, a new graduate.
Longer time to demonstrate function: Prototyping for hardware takes longer, whereas prototype software needs to be written and then can be tested (even if it’s a rough version). The process for hardware is a lot more involved, requiring planning, CAD drawings, sourcing parts, arranging tooling, and more.
Higher cost of change: The cost of making changes to hardware design is far more than a couple of hours of a software engineer’s time to adjust some code, for example. For the hardware, it may require new components to be purchased, a PCB redesign, etc, which is costly in time and funds.
More demanding range of operation: Hardware design takes longer, has more activities for the engineers, and requires more resources than to get to the same point with software.
Different testing demands: Software testing needs a server or computer to run the software repeatedly until a failure occurs and someone to test it, which is not as complex as hardware testing which needs expensive equipment and a team of well-trained staff in a testing laboratory in order to obtain valid test results.
More secondary design activities: The hardware design cycle includes a lot of processes that you can’t skip and that must be done in a certain order and must be panned for and worked on sequentially. Otherwise, skipping ahead to manufacturing too early will result in numerous quality and reliability problems with the finished products.
More challenges in developing specifications: Hardware requires very clear specifications including technologies, systems, and specifications that all need to be translated into agile ‘stories’ which is not easy.
Higher difficulty proving a task is done: It’s easier to get to an endpoint with software design than with hardware. Hardware engineers can always find something new to adjust even in finished products, whereas once the software is launched to users it can often be considered to be done with fewer changes needed.
Higher price of premature commitment: The agile design approach encourages a build, measure, and learn philosophy for software, but this can be costly with hardware as committing to physical hardware too early can lead to costly changes being required later on. (11:07)

8 points that companies that are used to running agile design for software development tend to overlook when developing new hardware products.

Companies that are used to developing software in an agile way tend to run into trouble when developing hardware for these reasons:

1. Agile is good, but planning and documentation can’t be skipped.

These companies try to spend less time on planning and documenting specific requirements for software, but this approach isn’t so compatible with a new hardware product’s V1.0. You need to start off with a clear list of functions in a user manual, a list of requirements, knowing where it will be sold, its market compliance requirements, the importance of reliability and durability, etc. Without this information, the purchasing and design teams will make mistakes such as selecting a module that isn’t pre-certified (such as needing to be food safe) and therefore leads to a non-compliant product. Compliance testing can be very expensive, so minimizing the need for it is important for a company’s budget. Redeveloping a product due to mistakes like this might also require tooling to be fabricated or altered which is also very expensive. (23:39)

2. You need to freeze the product design (including freezing the firmware) at one point.

Once you’ve got a final prototype that looks and functions as needed, you freeze the design and start testing and validating it. Software companies are well-known for tinkering with the software once the design is completed, but in hardware this is counter-productive and some new ideas and tweaks should be tabled and planned for the next version of the product, otherwise you will never get the new product shipped out in time. Agile ideas can be incorporated to improve the hardware design process, but a project manager still needs to draw a line in the sand somewhere in order to make progress. (31:35)

3. An engineering change management process must be taken seriously from a certain point.

When you’re working with your contract manufacturer, components suppliers, etc, you need to keep on top of what happens and have an approval process so that unauthorized changes don’t occur which could have a huge impact on the product (such as a different component that doesn’t have the required capacity being used which could lead to reliability problems). Change management might require a responsible person to take charge of it and may even utilize software in the case of large projects. (33:48)

4. You need supply chain visibility and to manage it yourself.

When developing software you don’t need to manage different components and their suppliers, but now you need to get used to managing a supply chain for your hardware. If you end up working with a trading company or manufacturer that won’t give you visibility into the supply chain that will be problematic and might result in you needing to switch t a new manufacturer who is reliable and transparent which is costly in time and money. You should plan to find good-fit suppliers with a visible supply chain for your critical components (PCB, display, battery, etc) at least and have a proper manufacturing contract to manage them and assure that they uphold their end of the bargain. All it takes is not being able to obtain a key component and this badly affects your project, so you need to know who supplies them and to even double-source from alternative manufacturers if a supply of them is critical. (35:46)

5. You will need a quality function.

Software testing is like QC, it will find issues. It can also be preventive as fixed issues won’t occur in future. But when manufacturing hardware you’ll need to do risk analysis, supplier validation of critical components, engineering management process, following up on issues and getting to their root causes, etc. The quality team have a lot of work to do. You should specify your quality requirements and clarify your expectations such as the color variation you can and cannot accept. As your team grows, think about hiring a staff member whose job is to focus solely on quality (and maybe compliance, too). (39:15)

6. BOM, drawings, schematics, etc. are all as important as software code.

When manufacturing hardware the BOM, CAD drawings and other design files, schematics of the PCB, etc, are just as important as the software source code. If someone makes a mistake and uses the wrong drawings or selects a component that is not on the BOM this could have disastrous consequences which shows how important these documents are, and it takes a seasoned project manager to catch these issues. The stakes are higher and timelines are more critical than with software and you need to be very deliberate when taking actions because you can’t make small tweaks repeatedly with hardware as in software. (42:21)

7. Product reliability is important, especially if they have a “product as a service” business model.

Software companies often use the SaaS model, and this continues when they add a hardware element to their product offering. Subscribers won’t stick around if the hardware is unreliable or sending replacements could become costly, so designing a reliable product that lasts for years really supports the SaaS model and your mid to long-term profitability as customers will maintain their subscriptions. So product reliability is actually even more important for many software companies who’re making hardware now due to their business model. The importance of reliability can’t be underestimated, because reliability issues can even cause safety risks for customers that can be very damaging financially and reputationally. (47:55)

8. Product compliance is an entire topic to take seriously.

You need to know which standards and regulations the product must comply with and plan ahead because it will impact a lot: your supplier choice, the components you choose, whether they should be pre-certified or not, how they are qualified, if the product should be designed with best practices in mind regarding making it compliant, etc. You don’t want to end up putting the product through expensive compliance testing only for it to fail and set your project back a lot of money and time. (52:46)

Don't miss a post