Product Management Fallacies: How to Think Like an Idiot (Part 2)

Product and project managers must master logical reasoning to optimize their own performance and to overcome illogical objections in the workplace. In the previous posts in this series, we defined “idiot” to be a person who has poor reasoning skills and therefore has poor odds of reaching a valid or optimal conclusion, yet who nonetheless has extremely high confidence in their conclusions. Want to think like an idiot? It’s easy. Today we focus on mistakes made when generating, following, and pruning the tree of possible options.

• Fail to question each link in a chain of reasoning. Product managers must evaluate in isolation the correctness of each link along a chain of reasoning. Suppose you reason as follows: “Enterprise customers have need X. Feature Y will satisfy need X. We should implement Feature Y. Doing so will enable us to win new enterprise customers.” Question each statement. Do enterprise customers really have need X? Does feature Y really satisfy need X? Should we really implement feature Y, or are there more important other things we should do first or overriding reasons not to do feature Y at all? Will implementing feature Y really enable us to win new enterprise customers, or are there reasons we’re doomed to fail in that market?
• Fail to question claims of cause and effect. Confuse sequence with causation.
  • A prospect once asserted that installing my company’s product had caused a tester’s computer to crash with a blue screen of death, so we needed to fix our product before we could roll it out to others. I accepted that a crash had occurred. But was it really due to installing our product? Engineering felt that it was extremely unlikely that a application such as ours even could cause a blue screen of death. On investigation, we discovered that our product had delivered a video protected with digital rights management to the user. That user had not yet “individualized” their Windows Media Player, and there was at that time a known blue screen crash bug when Windows Media Player individualized itself on that platform. What we really needed to do was to change our installation instructions and tell people to individualize their Windows Media Player before installing our product so that we wouldn’t be blamed if the operating system crashed during individualization!
  • This problem can also occur when something good happens. “After we did this demonstration, the prospect agreed to buy our product. The demo won the deal!” Not so fast. Perhaps the prospect had already made their mind before the demonstration. Perhaps one of your board members had talked to one of their board members beforehand and sealed the deal that way. Just because B follows A doesn’t mean that A caused B.
• Confuse correlation with causation. “We have a much higher close rate with pharmaceutical customers than financial customers, so we should focus on the pharmaceutical market.” It may be true that the company is closing a higher percentage of it’s pharmaceutical customers than financial customers, but that might not necessarily be related to the target vertical. What if there’s a single account manager assigned to each vertical and the pharma sales rep is more talented or working harder than the one assigned to financial customers?
• Overgeneralize. Reason from specific instances to universal conclusions without evidence for universality. ”This demo won the deal with customer X, so we should use this demonstration for all prospects going forward.” Even if the demo caused that customer to decide to buy the product, that doesn’t prove that it will have the same effect on any other customers. Another classic example is when the sales representative tells you that all the customers are demanding a new feature? His proof? One customer has asked for it. In both cases, more evidence is needed.
• Stop your analysis too soon, or don’t even analyze at all. Jump to conclusions. Rely on “gut instinct” without seeking other means of deciding. Sometimes you have to go with your gut, but not nearly as often as people would have you believe. People often argue for going with their gut because they don’t want to do the hard work of finding data necessary to make an informed choice, or because they have excessively high confidence in their gut opinions. Great product managers rely on gut instinct as a last resort. Lazy product managers rely on gut instinct as their first resort. Simply making up your mind too quickly without considering other possibilities makes it easier to commit all of the other errors we’ve covered.
• Spend too much time analyzing one possible explanation or option and too little analyzing another. When you make this mistake, poor reasoning begins to compound itself. Analysis requires deciding what issues you’re going to investigate and how long you’ll spend investigating each issue or option. If you do a poor job of deciding how to allocate your limited time, you won’t explore each possible path to the optimal depth, which means you won’t have the maximum chance of finding the best available solution. (Think about how chess software has to choose how deeply to explore each possible move on the board. Product management is the same.) Most questions are not important enough that it’s cost-effective to do detailed investigation of which things to investigate; this is an example of where it’s often necessary and efficient to rely on “gut instinct” when deciding how to allocate your time. But continuously monitor whether you’re spending the right amount of time on investigating each issue or option.
• Spend too much time on analysis overall. If a car is rushing towards you at high speed, you have to make a quick decision of whether to jump to the left or the right. If you spend too long deciding, you lose the option to decide or the decision becomes irrelevant.
• Consider only one possible explanation among many. This is another great way to defeat yourself before the starting gate even drops. For example, after one company lost a deal, an executive sent out an email to a large list demanding that the product manager explain which product flaws had caused the company to lose the deal. The product manager sent out a mildly-worded response pointing out that (a) just because the company had lost a deal, you couldn’t assume that product flaws were necessarily the reason; (b) the product had won the competitive product evaluation hands-down as confirmed by the prospect’s technical evaluation lead; and (c) the prospect’s business unit manager had already told the team going into the evaluation that they didn’t want to buy from the company because two other unrelated business units of the same company had burned this prospect already. You will never hit upon the best possible answer to a question if you fail to consider it. When trying to answer a question, first brainstorm with an open mind to try to generate as many possible answers before winnowing the list down to the apparent best answer.
• Forget to consider “do nothing” as a possible option. Not every problem requires an action in response. Sometimes problems are too infrequent or too minor in their impact to merit any attention at all at the current time (or ever). Deferring a problem to the distant future or deciding to never fix it are valid options to consider.

Logic in the workplace is often a train wreck, but it doesn’t have to be that way. By training yourself and your co-workers to recognize common errors in reasoning and disciplining yourselves to correct them, you can spend less time generating and evaluating bad ideas and more time focusing on potential good ideas!

Further Reading

• A List of Fallacious Arguments by Don Lindsey