Robert States, Principal at Stress Engineering Services, has spent 16 years doing something most engineering organizations can't - processing 650+ projects per year across medtech, pharma, consumer products, and oil and gas, with a third of that volume arriving as crisis work. His team has seen the same failure modes repeat often enough to stop treating them as unique. The episode asks a direct question: if you've seen enough failures to recognize the pattern, what are the patterns?
As an outsider looking in, we're an engineering services company. But inside these four walls, we're a people development company.
In this episode:
Why "I didn't know I needed to know that" is the single most common explanation for product failures and what it reveals about how engineering programs scope their requirements
How rapid prototyping creates overconfidence that pushes programs forward before the design is ready, especially when the prototype gets shown to someone without deep development experience
The four root causes Robert has traced across hundreds of crisis engagements and why the fourth one generates the most pushback from experienced teams
The environmental stress cracking wave in med device components triggered by post-ACA cleaning protocol changes and polycarbonate's counterintuitive failure mode under sustained load
Why med device development lags consumer products and aerospace by more than 20 years in predictive modelling and how digital twins catch late-stage reliability issues before products leave the line
Bonus Content:
"Just a Little Longer" Is Not a Decision
S2E52 Robert States | Solving Failures and the “Been There Done That” Engineering Strategy
Robert States is a principal at Stress Engineering Services, where his team runs more than 650 projects per year, with roughly 200 arriving as emergency work from teams that have been stuck for months. In this episode he walks through the pattern-recognition that volume produces. He covers the four root causes he has traced across hundreds of client engagements, why rapid prototyping is the most contested driver of product failure, how med device companies lag consumer products and aerospace by more than twenty years in predictive analysis, and what the shift toward digital twins means for catching late-stage reliability failures before devices leave the manufacturing line. He also describes the specific environmental stress cracking wave triggered by post-ACA cleaning protocol changes and why polycarbonate's counterintuitive failure mode is still catching teams off guard. For product development engineers and R&D leads in medtech and hardware, this episode is a field-derived diagnostic for the failure modes that don't show up on any FMEA.
>If YouTube isn’t your thing, check out this episode and all of our past episodes on Apple, Spotify, and all the rest.
Great engineering doesn’t always lead to successful products.
In this upcoming PDX Webinar, Arne Lang-Ree (Chief Design Officer & Cofounder at Spanner) will show how engineering teams can turn product-market fit into a practical design objective.
The session covers frameworks for translating user needs into engineering constraints and evaluating product success throughout development.
Join us on April 23 at 9:00 AM PT / 9:00 AM MST / 12:00 PM EST.
The Four Failure Patterns Robert States Traces in Every Crisis Call
Robert States has processed enough crisis work to stop treating product failures as unique. Across 650+ projects per year, a third arriving as emergency calls from teams that have been struggling for months, he's traced most failures back to the same four conditions. The first is the most common.
The simple answer is almost always: I didn't know I needed to know that.
The second driver is more specific - key stakeholders talking past each other. Robert describes what happens when an injection-moulded part fails and each discipline reviews it through their own lens without recognizing the limits of that lens.
If I have a failure and I show it to design personnel, it's a design problem. I take it to a materials person, they'll tell me it's a material problem. I take it to a manufacturing person, it was made wrong. And my more favorite one recently is I take it to human factors and it's a user.
The fourth driver, and the most contested, isn't a communication failure. It's a tool that most teams treat as a sign of progress.
Rapid prototyping gives you overconfidence too early. Especially when you show it to someone who doesn't know a lot about development. They go, 'it's there, just go.
The cost of these four patterns is not theoretical. Robert can put a number to it.
I know how much it cost to do the work that they needed to get done six months ago. But at times it was probably a $5,000 task that could have saved them a million dollars.
The teams that avoid these failure modes aren't smarter, they're working with people who've seen the pattern before and know where to look.
"Just a Little Longer" Is Not a Decision
NASA's Constellation program consumed $9 billion with no flight-ready hardware before the Augustine Commission found it "not executable as structured" - years after internal reviews had been approaching that conclusion. Robert States describes the same structural condition in this week's episode: the people with the clearest picture of a failing program are also the people with the most career exposure from being honest about it. This article names the mechanism and gives engineering leads two specific moves to make before the next program review.
To read the full article, visit the full article on The Wave.
When Your Machine Shop Says No
Last year, a customer couldn't find a shop willing to make their part. Difficult material, tight tolerances, small quantity.
We tested our internal supply chain. Made the parts ourselves. Sent them as a surprise.
They worked perfectly. That customer has ordered hundreds more since.
Now available: custom machined parts with Pipeline engineering oversight, pricing that outperforms domestic shops, and the same supply chain we trust for our own work.
Want to learn more? Contact us at the link below: