Chapter 11. How to Make Great Decisions

THE THING THAT’S DIFFERENT between software and English is not the language. C++ and Dickens share many of the same words. What’s different is that software is the physical embodiment of decisions. Because you can do anything in software (don’t let anyone tell you otherwise), the decisions your team makes about what your software will do, and how it will do it, are skeletons of your product.

Unfortunately, making decisions is not as simple as you saying “yes” or “no” to your team. Unlike most other compilations of English words, the complexity of software mandates that it is the creation of a group, and therefore it is a reflection of the decisions that the group makes. In some cases a Big Boss can dictate decisions. Unluckily, you are not the Big Boss, and you must enable your team to find ways to say no to the things they love. Here’s how to get the job done. If it bears any similarity to convincing a small child to go to bed instead of finishing watching Thomas & Friends, I’m sorry.

You will start by trying to defer the request. “We’ll finish it tomorrow,” you’ll say to little Johnny, who is the world’s biggest Thomas the Tank Engine fan. If Johnny starts to cry terribly, and you’re a sucker, you’ll try the next technique, which is negotiating. “OK, OK, sssssshhhh…10 more minutes, OK? 10?” The negotiation process can be complicated—certainly Johnny will argue for 15—but if you study this chapter, you’ll probably reach a good middle ground with both you and Johnny happy about Thomas. Of course, there’s always a risk that Johnny is simply overtired and confrontational. When this happens, you need to bring all of your conflict management skills to bear, like understanding that most conflict is the result of miscommunication, understanding what triggered Johnny’s response, and using personas to depersonalize conversations. I doubt personas will help you with Johnny, but they will help you depersonalize conflict in your business negotiations. Let’s look at each of these approaches in more detail.

Postponing: “We’ll Finish It Tomorrow”

“Featuritis” is a common affliction because we humans are afraid of conflict, and many software team leads are afraid to say no. Sometimes the fear isn’t of conflict, but rather of not being good enough; software team leads are frequently afraid that the software won’t do everything it could and acutely aware of how much it could do. This attitude leads to fear-based design and in turn generates overly complicated products that never ship. There’s a simple solution to this problem.

Any feature that isn’t part of the absolute minimum viable feature set can go into V2. The test for any feature is, “Can the user complete the basic task for which this software was invented?” If the user can complete the task without the feature, even if the accomplishment of that task was particularly painful and ugly, then the feature can go into V2. You must be diligent about this test, because every line of code (except for unit tests!) decreases the probability of shipping, and without shipping there is no greatness.

If you suggest that a feature go into V2 and you hit resistance, it’s time to negotiate.

Negotiation: “OK, 10 More Minutes”

Nearly every feature or user experience debate ends up as some form of hostage negotiation. You have their baby, or they have yours, and unless someone’s way is gotten…the baby gets it. Whether you’re debating if a bug is a blocker or the icons should be green or blue, this conversation is a negotiation—and the baby in jeopardy is your product. If you were the Big Boss, you could take the baby and run, but you’re not. Instead, you probably have little or no legitimate authority, so negotiating to a great consensus quickly is critical to your success.

The first step in negotiating properly is to understand that even though you are a product owner, you’re not the boss. Your team is working with you because they like you or they like the product. They’re not working on your product because they have to. It’s a given in the software industry that anyone you’d want to work with could easily work somewhere else. Therefore, it’s critical to bring your team along in the decision-making process and enable them to own the product with you.

Team leads commonly make the mistake of conducting decision-making meetings in small groups. Having a small meeting seems efficient on its face, but isolating the meeting from your engineering team can isolate the team from the decision-making process. If you isolate the team from decisions, they will disengage from the product development process and leave you. If you want to be great at shipping, you need a team that feels engaged and empowered to participate and voice their concerns.

A better process for team decision making is to engage with all the members of the team at an early stage, before your plans are finalized. In my experience, this approach is more efficient in the long term because you have the opportunity to explain the business objectives and team goals to the entire team at the beginning of the project. If you instead have many small meetings with senior stakeholders and then deliver a fully baked plan, you will probably need many more small meetings to deal with concerns that arise late in the game. Even worse, one or more of those concerns might be legitimate and cause some substantial change in your plans. Good project management technique says that you want to take all changes as early as possible in the development process.

