Why the Best Hardware Teams Have Started Talking Like Software Engineers

A delivery robot that survives Chicago winters and a one-ton search-and-rescue drone for the Swedish wilderness don’t have much in common on the surface.

But Coco Robotics and Saab’s The Rainforest have independently arrived at a lot of the same answers about how to build hardware fast, build it right, and keep improving it once it’s in the field.

Here’s what they actually do differently.

Share Links, Not Files

Imagine design reviews with no files to export or emails to send with said files. By sharing a live link to the actual design, the current state is accessible to whoever needs it.

It might sound like a small operational detail, however, it’s core to creating an agile product development environment. The time lost to file ping-pong can’t go into impactful design iterations.

Removing this friction point has allowed the team at Coco Robotics to move from design decision to collaborative review in minutes instead of hours, compounding into a faster agile product development life cycle with better outcomes per sprint.

Treat Design Branches Like Software Teams Treat Code Branches

Onshape’s branch and merge workflow lets multiple engineers work on the same assembly simultaneously without overwriting each other’s work. The Coco team uses it as standard practice: Propose a change in its own branch, review it, merge it if it works, discard it if it doesn’t.

This directly mirrors the agile product development framework used in software, where no one commits untested work to the main codebase. Applied to hardware, it means parallel design work that was previously serialized can now happen concurrently. Engineers aren’t waiting for others to finish before they can start. Multiple design directions can be explored simultaneously, evaluated, and merged or dropped based on evidence.

Automate Feedback Loops

At The Rainforest, a code commit triggers a CI/CD pipeline that calls the Onshape API, updates the geometry, pulls back mass and inertia data, runs simulations, and posts results to a live dashboard, all automatically.

This is the agile methodology applied to product development at the systems level with continuous integration for software and for the physical vehicle, too. The cycle time from making a change to understanding its impact on performance dropped from days to hours.

Display the Data in Real Time

The Rainforest team displays live simulation results on large screens throughout the office for the whole team to see in real time, long before a scheduled design review. Every design change, including small detail decisions, surfaces as a mission-level consequence: range, takeoff distance, payload capacity. No one is waiting for a formal release cycle to find out that this morning’s change broke the weight budget.

This is one of the most underrated agile product development steps any hardware team can take: Make the current state of the design visible to everyone, continuously. When the information environment is shared, decisions improve and silos dissolve.

Bring Manufacturers into the Design Earlier

At the Rainforest, manufacturing partners can work simultaneously in the same Onshape model and comment directly on geometry before anything goes to production. At Coco Robotics, vendors can access the same live files as the design team through the Onshape-Arena Connection, which connects Onshape CAD and PDM to Arena PLM.

Compare that to the traditional alternative, which The Rainforest team describes as throwing a design over a fence and waiting to see what comes back. In an agile product development environment, manufacturability feedback belongs in the design phase, not after.

An Actual One Source of Truth

The Coco Robotics team utilizes the Onshape-Arena Connection, which means design data, BOM, and sourcing details all live in the same system. When a file is released, everyone who needs to can look at the same version.

In an agile product development environment, this is risk management. A data mix-up could produce a bad manufacturing run, a delayed program, or a part that doesn’t fit. Cloud-native agile CAD, PDM, and PLM platforms working together eliminates the conditions for that class of error by design.

Stop Losing Time to Broken Assemblies

With file-based PDM, teams risk broken assemblies and hard-to-track changes, and the whole system depends on people manually syncing their work.

The Coco Robotics team knew this problem well from previous experience running a legacy CAD and shared database setup. Changes were hard to trace, fixes were manual, and every hour spent on infrastructure was an hour not spent on the product.

Cloud-native version control removes the sync step entirely. There are no local files to fall out of date, no broken references, and no reconciliation. Those recovered hours go straight into iteration, and the agile product development process gets faster at exactly the rate of all the dead time it eliminates.

Iteration is Encouraged

Both teams report that cloud-native, database-driven workflows produce quicker and more impactful design iterations. In an agile product development with a scrum or sprint-based approach, velocity matters.

But for hardware teams, iteration may be the single most telling measure of process health. At 10 to 50 times the speed, you’re moving faster to explore design ideas that are simply unreachable at conventional cadences.

Designing for Manufacturability at the Start

When your manufacturing partners are in the design environment, design for manufacturability becomes a continuous conversation rather than a post-design checklist. The practical result is cheaper production and fewer problems for the people actually assembling the hardware. The problems that used to surface on the shop floor now surface at the geometry stage, when they’re cheap to fix.

This is one of the most direct agile product development examples of “shifting left,” teams are catching issues at the earliest possible moment in the agile product development life cycle, before cost and schedule consequences have compounded.

Use AI Tools to Build Automation

AI tooling has significantly accelerated the code-writing side of the process to get past boilerplate setup faster, so engineers can spend their time on problems that actually require judgment.

As AI-assisted agile CAD software matures, with capabilities like AI-generated FeatureScripts, automated drawing annotation, and intelligent API integration, the teams that benefit most will be the ones who’ve already built the automation pipelines worth accelerating.

Track Every Change for Full Context

Cloud-native CAD gives both teams a complete audit trail, showing who changed what, when, and what it affected. In a file-based system, that history either doesn’t exist or lives in a chain of emails.

For teams building products that go into regulated environments, or for any team trying to understand how a problem was introduced three iterations ago, that traceability could be confused for bureaucracy. However, agile product development metrics only improve when teams can see, clearly and completely, what happened in previous sprints.

Use a New Vocabulary

When the Coco Robotics team describes their workflow, they reach naturally for words like branches, links, and collaboration. When Saab’s The Rainforest describes theirs, the language is pipelines, deployments, and automated feedback. Neither team set out to describe hardware development in those terms. The terms just fit the way they work now.

When the language your team uses to describe their process sounds like an agile product development framework, then the process has actually changed.