Latest / Hardware Startups with Fexingo: Devices, Robotics, and Manufacturing Tech Companies / How Hardware Startups Use Data From Field Returns to Improve Design
Transcript
- Lucas: You ship a hundred units. One comes back two months later. Customer says it just stopped working. Luna: Most startups I know just replace it, apologize, and move on. Lucas: Exactly, and that's a huge missed opportunity. That return is a free piece of field data — possibly the most valuable thing you'll ever get for free. We're talking about the closed-loop feedback from field returns, and why hardware startups that do a proper teardown on every return end up with much more reliable products. Luna: So you're saying instead of treating returns as cost centers, treat them as R&D inputs? Lucas: Right. But there's a specific method to it. I want to walk through a real case I saw recently. A smart-lock startup, about eighteen months in, had shipped about twelve hundred units. They were seeing maybe a three percent return rate, which sounds okay on paper. But one particular failure kept recurring: the motor that drives the deadbolt would seize. Luna: After how long in the field? Lucas: Usually between two and four months. So they'd replace the whole lock, customer's happy, but the problem is still out there in the other eleven hundred units. One day the founder decides to actually tear down a returned unit. He takes the motor apart, looks at it under a microscope, and finds that the grease — the lubricant in the gearbox — had migrated away from the gears. It was a low-temperature grease spec'd for an indoor device, but many of their customers were installing these locks on exterior doors where the temperature swing was wider. Luna: So the grease just... left? Lucas: It thinned out when it got warm, dripped off, and then when it cooled, the gears ran dry and seized. That one teardown probably saved them tens of thousands of dollars in future warranty costs. They switched to a high-temperature grease, validated it with a quick thermal cycle test, and the failure rate dropped below half a percent. Luna: But that's a pretty obvious fix in hindsight. What about more subtle failures? Lucas: That's the thing — a lot of them are subtle. We had another case from a wearable startup that makes a fitness tracker for industrial workers. They were getting returns where the display would just go blank after a few weeks. Teardown showed water ingress at the button seal. The O-ring they were using had the right durometer on paper, but the supplier had switched to a different batch without telling them. The only way to catch that is to open it up and look. Luna: How do you structure that process without it becoming a huge time sink? Because if you're a five-person team, you can't spend two days analyzing every return. Lucas: You don't need to. The key is triage. You categorize returns into three buckets: clear user error, obvious manufacturing defect, and mystery. For the mystery bucket — anything that doesn't have an immediate explanation — you do a full failure analysis. That might be one in ten returns. But you do it systematically. You photograph the unit as received, document any external damage, then open it up, look for burnt components, cracked solder joints, corrosion, anything unusual. Luna: You need a basic lab setup for that. Microscope, multimeter, maybe a thermal camera? Lucas: Yeah, but it's not expensive. A decent stereo microscope is a few hundred dollars. A multimeter is fifty bucks. And you can send the tricky ones out to a contract failure analysis lab for a few hundred per unit. Compare that to the cost of a recall or a bad review from a major customer. Luna: So the ROI is pretty clear once you frame it that way. But I think a lot of startup founders just want to clear the queue. Lucas: Absolutely, and that's the trap. You're busy shipping new features, you don't want to look backwards. But every return you don't understand is a ticking time bomb. I've seen startups hit a scale inflection point — say, they go from a hundred units a month to a thousand — and suddenly that three percent return rate becomes a thirty percent failure rate because the root cause was something they never understood. Luna: Because the failure mode was related to a manufacturing process that changed when they scaled? Lucas: Exactly. Maybe the first hundred units were hand-assembled with careful torque, but when they moved to an automated screwdriver, the torque was slightly different, and now a connector cracks after a thousand thermal cycles. That's the kind of thing you'd never catch if you only look at the defect rate at the factory. The field tells you what really happens. Luna: I want to talk about the documentation side. What should a startup capture when they get a return? Lucas: Minimum viable data: the product serial number, the failure symptom as reported by the customer, the date of return, and the date of manufacture. Then after teardown, you add the root cause — confirmed or suspected — and the corrective action. That corrective action might be a design change, a process change, or even just a note to the customer service team to say 'this unit was dropped, not a design issue'. Luna: And you track that in a spreadsheet? Or is there better tooling? Lucas: A spreadsheet works fine for early stage. Later you might use a quality management system, but the important thing is that the data is accessible to the engineering team. I've seen startups where returns are handled entirely by customer support, and engineering never sees them. That's a disaster. The engineer who designed the motor driver should be the one looking at the burned board. Luna: Yeah, that's a cultural thing. It's about creating a feedback loop where the field data actually informs the next revision. Lucas: Right. And the best hardware startups I've worked with treat returns as the single most important source of design feedback. They put a physical return board on the wall — yeah, a literal corkboard with failed parts pinned to it — and every Monday they review the new ones. It keeps the team humble and focused on reliability. Luna: If these conversations are useful for what you're building or running, I just want to mention that this show stays ad-free thanks to listener support. A couple of dollars a month is genuinely what keeps these going — buy me a coffee dot com slash fexingo, if you've gotten something out of them. Lucas: Yeah, and it really does make a difference. Every contribution helps us keep doing deep dives like this without any sponsor pressure. So, back to the topic — I think another angle worth exploring is the economics of returns. Because a lot of startups default to just replacing a unit because they think analysis is too expensive. Luna: What does the math actually look like? Lucas: Let's say your product costs fifty dollars in BOM and assembly. If you just replace it, that's fifty dollars plus shipping, call it sixty. If you do a full teardown and analysis, that might cost you five dollars in labor and maybe another ten if you send it out for something like X-ray or cross-sectioning. So you're spending fifteen to twenty dollars per return instead of sixty. But more importantly, that twenty dollars can prevent future returns. If you find and fix the root cause, you save all those future replacements. Luna: So the breakeven is basically preventing just one return per every three analyzed? Lucas: Yeah, roughly. And for a startup scaling up, the leverage is enormous. The fix might cost nothing — a software parameter change, a different lubricant, a tighter tolerance on a screw. But if you don't catch it, that failure mode propagates into every unit you ship from that point forward. Luna: I've also seen cases where the root cause isn't even in your product. It could be how the customer installs it or uses it. Does that show up in returns? Lucas: All the time. The smart-lock example — the grease issue was partly an installation environment problem. But the fix ended up being a better spec that covered both indoor and outdoor use. Another example: a startup making a portable battery pack was getting returns where the USB port broke off. Teardown showed the port had stress fractures. Turned out customers were plugging in stiff cables and leveraging the port. The fix was to use a reinforced connector with through-hole mounting instead of surface mount. That came directly from looking at the broken parts. Luna: So the teardown doesn't just tell you what broke — it tells you how the product is actually being used. Lucas: Exactly. That's the hidden value. You get usage data that no survey will ever give you. You see the scratches, the dirt, the corrosion — it's like a detective reading the scene of the crime. Luna: What about the timing? When should a startup start doing this systematically? Lucas: Day one. As soon as you ship a product, you should have a process. Even if it's just one person spending an hour a week on returns. By the time you hit a thousand units, you'll already have a pattern library of failure modes. If you start at a thousand units, you're playing catch-up. Luna: And you need to close the loop, right? The analysis is useless if the fix doesn't get implemented. Lucas: Right. So you need a formal corrective action system. It can be as simple as a ticket in your issue tracker. You document the root cause, assign an owner, set a deadline. Then you validate the fix with a test — ideally with a sample size that proves the failure mode is eliminated. And you update your design documentation so the next revision incorporates the fix. Luna: Do you ever see startups over-analyze? Like, spending too much time on a single return that was a one-off? Lucas: Sure. That's why triage is important. If a return clearly shows physical damage from being run over by a car, you don't need a root cause analysis for that. You just note 'customer abuse' and move on. The mystery bucket is where you focus. And even within that, if you see a failure mode only once and it's something exotic — like a specific component from a specific date code — you might log it but not redesign the whole product. You watch for patterns. Luna: Patterns are key. One return is an anecdote. Ten returns with the same symptom is a crisis. Lucas: Exactly. And the great thing is, the returns data tells you which patterns matter. You don't have to guess. If you see the same failure mode on three different units from different batches, that's a signal. If it's only on units from one production run, that's a signal too — maybe a process control issue. Luna: So the takeaway for a hardware startup founder listening: set up a returns teardown process now, even if you've only shipped ten units. Because the data you collect today will make your product bulletproof when you scale. Lucas: Yeah. And treat those returns as a gift. Every one of them is a chance to make your product better for the next customer. If you ignore them, you're just statistically guaranteeing that more will come back later.