Management guru Peter Drucker has a slightly different take in his book The Effective Executive, arguing that you want to have brief meetings with clear goals and relatively few attendees. His advice differs a bit from mine, but he also says that the effective executive should publish the agenda for the meeting to all concerned parties and plan to send clear notes afterward. This enables concerned parties to join the meeting and marginally concerned parties to understand the outcome. The details in his approach align well with what I suggest, so feel free to follow Peter’s advice, even though it is somewhat less collaborative.

If there’s a guiding principle that you should embrace when thinking about whom to involve in decisions, it’s transparency. Be transparent about why decisions are made. Be transparent about when decisions will be made. Be transparent about how your team can engage in the product process.

Once you’ve brought the right people together, you need to negotiate to consensus, not to a victory for yourself. Many software leaders can be a bit macho, and this leads to a victory-first approach. In a classic example, a young, tough, macho Google product manager went into a naming review at Google to decide the public name for his product. He was remembered by the marketing team later as saying, “Let’s call it Google Turbo!” and was, unfortunately, laughed at. Macho tends to be bossy, confrontational, and occasionally comic.

It is therefore unsurprising to me that many of the best software leads are women, even though men primarily populate the profession. Anita Woolley and Thomas Malone conducted some studies that offer insight into why this might be the case.[6] By comparing the IQ of individuals to the IQ of groups composed of the same individuals, the researchers discovered a remarkable and strong correlation: the higher the ratio of women to men in a group, the higher the collective IQ of the group. Their theory of causation is not the lack of a Y chromosome. Instead, they believe that the women in their study brought more collaborative skills to the exercise, whereas the “macho” types tended to act like a boss and dictate an answer.

Woolley and Malone’s conclusion makes complete sense to me. Brian Marsh, an engineering manager at Google responsible for a substantial part of Google Apps’ and Google+’s success, says that a team lead “needs to learn to move at the speed of N, where N is the size of the team.” The women in the study were able to reach a consensus that was smarter than they were individually, and the men weren’t. In other words, their collaborative approach generates a product name that’s better than “Google Turbo.”

Put another way, in an old-style compromise between you and a teammate, both of you win 50%, but both of you also you lose 50%. Alternatively, if you and your teammate can work together to reach a creative consensus that achieves your collective goals, 100% of you win and you have achieved what the women-influenced groups in the study achieved—a smarter outcome than either of the individual solutions.

Your goal, therefore, is to facilitate a creative solution that meets the needs of all parties. The Harvard Negotiation Project, popularized by Roger Fisher and William Ury in their book Getting to Yes (Penguin), identified the first key step in this process, which is to agree on the objectives.

Let’s pretend that I want to use your address book service in my Hello World application. I ask nicely, and you say no initially, because you’re already underprovisioned and you don’t have additional capacity in your servers. I bet this is feeling familiar, right?

You and I can state and agree upon the objectives that we have in this conflict:

  • You don’t want your servers to fail because of my requests.

  • Your existing clients can’t have a decrease of service quality as a result of my usage.

  • I need to use your address book service and get good service quality.

  • Neither of us wants to be a jerk.

These objectives seem pretty reasonable, and because we agreed that they were reasonable, we started from a point of consensus. Now we can work through each objective to invent a number of solutions that meet all the criteria, such as locally caching address book data on my servers, adding more capacity to your fleet, or building in support for HTTP 503 messages with a response field that points to a read-only version of the database, etc. Inventing a win-win solution that meets the needs of all parties is one of the most important and satisfying parts of being in a leadership role, and should inspire you to embrace negotiations as opportunities for invention.

Sometimes you’ll get stuck in your negotiation before you can even discuss the objectives. When this happens, there are three techniques that I’ve seen help get the negotiation back on track:

  • Focus on facilitation. Don’t start by trying to solve the problem. If you start trying to solve the problem, you take on a point of view and become an interested party, which can make the discussion more complicated. Instead, start by making sure that everyone gets heard. Pay attention to the extroverts, who tend to speak a lot, and the introverts, who are less willing to speak in a group but must be heard when they do speak.

  • “Seek first to understand, then to be understood.” Personal growth guru Stephen Covey authored this principle in his book The Seven Habits of Highly Effective People (Free Press), and it’s profoundly true. I’ve found that some of the most influential people in an organization are also some of the worst communicators and are under more pressure (time and otherwise) than is reasonable. Therefore, you have to work incredibly hard to figure out what the other party is really saying. Ask yourself, what does he or she really care about? Then confirm your assumption with questions.

    Frank Patterson, dean of the Florida State University College of Motion Picture Arts, once taught me a nice model for working with actors that applies here. Before trying to offer direction to an actor, articulate what you see by saying, “What I hear you saying is…” By reflecting the message back to the messenger, you give that person the ability to correct you and you minimize communication failures. This is a great technique that emphasizes your desire to seek first to understand, then to be understood.

  • If you already have a bias, go ahead and put it out there and then let others speak. I think that when the other party is already aware of your beliefs, it makes sense to start by stating your objectives and then pass the baton to the other party so that you can listen. This approach is genuine and efficient.

Up to now, we’ve focused on negotiation and collaboration in general, but there’s a common scenario that requires a slightly more specific set of skills: financial negotiations. Sooner or later, you’re going to do a deal for real money, not your Monopoly money stock. Your first deal, or even your 1,000th deal, can be intimidating, particularly if you own the company and it’s your money you’re going to spend. However, nearly all deals are pretty straightforward even though they feel fraught with craziness. I’ve done quite a few of these deals, including two corporate acquisitions at Google, and I’ve learned that negotiating financial transactions is like grieving: there are stages, and if you understand them you can better cope with your life and the outcome of the deal.

Stage 1: It’s Not About You

Financial negotiations are nearly always guaranteed to be frustrating because the corporate media elite built up high-powered negotiations as a way of establishing self-worth in the business world. If you believe that your value as a human is a function of your ability to get a fractionally lower recurring service fee from your bandwidth provider, then I’m sorry for your family. Please seek counseling before reading further.

If you see this syndrome in the party you’re negotiating with…once again, I’m sorry. Quit now or accept that if there’s a perfect middle of the deal, you’re not going to end up there. You’re going to have to give this macho a-hole his or her pound of flesh if you want to move forward. Accept it and get on with your life. I find it helpful to remind myself that his or her marriage probably stinks.

If you don’t believe me that financial deals are excessively macho and media-based, look at the typical phrases used in deal making:

  • “It’s time to open up the kimono some more.”

  • “We showed you ours, now let’s see yours.”

  • “Are we going to go to the dance together?”

  • “Eventually we have to stop dancing and get down to business.”

Yuck! Do yourself a favor and avoid warning-level offenses: don’t use these icky aphorisms. If you find someone using them, let such phrases be a reminder to you that he or she is in stage 1. Ask the individual to stop and move on to stage 2.

Stage 2: Being Fair and Using Data

Now that you’ve put away the “I have to get the lowest possible price because that’s what Gordon Gekko would do” attitude, you can go about negotiating reasonably. The most reasonable way to negotiate a number is by trading data. For example, you volunteer some data: “I can get bandwidth from AT&T for $1/Gb.” Then the other party will volunteer additional data: “Our costs are $0.95 per Gb.”

Hopefully things end nicely at this point, settling at $0.98 or $0.97 per gigabit (depending on who’s more of an a-hole), and both parties win. Your provider gets a tiny margin and you get a tiny discount.

If only most negotiations were this way! Unfortunately, you’re probably saying, “I’m willing to pay $0.75,” and they are probably saying, “We need to charge you $1.25.” You’re not done yet. You’re only entering stage 3.

Stage 3: That Data Didn’t Close the Deal…Let’s Make Up New Data!

The reality is that financial negotiations can take a very long time because you or your counterpart are constantly disclosing and inventing new information. It’s the inventing information bit that’s particularly challenging. You may invent your build costs: “It’ll cost me five engineers for a year to build this, so I shouldn’t pay more than $1 million.”

Once you cross this line, and you will, the other party will then likewise invent information: “Yes, but your time to market will be accelerated by six months, and that’s worth at least $5 million, so you should be willing to pay at least $4 million.”

This phase will eventually pass, but in the meantime it’s a hand-waving arms race, trying to figure out on which side of the middle you will land. Accept that you have to go through this phase and try to get through it quickly.

Stage 4: Searching for Things That Are Free to Give

Eventually, both parties are sick to death of arguing over how many engineers for how many months it will take to integrate, or how much each customer is really worth, or how long it will take Microsoft, Google, or Apple to build competing technology. In stage 4, each party tries to throw worthless crap that costs little to give into the deal. “We have major launch plans,” you say, “we’ll put you on the stage at Moscone Center.” The other side won’t even bother to put a value on this marketing ploy, and the reality is that you shouldn’t expect them to do so; you’re just hoping that if you “sweeten the deal” enough, they’ll take the last number you offered in stage 3.

In many ways, this “deal sweetening” phase is time that each party spends trying to get comfortable with The Reality Of The Situation, which is that neither of you is going to make out like a bandit. It’s too bad, but we always feel disappointed at this point, even though bandits are the bad guys—except in movies, where “corporate raider” sounds glamorous (see stage 1).

Stage 5: Walking Away and Thinking

It’s possible that after throwing in a few pot sweeteners and a few months of negotiation, everyone is so tired that you’re ready to do a deal. So you just do it. If this is you, proceed to stage 6 and light a candle at the chapel on the way home. Also, some money to the Salvation Army Santa might be in order.

Most of us are not so lucky because fatigue makes everything worse (or so my new-mother friends tell me). It’s possible that stage 1 (in which you wanted to be Gordon Gekko, master of the universe) may rear its ugly head again. Posturing may ensue: “OK, we’re too far apart; I guess we’ll have to build it ourselves.” Threats may be made: “We’re going to put you out of business anyway…” Phones may be put on mute and warning-offense quality curses uttered.

It’s at this point that a necessary cooling-off period is introduced organically. One party walks away from the deal, or gets upset and stops returning calls, or whatever. This is a good thing for the process because both parties get distance from the negotiation and return to being close to their products. This newly created distance allows you to consider again The Reality Of The Situation.

The products are where the deal started. You want them and they want you. If you really can’t live with the other party’s terms from a business standpoint, then yes, walk away. If you can live with the terms, then you’re going to have to take them. Give the discussion a couple of weeks to cool off and start over at stage 2, in which you share data. Stage 2 will play out differently this time because you’ll be willing to share more data and pay more money. The other party will also share more and be willing to take less, and you will all be somewhat more motivated to reach a number that is acceptable.

Stage 6: Agreement, Paperwork, and Recriminations

Just when you thought you were done, you’ll discover that any reasonably valuable deal is going to require a lot of paperwork. It’s not the paperwork that’s the problem. The problem is that there are tiny details inside the paperwork that can bring you right back to stage 5 and have you plotting scorched-earth solutions to this deal. These details exist because any contract that’s going to be effective needs to be extremely clear. To add clarity you must define every detail, and it is at this point that you discover miscommunication—and miscommunication leads to conflict.

If both parties are exhausted and macho, the deal will go off the rails at this point, in the same way that a mythical quarter can derail Amtrak. Remind yourself that this is merely a quarter, not the whole $10 million stack of bills, and let it go if at all possible. Employ the techniques for dealing with conflict that are described later in this chapter, and work hard to get the train back on the rails. You have, after all, “agreed to go to the dance” with these people, so be the bigger person and eat at the restaurant at which they want to eat.

Months later, you and your deal team probably won’t care about how much you paid. Over a beer, all you’ll remember is how long it took to do the deal. You may look back and say, “Why the heck did that take so long?!?” The answer is that most of the time was spent on stages 1, 3, 4, 5, and 6. Yep, these are the steps that were not based on hard data. So, if there’s a moral to the story, it’s don’t be macho.

Dealing with Conflict

The third and final tool you need to reach a great consensus is conflict management. We can assert from the start that there are a lot of a-holes out there, and they breed conflict. You may even think you work with a unique nexus of a-holes, idiots, and self-absorbed twits. But because you’re in the software industry, the odds are really quite small that this is the case. The odds are much better that the people you work with have subnormal communication skills and supernormal technical skills.

“But wait,” you may be saying, “I work with product managers and engineering VPs and designers—they certainly can’t have bad communication skills!” Ergo, they must be a-holes. You might be right. More likely, these people are so used to dealing with engineers and folks like you that they’re desperately insecure and afraid that you’re going to randomize their efforts. These people also care about shipping. Perhaps they care less about shipping than you do, but they care enough to be afraid that you’re going to alter their designs, objectives, or question their decisions in such a way that you’ll spark a reset.

Tony Schwartz is a management guru who wrote that in situations like this, you need to tell yourself a different story.[7] The story he’s talking about is the explanation you create for yourself to explain someone’s bizarre behavior. But it’s just that: a story, and it’s created from assumptions. Instead of assuming that the other person in this conflict is an a-hole, consider telling yourself a different story.

I’ll give you an example. When I joined the Maps team at Google, I was really frustrated by the design team. They seemed sharp and nice, but I was constantly butting heads with them when I asked normal questions like “What is the user problem you are trying to solve?” They would respond with, “Our design goal is ‘the map is the UI.’ You really need to spend more time with the other product managers.”

I was inclined to believe the Maps designers were idiots because “the map is the UI” is not a design goal and it doesn’t help users. But late into a whining rant over a bottle of white Côtes du Rhône, a designer friend of mine suggested a different story. “They’ve had no business goal,” she said. “Instead, they’ve been getting random complaints for years and since they’ve had no business goals, they’ve had to try to do your job on their own. They invented an organizing principle that could absorb all these tiny complaints from random VPs. And they may see you as just another one of those VPs.”

It’s not every day that your friends will give you brilliant insight, I know. But you can effect the same outcome, and save some bank on the vino, by saying, “OK, I’m telling myself the story that they’re idiots. I don’t actually have the IQ scores to back that up. Perhaps the story is that the former VP gave them a horrible objective, and they’re trying to live to it—in which case, it makes sense that they’re defending it.”

If you change the story you’re telling yourself about the other party, you can internally position yourself to have a more positive response to a conflict.

Now that you’ve convinced yourself that the guy you’re dealing with might not be an a-hole, you can get to the root of the problem. About 90% of the time, the root cause for your conflict is miscommunication. The other 10% of the time is divided between 1% genuine a-holes and 9% misaligned objectives.

All you really need to understand is that 90% of the time, you and your counterpart are “talking past each other.” In other words, you agree about the important things and are getting hung up on some detail or language problem. I find that engineers and engineering managers frequently focus on details when they really care about something much bigger, like not writing duplicate code, because it’s easier to be specific about a detail. By understanding that you’re most likely talking past each other, you can take a step back and ask yourself what the other party is really trying to say. This is the first major step.

Once you’ve established that you’re talking past each other, you can use that opportunity to establish a common vocabulary for the discussion so you can avoid miscommunication that results from language problems. To do this, you need to understand that engineers and teams frequently imbue certain words with special meaning. On one team a “hack” might be a horrible, dangerous thing, while on another team a “hack” might be a nice shortcut. Or, as I learned on the Maps team at Google, a common word like “landmark” might represent a whole class of things (restaurants, hotels, and the Eiffel Tower), rather than just the Eiffel Tower, which was referred to as an “attraction.” Such generalizations and naming conventions are de rigueur in software because that’s how software works—it operates on abstract objects and applies properties to make them specific. Therefore, it’s extremely common and entirely reasonable for teams to develop their own language.

Luckily, it’s simple to get past taxonomy problems. Say, “I’m sorry—so we’re on the same page, what are you referring to when you say ‘landmark’?” Engineering teams will be happy to explain because they love defining things. It’s one of the reasons why they write code.

If you are both using the same words with the same meaning, you may be “talking past each other” because one of you doesn’t understand the context of the conversation fully. Most of the nonengineers you work with are spread very thin across many projects. They do not necessarily know why you’re discussing a topic, and you don’t necessarily know why they are being a jerk. Take a step back and say, “I think we might be talking past each other.” Then get, or give, the context. For example:

Just for context, and so we’re all on the same page, maybe I can give a little background? We’re trying to build an application that does text-to-speech for blind users. Unfortunately, we want to ship at the Consumer Electronics Show, and that means we have a hard deadline. And, because our target user is blind, we have to make some tough decisions and optimizations. Does that make sense so far?

This example reveals two critical and common contextual elements. First, time is always a challenge, and clearly articulating the time constraints will help the other person understand what is possible. Don’t believe me that time is a problem? Have a friend tie two moderately complicated knots. Then, you and another friend untie the knots while blindfolded and not speaking. Repeat this task but with a one-minute limit. The difference between the two experiences is remarkable, and you probably encountered some frustrating, nonverbal conflict because although it’s initially challenging to communicate while blindfolded and mute, everything gets worse under time pressure.

The second dimension that the example shows is that there are frequently assumptions that other people make or don’t know about. In this example, the design target is a blind user, and that user has different needs than a typical text-to-speech user. When you provide context to teammates, be sure to tease out these assumptions because they frequently lead to miscommunication.

On a related note, try to keep your project name the same throughout the life of the product, because if you change it, you’ll confuse the people who didn’t hear about the name change. If you’re in a tiny company, changing the name doesn’t matter, but it does in a big company. Renaming a project rarely delivers enough benefit to make dealing with the resulting miscommunication worthwhile. And it will increase your Excedrin bill.

When words are failing you, and your attempts to clarify them through taxonomy and context are also met with hostility and dismay, turn to the whiteboard. I always have a big whiteboard by my desk for this reason. I’ve found that pictures and lists drive clarity. By writing down what you’re talking about, the other party can focus on the pictures or the words on the board, rather than words in the air. This is a simple technique, but it’s remarkably powerful.

There are times, however, when conflict is not the result of explicit miscommunication or fundamentally divergent viewpoints. Sometimes conflict occurs when someone pokes you in a place you don’t like being poked. You’ll know when you get poked because you either want to slug the bastard or run away. You had a classic fight-or-flight response.

When someone pokes you in a way that triggers you, take a full minute to understand what just happened. Stall. Say, “Huh.” It takes 60 seconds for the initial bolus of adrenaline to be absorbed into your system after you’ve been poked, and 20 minutes for that adrenaline to be completely absorbed. Therefore, doing absolutely nothing but stalling for 60 seconds gives you time to avoid running from the room or from poking that person right back.

If you want to get better at coping with the strong emotional responses we all have, you need to identify what triggers such a response. Maybe people who use your childhood nickname upset you, or maybe engineers who question your technical judgment really get your goat. Regardless of what the specific trigger is, being aware that you were poked in a sensitive place will give you the handle you need to wrestle your reactions back into shape, and over time your sensitivity will decrease.

Even if you can manage your triggers, it’s clear that working on software is an intense business that will occasionally cause tempers to flare. Most people work longer-than-average days and care passionately about the work they produce. It’s not surprising that emotions are strong, and you’d best accept right now that you’re going to piss someone off, especially if you’re trying to ship. But you may be able to minimize the frequency with which you piss people off if you can depersonalize your conversations.

Depersonalizing conversations means making the discussion about the software, the user, or the problem—not about the humans involved in the conversation. There are some powerful techniques you can employ every day to help ensure that you depersonalize your discussions and increase the probability of a stressless outcome. My top three favorite depersonalization techniques are:

  • Don’t say “You” or “I.”

  • Focus on the persona, not the people.

  • Use objective measures.

Don’t Use “You” or “I”

Try removing all instances of the words “You” and “I” from email. This technique depersonalizes the correspondence and focuses statements on the product rather than on what “you” think or what “I” contributed. If you can bring yourself to remove “you” and “I” from verbal communications, do that as well. You may find that you write in the passive voice more often, but it is a small price to pay to reduce your team’s stress levels and increase their happiness. Google is such a strong supporter of this approach that members of promotion committees are not allowed to say, “I think…” Instead, the committee member is supposed to say, “The promotion packet indicates…” Similarly, parliamentary protocol doesn’t allow politicians to speak directly to one another, which adds a layer of buffer and helps make the arguments less personal.

Focus on the Personas, Not the People

Another powerful way of talking about problems is to use personas like you might use sock puppets. Sock puppets have stood the test of time because they depersonalize challenging conversations, and personas can do the same thing. For example, instead of saying, “You don’t really want to sign in first, what you want to do is find out if the product is in stock…” you might say, “Sarah Shopper is a shopper. She wants to look around and evaluate her options. What does she want to do?”

Talking through Sarah Shopper depersonalized the conversation substantially. What’s more, personas are effective when it comes to making hard decisions, because the person who will get the short end of the stick when you cut that special feature is the persona, not the person who invented it. To continue our example, you might say something like, “We’ve said that Sarah is more important than Stanley. So we will need to optimize for Sarah here.”

Use Objective Measures

When I interview product managers and ask them to tell me about a time when they had to change someone’s mind, they almost always talk about how they used facts to turn someone around. They rarely get hired because their stories inevitably end badly. It’s sad, but the real world doesn’t care much about facts. You can see evidence for this trend in the Fox News “I don’t have the facts to back this up” approach to reporting. If you’re going to live in a world where facts play second fiddle to opinions, you’re going to need a way to deal with opinions as if they are facts. Luckily, we have usability tests and decision matrices.

Usability tests are great for establishing whether a subjective experience—user interface—succeeds or fails. You can read more about usability tests in Chapter 3.

A decision matrix is a simple chart that you build to help you decide between options. Table 11-1 demonstrates a decision matrix that will help me choose a pet.

Table 11-1. Pet decision matrix

Criteria/animal

Cat

Dog

Rabbit

Doesn’t shed

0

2

1

Cuddly

1

0

2

Friendly

1

2

0

Total

2

4

3

Clearly I should get a dog. When you establish a set of criteria by which the team will evaluate options and then evaluate those options as a team, you will craft a transparent picture of what your goals and priorities are. In addition, because the team can weigh in on each dimension, the discussion can focus on much more granular elements so no one is losing everything. Put another way, if I think “dogs are definitely a 1 on the cuddly scale,” and you think “nothing that drools like a dog can ever be cuddly, it’s a 0,” you and I are much more likely to be able to reach a consensus than we would if we were debating whether cats or dogs are better, because the worst case for both of us is that dogs are overappreciated or underappreciated by one point. That’s very different than an argument about whether dogs are better than cats.

It’s good to go a step further in your decision matrices if you have time. If you add a “weight” or “priority” column, as shown in Table 11-2, the team will have to discuss and agree upon the relative importance of various decision criteria. This process is immensely valuable for getting your team on the same page. In your case, you might have to compare reduced development time, increased scalability, and increased testability, all of which are good and important things, but you can’t get scalability and testability without spending more development time! In my case, I really don’t want an animal that sheds.

Table 11-2. Decision matrix with weights

Criteria/animal

Weight

Cat

Dog

Rabbit

Doesn’t shed

2

0

2

1

Cuddly

1

1

0

2

Friendly

1.5

1

2

0

Total

 

2.5

7

4

Good. Snoopy can stay.

..................Content has been hidden....................

You can't read the all page of ebook, please click here login for view all page.
Reset
3.144.109.223