Applying MECE Lists

Imagine you’ve been enlisted to create a recommendation to the CTO for a new database system to replace your legacy system. If you merely state the single database system you want to buy, any responsible executive will reject your recommendation as heavily biased, poorly considered, and potentially reckless.

So we want to first consider our audience, with empathy, and always ask: Who is this for, and what do they need to know either to make a decision or to do the thing in question?

Your deciding audience wants to know that they have been given a clear, thorough, thoughtful, unbiased proposal and that they are not being manipulated. In our empathy, we realize that everyone has a boss, and that no one in a company of any size just makes a decision in a vacuum. It’s not the CTO’s money. So your CTO must in turn answer to his bosses for the system he selects, and is accountable for its success. Your recommendation will be successful if you give your deciding audience a list of MECE lists.

But the list of database system choices is potentially in the thousands. It is impossible to include all of them, and impractical and unhelpful to include even 20 of them. Being ridiculous is not what is meant by “collectively exhaustive.” So first we’ll create a list of criteria to help us make our final list MECE. I include three or five factors on which you will base your selection and write those down, as they become part of your recommendation too. You’re showing your audience how you came to your conclusion, just like showing the long math in school: you’re not just giving the answer, but providing the steps by which you arrived at it. This helps the audience follow your story and agree with your conclusion.

Then we’ll perform a survey of the landscape, including systems that meet the criteria. Include open source alternatives as well as commercial vendors. We might have a few of each. If we recommended only the one we already wanted, we would miss the chance to perform the analysis, squander an opportunity for learning that might change or augment our view, and lose confidence in our choice and ability to execute. Including only our one recommendation would certainly and immediately invite considerable skepticism and questioning about the alternatives and how we considered them.

So make a MECE list of options. The list is exhaustive according to your chosen criteria. Say you have 8 or 10 options in your list of “all the database systems considered.” Say so in your recommendation. It shows you’ve done your homework and suggests less bias and a more data-driven, analytical approach. Then say you narrowed it down to five options to present. That list includes two you reject and state why. You have a list of three options remaining.

For each element on your list of remaining recommended vendors, create another list of lists: “advantages, disadvantages” (that’s a MECE list itself). The elements in each list should be something about the technology, particularly 1) the functional requirements such as key features that distinguish it from the competition and 2) nonfunctional requirements such as performance, availability, security, and maintainability (that’s a MECE list, too). Consider these systems also from the business perspective: ability to train the staff, popularity/access to future staff, ease of use, and so forth.

Then from the list of acceptible candidates, present them all, ranked as Good, Better, and Best. (The Good, Better, Best list is MECE too, because you wouldn’t improve its MECE-ness by adding a “Horrible” option: the category or name of this list is the acceptable options, which presumably does not include “horrible, and therefore unusable ones.”)

The Good option might be the one that is acceptable to you, and is low cost but not optimal. The Best one might be the most desirable but highest cost, and so on.

Organizing your list this way makes an executive feel more confident that you have an understanding of the entire landscape, aren’t too biased, and show your reasoning. That makes your recommendation stronger.

Getting good at quickly checking if you are thinking in lists and then making sure they’re MECE has the pleasant side effect of helping build your powers of analysis. Think of MECE as a lens. Every time you make a list, immediately test if it is MECE. Use it as a heuristic device with your team: inspect your list with the team as you’re meeting, be sure to ask if the current list you’re working on is MECE, and then refine it. Your team may groan at first, but they will gradually start to see the value, and then they will not be able to imagine how they ever lived without it.

Make your work lists of lists, and make those lists MECE. Your recommendations have a better chance of getting accepted, supported, and executed on. And you will create more power for your organization and your team.

Diagnostic Logic Tree

Diagnostic Logic Trees attempt to determine the applicable subcategories of problems and a root cause. They answer the question of why the issue has occurred.

As you ask “why,” you are using your powers of deductive reasoning, working backward from a known current state.

To reiterate, you start any strategy by first clarifying what problem you need to solve. You are then ready to create the Diagnostic Logic Tree to determine why this problem or situation is occurring. 

Solution Logic Tree

Solution Logic Trees are a way of representing possible solutions or courses of action to address a problem. They answer the question of how to proceed. You create this kind of tree after making the Diagnostic Logic Tree.

