A Technology Roadmap Isn't a Project List. It's a Business Commitment.

What 25 years of leading technology, digital commerce, and business transformation have taught me about investing in the right things.

I've seen technology roadmaps that look great in a board presentation. They have timelines, milestones, color-coded initiatives, and enough projects to keep an IT organization busy for years. ERP modernization. CRM improvements. Data platforms. Automation. And lately, AI seems to appear on almost every roadmap.

But there's a question I always come back to: If we deliver everything on this roadmap, how will the business actually be better?

After more than 25 years leading technology, e-commerce, and business operations, I've learned that the best roadmaps aren't built around technology. They're built around business outcomes. And getting there requires a different way of thinking about priorities, investment, and accountability.

The difference between implementing technology and creating value

One of the experiences that shaped my thinking was helping build SlimFast's direct-to-consumer business. When we started, annual e-commerce revenue was approximately $2 million. By 2021, it had grown to more than $40 million.

That kind of growth doesn't happen because you launch a new website. It requires an entire business operation working together. We had to think about the customer experience, digital marketing, commerce technology, data, fulfillment, and the operational processes behind every order.

Each of those areas presented opportunities for technology investment. But the objective was never simply to implement more systems. It was to build a business that could acquire customers, fulfill orders, support growth, and operate efficiently as volume increased.

A new commerce platform might be necessary, but the platform itself isn't the result. The result is what the business can accomplish because of it. Looking back, that's one of the clearest examples of what a technology roadmap should do: connect a series of technology and operational decisions to a measurable business objective.

Start by understanding the problem

I've found that technology discussions often begin with a proposed solution: “We need a new ERP.” “We should replace our CRM.” “We need an AI strategy.” Maybe those things are true. But before committing to any of them, I want to understand what's happening in the business.

Are employees spending too much time entering orders manually? Is inventory information unreliable? Does finance struggle to close the books? Are sales teams missing opportunities because they don't have a complete view of the customer? Those are problems worth solving.

Sometimes the solution is new technology. Other times, the problem is a process that was never standardized, information that isn't trustworthy, or a system the company already owns but isn't using effectively.

I've seen enough implementations to know that replacing a system doesn't automatically fix the problems underneath it. Without addressing those issues first, companies often spend significant money recreating the same problems on a newer platform. That's why I begin with a clear picture of the current operation and a measurable definition of what needs to improve.

The CFO and CIO should be having the same conversation

Technology leaders and financial leaders naturally approach investments from different perspectives. The technology team sees architecture, integration, security, scalability, and technical debt. The CFO sees cost, cash flow, margin, risk, and return. A good roadmap connects those perspectives.

If we're automating a process, how much time will we save? If we're consolidating applications, what operating costs can we eliminate? If we're improving the customer experience, what effect should that have on conversion, retention, or revenue?

Not every investment produces an immediate financial return. Security, resilience, compliance, and risk reduction are legitimate business priorities. But every major investment should have a clear reason for existing and a way to determine whether it achieved its objective.

I want technology leaders to be comfortable explaining their plans in business terms. And I want financial leaders to understand that some of the most important investments create the foundation for future growth rather than immediate savings. The best outcomes happen when both sides are working from the same priorities.

Acquisitions taught me to think beyond the implementation

Another experience that influenced my approach was working through private-equity transactions and post-acquisition integration. These environments change how you think about technology.

When a business is acquired or integrated, decisions that may have been deferred for years suddenly become urgent. Which systems should remain? Which should be consolidated? Where does critical business information live? Are processes consistent across the organization? How much operational risk exists in legacy applications or undocumented dependencies?

These aren't just IT questions. They affect the cost of integration, the ability to operate the combined business, and how quickly the organization can realize the value expected from the transaction.

They also expose something easy to overlook during normal operations: the cost of technology decisions isn't limited to what you spend implementing them. It includes what those decisions make easier—or harder—to accomplish later.

A fragmented technology environment can slow integration and increase risk. A well-managed environment, with documented systems, clear ownership, reliable data, and sensible architecture, gives the business more options.

That's especially important in private-equity-backed companies, where the investment horizon creates pressure to deliver results within a defined period. The roadmap needs to connect technology priorities to growth, margin improvement, operational efficiency, risk reduction, and the broader value-creation plan.

You have to earn the right to do the next project

One of the biggest mistakes I see in technology planning is trying to do too much at once. Most organizations have more ideas than resources to execute. There's always another system to improve, integration to build, report to automate, or emerging technology worth exploring.

But when everything becomes a priority, execution suffers. I believe in choosing a manageable number of initiatives, delivering meaningful progress, and using the results to inform what comes next.

That doesn't mean abandoning long-term planning. Companies need a clear direction for the next 18 to 36 months. But I prefer investment decisions in shorter increments, often around 90 days, with defined milestones and measurable outcomes.

What did we deliver? What changed in the business? What did we learn? Does the next investment still make sense? That creates accountability without locking the organization into assumptions that may no longer be valid.

Sometimes the right decision is to stop. A project that isn't producing value shouldn't continue simply because the company has already spent money on it. The goal is to improve the business, not protect the project plan.

AI makes the fundamentals more important, not less

AI has brought renewed attention to technology strategy, and for good reason. The opportunities are significant. But there's a risk in treating AI as something separate from the rest of the technology environment.

A company may want an AI assistant that can answer questions about contracts, customers, operations, or financial performance. But what happens when information is scattered across systems, documents are outdated, access permissions are inconsistent, or nobody agrees on which source is authoritative?

AI doesn't make those problems disappear. In many cases, it makes them more visible. That's one reason I've become increasingly interested in document architecture, information governance, and the data foundations required for reliable AI.

Before investing heavily in sophisticated AI capabilities, companies need to understand the information and processes those capabilities depend on. That doesn't mean waiting until everything is perfect. It means choosing practical use cases, understanding dependencies, putting controls in place, and measuring results.

AI should be part of the business roadmap, not a separate collection of experiments disconnected from operational priorities.

Business ownership matters as much as technical execution

Technology teams can implement systems, build integrations, and create capabilities. But they can't independently deliver business adoption.

If we're improving order management, operations needs to be accountable for the outcome. If we're changing financial reporting, finance needs to define success. If we're improving customer acquisition, commercial leadership needs to own the results. Those responsibilities should be established before implementation begins.

I've also found that a smaller, focused team with clear accountability can often accomplish more than a large program with complicated governance and unclear ownership. Deliver something useful, measure the impact, and build on what works.

What I look for in a technology roadmap today

When I review a roadmap, I'm less interested in how many initiatives it contains and more interested in whether leadership can answer a few important questions.

What business problem are we solving? What is the expected outcome, and how will we measure it? Who owns that outcome? What needs to happen first? How much are we willing to invest before evaluating the results? What will we do if the assumptions change?

I also want to see the relationship between foundational work and more visible initiatives. Reliable systems, clean data, well-managed information, security, and integration architecture may not be the most exciting investments in a board presentation. But they're often what makes everything else possible.

The result matters more than the technology

Looking back at the businesses and transformations I've been involved with, the most meaningful accomplishments weren't defined by the technology we implemented. They were defined by what the business was able to do afterward.

At SlimFast, that meant building and scaling a substantial digital commerce operation. In acquisition and integration environments, it meant understanding how technology decisions affected the ability to operate, integrate, and move the business forward.

Different challenges, but the same principle: Technology is an investment in business capability. The roadmap should explain how that investment turns into results.

So before approving another long list of initiatives, I'd ask: If we execute this plan successfully, what will be measurably different about the business? If everyone in the room can answer, you're probably building the right roadmap. If they can't, there's more work to do before the first project begins.