Everyone’s AI roadmap probably has 15 features marked ‘high priority.’ Most of them shouldn’t be built at all.

Here’s what usually happens in planning sessions. Teams present their initiatives: sentiment analysis for customer feedback, predictive churn modeling, a recommendation engine, generative content suggestions. The list is ambitious and impressive.

Then someone asks the critical question: “Which of these actually solves a problem we can measure?” They’ve been so focused on capabilities that they forgot to validate whether any of this creates measurable value. Sentiment analysis sounds innovative, but they already know which customers are unhappy (they’re the ones canceling). The recommendation engine is elegant, but customers aren’t asking for recommendations; they’re asking for better search.

They were building features instead of solving customer problems.

This pattern repeats more often than I’d like to admit. I’ve been part of these sessions too. RAND Corporation research from August 2024 found that more than 80% of AI projects fail—twice the rate of failure for information technology projects that don’t involve AI. Understanding how to translate AI’s enormous potential into concrete results remains an urgent challenge. AI becomes the giant “solution hammer” looking for “problems.”

We’ve discussed economics and hidden costs and API-first architecture patterns. Now let’s talk about the decision that comes before all of that: whether to build at all.

The Build vs Buy vs Skip Framework

Here’s a simple framework that I’ve adapted over the past couple of years when teams ask about “the AI” and using it for new features. Like any product leader, I love a good set of questions.

1. Can you solve this without AI?

Most problems don’t need machine learning. They need better data, clearer workflows, or simpler user interfaces.

A fintech team I worked with wanted to predict which transactions are fraudulent. Sounds reasonable, except the actual problem was that legitimate transactions were being flagged because the rules were too broad. They don’t need ML models; they need better rule tuning and customer communication.

Think about a support team that wants a chatbot to handle common questions. The real problem? Documentation is scattered across six different tools and nobody can find answers. They need information architecture, not artificial intelligence.

2. If AI makes sense, can you buy it?

Building infrastructure is expensive. Buying works when the problem is common across industries, you need results quickly, or the differentiation isn’t core to your business value.

A recruiting platform wanted automated resume screening. They could have built it (they had the data and talent), but instead bought an existing solution for $50/month per user. It worked well enough, and they spent their engineering capacity on features that actually differentiated their product. (For more on navigating build vs buy decisions, see Breaking Free from ‘Not Invented Here’.)

Building makes sense when the problem is unique to your domain, existing solutions don’t handle your specific constraints, or the capability is core to your competitive advantage.

That aviation decision engine I mentioned previously? They built it. Risk assessment in aviation has unique requirements that generic solutions don’t handle. Plus, the accuracy and explainability of their recommendations was their primary competitive advantage.

3. If you’re building, can you validate cheaply?

Before committing to full infrastructure, prove the value with the minimum viable version.

A healthcare analytics team wanted predictive models for patient outcomes. Instead of building a full ML pipeline, they started with simple statistical analysis using existing tools. Once they proved the insights were actionable and doctors would actually use them, then they invested in sophisticated models.

The Hidden Cost of “Innovation Theater”

The real cost of unnecessary features isn’t the development time but the opportunity cost of what you didn’t build instead.

I’ve seen teams spend six months building sophisticated recommendation engines when their users just wanted better filtering. The technology worked perfectly, but it solved the wrong problem.

Starting With Your Next Decision

You don’t need to evaluate your entire backlog this week. Start with your highest priority initiative and work through these questions in order:

Can we solve this without AI? Write down three simpler ways to address the underlying customer problem. If any of them work, start there.

If sophisticated technology makes sense, can we buy it? Identify whether this is a common problem with existing solutions, or truly unique to your domain. Don’t build unless building gives you real competitive advantage.

Can we prove value cheaply? Define how you’ll validate that people will actually use this before building full infrastructure. What’s the minimum viable version?

If you can’t write clear answers to all three, you’re not ready to build. If the answers fall apart when you present them to skeptical executives or have to defend them in a budget review, you’re really not ready.

Most roadmaps would be cut in half if teams honestly answered these questions, and that’s not a failure but focus.

The best strategy isn’t about maximizing features, but about maximizing the ratio of value created to resources invested. Sometimes that means building sophisticated systems. Often it means solving the problem more simply.

What’s on your roadmap right now that you’re building because it seems innovative rather than because it solves a validated customer problem? That’s where you start cutting.