Designing in Hostile Territory

Convincing cautious bosses of the benefits of a novel approach is a tricky business, but it can be done. Here's how

A friend who works for a large wireless provider complained to me recently about the impossibility of taking a design approach in his "design-unfriendly organization." He had put forward a new approach to customer service designed to dramatically enhance retention and was shot down by, of all things, the "Corporate Customer Innovation Committee."

"Roger," he bemoaned, "You write all this stuff about business design, innovation, and creativity, but unless managers have a CEO that aggressively promotes design, they will be squelched." I can feel his pain. I empathize -- but do I sympathize? Not really, because my friend is thinking about the question from a design-free perspective and expecting a design-friendly outcome that just isn't going to happen.

The bottom line: You don't need anyone's permission to think like a designer. But there are five things you need to do if you want to be effective in a "design-unfriendly organization."

1) Take Design Unfriendliness as a Design Challenge

The absence of a CEO who appreciates design is a constraint. But to a designer, a constraint is an important signal of a central challenge. And that challenge was not, in my friend's case, the design of a customer-retention enhancement. The real challenge was to design a way for the Corporate Customer Innovation Committee to take action on the proposed initiative.

The nondesigner's approach is to see the task as creating a nifty approach to enhancing customer retention, while averting his eyes to constraint of creating an idea that's compelling to the Innovation Committee. This is what I call "narrow perfectionism." If you ignore the trickiest constraints and define victory narrowly, you can always blame someone else -- i.e. the Innovation Committee -- for the failure to produce beneficial action.

In contrast, the design-thinking manager homes in on the most difficult constraint -- design unfriendliness -- and integrates that constraint into her design approach. While this makes the challenge bigger and more complicated, and increases the possibility of failure, it also increases the possibility of true success.

But how can the design-thinking manager proceed from this essential starting point?

2) Empathize with the Unfriendly Elements

The only way to design a compelling solution for a user is to understand the user in a positive way. If the Innovation Committee could only be understood by my friend as a bunch of ultraconservative, gutless Luddites, then the key insights to designing a compelling solution for them will be hidden.

It's almost impossibly hard to design something compelling for a person whom you don't respect or attempt to understand. The filing cabinets full of unbuilt houses designed for clients the architects saw as "philistines" are testament to the limitation of disrespecting your user. The architect consoles himself with the brilliance of his design without having any better explanation of its still-born fate than "the client had no appreciation of architecture."

In contrast, the design-thinking manager attempts to achieve deep understanding of the user in order to uncover the greatest range of options for creating a compelling solution. What are the user's greatest hopes? What keeps the user up at night worrying? What are the minimum acceptable conditions for the user to embrace a design solution? How much risk is the user willing to absorb?

We can answer these questions either with empathy or disdain. The nondesigner sees that what keeps the user up at night is the desire to keep his proverbial ass covered. The design-thinking manager sees what keeps the user up at night is the desire to protect his employees from the consequences of a reckless decision. A better understanding of the user's point of view enables the designer to probe what constitutes a reckless decision vs. a sensibly aggressive decision -- from the user's standpoint.

3) Speak the Language of Reliability

To empathize, one needs to communicate. But, design-unfriendly and design-oriented people speak different languages (see BW Online, 9/29/05, "Reliability vs. Validity"). The former speak the language of reliability, because they put a high priority on the production of consistent, predictable outcomes. They frequently use words such as: proof, regression analysis, certainty, best practices, and deployment.

Design-oriented people speak the language of validity because they put a high priority on the production of outcomes that delight, whether they're consistent and predictable or not. They frequently use words such as: visualization, prototyping, beta-testing, and novelty.

But to the members of a design-unfriendly organization, these words connote danger, uncertainty, and guesswork -- things that encourage, if not compel, them to say: No! In such circumstances, it's incumbent on the design-oriented person to learn the language of the majority -- the language of reliability.

I know how critical this is. I vividly remember working as a relatively young consultant for a big bank on a private-banking strategy for its high-net-worth customers. My team came up with a breakthrough idea, and in due course, we were given an audience to present our proposed strategy to the bank's chief executive officer and his six direct reports.

They listened attentively. At the end the chief operating officer asked one question: "Have any of our competitors done anything like this?" Reveling in the unique brilliance of our solution, I enthusiastically responded: "No, not even close!" I was too young, foolish, and design-insensitive to realize that my answer put the final nail in the coffin of our idea. That was 1988. It's small consolation indeed that I have observed several banks only recently utilizing the approach we laid out almost two decades ago.

4) Use Analogies and Stories

What tools can help bridge the language gap? It's difficult to provide "proof" or "certainty," even if a design-thinking manager appreciates that those words loom large in the reliability lexicon. The best tool available is analogy: crafting a story that takes an existing idea in operation elsewhere and shows how it's similar to the novel idea being proposed -- not exactly the same, but similar enough.

Had I had more empathy with my banker clients and understood the language of reliability, I might have responded to their query: "None of our domestic competitors have done this. But a variant of this approach has been used by some of the best performing European private banks for some time now. It isn't exactly the same, but it bears important similarities. And recall, our bank has succeeded in the past when it has taken an idea from outside our home market and introduced it here."

This doesn't eliminate the apparent riskiness of an idea, but it presents it in a reliability-oriented framework. And in the end, in order to take action, decisionmakers will need to convince themselves that the idea falls into an acceptable range of reliability.

5) Bite Off as Little a Piece as Possible to Generate Proof

Even with careful use of language and employment of analogies, "proof" is the biggest problem. Designers don't traffic in proof of the sort reliability-oriented folks want. Designers simply can't prove in advance that their ideas will work in the way a reliability-oriented executive can prove that she sold $800 million of product in the latest fiscal year. As a consequence, a big part of the challenge facing the design-thinking manager in a design-unfriendly environment is to generate bits of proof on the way to the full deployment of the design idea.

Design-oriented managers don't like this notion, because it feels to them that any parsing or phasing of the solution will destroy its integrity. But a whole industry -- venture capital -- has thrived on this approach.

The entrepreneurs that venture capitalists finance are validity-oriented designers. They attempt to come up with new-to-the-world products or services, which they believe will be smash hits, although they can't prove it in advance. Each one would love the venture capitalists to fund the entire project from start to finish. But since the wacky days of 1998-2000, that rarely happens.

The venture capitalists, who feel the need to be more reliability-oriented on behalf of their investors, dole out the venture financing in little dollops, with each round contingent on increasing levels of proof that full deployment of the idea in question will be a big success.

Like venture-backed entrepreneurs, design-thinking managers living in design-unfriendly environments need to develop the capacity to create roll-out plans for their ideas that help their organization ratchet up its confidence stage by stage.

So while it's not easy, it's possible for design thinking to prosper if managers in my friend's position embrace the challenge of designing in hostile territory by empathizing, learning a foreign language, story-telling, and taking one bite at a time.