If the terms “feature creep,” “waterfall,” and “agile methodology” are a regular part of your vernacular, it’s safe to assume your career entails lean hardware development.
Just as the terminology specific to hardware* engineering may be complex and nuanced, so too are its challenges — with a project’s difficulty often being influenced by outside factors (client-requested modifications, regulatory roadblocks, etc.).
During Boise Startup Week in early October 2019, we had an opportunity to discuss these challenges — and their remedies —with three successful leaders in the hardware development space. Speakers represented companies large and small, which undertake projects of a vast range in scope. They were: Rich Reavis, Director of Engineering at Black Box VR; Steve Howarth, Director of Hardware Engineering at Cradlepoint; and James Shawver, CEO at Swym.
The event lasted just an hour (and we got through about half of our planned topics), but the lean hardware development conversation provided a compelling look at what is working in this space and where there are opportunities for improvement. Below is our recap of the event along with insights, from SGW Designworks’ perspective, into what readers can take away from the discussion.
Lean Hardware Development: A Need for Speed
Early in the discussion, we talked about speed — such as what constitutes a fast development timeline and the obstacles to look out for when taking a product from concept to commercialization. We also discussed what a typical design cycle entails for these companies and how they are executed.
“We have cloud-based software that has a very rapid cycle — we might have a release every two, three weeks that the customer is not even aware of,” explains Howarth. For Cradlepoint, firmware cycles typically take about a month, and when it comes to hardware cycles, 9 to 12 months is pretty standard for a complete platform.
Prior to his role at Cradlepoint, Howarth served as Big Data Program Manager at Hewlett-Packard — an organization where a typical product development cycle lasted around two years, much longer than the shorter timeframe he’s grown accustomed to in his current position. He partially credits technological advancement for this increase in speed.
“I think there are things happening in the industry today that can lend themselves to greater odds of success if you wanted to adopt a lean or an agile hardware development methodology,” says Howarth. “[For example], rapid prototyping is something that didn’t really exist at least to the extent that [it does now]. If you need a one-day turn on a two- to four-layer circuit board, it’s pretty much no problem… today you can get up to 14 layers in a week with pretty good quality control. That sort of stuff [has] given me pause in my own process — what do we do to try to be a little bit faster than we are today? I thought [HP was] fast to begin with, but when I first joined Cradlepoint it blew me away how fast we could turn a product, compared to my previous role.”
At Black Box VR, Reavis says development cycles also move quickly, especially if his team is working with a previous model that’s already functional. “To the next version, that’s a six-month turnaround — from design package to the actual product in-house and assembly,” he explains. “It moves pretty quickly.”
One factor that directly affects the overall speed of development is communication.
“When there are different teams involved and you’re working in your own silos, it becomes a little trickier,” says Reavis. “You need to have a better-defined scope — because what you think is a good idea or what might work for the next implementation may cause another team weeks of work they’re not ready for or planning to do. So there’s a lot of cross-communication that needs to happen to integrate those two platforms nowadays with embedded hardware systems.”
Our takeaway: At SGW, we have found that one of the best ways to speed up development is actually to spend a little more time planning. Many times, development projects end up taking longer than anticipated due to problems that could have been avoided with a little planning. This is why we typically begin new development projects with a Phase 0, specifically focused on planning and feasibility.
Preventing Compliance and Regulatory Headaches When Developing Hardware
Next, our speakers explored the topic of certifications, and all seemed to agree: regulatory snafus — if not resolved quickly — can sound the death knell for a project.
Reavis recalls Black Box VR’s San Francisco gym opening earlier this year — and the impact that unexpected regulatory issues had on the project.
“We had a lot of conversations with the city itself about trying to open a public use facility that was deemed safe and appropriate to the California electrical code,” he says.
“Things were pretty straightforward in a sense, but when it came down to the actual VR — using VR with an automated robotic machine with embedded electrical systems — we had to do our due diligence to prove that the components we were using were UL rated to California state electrical code. We had to trace everything with documentation and submit a package, but even then the city inspector still had the authority to deny the application,” explains Reavis.
“So we had to fly a national testing certified lab from Florida to California the next business day — we paid a pretty penny for that — and had them do an onsite assessment. [That] entailed a bunch of paperwork, but all we needed was a sticker he pulled out of his bag and put his initials on and dated, and we were good to go,” he relates.
“But there were a couple of days we were researching and probably read almost every page of that electrical code — which is, like, 900 pages long — trying to find anything we could to be prepared if the inspector needed us to provide something else. Some of those items could’ve been months in development, and here we are trying to get occupancy to open our first gym, which we were already paying a lease on the building for. We’d moved all the machinery down there and hired personnel and staff, so that was a very strenuous time,” says Reavis. “Luckily it all worked out. But we learned our lesson. We now have systems in place to make sure we mitigate any surprises of that magnitude.”
For Howarth, certifications require products to be safe and legal to ship — and, since Cradlepoint works in the LTE (soon to be 5G) space, the company’s products operate on cellular networks, which are controlled by the carrier themselves, a private entity or corporate entity.
“AT&T and Verizon, for example, have their own rules for how you can operate on their network,” he explains. “We have to be compliant with their rules before we can ship our product because we rely on their network infrastructure for our products to work.”
Shawver explained how setting expectations with startup clients and educating them about regulatory compliance can keep the project on track (and on time).
“For us, a full product iteration that includes certifications really slows down the timeline,” he says. “And so we want to get the feature set completely locked in before we go through the entire certification process. We save that for last.” This often means testing a product with family and friends early on, in order to have an accurate customer sample.
Our takeaway: A lot of startup founders don't realize that almost all hardware products sold in North America are going to need some level of regulatory compliance prior to launch. At SGW, we include regulatory planning in early conversations to make sure the client’s expectations are correct. We typically are able to manage the regulatory testing and compliance process on development projects, but it is common for the regulatory work to be critical-path just prior to launch.
How to Best Capture and Integrate Market and User Input
A challenge that often arises during the lean hardware development process is capturing market and user input — not to mention, integrating that input into the UI.
During their early stages of hardware development, Black Box VR began by extending a beta program to friends and family so they could try the product and offer honest feedback for implementation. Next, they launched the full beta program that allowed users to complete the entire regimented program in Black Box VR’s warehouse facility. This gave the company several weeks of valuable interactions with users along with instantaneous feedback. Additionally, users could submit input via an app — a process Black Box VR has continued using even after launch.
When it comes to translating feedback into actionable development tasks, Reavis recommends tackling “the lowest hanging fruit items.” In other words, prioritize improvements that will have the most impact while requiring the least amount of work.
“You can get lost trying to please a small segment of your user base,” he admits. “It does take multiple departments to make some of these decisions; it may not be just up to the hardware team or the development team.”
Howarth adds that it’s crucial to know who your target customer is and to establish protocols for gaining their feedback early on. “As that hardware process gets further down the line, it becomes much harder once you start tooling,” he explains. When implementing feedback, he recommends the 80/20 rule. “Is that really going to benefit the majority of my customers?” He asks. “Make sure you’re doing things that are going to position you better for success.”
Our takeaway: There is no substitute for feedback from real users, using your actual product. Many business leaders and startup founders make the mistake of believing that they fully understand how users will interact with the product, and the product is designed around those assumptions. Then when the product launches, the market reacts badly because certain use case or user preference was not addressed in development. Get prototypes in the hands of actual users early and often during development!
Lean Hardware Development: Avoiding Pitfalls
We also talked with the panelists about war stories (but we’ll save that conversation for another day). Most importantly, speakers discussed lessons they’ve learned and ways that startups can save themselves time and money by avoiding certain pitfalls related to lean hardware development.
Howarth’s advice? “Establish a process. Get the feedback — [wherever] you are in the dev cycle — and listen to it. Have fast discussions.”
Shawver cautioned against being too trusting, specifically when outsourcing, and especially if the connection isn’t vetted. “There have been people who were able to get a really low cost, but when the bill came due, they would have to pay X amount to be given the intellectual property rights. If you don’t check for who owns the intellectual property, you’re basically paying for their time — and then they own it and [can] hold it ransom,” he explains. Shawver also says to make to get the source code — which allows for changes later on, should they be necessary.
Reavis also had plenty of great advice: have a system or process in place, be cautious when working with other startups, and develop an appetite for risk. The kicker? “You’ve just got to evaluate that with the entire team, all stakeholders, to make sure everybody’s bought into that mindset,” he says. Reavis also stressed the importance of communication, honesty, and tempering expectations when it comes to deliverables. “It’s hard as designers, engineers, project managers, especially working in today’s industry — you want to show that you can deliver on time and your team is [made up] of rockstars and you can do anything,” he explains. “But you need to assess, ‘Is this really realistic?’ And again, making sure that everybody is on the same page [in terms] of what the end goal is.”
Howarth also recommends thinking through a hardware development project — past the whiteboard stage. “Invest the time in specifying what you’re building,” he says. “In a startup world, you’ve got to do things fast and you’re under pressure, but it’s worth it to write this down. The process makes you think through — how is that thing actually going to be built? How much is it going to cost? How is it going to be put together and built? Creating specification takes time up front but it’s going to save time on the back end.”
But he issues a caution about how much detail to include in a spec: “If you don’t have enough detail, the likelihood you’re going to get what you want is low. But if you put too much in that spec, and you’re asking someone else to build it or even [building it] internally, now it’s too complicated, and your likelihood of getting what you want decreases again.”
“We sometimes assess project scopes [based on] must have, should have, could have, and will not have,” adds Reavis. “That helps us get through things a little more quickly and bring other teams inside as well.”
Our takeaway: Another pitfall that startup founders tend to overlook is the inherent risk involved with developing and launching a hardware product. A robust planning effort can identify the likely technical risk areas and then prioritize those items first in the development project. But even after a quick and successful development project, other business realities come into play. In addition to the normal sales and marketing challenges that a startup faces during launch, setup and management of manufacturing partners can be difficult. Many businesses fall flat here because they just don’t have any experience with contract manufacturers, inventory planning, product revisions, etc. This is why SGW Designworks offers Manufacturing Management services to clients after development. We take on the challenges of dealing with the manufacturer so that the client can focus on generating demand and satisfying customers.
*Editor’s note: When we speak of hardware, we’re referring specifically to electrical/electro-mechanical devices, which usually contain firmware or embedded software. Hardware development typically involves developing designs for devices that will be manufactured, such as phones and other communications technology, consumer electronics, computers, industrial equipment, and medical devices.