Creating the Tree

To create the tree, you’ll first conduct a diagnostic analysis and then a solution-oriented analysis. These are separate exercises.  It is tempting to jump to solutions without taking the time to gain a clear understanding of the true problem.

Represent your thinking in two separate trees. You may be familiar with the Five Whys, or fishbone diagram, which is also called an Ishikawa diagram. We’ll use a similar structure to create the trees.

Once you are presented with a problem, ask why that would be the case. You may quickly see several possible reasons. Write each reason as the second level of the fishbone diagram. Then ask in turn why that would be the case, and write the reasons at the next level. Do this using the MECE technique (see “MECE”). Repeat a total of five times to come up with a set of possible root causes. Now you can make a declarative statement in your Ghost Deck (see “Ghost Deck”) that this is the problem and this is the root cause. For more on Ghost Decks, see Chapter 9.

My colleague at Sabre, Justin Ricketts, likes to use the example in Figure 2-1 to help teams see how to approach a Five Whys analysis. It shows a memorable way of demonstrating how you can come to simple solutions and processes.

Figure 2-1. Example of Five Whys

So it turns out that the Jefferson Monument was eroding because the lights that illuminate the statue at dusk attracted tiny midge flies, which attracted spiders, which attracted pigeons, which required cleaning crews to use harsh chemical processes to continuously keep it clean.

The solution to the problem was to simply turn on the lights that illuminate the statue one hour later—saving work crews, preserving the statue, saving on electricity and bulb replacement costs, and disrupting fewer tourists who come to observe the statue—and it cost nothing and took no time to implement. Justin’s illustration is a great way of showing how you can get to the root cause, but also how the solution may be easier than you’d think.

After you have determined some problems your strategy can address, and then figured out their root causes, you can start to formulate plans for addressing them through a variety of lenses and with tools we’ll explore in subsequent chapters.

The other part of the strategy scoping is to consider solutions. To do this, start by imagining the ideal end state—that is, what the world looks like after the problem has been solved or no longer exists. Make that declarative statement in your Ghost Deck. Ask “how” that state could be realized by determining what the prior necessary condition would have to be to achieve it. Do this in five layers of depth, regressing closer to the current state that has the problem. This will help you plan the path forward.

Problems Versus Opportunities

Here we’ve focused, for the sake of brevity and convenience, on problem solving. But if you focus only on problems, the best you can do is maintain the status quo. Therefore, don’t forget to focus on opportunities for your strategy, things that represent gains to your customers and organization that they might not be aware they need.

This requires you imagining a better world, absent any direct feedback that people are hurting without it. For example, no one in 2007 was walking around the streets feeling the pain of not having a smartphone—they didn’t exist. No one had apps, and no one was sad about it. The iPhone didn’t directly address a clear and present pain that consumers felt at not having apps in their lives. But the invention represented a gain for consumers, augmenting and improving their lives and giving them conveniences they hadn’t thought of or knew they wanted.

Apple commonly employs this strategy of looking for customer gains, not just pains to solve. Take one of many other examples from the company: in 1998, no one was in despair or unable to be productive because their computers were only one color: boring black. But once Apple made the iMac in five colors named after fruit, the product sold like hotcakes, and is actually responsible for saving the company, bringing it out of the financial crisis created in Steve Jobs’s absence. The strategy seems to have worked out OK for Apple. 

The Five Questions

Hypothesis formulating is making a claim about the world: “this is that.” Or, “the reason for X is Y.” Or, “the way to make A better is to stop doing B and start doing C.” I suppose you can just start making statements along these lines and call it a hypothesis. But that’s not going to get anyone a strategy consulting job at McKinsey, and it’s not going to serve you as a building block for your strategy.

This pattern is implied by the hypothesizing that strategy consultants do, but is not their process. So you might see very different material on this pattern in other sources. What I describe here I’ve adapted and customized based on my graduate studies in philosophy and what I have to put to work making successful strategies in my roles as CTO, CIO, and Chief Architect in a variety of companies.

Clinton Anderson was a Bain strategy consultant for 20 years. He once told me that his job in that time was about asking the right questions. The hard part is determining what the right questions are. Professor of Philosophy Alison Brown helped me see that in this context, hypothesizing (asking the right questions) tends to mean we start by asking these five key questions:

