Lessons in product engineering from a low-clearance bridge

Tiny adjustments to software can lead to meaningful behavioral shifts downstream. How do world-class innovation teams navigate this complexity?

Near my house, there’s a covered bridge which has always displayed its clearance height. But trucks would occasionally hit it, so the town recently decided to get more aggressive — by adding a dangling clearance marker that physically hangs a few inches below the bridge itself.

The recycling truck that comes through every week has always fit just fine under the structure. But now? It can’t get past the dangling clearance marker.

The result? A routine that worked perfectly for years suddenly hit a roadblock — not because of some major change, but because nobody considered the potential negative consequences of adding this seemingly helpful and benign marker.

For me, this was a perfect analogy for software product engineering. Just like that clearance marker, seemingly minor bug fixes or improvements can create ripple effects that disrupt user workflows in ways we don’t anticipate.

Software is used in the wild

Tiny adjustments to software can lead to meaningful behavioral shifts downstream. This is especially true in enterprise environments, where users often rely on complex and rigid processes. Changes — no matter how minor they seem — can catch users off guard, leading to significant frustration.

In the case of the bridge, no one checked the height of the neighborhood recycling trucks. No one communicated the addition of the clearance marker to the key "stakeholders". Sound familiar? Too often in product engineering, we overlook the broader impact of a change because we’re focused on the specs, not the humans.

How to avoid the “clearance marker moment”

So, how do great engineering, product, and design teams avoid the clearance marker moment? By abiding by a few key principles:

1. Engage key stakeholders early: Especially in enterprise software, involve users, admins, and partners in your planning. Their input can help you identify potential pain points you might miss.

2. Put yourself in the user’s shoes: Step back and think about how your users interact with your product in the real world. What workflows, tools, or systems depend on the change you’re making?

3. Test for edge cases: Just because something works in theory — or in your testing environment — doesn’t mean it will work for every user. Account for those “recycling truck” scenarios.

4. Communicate proactively: If there’s even a hint that your change might cause confusion, over-communicate. This includes announcements, user guides, and contextual messaging within the product itself.

5. Experiment: In a software context, experiments can be run on small segments of users. Consider rolling out changes slowly so that you can monitor impact.

Promoting trust

Bottom line, users need to feel confident that your product won’t throw them curveballs, especially in environments where reliability is critical. Every time you dangle a clearance marker in their previously uninterrupted path, it puts a dent in their relationship with your product.

So the next time you’re debating a minor change, ask yourself: “Is this a bridge that’s in the user’s critical path?” If the answer is yes, make sure you’re considering the vehicles that actually cross it — not just the ones you originally designed for.

---