Building complex hardware and software ecosystems that find product/market fit is a difficult task. While most hardware startups ultimately fail because they run out of money, according to a report from CB Insights, the biggest underlying reason is actually the lack of demand for their products. This only underscores the importance of how critical the product manager role is for hardware startups, as their primary goal is to figure out client needs and pain points in order to deliver a successful product.
The last company that I ran created an ecosystem of web, mobile, embedded software applications, and hardware devices for the parking industry. Hardware product strategy was part of my daily work, which led me to experiments with various hardware product development workflows. Despite working with hardware products for 10 years and having a BS in Electronics and Telecommunications, I still had a lot to learn on the job. I’ve created the guide below in the hopes that you can get up to speed on product management within the hardware with embedded software space faster than I did.
Challenges of Hardware Product Management
While SaaS and mobile apps can easily be developed using an agile framework, the unique conditions in embedded software and hardware device development make it much harder to apply agile principles. In this first section, we will cover characteristics of hardware development that create complexity. Not all of them have straightforward solutions, but there are ways to reduce the difficulty by employing particular hardware development strategies, which will be covered in the next section.
Specialized Technical Talent Is Hard to Find Locally
Creating new hardware products is significantly harder than iterating on existing ones. It involves a lot of creativity and experience in prototyping, which is rarely taught in universities. Some universities don’t even have prototyping facilities or necessary tools to develop these skills and such experience is almost exclusively gained in larger hardware corporations that have R&D centers. Finding local professionals with relevant expertise can, therefore, be very hard, resulting in a lot of hardware startup founders needing to expand their talent pool by hiring remotely.
Version-control Systems Are Not Adapted to Hardware Design
Most version-control systems (VCS) are oriented in supporting textual format, as they were created for software development collaborative work. In projects involving hardware development, information is instead wrapped up in design files created with the help of special tools like OrCAD. And some of these tools only support binary files that are not even optimized to be used in VCSs. CADLAB is a relatively new attempt at creating a hardware compatible VCS and hopefully, there will be more tools like this one in the near future.
Hardware Production Facilities Are Delocalized
Hardware production facilities are often located in another region, country, or continent. Communication between the hardware producer and the manufacturer needs special consideration and is the key to successful product delivery. Successful communication requires more strategic framing to assure the quality of the product and to ensure that it can cope with changes in the dynamic product-market validation stage. To achieve this, the hardware producer needs to create many detailed specifications sent to the manufacturer. The collaboration framework must ensure the fast-paced delivery of information and management of the specifications’ lifecycle, as they can easily get out of date quickly.
Hardware Changes Are Less Flexible
A popular operating model in software startups sacrifices quality for speed in the early stages. Even Facebook championed the mantra “move fast and break things” for quite some time. Another familiar approach is “fake it ‘till you make it.” This works for software startups because of cheap infrastructure costs and streamlined programming frameworks that allow developers to deploy code updates daily.
While this approach to development has slowly crept into the hardware space, it’s an unfortunate trend in this field, as it is much harder to make and deploy hardware changes. The development costs offset the value gained through fast and frequent releases, so it’s actually a much more desirable strategy to invest more in the design phase to create sound hardware architectures.
The Pitfall of Crowdfunding
Many startups are trapped in the idea that launching a successful hardware crowdfunding campaign is equivalent to market validation. Crowdfunding tends to be most successful for products involving a hardware component, particularly because of our unconscious desire of ownership related to the physical object. However, crowdfunding is not meant to validate your product at scale, but rather a democratic way of financing early-stage product development. The unfortunate reality is that many companies with successful crowdfunding campaigns have subsequently found it difficult or nearly impossible to scale their production since they did not validate their market at scale.
Certifications, Regulations, and Approvals
All hardware products require some kind of certification to be sold. It’s one of the most overlooked steps in the very early stages of bringing hardware products to the market. How will the certification constraint affect the product plan and the framework applied for development? It’s not uncommon to plan the early phases of the project with certification and other approvals as a project milestone, only then to backtrack conditionally to the kick-off phase. Product managers can instead carefully analyze regulations, dependencies, and product-plan strategic decision gateways in a more waterfall-like approach.
Opportunities for Hardware Product Management
Now that we have covered some of the challenges existing in the hardware with embedded software field, let’s now look at how to make the development process more streamlined and predictable in order to offset the inherent difficulties of hardware development.
Incorporate Agile into Hardware Development
Experienced product managers are aware of the challenges behind building hardware products with embedded software that tries to exploit a market opportunity created by new technological developments. They learn to balance speeding up time to market without compromising the likelihood of product success from the planning stage. Most of the time, this takes form via a water-scrum-fall approach.
The product ideation phase expands the product principles, goals and high-level features in as many details as possible. Great product managers spend more time refining deliverables of this phase: vision, mission, opportunity assessment, hardware product goals, and features. This is the north star of the product that needs to be clear enough before starting to work on any kind of hardware prototype, hence a waterfall approach is recommended.
It is critical to have well-documented requirements and functional specifications for hardware products, as well as a good technical architecture for the embedded software driving the hardware product. Changes in requirements and specifications should be penalized, not encouraged once they are signed off by the entire team.
A standard scrum methodology can be used when developing embedded software. It is less expensive in terms of time and money to adjust and refine software implementation in order to work with the predefined hardware architecture than vice-versa.
Final integration testing and user acceptance testing should be performed in waterfall conditions. At this stage, the development phase is complete and new functionalities and missing features are logged as additional work requests for the next planning period.
Incorporate Agile into Embedded Software Development
Building complex hardware products with embedded software impacts how traditional software development methodologies are applied. Many systems used to produce software that runs on a personal computer are not appropriate for developing embedded software, because there are constraints with respect to resource scarcity and much longer development lifecycles.
A group of academics and professionals from Brazil has offered a potential solution: Platform-based Software Design Methodology for Embedded Control Systems: An Agile Toolkit. This methodology incorporates agile principles into embedded software development. Below is a short summary of the methodology, but hardware product managers are strongly advised to read the full description before applying it in their practice.
The roles involved in this methodology are:
- Platform owner – Responsible for defining quality, planning, and cost targets
- Product leader – Responsible for implementation, integration, and test of the product
- Feature leader – Responsible for managing subsystem projects and tracking the progress of the feature deliverable
- Development team – Working on the product development
The methodology splits the development of embedded software into three process groups:
- System platform processes group. A system chooses the system components that will be part of the architecture and API platforms from a platform library and customizes them to satisfy the constraints of the application in question. The customization process is carried out in iterative cycles by programming the designer-configurable processors and runtime-reconfigurable logic integrated into the platform.
- Product development processes group. The functionalities which make up the product are partitioned into either hardware or software elements of the platform. The methodology provides partitioning algorithms to take into account the energy consumption, execution time, and memory size of the application’s components.
- Product management processes group monitors and controls product scope, time, quality, and cost parameters. Suggested approaches mainly consist of the practices promoted by the Scrum Agile method as well as the agile patterns.
Create a Hardware Development Program
Structuring an early-stage hardware development program has enabled companies to provide rapid pivoting or a plan B. From a business point of view, it may diminish financial margins, but in the end, it provides the needed agility for coping with ever-changing market conditions in terms of products released by the competition and advancing technological capabilities.
Suppose that a company runs a successful crowdfunding campaign for its hardware product with embedded software. They work great toward the first batch of products until a big established company announces something similar. Versatility and time to market are most important, and a pragmatic and agile response to this situation increases the likelihood of a successful product. By having a program of hardware development in place, the company can quickly adapt and put in the spotlight a richer version of the product as a response to their competitors.
Successful Testing of Hardware with Embedded Software
Testing is a crucial component of hardware product management because, unlike in agile software testing, most hardware bugs can only be fixed by producing a new batch of products. The Samsung Galaxy Note 7 devices which were catching fire is a great example of why hardware testing should be a top priority for all product managers.
Functional tests are the key goal of technical validation for hardware with embedded software products. The complexity of these procedures comes from the fact that errors are likely to come from any part of the system.
Unit testing usually happens in a simulated environment after each sprint, as simulated hardware offers the advantage of being perfectly controllable. Test scripts can be automated, can supervise the execution, and kill tests that seem to have crashed failing to produce any results.
Integration testing should take into account online and offline operations and submission of the hardware product to real-life operational conditions. For example, if the company develops a head-mounted brain monitoring system during outdoor activities, the testing conditions should consider these particularities.
System testing involves testing the entire system for errors and bugs. This test is carried out by interfacing the hardware and software components of the entire system (that have been previously unit and integration tested) and then tested as a whole. This testing is listed under the black-box testing method, where the software is checked for user-expected scenarios, potential exceptions, and edge case conditions. Mentionable special categories of testing:
- Event-triggered testing: Initiated by particular events or state changes in the life of the hardware product (e.g., startup, reset, shutdown). Its goal is to detect permanent faults.
- Time-triggered testing: Initiated at preconfigured times in the normal operation of the system, periodically done to detect permanent faults. It is useful in systems running for long periods, where no significant test triggering events occur. Time-triggered testing is also useful for detecting intermittent faults.
Product Acceptance of Hardware with Embedded Software
Product value for products of hardware with embedded software is typically validated after the product acceptance step in the water-scrum-fall methodology. The hardware with embedded software ecosystem must prioritize hardware over software for validation and acceptance. As previously stated, hardware changes are more difficult and expensive to perform. It’s common for product managers to conceive innovative solutions, required to solve acceptance problems or adjust the value by considering the constraint of not being able to alter the hardware and favoring extra iterations on the software development field.
Excellent product managers have the product acumen and the great power of vision in forecasting hardware needs and prioritizing the right includable features so that the business model is sound, acceptance is solid, and users enjoy using the product. Considering embedded software, the “decoration” of hardware should not be surprising, as it needs to follow rules and constraints, driven by hardware development processes, certification procedures, production challenges, and market acceptance.
Hardware Development Requires Managed Agility
Agile has taken the world of software development by storm and has now started to creep into the hardware space. However, the conditions of hardware product with embedded software development entails various challenges:
- Lack of specialized talent
- Version control systems that are not adapted for hardware
- Delocalized production facilities
- Changes that are harder to make compared to software
- Certification and regulation requirements that impose planning hurdles
These challenges make it harder to apply agile principles in the same way as software companies do.
In order to combat these challenges, a managed agility approach is needed in the form of water-scrum-fall. The embedded software development is created following the standard scrum procedures, while other steps like ideation, creating specifications, and testing are implemented in a waterfall setup. This allows hardware companies to reap the rewards that Agile offers while maintaining a functioning product management approach that has to consider the various constraints listed above. This managed agility approach provides a successful way forward in the context of fast-changing market conditions and constant technological improvements.
Understanding the basics
The water-scrum-fall approach is recommended for agile hardware development. The embedded software development is created following the standard scrum procedures, while other steps like ideation, creating specifications, and testing are implemented in a waterfall setup.
A hardware development engineer is responsible for actually creating and testing the hardware components like circuit boards, processors, memory devices etc.
The main difference between software and hardware engineering is the physical element. Software engineers only work with code on a computer, while hardware engineers work with physical products like processors, circuit boards, or memory devices.
Embedded systems are software components that run within a hardware product. They are called embedded because they are only adapted to run on that particular hardware.