1. What is the conjunct of propositions that describe the problem?

2. What semantics characterize these propositions?

3. What are the possible outcomes?

4. What are the probabilities of each of these outcomes coming true?

5. What “ease and impact” scoring values suggest the right strategy?

This is our framework for asking those questions well. Let’s take them in order.

1. The Conjunct of Propositions Describing the Problem

When it’s time to perform an analysis, which is most of the time, we start with the first of our five questions: What is the conjunct of propositions that describe the problem?

Twentieth-century philosopher Ludwig Wittgenstein was one of the leading thinkers in propositional logic. Propositions and propositional logic are well, but not definitively, explored in his book Tractatus Logico-Philosophicus, which I highly recommend. Ten years earlier, in 1911, Wittgenstein’s teacher Bertrand Russell wrote a paper titled “Le Réalisme Analytique” in which he describes propositions.  Here we’ll unpack a few simple tools from this field to aid in our analysis.

In the Tractatus, Wittgenstein writes that “a proposition asserts the existence of a state of affairs” (section 4.21). So when you make a proposition, you are making a claim about the world. You are characterizing something that should be able to be expressed as a truth value.

When you are presented a problem, define it as a set of propositions. Each proposition is connected by the conjunct (the logical operator AND). Within each proposition, the variables, or constituent names, are also linked by logical connectors, so that you can deduce the truth value of the overall formula from determining the truth or falsity of each variable.

In modal logic, a proposition is true in accordance with its being borne out by the facts. So you must collect a few data points before making a proposition. Ultimately, your hypothesis will be a list of subhypotheses, each based on an insight, which in turn are each based on a series of data points (see Figure 2-2). As we frequently hear from machine learning teams: if you think your data is clean, you haven’t looked at it hard enough.

Figure 2-2. Hierarchy of data, insights, and hypotheses

Proposition P is a truth function of a set of constituent propositions if and only if you fix the truth value of P while determining the truth value of every proposition in the set. This is a cheerfully academic way of saying you have to be clear on what you are talking about: define your terms. People use “resource” to mean “compute power” or “human programmer.” When you say “customer,” do you mean the franchisor you are selling to or their customer? Your definition of “system” is likely too slippery to be talked about. So again, the simple solution is to define your terms.

2. The Semantics Characterizing These Propositions

Now let’s ask the second question in hypothesis formation: What are the semantics that characterize each of the propositions?

Here you are creating an interpretation, determining the discourse around each of these propositions. That’s because, again according to Wittgenstein, the “elementary proposition consists of names. It is a nexus, a concatenation of names” (Tractatus, section 4.22). But your interpretation must be clearly prescribed by a domain of discourse. To put it more simply, the word “play” means something different to a shortstop than it does to a theater goer than it does to a violinist than it does to a femme fatale in a film noir than it does to a toddler than it does to a deconstructionist philosopher. “Gradient” means something different to a data scientist than it does to a UI designer.

As you conduct your analysis, it’s powerful to realize that you are operating within a discourse, a patois, a learned and shared and, to some extent, private language. What are the terms you aren’t sure of? What are the terms someone else might not be sure about? Your work and the spheres of technology and architecture participate in what Wittgenstein called a language game. We use old words in new ways, and new words in old ways, and apply a word from one realm of life to another. Words have a preponderance of meaning.

This causes confusion, missed expectations, improper specifications, and incorrect application. It’s bad for software and organizations.

To sum up the point of this second of the five key questions: “stuff means stuff.” Being aware of the language games in which you and your teams are working is a great step toward being clear with your language.

This allows you to be clear on your definitions of each proposition, such that you can assign quantifiers and qualifiers with more rigor. You examine here what is believed, what is doubted, what is hoped for, and what has been invested in to determine the truth value of your proposition. For example:

• Ask yourself how biases might be entering your work. Keep a data dictionary to act as a glossary of terms if necessary. Keep your language and terms clear and precise and accurate. A common mistake here is use of the word “platform.” People in tech say it so much that they think they have one just because they said it, but it often is improperly used as a synonym for “system” or “application.” A true platform offers APIs that allow customers to build something new of their own on top of it. Android is a platform. Alibaba is a platform. AWS is a platform. Salesforce is a platform. Your mission-critical system might be important to your customers, and wonderful, but if people can’t make new applications of their own on top of your system without talking to you, it’s not a platform.

