Root Cause Thinking: Why We Build From First Principles

Every product we've shipped started the same way. Someone on the team hit a problem, looked for a tool to solve it, and found every option treated a symptom instead of the cause.

Fleet management tools showed where trucks were, but not why routes kept failing. Developer dashboards counted deploys, but not whether engineers were burning out making them. The market had dashboards. It didn't have understanding.

The five whys, applied to software

Borrowed from manufacturing, the five whys is simple. When you find a problem, ask why it exists. Then ask why again. Repeat until you hit something fundamental.

For FleetOS, the chain looked like this. Deliveries are late because routes are inefficient. Routes are inefficient because they're planned on stale data. The data is stale because dispatch runs on spreadsheets updated once a day. That happens because nobody built dispatch tooling for small fleets, only for enterprise giants.

That last sentence is the root cause. Everything in FleetOS flows from solving it.

What this means in practice

Building from first principles is slower for the first two weeks and faster forever after. When your product attacks the actual cause, features fall into place naturally instead of getting bolted on.

It also means we say no a lot. A feature addressing a symptom gets cut in review, even when it would demo well.

Try it on your own roadmap

Take the next feature on your list and ask why it needs to exist five times. If you can't reach a statement about a fundamental problem, you've found a symptom. Probably a candidate to delete too.