When I worked with Zmags on their go-to-market strategy, the company was in the middle of a transformation they were not fully naming as such. They had built a digital publishing platform for print media companies making the transition to digital. Their customers were doing digital transformation whether they were ready or not - the shift from print to digital was not optional for magazine publishers in 2009. What Zmags was selling was not just software. It was a path through a transformation that their customers found genuinely disorienting.
The insight that changed how we positioned the product: the customers furthest into the transformation were the easiest to sell to because they had already accepted the reality of what was happening. The ones who were resisting were not resisting Zmags. They were resisting the transformation itself. The sales and marketing work was not primarily about the product. It was about helping customers accept the transformation before we could sell them the tools to execute it.
I ran into the same dynamic at Surround Insurance. The insurtech category was itself a transformation story - incumbent carriers doing things the traditional way, a new generation of digital-first platforms rewriting how insurance was bought and serviced. The customers Surround was targeting were not just buying a new insurance product. They were participating in a transformation of how they related to insurance as a category. The companies that won in that environment understood they were selling a transformation narrative as much as a product.
Digital transformation is one of the most over-used and under-delivered initiatives in business. Organizations spend heavily on transformation programs and measure progress in activities rather than outcomes: how many employees trained, how many legacy systems replaced, how many new tools deployed. The ones that produce genuine change measure something different: what can the organization do now that it could not do before.
The 70% failure rate cited in transformation research isn't a mystery. It's the predictable result of treating organizational change as a software deployment. You can deploy software on a timeline. You can't deploy behavior change on one.
At AMC, the Appalachian Mountain Club, I'm currently leading a digital transformation of the membership platform. The technical scope is well-defined: migrate from a legacy system to Nimble, integrate the Outdoor Connector, connect Salesforce. But the transformation work - the part that determines whether the new platform actually changes how members experience the organization - is happening in workshops with chapter leaders, in requirements conversations with volunteer coordinators, in governance decisions about who owns what data. The technology is maybe 30% of the work.
Technology is maybe 30% of a digital transformation. The other 70% is the organizational change work that most transformation plans don't account for, don't budget for, and don't staff for.
The Vision-Execution Gap
The most common failure point is the gap between the executive vision and what the people doing the work understand about how their jobs will change. I've seen transformation initiatives announced with compelling vision decks and no follow-through on the 'what does this mean for you specifically' question. That gap fills with speculation, and speculation is almost always worse than the reality.
| Failure Point | Underlying Cause | Roadmap Solution |
|---|---|---|
| Lack of Clear Vision | The "why" is not communicated or understood across the organization. | Start with a clear, compelling vision statement. Define what success looks like in concrete business terms, not just technical milestones. |
| Employee Resistance | Fear of the unknown, job insecurity, or lack of involvement in the process. | Integrate a comprehensive change management plan. Involve employees early, communicate transparently, and create feedback loops. |
| Poor Executive Sponsorship | Leadership is not actively or visibly championing the initiative. | Secure a dedicated executive sponsor who will remove obstacles, communicate progress, and hold teams accountable. |
| Siloed Execution | Departments work in isolation, leading to fragmented efforts and incompatible tech. | Create cross-functional teams from day one. Ensure the roadmap is a shared document that aligns all departmental goals. |
| Ignoring Skill Gaps | Teams are expected to use new tools without proper training or support. | Include a dedicated workstream for upskilling and training. Conduct a skills gap analysis and budget for necessary education. |
| No Quick Wins | The project is too long-term, causing a loss of momentum and stakeholder buy-in. | Structure the roadmap to deliver tangible, small wins early and often. This builds confidence and demonstrates value quickly. |
Ignoring Culture
Technology doesn't transform organizations. People do. And people change their behavior when they understand why the change matters to them personally, when they have the skills to operate differently, and when the incentives and environment reinforce the new behavior. If any of those three conditions are missing, the transformation installs new tools and leaves the old organization intact.
Building a Shared Vision That Actually Travels
A transformation vision that exists only in a slide deck isn't a vision - it's a communication artifact. The test is whether the people who need to execute the transformation can articulate it without the deck. That requires a different kind of engagement than a town hall announcement.
At EnergySage, aligning the product and engineering organizations around a platform migration required a sustained narrative effort that went well beyond a single launch communication. We ran working sessions by function, translated the platform change into specific workflow changes for each team, and built a coalition of people from different departments who could speak to the change from their own perspective. That coalition was more valuable than any communication we produced centrally.
| Audience | Key Message | Best Channel |
|---|---|---|
| Executive Leadership | How the roadmap hits financial goals and secures our market position. | Board meetings, monthly business reviews, detailed reports. |
| Middle Management | How these changes help them crush their department's targets and make their teams more effective. | Departmental meetings, dedicated workshops, one-on-one check-ins. |
| Frontline Employees | What’s in it for them-how new tools cut out tedious work, make their day smoother, and help them win. | All-hands meetings, team huddles, internal newsletters, video demos. |
A vision that requires the executive to be in the room to explain it is a vision that won't survive execution. The goal is a story that travels without you.
Mapping Your Current State
Transformation plans that skip the current state assessment are building on assumptions. The gap between what leadership believes about how the organization operates and how it actually operates is almost always significant, and it's always larger in the areas where the transformation is most ambitious.
The current state work I find most valuable isn't the technology audit - that's relatively straightforward. It's the process audit: how does work actually flow through the organization, who makes which decisions, where are the handoffs that slow things down, and what are the informal workarounds that people have built around inadequate systems. Those workarounds are doing real work. Transformations that eliminate them without replacing them create operational gaps.
| Category | Description | Example |
|---|---|---|
| Quick Wins | Low-effort, high-impact projects that build momentum and solve immediate frustrations. | Automating a repetitive manual report that saves a team 10 hours per week. |
| Foundational Projects | Larger initiatives that fix core infrastructure or process issues, enabling future innovation. | Migrating a legacy customer database to a modern, cloud-based CRM. |
| Strategic Bets | High-effort, high-potential projects that could create a new competitive advantage. | Developing a predictive analytics model to reduce customer churn. |
Architecting the Roadmap
A transformation roadmap should be sequenced around capability dependencies, not organizational enthusiasm. The temptation is to start with the most visible initiative - the one that will generate the most stakeholder excitement. The right answer is to start with the foundational capabilities that everything else depends on.
The three-wave structure I use: Wave 1 establishes the foundation - data architecture, core platform, identity and access. Wave 2 builds the user-facing capabilities on that foundation. Wave 3 optimizes and extends. This sequencing means Wave 1 is often invisible to end users, which creates communication challenges. The discipline is maintaining stakeholder confidence during the foundational work without rushing to visible features before the foundation is stable.
- Wave 1: Foundation - data model, core platform, authentication, integration architecture
- Wave 2: Capability - user-facing features, workflow changes, training and adoption
- Wave 3: Optimization - performance, advanced features, process refinement based on adoption data
Start with the foundation, not the feature. The temptation is to show progress through visible user-facing changes. The discipline is building the infrastructure that makes those changes sustainable before you build them.
Execution and Adaptation
The transformation roadmap is a hypothesis. Execution is where you test it. The organizations that deliver on their transformation commitments are the ones that build feedback loops into the execution process - not just quarterly steering committee reviews, but ongoing signal collection from the people doing the work.
The failure mode is treating the roadmap as a contract rather than a guide. Markets shift. Priorities change. Technology options evolve. A transformation roadmap that can't absorb those changes will be quietly abandoned when reality diverges from the plan. The governance structure needs to have explicit authority to adjust the roadmap, with a documented process for how adjustments get made and communicated.
| Metric Category | Example KPI | Its Purpose |
|---|---|---|
| Adoption Metrics | Daily Active Users (DAU) of a new tool | Are people actually using the tech you rolled out? |
| Operational Metrics | Average ticket resolution time | Is it making your processes faster or more efficient? |
| Business Metrics | Customer Lifetime Value (CLV) | Is this work actually moving the needle on revenue? |
What Separates Transformations That Deliver
The digital transformations I've seen generate measurable business value share three characteristics. First, they started with a specific business outcome - not 'modernize our platform' but 'reduce customer onboarding time from 14 days to 48 hours.' The specificity created alignment and made success measurable.
Second, they measured the outcomes that mattered before the transformation started. Customer satisfaction score, time-to-value, operational cost per transaction - whatever the transformation was supposed to move, they had a baseline before they started. That baseline made the business case defensible and the post-transformation results credible.
Third, they designed for adoption before they designed for capability. The most sophisticated platform is worthless if people don't use it the way it was intended. Adoption planning - training, change management, incentive alignment - was built into the roadmap from the beginning, not added at the end when rollout was happening.
| Category | Example Metrics | What It Tells You |
|---|---|---|
| Technology KPIs | System uptime, user adoption rates, API response times. | Is the new tech working reliably and are people actually using it? |
| Operational KPIs | Cycle time reduction, cost per transaction, process error rates. | Are we becoming more efficient and effective in how we do our work? |
| Business KPIs | Customer satisfaction (CSAT), revenue growth, market share. | Is this transformation actually delivering on its ultimate promise to the business? |
Common Questions
How long should a transformation roadmap be?
The detailed, actionable portion should cover 12 to 18 months - long enough to sequence meaningful work, short enough that the assumptions are still valid. Beyond that, use directional themes rather than specific initiatives. Markets shift. Technology evolves. A five-year transformation roadmap with quarterly initiative detail is a plan you'll spend as much time revising as executing.
Who should own the roadmap?
Single executive sponsor for accountability. Cross-functional steering committee for governance. Program owner for day-to-day coordination. The most common mistake is concentration of ownership in IT or engineering, which creates a dynamic where the transformation is seen as a technology project rather than a business change. The business sponsor needs to be as visible and committed as the technical sponsor.
What is the biggest mistake to avoid?
Creating a roadmap that's all about technology and nothing about people and process. I've seen this repeatedly: a beautifully constructed technology migration plan with no budget for training, no plan for the workflow changes that the new system requires, and no stakeholder management for the people whose jobs will change. The technology ships on time. Nobody uses it correctly. The transformation fails.
Leading a Digital Transformation?
Digital transformation that starts with technology and works backward to strategy is the most common expensive mistake I see. I work with leadership teams navigating significant organizational and technology change. If that's where you are, let's talk.
