You Bought a Box of Car Parts. Now What? (the SaaS problem)

SaaS tools promise simplicity. But when you're building for a team, you're not buying a car — you're buying 300,000 Legos with no instructions.

There was a time when software came on a disc. You bought it at Circuit City, you installed it, and that was what you got. No updates, no configuration options, no cloud. If it broke on arrival, you were just out of luck.

That world is gone. In its place: hundreds of SaaS tools in every vertical, pushing updates daily, configured differently for every team, and presenting themselves as the easiest solution to all your problems. The gap between that promise and reality is exactly where process debt is born.

The Lego Problem

Monday.com, Asana, ClickUp — these tools market themselves as intuitive. And for a single user, they often are. But the moment you add a second or third person, you're now dealing with the least technically fluent person on your team setting the pace.

What looks like a simple six-piece Lego set at signup is actually a bucket of 300,000 pieces. The tool will let you build almost anything — which means it will also let you misconfigure almost anything. Without a game plan, you'll do exactly that.

The Requirements Trap

Here's the core problem with most SaaS implementations: people's requirements are based on the bad system they're leaving. They don't describe what they need in the abstract. They describe what they had before — in exhausting detail.

"We need notifications." Why? "Because when a status changes, we need to send an email." Why? "Because we do all our work in email."

Suddenly you realize the real system of record was Outlook all along, and nobody said it out loud. The requirements weren't about the new tool — they were a map of the old one.

The Car Analogy That Actually Works

When someone walks into a dealership, they don't open with: "I need a low-fuel warning light and an arrow showing which side the gas cap is on." They say: "I need a truck," or "we just had another kid, I need a minivan."

They think in terms of use and outcome, not features. But in technology conversations, that instinct disappears. People anchor on the last tool they used and try to replicate its feature set in the new one — rather than asking what job they're actually trying to do.

Push First, Then Pull Back

Chris's counter-intuitive approach: push people into the tool before trying to pin down requirements. Until someone has driven the car, asking them what they want in a car is academic.

The pattern that works: lean into the feature set, let people experiment, watch what they actually use versus what they ignore, and then mature the process around real behavior — not hypothetical preferences. It's how the best SaaS implementations evolve.

The Zoom Waiting Room Confession

Even highly technical people get tangled in SaaS configuration. Chris — self-described as developer-adjacent — spent a month accidentally sending everyone to a Zoom waiting room because removing the passcode requirement quietly enabled a different restriction. One setting silently overrode another.

The lesson isn't that the tool is broken. It's that modern SaaS complexity is genuinely hard to navigate, even for people who should know better. Assuming your team will figure it out on their own is not a strategy.

The Three Things You Actually Need

Before any tool goes live for a team, three elements have to be in place:

• The right people at the table — not just IT, but the people who actually do the work and the people who can make decisions about it.

• Agreement on the process in the abstract — not which button to click, but what everyone's job is in the workflow, in plain language.

• An executive sponsor who requires value — without someone at the top demanding the tool be used and producing results, every implementation quietly dies.

Skip any of these and you're not implementing software. You're just buying a very expensive organizational habit you'll never develop.

Sharp Rocks

Back on the Savannah, early humans didn't make sharp rocks because they looked pretty. There was a purpose. Software should work the same way — it should assist, not just exist.

If your tool isn't helping, it's because the process was never defined clearly enough to build into it. The solution isn't a better tool. It's a better conversation about what you're actually trying to do.