The sledgehammer I almost rebuilt on purpose

A simple two-question test for telling real competitive advantage from complexity that just happened.

I keep running into system owners who exhibit the instinct to preserve their business system exactly as it is, down to the smallest detail. When I ask why, the reason eventually comes back to is it feels safer than changing it.

I had that instinct myself recently while helping a consulting firm migrate their CRM from Salesforce to HubSpot.

The firm obsessively tracked revenue forecasts month by month for 18 months out, down to the exact dollar figure. In Salesforce, every single monthly payment on every deal was its own separate record. Even when the amount never changed and on retainers that renewed every year. They were using a sledgehammer to swat at flies.

My first instinct was to figure out how to rebuild that exact structure in HubSpot. That instinct was wrong.

This article explains why, and shares the two questions I now ask before rebuilding anything I inherit.

Why inherited complexity feels sacred

When you take over a system someone else built, the natural inclination is to preserve it as-is. The more complicated it is, the stronger that urge gets.

There are two reasons for that. One is fear. You don’t fully understand why it’s built this way, so changing it feels risky. The other is the assumption that if it’s complicated, it must be complicated for a reason.

That assumption is usually wrong. Systems rarely get complicated on purpose. They get complicated the way most unmanaged things do: one exception added on top of another, with no single moment where anyone stepped back and asked whether the whole thing still made sense.

To complicate things (pardon the pun) accumulated complexity and deliberate complexity look identical from the outside. Treating the first kind like the second is how you end up spending a week faithfully rebuilding something that never needed to be that complicated.

Let purpose guide your approach

The fix is a model built by Niel Nickolaisen, an IT leader and advisor, called the purpose-based alignment model. It sorts any business activity along two axes:

• Is it essential that the business does this at all? (mission critical)
• Does doing it well actually separate you from competitors or generate new business? (differentiating)

Cross those two questions and you get four categories:

The purpose based alignment model

So is precise, monthly, multi-year revenue tracking essential? Sort of — most businesses forecast in some form. Does doing it with that level of granularity win the firm new clients? No. Nobody hires a consulting firm because of how exact their internal revenue tracking is.

That combination lands it in parity, not because forecasting doesn’t matter, but because the level of precision wasn’t buying them anything.

Once I knew this was a parity activity, I stopped trying to replicate the old structure and started asking what they really wanted to accomplish with their revenue tracking and forecasting.

The finance team wanted usable forward visibility on revenue. They didn’t need the exact payment amount for every contract past the life of the contract. Standard HubSpot forecasting functionality, with a few minor adjustments, delivered the same visibility without the original complexity.

Use the purpose check to guide your actions

I call this the purpose check. It’s two questions, then an action:

Step 1: Is it essential that we do this? Yes → right side of the matrix. No → left side.

Step 2: Does this separate us in the marketplace, or help generate new business? Yes → top of the matrix. No → bottom.

Step 3: Act on where you land.

• Parity: Do we do this as well as our competitors? If not, close the gap — simply.
• Differentiating: Run the billboard test (below) before you commit to building it well.
• Who Cares: Can this be eliminated entirely, or does it just need minimal attention?
• Partner: Who is this differentiating for? Let them own it.

FAQ

How do I know if something is “differentiating” instead of just complicated? Use the billboard test. Picture the activity on a highway billboard, as the centerpiece of your advertising. If your company would never actually advertise the activity regardless of how complicated it’s become, it’s not differentiating. It’s parity.

The billboard test

What if someone insists their process really is a competitive advantage? Ask them to apply the billboard test. Most organizations only have one or two things that are genuinely differentiating; some have none, so the burden of proof is on the person making the claim.

Doesn’t simplifying something risk breaking what people are used to? Sometimes. That’s why a natural trigger, such as a migration or new integration is the right moment to ask, rather than auditing every system you own from scratch. You probably already know where the complexity lies.

Does this mean I should never innovate on internal systems? No. It means concentrating your best, most original work on the few things that actually differentiate your company, instead of spreading that same effort across everything that crosses your desk.

Get what you need without the gold-plated sledgehammer

The consulting firm still tracks and forecasts revenue today. They just don’t need a separate record for every identical monthly payment to do it. The precision they’d built wasn’t the advantage they thought it was. It was complexity that had accumulated unquestioned because nobody asked about it until the migration forced the question.

You probably have a version of this somewhere in your own systems right now. You don’t need to go find it today. But the next time something gives you a real reason to touch it, run it through the two questions first. Chances are, it’s simpler than you think it needs to be.

I publish a free weekly newsletter called InsideProduct for people who own systems, tools, and workflows in growing businesses. Subscribe here.