Call Us
How perfectly truthful answers can still lead you to buy completely the wrong software.
Picture this: You ask a software vendor whether their product can do something.
They say yes.
Six months later, after implementation, training, configuration and a moderately concerning number of spreadsheets, you discover it doesn’t do what you thought it did.
Did the vendor lie?
Probably not.
What tends to happen more often, is that you asked a perfectly reasonable question, they gave you a technically accurate answer, and you were both talking about completely different things.
This is one of the trickier parts of software selection. Words like integration, automation, customisable and supported sound reassuringly specific, while leaving enormous room for interpretation.
The good news is that there’s a simple way to cut through the confusion.
Imagine you’re evaluating a new CRM and ask whether it can automatically assign new enquiries to the right salesperson.
The vendor says yes.
Excellent. Tick the box.
Except… there are three very different versions of “yes”.
The software can technically be made to do it, perhaps using an API, additional software, development work or consulting.
Feature: How does the product do it?
The product has functionality designed for the job, but it may come with limitations, configuration requirements or additional licensing.
Once implemented with your people, processes, data and other business systems, will enquiries reliably reach the correct salesperson without manual intervention?
That last question is usually what you actually care about.
Buyers tend to think in outcomes. Vendors naturally talk about their product’s capabilities and features. Neither side is necessarily wrong, but the gap between them can become very expensive.
One of the most dangerous questions in software selection is:
“Can it do X?”
That is usually a capability question, when what you really want to understand is whether the software will achieve a particular business outcome.
Take integration. A vendor saying their software “integrates” with your accounting system might mean there’s a polished native connection. It could also mean there’s an API available for someone to build one. Both might technically qualify as integration.
Instead of debating definitions, get specific:
Software demos are lovely places.
Data is clean. Approvals happen promptly. Customers provide the right information. Nobody accidentally creates the same company three times.
Your business, unfortunately, does not live in a software demo.
A standard demonstration can prove that a feature exists. It doesn’t prove that your desired outcome will be achieved.
The real cost and complexity of business systems often lives in the awkward 20 per cent: exceptions, mistakes, unusual customers and processes that refuse to follow the nice straight line on the diagram.
So bring reality into your software selection process.
Ask vendors to demonstrate your actual scenarios, including the messy ones. What happens when information is missing? What if someone makes a mistake halfway through? How does the system handle your unusual but important exceptions?
Don’t just sit through their perfect demo. Ask them to show you the outcomes using your own business logic.
There’s a handy resource for you at the bottom of this article.
Another common problem starts with the requirements themselves.
These describe functionality, but they don’t explain what success looks like.
A requirement might say: “Users can export customer records.”
Technically, an Export button producing a gigantic file could satisfy that requirement.
But perhaps what you actually need is for account managers to quickly and safely export the information they can see, in a format they understand, without exposing confidential fields.
That’s an outcome.
When designing strategic business systems, don’t just document what the technology needs to do. Describe what a successful result looks like for the person using it.
You don’t need another spreadsheet containing 300 requirements. And you certainly don’t need to become a technical expert before you’re allowed to buy software. But you do need to ask the right questions.
For every important requirement, move through at least three questions:
Remember: “yes, our software can do that” and “yes, this will work the way your team needs it to” are two very different promises.
A handy resource for you is the Strategic Pre-Demo Playbook. With it, you can flip the script on software demos: walk in prepared, walk out with clarity
If you’re trying to choose software and aren’t sure whether you’re evaluating features or designing the right strategic business systems in the first place, book a complimentary Systems Concierge Call with our Systems experts.
We’ll help you step back from the feature lists, clarify the outcomes your business actually needs, and build a clearer path towards technology and people working in harmony.
