We counted about 55 individual parts in a pair of Apple AirPods. Apple has never published unit volumes, but industry analysts estimate that hundreds of millions of pairs have been sold in the nearly ten years since launch. In 2023 alone, the estimated revenue from AirPods exceeded Nintendo’s total revenue for the same calendar year.[1] New pairs roll off the line every minute of every day, 365 days a year.
You can bet that each one of those parts was designed by a very invested team of people. Thousands of decisions and lessons learned went into that design to ensure high quality and high production volume. Tear down a pair and examine each assembly, subassembly, and individual part, and there's a story hidden in each one.
At Engenious Design, we design and develop medical devices for our clients; devices that range from simple assemblies to complex systems made up of hundreds of parts, all working together to keep patients safe, deliver effective results, and meet the needs of the business. Most of our efforts to build a new product start with tearing one apart. Often taking apart multiple products in the quest to learn quickly.
Product managers already learn a lot from using and observing competitor systems. But the teams that move fastest go a step further and have R&D tear down a predicate device. It does not take a 100-person engineering group; basic tools and a healthy bit of curiosity get most teams started, and Engenious can help with the rest. You will find what the other design team learned when they built the device: what worked, what didn't, what cost more than expected, and where they ran into a wall of patents.
A well-run teardown is a free head start. A new product does not require the proverbial blank sheet of paper. Someone already invested the time to get it right. Experienced teams don't ignore that.
It's tempting to assume the competition made mistakes and the new product will be wildly superior. Sometimes that's true. But tear into a medical device and the specific choices come into focus: components selected for a reason, subsystem interfaces handled in a particular way. Behind each choice was a decision. Behind each decision was a requirement.
If you ask “why” enough times, you will get to an answer. You don’t have to agree with it, but you will be miles ahead by understanding it. Always assume the competitors set out to make the best device possible. Anything else creates dangerous blind spots in your product strategy.
First principles make sense on paper. A block diagram is clean and well defined, again, on paper. Once the system runs headfirst into the realities of production, supply chain and cost of goods sold (COGS), things change fast. When a component looks out of place, the productive move is to ask why. There's nearly always a reason, and the teams who get the most out of a teardown start from the assumption that the previous design team was smart and motivated.
We recently saw an unexpected pump arrangement in a device. Rather than one appropriately sized pump, there were two plumbed in series. Why add complexity to the system? Why add the risk that additional connections might fail under load? When we dug deeper, we found that the appropriately sized pump not only had a large form factor, it was also wildly expensive. The previous design team made a smart tradeoff: improve COGS and reduce supply chain risk, while accepting a slightly more complex system.
Uncovering unused components or missing parts in the final build can be a clue that a requirement was changed or added at the last minute. A stand-alone Bluetooth (BT) module might point to a last-minute change with no time to certify an integrated design. If that BT module is inactive, it may point to a late decision to avoid the burden of a cybersecurity submission to the FDA[2].
Missing parts or unused expansion capability can also point to a product roadmap the other team hasn't explored yet. That's a particularly valuable clue for a team still shaping its own feature set and user needs.
At Engenious, we work on a lot of larger capital equipment with long life expectancies and high duty cycles. That necessitates that serviceability is designed in from the beginning. A teardown of a predicate device is the moment to note what the other team treated as consumable and what they treated as serviceable.
Where's the line drawn, and why? Defining certain components as consumable may guarantee an ongoing revenue stream. It may also reduce the burden on service technicians and the design that supports accessibility.
If there are integrated electronics that require updating, does that happen on-site or over the air (OTA)? By avoiding OTA updates, a product manager may be able to remove a hospital's IT group from the path to purchase and improve the odds of adoption. On-site updates also require a technician to service the device. This is a labor tradeoff, but also potential revenue from service contracts. These are product management decisions as much as they are engineering decisions.
When the target device has a 510(k), the teardown will show evidence of the predicate pathway. Just because a design is expedient or effective doesn't mean it will adhere to the predicate. A significant change may trigger a new review and add risk to the development cycle, so these decisions get made carefully[3]. An element that deviates from the predicate in a meaningful way is usually a feature or requirement the team judged critical to market advantage.
Journalist David Epstein argues in his book Inside the Box: How Constraints Make Us Better[4] that too much freedom can be crippling. Left with no boundaries, the brain sprints straight for the familiar instead of the original. He writes, “Overvaluing complete freedom can be disastrous for everything from starting a company to harnessing creativity…”[4] (p. 25). This can seem counterintuitive, until you consider the last time anyone stared at a blank sheet of paper or a blinking cursor at the top of a new document. It's daunting to know where to start.
Epstein points to General Magic, the 1990s startup stacked with the engineers who would go on to build the iPhone and Android, they had unlimited talent and funding and still failed because the team couldn't agree on what not to build. The Palm Pilot, built around the same time with a fraction of the resources, succeeded by deliberately limiting itself to four apps at launch.[5]
In medical devices, the constraints can be especially confusing. Engineering wants zero risk, manufacturing wants low cost, marketing wants something brand new, and the user ultimately just wants to help their patients. Every team in this industry has struggled with those same tensions.
Those seemingly mutually exclusive demands become the constraints that guide development toward something genuinely better. Getting under the hood of the devices that came before is about getting inspired by the engineers who had the very same questions. Gathering intelligence on device construction isn't about reverse-engineering someone else's success (or failure); it's about making new connections, building on existing knowledge and ultimately driving innovation forward.
So, in the words Ted Lasso made famous: “Be curious, not judgmental.” Now go break some stuff.
I’m part of Engenious Design, a medical device design and development firm that works on some of the industry’s most advanced technologies while carefully curating the user experience along the way. We help R&D leaders create new medical devices quickly. Our team of 100 designers, engineers, and builders can plan, architect, design, engineer, prototype, verify, validate, and transfer products to production, all under one roof.
1. PCMag, "Apple's AirPods Made More Money Than Nintendo Last Year." https://www.pcmag.com/articles/apples-airpods-made-more-money-than-nintendo-last-year
2. FDA CDRH, Cybersecurity in Medical Devices: Quality System Considerations and Content of Premarket Submissions. Final guidance, September 2023.
3. FDA CDRH, Deciding When to Submit a 510(k) for a Change to an Existing Device. Final guidance, October 2017.
4. Epstein, David. Inside the Box: How Constraints Make Us Better. Riverhead Books, 2026.
5. “Palm OS”, 2026 In Wikipedia. https://en.wikipedia.org/wiki/Palm_OS