• Ask yourself what language is used that isn’t clear. I have heard product managers ask teams for a “concept model.” This was apparently an art term brought over from a previous employer, and might be a great idea. But no one knew what it was. Is it the same as an information architecture? A set of use cases? A set of UX wireframes? Are we telling customers that we’re delivering an AI platform, but the data scientists think we’re doing a few machine learning algorithms in the background? That’s laudable, but different, and linguistic alignment turns out to be A Thing. You can’t deliver it if you don’t know what it is. Rooting out ambiguous terms will go a long way later.

3. Possible Outcomes

Our third question is, What are the possible outcomes?

Determining the possible outcomes of a decision or action is an act of imagination, and also of reasoning. You can brainstorm with your team to consider what the possible outcomes might be. Write them down into a MECE list. Keep this list around in a spreadsheet or something, because although you’ll soon get started by focusing on one path, that doesn’t invalidate others. You’ll want to use this list for further exploration.

Brainstorming is a useful activity when organized and timeboxed. It will give you a load of sticky notes that suggest good next steps. But it’s not going to draw the trajectory from here to a possible future in any sophisticated way, or help you hash through your hypothesis as a thought experiment before you go too far. For that, we’ll quickly review inductive and deductive reasoning.

Inductive reasoning finds a fact (a true proposition) and generalizes from there to create a new proposition about broader circumstances. You draw conclusions based on data. The data, as true facts, offer evidence that supports a conclusion. This is what we hope to do as a necessary first step in strategy construction. This is quite useful in hypothesizing. But people fall into traps when they generalize here, and can draw incorrect conclusions. With inductive reasoning, the facts are certainly true, but the conclusion is only probably true. It cannot be certainly true. Insights are the product of inductive reasoning. It can add nuance and support to the claims you make within your strategy work if you show the probabilities. More importantly, you must be careful to not take as certainly true what is only maybe true. We see this frequently at business meetings, and we need to be able to identify when claims are being overstated so we can determine what other evidence we should collect, or take a different direction in the analysis.

Start by defining your terms and looking at the data you have, and labeling it properly. What relevant facts are there, what research can you do, what database queries can you make, what invoices can you find, what logs can you trace, who can you call up to get a report so you can start with some thread of data?

If you’re considering opportunities instead of problem solving, read McKinsey Insights reports, industry articles, technology trends books, business books, Harvard Business Review, O’Reilly books, MIT Sloan School of Management books, and your favorite websites, and talk with your colleagues to see what you might be able to take advantage of.

Either way, it’s a research problem, like in school. You’re like an investigator at the scene of the crime. You need a starting point that isn’t based on conjecture. You don’t need the whole picture, and probably can’t get it yet, if ever. So you start with something concrete to work with and take a shot at making a hypothesis quickly so you can start testing.

4. Probability of Each Outcome

The fourth question you ask in conducting an analysis regards figuring out how likely different possibilities are to occur: What are the probabilities of each of these outcomes coming true?

You don’t have to be super-specific, like “the probability of hypothesis A coming true is 76%.” If you feel you have enough real data and sophstication in your methods and a small enough problem set to make such a claim, knock yourself out. But I try not to talk that way. That’s because in general, people whose full-time jobs it is to predict things are typically pretty bad at it. For instance, Kevin Warsh, former governor of the Federal Reserve System, recently stated at the AH&LA Forum in Virginia that the Fed accurately predicted 0 of 144 financial crises globally that resulted in a recession between 2005 and 2014. And that’s kind of all the Fed does. But you can roughly assign probabilities to each of those outcomes with some kind of traffic light to represent ranges of probability such as High, Medium, or Low.

