When Excel Wins: Why Your Spreadsheet Might Be Better Than Enterprise Software

Navision CRM was one of the most brilliant products I ever saw.

Not because it was technically sophisticated. Not because it had every feature imaginable. But because it understood something fundamental: solving a real problem simply beats solving a hypothetical problem perfectly.

The Navision Story

The first time I installed Navision’s CRM module at my company, I was underwhelmed.

Literally, it was a table with filters. Not even complex filters—just basic SQL-style filtering. You could manage your customer relationships in an Excel spreadsheet shared across your team, and honestly, you wouldn’t lose much functionality.

But there was something magical about it.

It worked. It was reliable. Your salespeople could actually use it. And it did exactly what they needed: keep track of customers and deal status.

Nothing more. Nothing less.

The Zoho Comparison

Fast forward a few years. Zoho came along with an ambitious vision: build a CRM with more features than anyone else. More customization. More integrations. More analytics.

On paper, Zoho was better. Way better.

In reality? It was buggy at launch. The interface was confusing. You needed training to use it. And for most small businesses, 80% of the features they’d never touch.

Navision won not because it was better. It won because it was enough.

What Google Docs Taught Us

The same lesson played out with Google Docs.

Microsoft Word was the king—overstuffed with features, powerful, but bloated. Editing documents was a technical skill. The barrier to entry was high.

Google Docs showed up and said: “What if we made an editor that just… worked?”

In the first version, you couldn’t even add page numbers. Major features that Word users took for granted—gone. The internet mocked it. “This is not a real word processor.”

But something happened: a non-technical person could open Google Docs and start writing. No installation. No learning curve. No overwhelming menu bars.

Fast forward to today, and Microsoft Word is struggling to stay relevant. Google Docs doesn’t have every feature. It never will. But it has the features that matter to the majority of users, and it’s accessible enough that everyone uses it.

The PM Principle

Here’s what separates good PMs from mediocre ones:

Mediocre PMs think: “What features do we need to compete?” Good PMs think: “What’s the smallest set of features that solves the actual problem?”

Mediocre PMs build for a hypothetical future user with hypothetical needs. Good PMs solve for the actual user with actual problems today.

When Navision shipped a “table with filters,” they weren’t lazy. They’d thought deeply about what salespeople actually did. They’d stripped away everything that wasn’t essential. They’d nailed the basics.

That’s harder than adding features. It’s easier to add another button than to decide which buttons you don’t need.

The Cost of Completeness

Here’s the trap: completeness is expensive.

It costs:

• More engineering time to build
• More QA time to test
• More documentation to explain
• More training for users to learn
• More maintenance as features interact in unexpected ways
• More UI real estate, making core features harder to find

Every feature you add makes your product more complex. Every complexity costs you users who don’t want that complexity.

Zoho spent months building the “complete” CRM. Navision spent months figuring out what to not build.

Navision won.

The Navision Decision Tree

When a Navision PM looked at a feature request, I imagine they asked:

• “Does this solve a core problem?”
• “Can 80% of our users benefit from this?”
• “If we don’t build this, will customers leave?”
• “Can this wait six months?”

If the answer to any of those was “no,” it didn’t make the cut.

That’s discipline. That’s product thinking.

Most companies? They asked: “Could someone use this?” And if the answer was yes, they built it.

The Lesson for Your Product

If you’re building a product—any product—the temptation is always toward completeness. Toward being the “everything solution.”

Slack could have built a complete replacement for email. Instead, they asked: “What’s one thing we can do better than email?” Answer: instant messaging for teams. Done. That’s all it did at first.

Stripe could have built a payment processing platform that replaces every legacy processor. Instead, they asked: “What’s the simplest API for accepting payments?” And they nailed that before adding everything else.

What This Means for Your Career

If you’re a PM breaking into the industry, memorize the Navision lesson: Simple solves. Complex confuses.

When you’re debating features with your team, ask the hard questions:

• Who actually needs this?
• What problem does it solve?
• What happens if we ship without it?
• How does this make our core offering better?

If you can’t clearly answer those questions, it probably shouldn’t ship.

Your first version won’t have everything. That’s not a failure—that’s a feature. It means you’ve thought about what matters.

Navision understood something that still applies today: you don’t win by having the most features. You win by solving the problem your customer actually has, in the simplest way possible.

Everything else is nice to have.