Three Questions Before Any Technology Decision

I watched an oil and gas services company spend $12 million on an ERP system that promised to "transform their operations." Two years later, they paid consultants another $8 million to customize it into something that worked for their business.

The problem wasn't the software. The problem was that nobody asked the right questions before buying it.

After 20 years building platforms for millions of users and leading technology decisions at Microsoft, I've seen this pattern everywhere. Teams pick tools first, then try to force them to solve problems. Smart leaders do something different. They ask three specific questions before any technology choice.

These questions have saved companies millions and prevented countless failed projects. More importantly, they help you make decisions that solve real problems.

Question 1: What Problem Are We Actually Solving?

Most technology discussions start with solutions. "We need a data warehouse." "We should move to the cloud." "Everyone's talking about AI."

Stop. Back up. What specific business problem are you trying to fix?

When I worked with a major retailer on their cloud migration, their initial request was simple: "We want to move everything to Azure." When I dug deeper, the real problem emerged. Their inventory system couldn't handle Black Friday traffic spikes. They needed better performance during peak periods, not a wholesale platform change.

We solved their actual problem with targeted improvements to their existing infrastructure. The fix cost $200,000 instead of the $2 million cloud migration they originally planned.

The difference between a problem and a solution request is everything. "Our reports take too long to run" is a problem. "We need a data warehouse" is a solution. Problems tell you what success looks like. Solutions lock you into one specific path.

Here's how to find the real problem:

Use the Five Whys technique. If someone says they need better analytics, ask why. They might say reports are slow. Ask why again. Maybe the database is overloaded. Keep going until you reach the root issue. This method, developed by Toyota, helps you dig past symptoms to find real causes.

Focus on outcomes, not features. Instead of "we need real-time data," try "we need to respond to customer issues within 10 minutes." The first locks you into expensive streaming technology. The second opens up multiple solutions.

Document the pain points in detail. What exactly happens when things go wrong? How much does it cost? How often does it happen? Numbers make problems concrete and help you measure success later.

Question 2: What Happens If We're Wrong?

Every technology decision is a bet. Sometimes you win, sometimes you lose. The question is: can you afford to lose?

I've seen companies bet everything on a single platform choice, only to discover six months later that it won't scale, integrate, or perform the way they expected. The cost to change course can be devastating.

Consider a mid-size company that chose a cloud platform based on low initial costs. Two years later, they discovered that moving their data elsewhere would cost $500,000 in egress fees. They were trapped paying increasingly high bills for a platform that no longer met their needs.

Calculate the real cost of being wrong. This includes:

Money to switch platforms or rebuild systems. License costs for software you can't use. Lost productivity during transitions. Opportunity cost of delayed projects.

Time to implement a different solution. Most platform switches take 6-18 months. Can your business wait that long if the current choice doesn't work?

Political and career impact. Failed technology projects damage reputations and relationships. Factor this into your risk assessment.

The ERP trap is the perfect example of ignoring this question. Companies spend millions customizing enterprise software to fit their unique processes. When they finally want to switch, they discover that all those customizations are worthless. They're locked into a system that may not even exist in five years.

Before making any major technology decision, run a simple exercise. Assume your choice fails completely six months from now. What would it cost to fix? If the answer makes you uncomfortable, you need a different approach.

Question 3: How Do We Get Out?

This is the question nobody wants to ask. Everyone hopes their technology choices will last forever. They won't.

I learned this lesson early in my career when I helped a company migrate off a mainframe system they'd been using for 15 years. The system worked fine, but the vendor was discontinuing support. The migration took three years and cost $40 million because they'd never planned for an exit.

Smart leaders always have an exit strategy. Not because they expect to fail, but because it keeps their options open.

Here's what a good exit strategy looks like:

Keep your data in standard formats. Use open standards like JSON, XML, or industry-standard database formats. Avoid proprietary file types that only work with one vendor. Make sure you can export your data in formats that other systems can read.

Document your integrations and customizations. When you eventually migrate, this documentation will save months of detective work. Include not just what you built, but why you built it.

Build abstraction layers between your core business logic and vendor platforms. This is where architectural patterns like the Adapter Pattern, Repository Pattern, and Anti-Corruption Layer become crucial. If you're using a cloud service, wrap it in your own API using these patterns. When you switch providers, you only change the wrapper, not your entire application.

Negotiate contract terms that protect your ability to leave. Include data export clauses, reasonable notice periods, and limits on switching costs.

Test your exit strategy regularly. Run small experiments, moving non-critical data or processes to alternative platforms. You'll discover problems while they're still cheap to fix.

The companies that survive technology transitions are the ones that plan for them. They treat vendor relationships as partnerships, not marriages.

The Three-Question Framework

Before your next technology decision, use this simple framework:

Problem Definition Meeting: Spend an hour defining the actual business problem. Write it down in one sentence. Make sure everyone agrees before looking at any solutions.

Risk Assessment: Calculate the cost of being wrong. Include money, time, and organizational impact. If the risk is too high, look for smaller steps or proof-of-concept approaches.

Exit Planning: Document how you'll get your data and functionality back if things don't work out. Include this in vendor negotiations and project planning.

Most teams skip straight to comparing features and prices. That's backward. Features don't matter if you're solving the wrong problem. Price doesn't matter if you can't afford to be wrong.

Start With Problems, Not Solutions

Technology decisions shape your company's future. They determine how fast you can move, how much you'll spend, and what opportunities you can pursue.

The companies that make good technology decisions don't have better engineers or bigger budgets. They have better questions.

Next time someone suggests a new platform, database, or service, pause. Ask what problem it solves. Calculate the cost of being wrong. Plan your exit before you commit.

Your future self will thank you.