Tag Archives: stakeholder buy-in

3 Things Product Managers Can Learn from Management Consultants

By Alex Joseph


House Of LiesManagement Consultants are probably one of the most ridiculed professionals in popular culture (only next to Wall Street bankers). They are often portrayed as ruthless and self-obsessed mercenaries in Dilbert cartoons (‘Dogburt, the Consultant’) or in ‘House of Lies’, a show which is based on the book titled ‘How Management Consultants Steal Your Watch and Then Tell You the Time’!

However, most executives admire management consultants (at least secretly!) and would love to hire top-notch consultants. After having worked as a management consultant and a product manager, I have noticed that many product managers are still skeptical of ‘the consultants’, as most PMs come from engineering or design. I understand some of the concerns, but also believe that many consulting skills (apart from the passion and drive) can be extremely valuable in product management roles. Here are three of them. (BTW, according to consultants, any list should only have three items, since people can’t remember more than three things!)

Gather Data Smartly

Good management consultants are extremely analytical and are obsessed with data. Though sometimes bordering on ‘analysis paralysis’, consultants are methodical in proving or disproving their ‘hypotheses’ and often find creative ways to find proxy data, when it’s not easily available. Though often derided as ‘POOMA’ (you know what that means!), estimating something hard to observe based on something you can observe can be extremely valuable in product management, since the most interesting market data is rarely presented cleanly in an analyst report!

In my first consulting project, the engagement manager asked me (as the most junior member of the team) to analyze the success stories of the four biggest competitors. It was a painful task going through 100+ customer testimonials, but when I clustered them into industries creating a heat map (in one chart), it was an eye-popping revelation how few use cases they actually address – despite their public claims of solving every problem under the sun. It was a classic case of ’80-20’ (as consultants would call it). The conclusions were not entirely surprising, but we then had solid data to back that up, instead of getting into the ‘my opinion vs. yours’ religious battles.

Synthesize and Present Top-Down

Product managers sometimes get lost in a ton of data. I recently watched a product manager presenting a proposal using many dense data charts – pulled from various analysts segmenting the market in different ways and presenting numerous possible features and functions. At the end of the long presentation, I asked him, “Where should we focus?” His answer was, “They are all attractive, and if we have the resources we should do them all.” Something a good management consultant would never say!

In consulting, the ability to structure the message using the Pyramid Principle is extremely important. The goal is to communicate top-down with the most important message first (‘tip of the pyramid’). The supporting conclusions are presented at the next level (following ‘MECE’), resembling a pyramid. This makes it easier for the reader (and especially for busy executives) to grasp the gist of the message instead of being bombarded with a lot of rambling details.

While telling the story, most use a variation of an approach called Situation, Complication, & Resolution to drive to a clear course of action. All of these are equally important for product managers while communicating a product vision & strategy. (Good presentation on applying Pyramid Principle for structured communication).

Gallery of management consultants

Get Stakeholder Buy-In

One thing in common between consultants and product managers is that they often have to ‘influence without authority’. It’s critical for consultants to get buy-in from executives by finding common ground. Most construct a stakeholder diagram at the beginning of the project to figure out the key people to influence. Contrary to stereotypes, no smart consultant will walk in to the big meeting with a heavy PowerPoint deck without getting buy-in privately from these decision makers (‘pre-wiring’).

Product Managers (especially in a big company) have to navigate complex organizational units. Many PMs, especially those from a technical background, seem to have the naïve belief that ‘the best idea will win’. ‘Politics’ may sound like a dirty word, but it’s nothing more than using emotional intelligence while dealing with organizations and executives (that are human too!), considering their collective self-interests.

Does this mean that all management consultants would become excellent product managers? Not always, but that’s a topic for another post.

Alex Joseph is a product manager and former strategy consultant and engineer. He is now an ‘intrapreneur’ in a large software company in Silicon Valley applying what he has learned from startups and corporates. Alex reflects on consumerizing the enterprise by beautiful mobile apps on Twitter and his blog.

The Case Against The Business Case

Note: This is part of 1 of a two-part series. Read part 2 here.

I have a confession to share.

I don’t like business cases.

At least, I don’t like the traditional way I’ve been taught to prepare a business case.

The conventional approach to pursuing a new product idea in an organization is to first prepare a business case. This is what we’ve always been told.

