Games executives play: Guess what’s in the envelope


Add to FacebookAdd to DiggAdd to Del.icio.usAdd to StumbleuponAdd to RedditAdd to BlinklistAdd to TwitterAdd to TechnoratiAdd to FurlAdd to Newsvine

Guess whats in the envelopeSome of you will be too young to remember Johnny Carson playing Carnac the Magnificent. But I am guessing you’ve seen this game before. On the Carson show, Johnny would hold an envelope to his head, pretend to intuit a phrase, then open the envelope and find something funny inside.

I like to call it “Guess what’s in the envelope”.

Guess what’s in the envelope

In my corporate experience I’ve seen many executives play games similar to Carnac’s. This time, though, it’s not so funny.

The corporate version of the game goes like this:

  1. Your VP or manager tells you that you own the product line and it’s up to you to decide how to manage it. You should provide the direction, positioning, messaging, and requirements for the product. Once that’s done, you are charged with making sure the company is aligned to produce the results your manager wants.
  2. When you come back with a PRD, MRD, product strategy, or other document, the response is: That wasn’t what I was thinking. Start again.

It’s like your manager is holding an envelope to her head, and asking you to guess what’s in it. The truth is that she probably doesn’t even know what’s in the envelope, but when she sees your hard work, it wasn’t what she “had in mind”.

For the PM this is infuriating on a personal and professional level. But the people who should be infuriated are the senior managers and investors in the company, for this is a stupendous waste of company resources. The costs go far beyond the time you spent researching and writing. As the Product Manager, you are often on the critical path for delivery of product and revenue. If you make the right picks, the revenue will be much easier to get. But if you are stalled in a cycle of indecision or managerial incompetence, the whole company is impacted.

I have found it useful to start by simply naming the game that is being played. By naming it, we can start to describe it and thus deal with it. I have a few names for this game:

  1. Guess what’s in the envelope! As above, the picture here is of a manager holding an envelope with top-secret information. She is asking you to write a requirements document, and when it is complete, she will compare it to the secret document in her envelope.
  2. Guess what I’m thinking! Same as above. But the envelope is funnier.
  3. Rock Fetch! I love this name. The game is: I want you to go out and look for a rock, shaped something like this, weighing about this much. Go look for it in that field over there. When you come back, the answer is simply “Wrong Rock! Try again please.”

It helps me to laugh about the situation, but it might also help to be truthful and call it what it really is: An impossible task.

Some managers make this even more fun by offering support for your MRD until the software ships. If results are below expectations, it is because you didn’t read their minds. You found the wrong rock. Only this time, you invested an engineering team’s time, a release cycle, and precious months of time in the market.

What’s going on here?

The underlying problem is often very deep and hard to fix. But it’s worth figuring out what is causing this situation. Consider these possibilities:

  1. Your manager is a doer, not a delegator: Doesn’t know how to delegate with authority. Doesn’t know how to give you the parameters in which you can work. Thus they tell you to go do the research, but reserve the right to disagree with your conclusion.
  2. You didn’t understand the assignment: Just because I made fun of your manager above, it doesn’t follow necessarily that your manager is to blame. You may need to clarify what level of authority you have, and what constraints are in place. If your recommendations are out of line with the real needs of the product (eg: your product needs maintenance but you are spec’ing new features), you need to get your assignment straight.
  3. Manager thinks they know better: Your manager likely has an intuitive grasp of the industry, the executive mood, and the needs of your product. If your recommendations clash with their understanding, you’d better be prepared with facts to back up your conclusions.
  4. Manager is insecure: Some managers wrongly feel that if their employees succeed, they themselves will be seen as unnecessary. This is wrong thinking, but very common. If you are working for a person like this, I would consider a transition path to a better, more mature manager.

How can I get out of this mess?

There really are no sure-fire ways for a person to escape this kind of problem with a manager, and the prescription will depend on your diagnosis of the underlying problem (see previous section). My advice is to use a series of tactics to build agreement and settle disputes:

  1. Seek first to understand, then to be understood: It is a career-limiting move to assume that your manager is a bonehead. And it’s probably untrue. Even if you are right, there has to be some amount of wisdom in what your manager is saying. Go into diagnostic mode. Would they prefer a different emphasis? A different presentation of the information? Did they understand your proposal?  What are the main areas of disagreement? Can you identify areas of agreement?
  2. Debate assumptions, not conclusions: Arguing about conclusions is a waste time. Walk down the “ladder of inference”. and seek to understand your manager’s assumptions. Compare them to your own. If you have data to back up your position (and you’d better have it), present that data and get feedback. Is more data needed? Does your boss have different data? More data?
  3. Find areas of agreement, and build: If you focus only on disagreements, you will both be frustrated. I would ask your boss to highlight areas of agreement and hunt for them yourself. You will both feel better and confine the discussion to the areas of disagreement. You may also find that as you talk about areas of agreement, assumptions will pop up that you can use to debate the contentious areas.
  4. Clarify your level of authority: If you are going off to do more research, make sure it is very tightly prescribed, and try to agree on a decision tree, such as: if we find X, we will do A, but if not, we will probably do B. This kind of discussion should occur before any research process, but it is even more crucial when you are re-starting an investigation.
  5. Clarify the constraints: Similar to level of authority, what things cannot be done, and what things must be done?
  6. Be agile. Fail fast: Disagreements like this are painful, but even moreso when they come at the end of a long and expensive process. Work with your manager along the way to schedule time to review your work as you progress rather than doing so only at the end. I like the idea of failing fast. It implies that we are going to fail, or disagree, so we’d better find, and settle, our disagreements early. This kind of thinking is at the heart of an agile process, and can be applied to research as well as building.