We might state our claims as “I hypothesize that our customers can increase their revenue by 40% if they use our machine learning product.” Or we might say, “I hypothesize that within five years mobile phones will represent only 10% of the market and therefore we should use our technology to create a wearables product.” Those are fine hypotheses, assuming we have done our homework and can show the data in a slide that helped us draw that conclusion. But one trap here is a logical fallacy called false precision. If we were to ask anyone on the street what the temperature of a human body is, we would likely hear “98.6 degrees.” This is not as true as it suggests. The precision of this number, and the decimal place, gives the impression that it is a single number that is constant and never fluctuates within more than a tenth of a degree. Of course, human body temperatures regularly fluctuate, and depend on a great variety of factors, such that it’s more accurately stated as a range (it’s something like 97.5 to 99.5 degrees under normal conditions). Precise numbers make things that aren’t facts look like facts. Executives don’t like having expectations set for them that aren’t met. We set them up for disappointment when we overstate things this way. We tend to produce numbers instead of ranges for estimates all the time. I suspect that’s because we are afraid as technologists to state that we don’t know something, since our whole careers are predicated not on how sociable and sporting and what snappy dressers we are, but on how smart we are. Train yourself to use ranges. Technologists commit the fallacy of false precision more than any other group of people I’ve seen—as much as 27.3% more.

We must not be misled by the traps of inductive reasoning. Just because we have seen something in the past does not mean it will continue.

Bertrand Russell famously and colorfully indicts inductive reasoning thusly: Imagine a turkey who is an inductive reasoner. He is fed without fail every morning of his life for years, and reasonably concludes this will continue to the point of never thinking of it, until Thanksgiving morning when his throat is cut. This is a good lesson for technology strategists and business executives alike.

And we should make another, more nuanced point. We can reason that a fair coin has a 50% probability of coming up heads when we flip it. However, upon the first flip coming up heads, we then start to assume that the next time it will come up tails. Thus has much money been lost at the roulette tables in Las Vegas. Every flip is independent of the last. It is possible that we flip a coin 76 times, and that every time it comes up heads. Of course, the probability of flipping a fair coin 76 times and its coming up heads is 1.3 × 10^–23 (or 1 in 1.3 sextillion). We do not expect this to happen. But if, that having happened, we were to place a bet that the next time it would come up tails, we would be seduced into thinking that the chances of it coming up heads yet again must be impossibly low. But there is no “yet again” to the fair coin. Even on this 77th flip, the probability of heads remains one in two. This is debated delightfully in Tom Stoppard’s play Rosencrantz and Guildenstern Are Dead. Upon seeing the coin flipped heads 77 times in a row, one character remarks, “A weaker man might be moved to re-examine his faith, if in nothing else at least in the law of probability.” (Fun fact: Rosencrantz and Guildenstern are two minor characters from Shakespeare’s play Hamlet.) So flipping with the same outcome 76 times in a row is an entirely different question, and different probability, than this discrete flip after 76 previous flips that happened to come up heads. So there are two matters, not one.

We must first understand the data without adding our assumptions, conjecture, explanations, filters, and biases to them, and make sure we’re clear on what we mean. Here’s an example, devious in its apparent innocence. Once when making a strategy for a company, my team needed to understand the number of customers we supported on the current hardware so we could help project costs for supporting more customers in the future, and use that as input to determine the cost differences if we migrated to the cloud. I asked the team how many customers were on the system. I was told it was about 30,000. That ballpark was good enough to start working, but as we needed to refine the business case, we thought eventually we should actually query the database. I was told it was 44,000—a difference of 47%! A short time later, I was given another number of 39,000 and then later, 34,000. This was a very straightforward question. We were all over the map. How could this be? It turned out that there were some guesses, and then some assumptions built into the queries people ran—in one case the DBA filtered by “active” customers (a perfectly reasonable assumption), which refined the query to throw out rows that hadn’t been updated “recently” (whatever that means). Starting with good data and only true facts, and refining what you name things so you’re clear about their status, is critical to increasing the probability of your inductions being true, relevant, useful, and important.

5. Ease and Impact Scoring

The fifth and last question in our analysis framework takes up the set of possible outcomes along with their probabilities, so assigns them a value in order to prioritize them. We ask: What “ease and impact” scoring suggests the right strategy?

We’ve done our homework, collected data, formed propositions as insights while recognizing the semantics at work, stated hypotheses, and assigned them probabilities, and now we’ve got a pretty sizable collection of possible stuff we could set the organization off to go execute. But we can’t do everything at once. So we must prioritize.

