Avoid the Trap of a Bottleneck with FEB Thinking
Why the fastest way through a bottleneck is to never reach it
Avoid the Trap of a Bottleneck with FEB Thinking
Why the fastest way through a bottleneck is to never reach it
Herbert Roberts, P.E. | Inventor's Mind
I was first introduced to systematic innovation as a Black Belt, and the assignment that taught it to me was a trap disguised as a straightforward engineering problem.
The company had built a long, profitable history on derivative products — new offerings engineered off a single engine frame that was, by the time I got the assignment, roughly twenty years old. It had earned its keep. It was proven, well-understood, cheap to manufacture, and every engineer in the building had a decade or more of hard-won intuition about exactly how it behaved. The customer base, meanwhile, was asking for real innovation — capability the old frame architecture had never been designed to deliver and, after two decades of derivative refinement, wasn't going to deliver no matter how cleverly you pushed on it.
My Black Belt assignment was to help the engineering team find a way to integrate new innovation into a new engine frame — without losing the magic of the past.
That last phrase did more work than it looked like it was doing. "Without losing the magic" wasn't a nostalgia clause. It was the actual constraint, and it's the one that made the assignment hard: not "design something new," which is easy, and not "keep the old frame," which is also easy — but find whatever it was about the old frame that customers, and the engineers themselves, were actually attached to, and carry that forward into something the old architecture could never have supported.
The bottleneck wasn't the engine frame. The frame was just where the constraint became visible.
Confession. My first instinct, and the instinct of most of the engineers in that room, was to treat this as a narrow-end problem: characterize what the old frame did well, then find a way to bolt new capability onto it, or alongside it, without disturbing what worked. That instinct isn't wrong, exactly. It's the entire discipline of engineering, in fact: characterize the system, isolate the variable, converge on a fix within the architecture you've got. It's just aimed at the wrong end of the funnel more often than any of us like to admit, and it took me embarrassingly long to name why.
The false issue was "how do we add new capability to this engine frame." It felt like the real problem because it was the one sitting directly in front of us, backed by twenty years of institutional knowledge, with a clean and defensible path to a fix. The true issue was "what is 'the magic' actually made of, and does it require this specific frame to exist at all" — a question that required walking back past the frame itself to the design decisions and customer experiences that had made the old product beloved in the first place, most of which had nothing to do with the frame's specific geometry and everything to do with what that geometry had allowed the product to do.
The forensic correction.
A bottleneck, by definition, is the narrow end of a funnel. It's the point where flow — material, information, design freedom, whatever you're moving — gets squeezed down to its tightest constraint. Every established discipline built around bottlenecks treats them the same way: work at the narrow end. Manufacturing engineering relieves the constraint, adds capacity, buys down the choke point. Traffic engineering widens the road, retimes the signal. Eliyahu Goldratt's Theory of Constraints — still the standard reference three decades after The Goal — is explicitly a narrow-end discipline. Its entire method is finding the constraint and working directly on it until it stops being the constraint.
All of that is legitimate, proven engineering. None of it is what I'm about to describe, and the distinction matters enough that I want to be precise about it before going further: this isn't a claim that "bottleneck" is a word FEB owns. It isn't. Collins English Dictionary categorizes "bottleneck" under Automotive Engineering for exactly the reason above — it has real, established technical meaning in manufacturing and production-throughput contexts, and Goldratt's framework is rigorous and correctly narrow-end-focused for the problems it was built to solve. What follows is a different question, asked at a different point in the funnel, before the narrow-end tools ever get their turn.
The technical teardown.
There's a second place to work, and it's almost never where anyone looks first: the wide end of the funnel — upstream of the constraint, at the framing and assumptions that determined the funnel would narrow down to that point at all.
The trap is subtle, and it's not the bottleneck itself — it's arriving at one and assuming that's where the work starts. By the time a constraint is visible enough to name — an engine frame that's aged out of what the market needs — the framing that produced it is usually long settled, unquestioned, and invisible to the team now staring at the narrow end. FEB thinking is the discipline of catching that trap before you fall into it: refusing to accept the funnel's shape as given, and checking upstream before you spend a career optimizing a frame you never needed to keep.
This is the move I call FEB — Formen Engpass Barriere, a German-language coinage that translates roughly to "shape the bottleneck-barrier." That literal translation undersells what's actually happening grammatically, and the grammar is the whole point. Formen is a verb — "to form, shape, mold." It governs the two nouns that follow it: Engpass, the bottleneck or constraint, and Barriere, the barrier. Read correctly, the phrase doesn't label a subject matter the way "a book about bottlenecks" would. It names an action performed on a constraint — and the action isn't "relieve" or "widen," the narrow-end verbs. It's "reshape the framing that produced it."
Concretely, the FEB move looks like this, and it's the one analytical move in this piece I'll name outright rather than let you infer it: when a solution space collapses down to a single hard constraint, stop optimizing at the constraint and instead walk the causal chain backward until you find the decision that created the funnel shape. Not "why is this hard" — "what upstream framing made this the only shape the problem could take."
In the engine-frame case, the upstream framing wasn't a single decision — it was twenty years of derivative products, each one a small, individually reasonable choice to build on what already existed rather than question whether it still should. Nobody on that Black Belt assignment had signed off on any single decision that trapped the product in that frame. It had accumulated, one derivative at a time, the way most real bottlenecks do. The narrow end was the frame. The wide end was two decades of "just build on the last one" that nobody had been asked to revisit until the customers stopped letting us get away with it.
This is where TRIZ and FEB shake hands but aren't the same tool, and the distinction is worth being exact about since I use both. TRIZ gives you a structured way to resolve a contradiction once you've correctly identified it — the classic forty principles, the contradiction matrix, the discipline of refusing to trade off two requirements that both matter. FEB sits upstream of that. It's the check you run before you accept that the contradiction you're staring at is the real one, or just the shape the funnel happened to take because of a decision three steps back that nobody revisited. TRIZ solves the problem you've named. FEB checks whether you named the right one.
Forensic signature.
The tell that you're solving at the narrow end when you should be at the wide end is almost always the same: the team is very good at the problem in front of them and no better off after solving it. An engineering group that's spent twenty years getting excellent at extending one frame will keep getting better at extending it — right up until the extending stops being enough, and the skill that made them good at the old problem doesn't transfer to the new one.
If you want to catch this pattern earlier than I did, the fastest question you can ask isn't "how do we fix this." It's "who decided this had to be this shape, and were they solving for something we've since stopped needing?" That question does something the narrow-end tools can't: it reopens a decision instead of optimizing inside one.
Aftermath, and a forward prediction.
We found the magic, eventually — and it wasn't the frame. It was a small set of things the frame had happened to enable: a specific handling characteristic, a serviceability trait technicians had come to rely on, a silhouette customers recognized without needing the badge. None of those required the twenty-year-old architecture specifically. They required knowing, precisely, which parts of "the magic" were load-bearing and which parts were just the frame that had been carrying them for two decades because nobody had asked. Once we knew that, the new frame wasn't a betrayal of the old product. It was the old product's actual values, carried by hardware finally capable of doing what the customers had been asking for the whole time.
Here's the forward-looking piece, and it's the reason I'm writing this now rather than filing it away as an old assignment: I don't think this pattern is limited to engine frames, or to engineering teams, or even to hardware. Anywhere a group of smart, disciplined people are working very hard at a well-characterized constraint and not gaining ground, there's a real chance the constraint isn't the problem — it's the residue of a framing decision made one or two steps upstream, by people who've since moved on and have no reason to know it's still costing you. Over the next several pieces, I'm going to walk through that same wide-end move showing up in places you wouldn't expect it — a Cold War propulsion program, a rocket landing on a boat, and the middle of the current EV market correction — because once you've seen the pattern once, it gets hard to stop noticing it everywhere else.
I'd love to hear about the bottleneck you eventually stopped solving by refusing to solve it — the moment you went looking upstream instead of leaning harder on the narrow end. That question drives everything I write here.
Herbert Roberts, P.E. is a licensed professional engineer with 30+ years in aviation research and development.
FEB (Formen Engpass Barriere)™ is a pending trademark of Inventor's Mind Press, naming the practice of reframing a problem from the wide end of the funnel — reshaping the framing that produces a constraint, rather than working the constraint itself.