It’s not you, it’s me

You might conclude after this exercise that your manager is limiting your career development. If so, perhaps you should begin to plan a transition.

But you should also be open to the idea that you are simply not managing your boss well enough. You need to take an active role in defining your own work to avoid these kinds of problems. When they arise, schedule a 45 minute meeting a week after the event to discuss the problem with your boss. You can frame it like this:

I want to avoid disagreements like the one we had over the PRD last week. To that end I would like to develop a better process for the next time I do a PRD, or any major project.

It is too easy to privately call your manager incompetent and avoid taking responsibility for the problem. But if you want to go somewhere in your career, slagging your manager will not help.

Some final advice

Take the bull by the horns:

  • Diagnose the problem with your boss.
  • Be open to your own part of the problem.
  • Be firm about improving the situation the next time around.

If this whole thing happens again, repeat the process. Keep notes.

If your manager insists on playing “Guess What’s in the Envelope”, then it might be time to move on. But first make sure that you are not the one playing games.

– Alan

PS: Feel free to write to discuss.

Supplementary articles from HBR:

Managing your boss (Gabarro, Kotter)

Managing Oneself (Peter Drucker)

Advertisements

8 responses to “Games executives play: Guess what’s in the envelope

  1. Alan, good post.

    One of the things that I’d add to the list of how to avoid such situations is ask lots of questions. Often times PM’s or even all of us steer away from that thinking that asking questions would be treated as a sign of weakness or the manager would think you dont know what you’re doing.

    While most good managers would like questions asked and cleared.

  2. Really outstanding article! And very sticky idea, at least for 40+ people like me who remember the great Carnac!

    Fantastic.

    Add to the list of techniques – “Stuff your own envelope”

    When you see the (what’s in the envelope) gesture, respond by scribbling an answer, stuffing it in your own envelope, tear it open and confirm right there. Same logic as “fail fast” only it is really “fail faster.”

    Elicit what’s in (or should be in) the exec’s head, and get agreement on the goals / acceptance criteria.

    Another way to think about it – get specific measurement criteria (size, weight, shape, color, etc) by which the rock will be accepted, before going out in the field. The goal – your exec doesn’t have to waste time waiting around for you to bring back a rock that will be rejected. All of the “bad rocks” can be automatically rejected.

    Anytime a hidden reason for rejection is discovered (on an otherwise passing rock), add that to the list…

    Again – fantastic article!

  3. Wow, that’s awesome that you’re coming down. We should definitely grab a beer while you’re here. Ping me and we’ll plan…

  4. Alan – I loved your comparision of Boss’s with the Carson show. Great and funny way of looking at it.

    On a serious note, people in high positions have egos that come out only after research! Need to be very careful while discussion the disagreement points! my 2 cents

    Thanks again!
    Maruti

  5. Really good article and I’ve had to play to guessing game many times, even with clients.

    2 other observations/recommendations:

    1) I found it useful to dive into clarifying assumptions immediately upon getting an assignment. While the manager may try not to divulge any info “so as not to taint your view”, the reality is some assumptions already exist that you will need to align or overcome, so get them on the table early.

    2) Your boss may also be getting whipped around by THEIR boss who keeps changing the contents of the envelope. Try to get to the real authority and who’s driving the project. After you’ve gotten a full disclosure from your manager, also ask who you should be talking to in the org, and ask permission to go solicit input. Your job is not only to come up with the deliverable, but to also be involving and aligning the organization.

    You’re going to be more successful in getting the answer “right” by getting as much info as possible from inside coupled with your market research. At the very least, you’ll know what you’re up against ahead of time.

    Thanks,

  6. Don: Great responses. Thanks very much for contributing. Everyone who reads this article will benefit from your additional insights.

    If you like the article, please feel free to share it! Twitter, facebook, another blog … it’s here for the reading. 🙂
    – Alan

  7. Pingback: Guest Post: Stop, Collaborate and Listen « On Product Management