To prioritize the work, we’ll use a practical method.

Create a spreadsheet listing your hypotheses or other work items. Add two columns: one for ease of execution (how easy it would be to get that done) and one for impact (how much of a difference it would make to do it, how much positional advantage it would give you). Figure 2-3 presents an example.

Figure 2-3. Resulting scatterplot chart of scoring your proposals on ease of execution and impact/value

Using a spreadsheet program to automatically plot these items, color four quadrants with equal areas behind the plot, like so:

• The top right are items that are relatively easier to do and have the greatest effect. Color this quadrant green. They should be prioritized first.

• The bottom left are the things that will be hard to do and make only a small advance. Color this quadrant red. They should be prioritized last.

• The top-left quadrant are things that are easiest to do but have a relatively small impact. Color this quadrant yellow. They should probably be prioritized second.

• The bottom-right quadrant are things that are hard or very time-consuming to get done, but are important to advancing your strategy. They don’t represent quick wins and aren’t the most important, so should likely be prioritized in a third group.

This is only a guide, not a hard-and-fast rule. It serves only as input for you to make your final determinations on what to recommend doing in what order. So it may be that there are elements from the middling quadrants that you exchange in priority, doing one or two big-ticket items instead of several easier, small ones. This is a judgment call depending on your other competing priorities, team capacity, and strategic directives from executives. The resulting chart makes a great visual for your deck, to help substantiate that you considered many alternatives, took a data-driven approach, and made your recommendations from the many available options based on what made sense.

You can use a variation on this, replacing “Impact” for “Value” and “Ease” for “Effort.” While these are words a businessperson readily understands, I don’t like them as much because they are not both positive axioms, so they’re inverted from each other: you want more value for less effort. So “easy” is good, and “valuable/impactful” is good too. It’s kind of “six of one, half a dozen of the other,” as they say, but helps make the chart quick and easier for your audience to understand, which is empathetic and therefore helpful rhetorically.

Signal and Noise

We can draw a line from the Ease and Impact scatterplot to a related idea: the 80/20 rule, sometimes called the Pareto rule. An common example of this rule is that 80% of your profits come from 20% of your customers. Using the 80/20 rule as a starting point gives us a different way to filter and sort our data, hypotheses, and strategic priorities. It’s an informal way of separating the signal from the noise:

Signal

Something that points to the true state of affairs, something that represents the stuff that matters.

Noise

Random patterns that might easily be mistaken for signal, or the sound produced by competing signals.

Business moves quickly, and we are frequently asked to make recommendations and estimates long before we feel comfortable that we have enough data, or enough understanding of the problem to do so properly. I’ve seen architects poring over data for many weeks on end, trying to ensure they’ve looked at every aspect of the problem before coming to any conclusion. They do endless prototyping and analysis for months just to determine that, yes, in fact the most popular deep learning library is the one they want to use. This doesn’t work for modern business. While it seems thorough, and is perhaps well intentioned, it’s bad for business and it’s unnecessary. You cannot read and try out everything, and everything isn’t important. As Larry Page stated, the only cost that matters is opportunity cost, so hone your intuition to make quick “good enough” conclusions, which you can carefully refine later.

There’s a discussion in Nate Silver’s wonderful book The Signal and the Noise that illustrates the point using poker. Silver discusses how “keeping the water level high” means that new players can level the playing field with very experienced, strong players by doing these things:

• Learn the hands

• Learn a rough idea of the odds

• Fold your worst hands

• Make a modest effort to consider what cards your opponents might hold

Doing only those things will substantially mitigate your losses. Because of the distribution of the cards, 80% of the time, you’ll be making the same decision about your hand as the best poker players would, even though you’ve spent 20% of the time learning the intricacies of the game as they have.

Therefore, when wading through hypotheses to make your strategy recommendations, you can hope to make the same recommendations as the best strategists by using just a few of the most applicable patterns, identifying the most fundamental data points, and developing hypotheses that open to the biggest impact. You might come up with 67 recommendations to fix the problem. What are the 10 best, based on high impact and ease of execution? You have better hopes of getting 10 important things done in a quicker time frame, with more clarity of vision for the teams, if you can prioritize well.