It’s what we’re taught in business school.

There are even competitions organized around it.

And it’s been reinforced every time we need IT and implementation resources for a new idea — the only way I could get those resources was by having a business case.

And this usually meant writing a big document, preparing a multi-slided presentation, or filling out some cumbersome form.

Now, I’ve written many business cases in my career. Some good, some excellent, many bad ones. Over the years, I’ve gotten pretty good at it.

But every time I did it, I hated it.

Here are just three reasons:

1. I always felt it was a time consuming exercise in guesswork.

For example, I’d be asked to estimate (guestimate?) market size and put multi-year financial projections. This is an exercise in future prediction. Something we’re not good at. No one is. I’m certainly not.

2. No one reads it.

People are busy. They don’t have time. Most want the elevator pitch.

I can’t count how many pitches I’ve been in where the execs flip to the end or simply ask you for the bottom line: what’s the opportunity, how much do you need, why do you need it, when do we see return. 60 seconds. Go.

This means a business case is nothing more than a 20, 50, or 100-page paperweight. Steven Blank famously called a business plan “a document investors make you write that they don’t read.” The same could be said for the traditional business case:

“A business case is a document executives make you write that they don’t read.”

3. Selling the business case is hard.

This is especially true in larger organizations. Lots of opinions. Lots of approvals. Competing agendas.

So ensuring internal stakeholder alignment and support is a big challenge. Lack of stakeholder support can be the biggest impediment to your product idea.

It’s important to capture and address stakeholder concerns as early as possible to ensure continued buy-in, and that everyone is on the same page. This is time consuming.

Part of that has to do with the realities of coordinating schedules. But also I’ve found this experience to be very ad hoc and messy. There has to be a better way.

[optin-monster-shortcode id=”tjtsmjhkd0zsxede”]


Now, maybe the way I’ve gone about creating and selling my business cases has been wrong. Maybe my situation is unique. Maybe others don’t find this process so wasteful. Maybe they’re more brilliant than I am in creating awesome business cases that always get approved. Maybe they work in organizations that have streamlined the process to pursue a new product idea.

Maybe I could test that hypothesis.

So I did.

I set about to find out what other product management folks’ experiences have been with the traditional business case process.

Over a three week period, I spoke with over 24 product professionals in companies across a range of industries, from small 50-person companies to Fortune 100 organizations.

All had experienced preparing and selling a business case for a new product idea. They had an average of 7 years PM experience, and had titles ranging from Product Manager to VP of Product Management.

Business Case Interview Map

Here’s what I found out.

Getting buy-in was rated as the #1 problem by every person except one. And that person rated it as a very close #2.

75% of them validated that maintaining stakeholder support and alignment is important, but a real challenge. Only 3 out of 8 pursed doing this in any kind of systematic manner. Most agreed it was pretty ad hoc.

Furthermore, creating the business case was acknowledged as time consuming, and a “necessary evil”.

Necessary evil? Whoa.

When I probed deeper into their feelings about the actual act of preparing a business case, I uncovered an outpouring of vitriolic frustration.

Here’s what some of them had to say:

  • “It’s a necessary evil. But it’s a wasteful process.”
  • “It’s a joke.”
  • “It’s just a lifeless Powerpoint deck.”
  • “It’s a manager fighting with an Excel spreadsheet for a month.”
  • “I’m forced to project revenues out of thin air. Putting revenue projections is a nonsensical exercise.”
  • “Financial analysis – it’s really just pretend.”

“Lifeless”. “Nonsensical.” “Pretend.” “A joke.”.



And my favorite comment:

“You are describing my life!”


I feel safe to say this feedback clearly validated my entire hypothesis.

So what’s the solution?

This is not so easy to answer.

It seems to me we need a different way to pursue new product opportunities within our organizations.

One that will provide a systematic process to create validated business cases.

And one that provides us with tools and resources needed to obtain that validation.

One that will enable us to more systematically build and maintain critical internal support.

And one that allows us to spend more time with customers testing and developing product ideas than writing paperweights, while also providing an effective means to communicate progress internally for continued engagement, feedback and buy-in.

What has your experience been with business cases? How have you pursued a new product idea in your organization? Please share your frustrations or joys in the comments below!

Read part 2 here.