It's rare but fantastic when people from different disciplines run into each others' assumptions and meet them with curiosity, not rejection.
In my case, I was so thankful to a private equity professional with whom I worked on an investment deal:
One moment, we were working through the practicalities of a business case. The next, we suddenly ran headlong into each others' assumptions. Simplifying a bit:
Him: "Hey Steffen, what assumptions do you need in the financial model?"
Me: "None. I have no assumptions."
Him: "Huh?"
Me: "🤷‍♂️"
For a second, we just looked at each. Then, he had the presence of mind and curiosity to steer us into a good direction: "Wait, why?" he asked.
So we discussed it. And it turned out we each had good but very different assumptions based on the needs of our job:
In his world of buying and selling businesses, managing directors "have a vision for what the financials 'should be.' It's then the team's job to make the numbers work to get there." The point of the numbers is to create a narrative that makes an investment case either attractive or not. The numbers may not end up being "right." But everybody knows that. When you buy and sell companies, you can't get to "right." You can get to "plausible," "believable" and, most importantly, "attractive even if we are wrong."
In my world of building businesses, numbers are just placeholders. They help us to identify the assumptions that are both (1) big enough to make or break the entire business case and (2) unknown enough that we can't tell yet whether they will make ... or break the business case. (I don't really worry about big but fairly certain assumptions. We can treat those like facts.)
To close the conversation before we returned to building our model, I generalized the point into a principle for him:
As innovation leaders, we offer facts where we can and assumptions that we can replace with facts where we can't.
Or, even more generally, we serve clients' best interests, not their expectations.
Whether people like what we offer them or not doesn't matter. Nor does it matter whether we get our insights from orthodox or unusual sources. We just offer the best guidance toward building businesses that we can.
In a word, our job is to be useful.
Client need > Client expectations
It is not our job to meet client (or boss) expectations.
Instead, we owe clients our best advice i.e. do the best thing in the service of clients’ eat interest.
Many times, the two match up.
But when client expectations clash with what is in their best interest (i.e., when what they ask is patently a bad idea), then it’s our job to help them instead pursue what is in their best interest.
That can happen gently, directly, by any subterfuge in the book if needed. But we do owe it to them, and you should have set that expectation at the outset of your work). Again, this must not be about some pouty desire to tell a client how stupid they are. It must be about truly serving their best interest, to the best of your abilities.
Actually, the best way is actively to investigate first, so you are sure that they are the ones making a mistake (relative to their best interests), not you.
In theory, this applies always. Why call it out?
Because really-really, too many projects turn out to be ruled by “well, but we must do it anyway, because the client expects ...” or by “the client just did it; we weren’t consulted” or any other variation of, essentially, ducking.
More importantly, I’m operational settings (e.g. where your organization’s strategy team might do internal consulting work), the balance of factors might even fall out differently than in Innovation Settings. (By the way, this also holds true for innovation in startups, as opposed to big org's.)
What should I do with this?
Serving clients' best interests, not their expectations" can start quite simply.
Look for and avoid the common problems I have seen pop up in real life.
Typically, they appear when people are under pressure. Both innovation leaders and clients tend to work well together under relaxed conditions. But when stressed, I have seen three issues appear.
Three problems can tempt you into serving expectations over interests
The three problems that stressed clients and innovation leaders can fall prey to are: clients’ desire for extra speed, doing what their own boss demands, or the need "just to make something (impossible) happen."
In operational settings, these factors weigh much more heavily and often describe a “greater right” even when something “appears wrong” when evaluated from a myopic, function-internal lens.
But in Innovation, they can trip up executives when they don’t adapt them to the Innovation context. Sticking with wrong assumptions or directions will just come to haunt us later, when the world beyond our org doesn't care about our company-internal discussions and blithely exposes our mistakes.
So look out for:
The "more speed" push: Speed (and cost) to knowledge matter in Innovation. Speed to output (i.e., how much stuff you deliver how fast) only matters to the degree you speed up learning. Otherwise, you work yourself to death, only to overlook an important assumption and have the whole project fall apart later, when the false assumption blows up and shows all your pretty output to be useless. It’s your job to avoid such wasted time and cost.
The "do what my own boss demands" push: In Innovation, test your assumption with end users (and other external stakeholders like regulators, the laws of physics, etc). If your client’s boss proposes something stupid, the external universe will be all too happy to prove the boss wrong, as already mentioned: Users won’t buy “that awesome product,” a “brilliant technology” just won’t work because it violates the laws of nature, and so on. It’s your job to ensure that even the CEO’s assumptions are scrutinized, and, at least, tested. After all, if the boss is so brilliant, then surely, it won’t do harm to confirm it via a little controlled test, right?
The "make something impossible happen" push: This issue is by far the trickiest of the three. What even is impossible? What “minimum viable” approximation of the impossible thing might your Team have come up with if they just did not impossibility?
To deal with this issue, you need two tools:
Tool 1: understanding your Team’s capabilities and your topic space extremely well: if you do, you can shift an untenable claim of “it’s impossible” to a perfectly sensible one like “our team has never managed to achieve x the last y times we tried. With current tools and capabilities, it appears exceedingly unlikely that this time is different. To make it happen, we would need z, which we can certainly pursue but just don’t have right now.”
And tool 2: Sustainably balancing short term and long term priorities. In the short term of a single project, your Team may trust you and try to achieve the impossible. But they are still professionals (I hope). They still know that what you just asked is most likely “actually” impossible. Maybe they will outdo themselves, make it happen anyway, and shift the marker for what’s impossible further out. But they also may not. Make them fail often enough against their recommendation and professional expertise, and you will lose their trust. The good ones will eventually leave. And it’s already good enough to attract good Innovation professionals to big organizations, when they have plenty of opportunities in startups or cutting-edge research fields. It’s your job to avoid the issue of “people join good companies and leave bad bosses.”
Side bar: Don't over-swing the pendulum into petulance
Some innovation leaders who understand this idea take the wrong lesson from it.
They make it a point of pride to disagree, to denigrate, or to dismiss what clients have to say.
Sometimes the attitude really looks like direct ad-hominem attacks: "You're just wrong and/ or don't know how things need to happen in innovation." More often, it comes out as mere innovation orthodoxy, Ă la: "This is how it's always done. This is what our gurus and toolkit say. Your wanting something else is nice but irrelevant."
Either way, our tools are just that. Tools. Use the right one for the job, to avoid the situation where "when all you have is a hammer, everything starts to look like a nail." It doesn't even matter if the tool comes from innovation or broader business. Use what makes sense.
Be useful.