Come up with a few, or several, hypotheses quickly, and pick the one that looks most promising to investigate. Your first avenue might not be right, or it may be that multiple forces are at work and there’s not a clear, discrete, simple answer.

Perhaps the question posed to you as part of formulating your strategy is: How do we make higher-quality products with less defect leakage? You might hypothesize that you don’t have high-quality developers because you don’t pay a market rate. Alternatively, you might hypothesize that you have high-quality developers, but the code base was allowed to grow without a concomitant investment in test and deployment automation. Or perhaps you have a capable development staff and automation but don’t have domain expertise, or the product management team has consistently prioritized features over nonfunctional requirements. Or management says it cares about quality, but at the end of the day, everyone is bonused on hitting the date, and ultimately that prevails at a cost to stable, maintainable software. Brainstorming for a few candidate ideas goes quickly at a whiteboard. All of these hypotheses sound reasonable, and will quickly spring to mind. They present very different strategies for correcting them, and it is not necessary that only one is the most impactful root cause.

There is an obvious challenge with starting with a hypothesis so early in your engagement. You can, almost per force, introduce a bias. That’s to be assumed, and it serves to give you a scope of work to begin to gather the data and understand the relevant factors. And then you can stand back objectively and let the data speak for itself. Revise your hypothesis if the data does not support it, and follow a different path.

Your initial hypotheses may very well be wrong. That’s fine. This is about putting a stake in the ground to get a good place to start, and then coming up with more hypotheses. It’s about proving something right or wrong as quickly as possible so that you can move on.

Context

Taking things out of context is another common cause for faulty reasoning, which leads to faulty conclusions, which makes for bad strategies. Unfortunately, it’s all too common. We forget or forego the context in which an executive or competitor made a declaration, or the context for a managerial decision to use this vendor instead of that, or the context in which an outage occurred or a message was sent.

Recording, and making transparent, how you arrived at a conclusion will help provide context to future readers of your strategy. Indeed, many of these patterns are tools to help you build, piece by piece, a proper set of propositions to arrive at the right strategic conclusions, and happily offer a transparent trail of how you got there.

Resist the temptation to wait until you have all the data before you start. You will never have all the data. There is no such thing as “all the data.” The universe is an infinite conjunct of propositions. Therefore, you must necessarily draw a line around some set of propositions that you collect together in strong relation. Then be bold and make a claim. Ask smart people you trust who aren’t sycophants to argue the hypothesis.

Eventually a hypothesis will need to be tested by action. Let the impact of being wrong determine how much analysis you do before taking that action—to a point. Once you start building on your hypothesis by creating the execution plan, you will be able to tell if you’re in the right ballpark.

Once you’re in the ballpark, you need to perform more data gathering. This means conducting research within your company and on the web, reading industry reports, and finding anything you can to help you determine that your hypothesis is true (in the case of diagnosing problems), or probable (as in the case of imagining opportunities).

This is a simple technique, but starting with it early in your strategy engagement will help align your subsequent strategic technology choices with the business.

Objects and Relations

As Wittgenstein shows us in the Tractatus, the world is all that is the case. It is a collection of propositions, an infinite conjunct of lists-of-lists of objects, their attributes, and their relations to one another.

For our purposes here, let’s call an object anything that is a possible focus of inquiry. It’s something that we can call discrete, such that we could refer to it directly, as a sign, like a child pointing at a ball and uttering “ball!” (Yes, that’s a very problematic statement in semiotics, the philosophical study of signs, but I won’t fascinate you with the reasons here.)

When you conduct an analysis, determine what the objects are, how they are compositions of other objects, and where objects are finally atomic (no longer usefully divisible for your purposes).

Determine what their necessary relation is to other objects: that is, this object exists if and only if another object does.

What is a necessary but not sufficient condition? To get a job, it is a requirement (necessary) that you apply for it, but that alone is not sufficient, as you must also interview and get accepted.

What are the contingent relations? This object exists if and only if a given relation or attribute continues to exist.

For our purposes, there are a few different kinds of relations in the world, but surprisingly few. Let’s review them, as shown in Figure 2-4, so when we’re conducting research or creating our strategy, we can sort large volumes of data more quickly and reliably.

Figure 2-4. Kinds of relations, on a spectrum of interestingness