Ask What Could Go Wrong, Not Just What It Does

Most software evaluations ask: “What does this platform do?”

A better question is: “Where could this platform fail us?”

Before recommending a software product, we think like a red team.

We look for:

• Features that look impressive but won’t actually be used
• Integrations that work in demos but create implementation headaches
• Pricing structures that become expensive at scale
• Manual processes hiding behind “automation”
• Security gaps buried beneath enterprise checklists
• Vendor dependencies that are difficult to escape
• Implementation assumptions nobody discussed during the sales process

Why this matters more than it sounds

This isn’t just a philosophy. The numbers back it up. Gartner research puts the failure rate for ERP implementations at 55–75%, meaning most large software rollouts don’t achieve their stated objectives. That’s not a niche problem with one category of software; it’s the norm for how these decisions tend to go when the evaluation stops at “what does it do.”

There’s a well-documented reason a “what could go wrong” mindset works better than a feature checklist. Cognitive psychologist Gary Klein popularized a technique called the pre-mortem: before committing to a plan, imagine it has already failed, then work backward to figure out why. Harvard Business Review has written about it as a way to surface risks that optimism and sales momentum tend to bury. The same logic applies directly to software evaluation. A demo is designed to make the product look inevitable. Asking “how could this fail us six months from now?” is what breaks that spell.

What this looks like in practice

A successful software purchase isn’t about finding the product with the longest feature list. It’s about finding the product with the fewest unacceptable risks.

That’s the difference between comparing software and actually evaluating it.

Don’t just ask vendors what their software can do. Ask what could go wrong. That’s where the real evaluation starts.