Look for the Duct Tape

Walk into any iBwave customer’s office and you’d see it: enormous 3D building models displayed proudly on screens. Football stadiums with grass textures rendered in painstaking detail. Airports with realistic airplanes parked at the gates. Convention centers with every chair modeled individually. These were not quick sketches — they were works of art. And the companies that built them were proud of them.

Behind each of those models was a building modeling specialist — someone whose entire job was constructing these digital buildings, all day, every day. Some of them had been doing it for years. They knew every workaround, every trick, every keyboard shortcut to coax the tool into producing something it was never really designed to produce.

The Pain Nobody Questioned

The modeling tool wasn’t built for this level of detail. It was slow, tedious, and required specialized skill that took months to develop. A regular project — a hotel, an office building — could take two to three full days of work. A complex building — a stadium, an airport terminal, a museum with a spherical ceiling and crazy walls — could take one to two months. A truly herculean task.

But nobody complained. Not really. When I asked people about it, they’d shrug. This was the job. This is what building modeling looks like. You sit down, you draw walls, you place doors, you adjust dimensions, you wait for the tool to catch up, and you do it again tomorrow.

I’ve seen this pattern many times since, and it has a name: learned helplessness. When you’ve lived with a particular pain long enough, you stop recognizing it as pain. It becomes invisible. It’s just “how things are.” The specialists weren’t suffering in silence — they genuinely didn’t think there was a problem.

The Duct Tape

But when I pushed a little harder — “If you had a magic wand, what would you change?” — the answer was always the same: “If I could just import OBJ files, that would solve everything.”

OBJ is a basic 3D geometry format. Their idea was simple: model the building in some other tool that’s better at 3D, export it as an OBJ file, and import it into iBwave. It made intuitive sense. It was their duct tape — their imagined workaround for a problem they couldn’t fully articulate.

Here’s the thing about duct tape: it tells you something is broken. But the fix people propose is almost never the right solution. It’s a band-aid on a broken leg. The real question isn’t “should we support OBJ import?” The real question is “why are people spending days building something that should take minutes?”

Look Past the Workaround

This is the principle I rely on most in field research: when someone has duct-taped together their own solution — or is dreaming about one — don’t just note it. Dig deeper.

The workaround points at the problem. The problem points at the opportunity. And the opportunity is almost always bigger than whatever the user is asking for.

Users at iBwave were asking for OBJ import. What they actually needed was a way to get realistic 3D buildings into the system without spending days drawing them by hand. Those are very different things. OBJ import would have given them dumb geometry — walls and floors with no semantic meaning. What iBwave’s product actually needed was smart geometry: walls that know they’re walls, doors that know they’re doors, floors that know what level they’re on.

The Dig

I started researching every 3D engine and CAD platform I could find. Autodesk. SketchUp. Onshape. Shapr3D. Open source alternatives. This went on for about two years, on and off, alongside my regular design work.

Most paths were dead ends. A 3D engine could render beautiful buildings but couldn’t tell you what a door was. A CAD tool could model precise geometry but couldn’t export it in a format iBwave could consume. The open source options were too immature or too fragmented.

Then I found Autodesk Forge — now called Autodesk Platform Services. It was a cloud API that could ingest real architectural CAD files — the kind architects already create — and return semantic 3D data. Not just triangles and vertices. Door types. Wall materials. Floor boundaries. Room classifications. Exactly the kind of structured data that iBwave’s wireless planning algorithms needed.

The Wall

Finding the right answer was the easy part. The hard part — the part nobody warns you about — was convincing the organization.

I proposed rebuilding the modeling engine around this new approach. Rejected. Too risky. Too expensive. I proposed integrating an open source 3D library as a first step. Rejected. Not a priority. The product roadmap was already committed. The engineering team was already allocated. The leadership team had already told the board what they were going to ship.

This is the wall that every problem-finder hits eventually. You’ve done the research. You’ve found the answer. And the organization isn’t ready to hear it. Not because they’re stupid — but because the systems they operate within don’t reward this kind of thinking. They reward shipping what’s already planned.

The Sponsor

What finally moved the needle wasn’t my research, my prototypes, or my user stories. It was a sales manager.

He saw the demo I’d put together and immediately understood what it meant — not in UX terms, but in revenue terms. New clients who had been saying no because the onboarding process was too painful. Faster deployments that would reduce the sales cycle. A competitive advantage that no other vendor in the space had.

He became the champion. He didn’t talk about user pain or contextual inquiry or design thinking. He talked about money. And that’s the language the decision-makers spoke.

The lesson: when you’ve found the right problem, find someone who can translate your discovery into the language that moves the organization. You probably can’t do that translation yourself — and that’s fine. Find the person who can.

Five Minutes

Buildings that used to take two to three days were done in five minutes. Complex projects that took one to two months were done in ten. You could import an architect’s actual CAD file — the same file they designed the building with — and the system would automatically extract the floors, walls, doors, and rooms with all their properties intact.

At a product demo, the product manager imported the Burj Khalifa — one of the tallest and most complex buildings in the world — in about ten minutes. The room went silent. That same model would have taken a specialist over a month to build by hand. And the imported version was more accurate, because it came from the architect’s original data.

How to Spot Duct Tape

The duct tape is always there if you know where to look. Here’s what I watch for:

• Spreadsheets that supplement your software — when users maintain a parallel system in Excel, your product is missing something fundamental.
• Post-it notes on monitors — these are memory aids for things the software should handle but doesn’t.
• Scripts people wrote themselves — a user who learned to code just to work around your tool is screaming at you.
• Manual processes that “should” be automated — especially ones where people say “we’ve always done it this way.”
• Feature requests that are really workarounds — like OBJ import. The request sounds specific and reasonable, but the real need is something else entirely.

The duct tape is always there. You just have to be willing to see it, and willing to spend the time — sometimes years — understanding what it’s actually telling you.