Among engineers and product managers, a pros and cons document is a fairly common practice. The practice calls for outlining a problem statement that defines the scope of solutions, then lists potential solution options, with two lists for each option: a list of pros and a list of cons. It’s a fairly straightforward and easy to follow pattern.
After observing it in the wild, one thing that I am noticing is that this pattern tends to yield somewhat unsatisfying outcomes. Here are some typical failure cases.
In one failure case, as we add the pros and cons, we somehow lose sight of what’s important: the lists just grow with various things we observe about the options, making comparison of options an increasingly arbitrary process. I have seen several of these exercises stall because the pros and cons list became unwieldy and daunting.
Another failure case comes from the flattening that any list forces on decision-making. Among all options, there is usually one or two that stand out as preferred solutions to anyone familiar with the matter, and the other options are there to make a crowd. It’s kind of like the police lineup. Another variation is where the options listed include solutions that aren’t feasible, however desirable. A police lineup with unicorns, I guess.
Sometimes, options look either too similar or too dissimilar to each other, which deflates the decision making process, and an endless debate emerges. Folks who prefer their option keep beefing up its pros, and diminishing the cons. Instead of being a helpful tool, the list becomes the arena of organizational dysfunction.
Let’s give pros and cons a makeover. I’ve been playing with a rev on the practice and it seems to work more effectively. Here’s what I am doing differently.
First, start with the principles. What are the attributes of the solution that are important to us? What are the desired properties that we want the solution to have? Try to limit the number of principles: three to five is a goldilocks range. This might take a little thinking and wrangling of often-conflicting wishes. If you’re new to the concept of principle-crafting, check out this handy guide I wrote a while back.
The process of discerning the principles is useful in itself, since it leads to better understanding of the problem and possible solutions. This might not feel like problem-solving, but it’s actually the bulk of it. Knowing what’s important in a solution is the key to finding it.
Using principles we’ve just devised, imagine the ideal solution. If the principles are sound, it will just pop out. We should be able to articulate what it is we’re looking for. Write it out, draw a mock, etc. Principles and the ideal solution don’t have to be approached sequentially: sometimes I have an intuition for an ideal solution first, and then have to articulate why with principles.
If we’re lucky, this will be the end of the journey, because the ideal solution is something we can already do. If so, let’s do it!
If not, we move on to studying headwinds. What makes it hard for us to implement this ideal solution? List each reason as a separate headwind, and note which principle it undermines. These require a high level of candor and may be uncomfortable, especially in team cultures that overvalue being agreeable. For example, it might be that our team does not have the right skills, or that the infrastructure we currently use is not a good fit. It is okay to have weaknesses. Knowing our weaknesses helps us make better decisions.
Now, let’s look at the alternatives. This is the familiar step where we generate a list of options. Since we’ve already thought about the headwinds, we can lean on them to come up with better options. Which solutions will be resilient to the headwinds? Which ones will manage to avoid them by compromising on the ideal?
Instead of pros and cons, evaluate how far the solution is from our imagined ideal. Think of it as taking on a “principle debt”: how much are we violating our own principles to solve this problem? The farther the solution is from the ideal, the more work we will have to do to get there in the future. At this step, the key is not to get mired in pros and cons. Instead, play the outcomes of the solution forward and understand its effects. How far from the ideal will they take you?
Pick the option that accumulates the least amount of debt. This will no longer be a daunting task. At this point, we’ve done all the thinking, and will have much better clarity on the matter.
Finally, document the ways in which the solution we’ve chosen would not live up to our principles. Again, blunt candor is preferred here. Each of the items in this list is a bug to be fixed, our “principle debt” payment schedule. Set an intention to fix them over time.
Don’t skip this last step. Most solutions are compromises. If we found ourselves at this step, we picked something that deviates from the ideal solution. Knowing the shortcomings of the solution is our roadmap, a path to iterate toward what we actually want.
If you’re up for it, give this method a try. Let me know how it works for you. I would love to learn about ways to improve it.