Article Summary
Bain & Company found that only about 12% of business transformations achieve their original ambition. Its research points to a familiar problem: organizations overfocus on technology and underinvest in the operating model and decision-making changes required to make it work. In the projects we're brought into, the gaps show up in four places: the people who use the thing, the goals behind it, the expectations around it, and whether the organization can actually run it after launch. HOLO is the framework we use to surface those gaps before they become expensive.
Key Takeaways
- Only about 12% of business transformations achieve their original ambition, according to Bain's 2023 Transformation & Change Survey.
- Many projects don't show their biggest problems at launch. They show up months later, when people use the product in unanticipated ways or quietly stop using it.
- The people with the clearest view of the problem are often in operations, sales, or support, and often aren't in the workshop.
- There is no average user. Design for everyone who touches the product, including internal staff.
- Write down what success means, and who is actually measuring it.
- If nobody owns it on Monday, it won't survive.
Related Video
Full Article
The project looked great, and nobody used it
We see this pattern constantly. The project gets approved. The design review goes well. Everyone's happy at launch. Months later, people are using the thing wrong, or they've quietly stopped using it.
Nobody calls that failure. It gets folded into the next project, and the new brief says the old one "looked dated." So the team redesigns the same thing, and the real problem survives another cycle.
Technology is only part of the job. Research on digital transformation keeps pointing to the same factors that determine whether a project delivers value after launch: adoption, workforce capability, operating model change, and clear business ownership. McKinsey, for example, recommends that adoption be owned by the business leader responsible for that area rather than left to the digital team, and that frontline people be involved before any code is written. That matches what we see.
The person who knows often isn't in the room
On many projects, the people with the clearest view of the day-to-day problem work in operations, sales, or customer support. They aren't in the workshop, not because they lack useful knowledge, but because nobody built their perspective into the discovery plan.
We built HOLO to fix that. It stands for Humans, Objectives, Landscape, and Organization. The name comes from the Greek holos, meaning whole or complete. It's the lens we use for every project to uncover what the core team doesn't yet know.
Humans: there is no average user
The trap isn't ignoring users. It's designing for an average user who doesn't exist. Take everyone who touches a product, blend them together, and you get someone nobody recognizes.
We push teams to separate their audiences explicitly into primary, secondary, and tertiary, and to include internal users. If you're building an e-commerce experience, the obvious focus is the shopper. HOLO also makes you map the warehouse employee packing the order and the support rep handling the return.
One e-commerce client was getting complaints that shipping times weren't showing at checkout. It looked like an API problem. It turned out to be a fulfillment problem, tied to where the warehouse was and how the people in it worked. A short conversation with the fulfillment team would have found it.
That conversation is some of the cheapest research for a project, and it's rarely within scope. A short interview, or even an email, beats nothing. It often tells you more than the persona work everyone wants to spend time on.
Objectives: write down what success actually means
This is where design and business either line up or don't. Every digital project sits inside a larger organization with its own goals, so the questions are: what are the company's goals, what are the project's goals, and are they actually written down?
The gap frequently looks like this: the project goal is to lift conversions this quarter, but the real business goal is to keep customers longer. Those lead to different designs.
One simple question in our workshops exposes it fast: Who else has a number riding on this project, and have they seen the brief? The answer is often no, or they're on vacation. That person's definition of success may be completely different from everyone else's in the room.
Vague goals need digging too. "We want the website to be less of a headache" means something. How many hours a month does your team spend fighting the CMS? Nobody has that number at first, but there's a real cost behind it, and it belongs in the plan.
Landscape: know the minimum you can't fall below
This is the outward-looking part, and it covers three different things:
- Regulatory and legal requirements: accessibility, privacy, security, and any sector-specific requirements.
- Category conventions: the experiences users expect because your competitors already offer them.
- External shifts: where technology, customer behaviour, and adjacent industries are heading while you build.
On a fintech product, if you don't know the security and accessibility requirements your category is held to, you can ship something beautiful that's still behind. If your users don't catch it, your compliance team will.
Your users also don't live only in your industry. They compare your product to everything else they use. Ask anyone how their bank's online experience compares to Wealthsimple.
Landscape isn't a mood board. It's about knowing the minimum you're not allowed to fall below.
Organization: who owns it on Monday?
This is the pillar we care about most, because it's where we see projects quietly fail. Can the organization actually absorb what you're handing over: the workflows, the training, the ownership?
Sometimes the vision gets ahead of the execution. A manufacturer can want an e-commerce revenue model long before its operations can support one. More often, it's smaller. We ask who will update the content and what the SEO plan will be after launch, and the answer is: one overstretched marketer. We know what happens next: nothing gets published, and the site slowly stops working as a business tool.
Whatever we build has to still work three years from now, run by someone the client hasn't hired yet. That's an organizational question, not a design question, and it has to be answered during discovery.
Run your last project through it
You don't need a six-month engagement. Take a new project, or the last one you finished, and go through the four pillars. In our work, a focused one-week sprint usually surfaces the highest-priority gaps. It won't answer all four completely, and that's the point. What's missing is the most valuable part, because that's where the risk is: a compliance gap, a supply chain bottleneck, a goal nobody wrote down.
We still get pushback on doing discovery at all. Bain's research doesn't say discovery alone decides whether a transformation succeeds. Its findings also emphasize talent and organizational capability. But the lesson is the same: a transformation isn't a technology purchase. It requires upfront work to align people, goals, constraints, and ownership before anything gets built.
If you want to go deeper, read why we built HOLO, or start with a better project brief.
Frequently Asked Questions (FAQ)
What is the HOLO framework?
HOLO is Tennis's discovery framework. It looks at every project through four lenses: Humans (everyone who uses it, internal and external), Objectives (written-down business and project goals), Landscape (regulatory requirements, category conventions, and external shifts), and Organization (whether the business can adopt and sustain what's built).
Why do most business transformations fall short?
Bain found that only about 12% achieve their original ambition, and its research points to organizations overfocusing on technology while underinvesting in operating models and decision-making changes. In our experience, the common gaps are designing for an imaginary average user, unclear or conflicting goals, missed requirements, and organizations that aren't set up to adopt the result.
How long does discovery take?
In our work, a focused one-week sprint usually surfaces the highest-priority gaps. Larger or regulated projects need more time.
Can I use HOLO on a project that's already finished?
Yes. Running a completed project through the four pillars is one of the fastest ways to understand why it didn't land the way you expected.
