I’ve noticed a pattern in much business writing, including technical writing. People feel compelled to label every effect as “pro” or “con”. I think this springs from our primary-school training in persuasive writing. As a result, what should be an engineering analysis often reads like marketing copy.

(A related effect, when writing persuasively, people tend to minimize or discount the effects they don’t like. Richard Feymann advised students to be their own harshest critics, to find ways to poke holes in their own arguments. It’s the only way to avoid fooling yourself, he said, and you are the easiest person in the world for you to fool.)

Instead, I suggest we first describe simply consequences, not benefits or problems. That’s because a consequence is just a statement about how the future will differ from the past. It is objective.

Whether you judge that consequence to be a “pro” or “con” depends entirely on your relationship to the change. If you perceive the change as an improvement to status quo then you call it a “pro”. If you don’t like the version of the future which includes that consequence, then you call it a “con”. That means labelling a consequence as a benefit is subjective. It describes the relationship of you and the change.

What about the changes that you don’t particularly like or dislike? The ones that are neither “pro” nor “con”? Most of the time those don’t get written down at all!

(As an aside, I also see technical writeups that include a list of “pros” for the recommended solution, where each “pro” precisely lines up with a “con” of the current world. This always tells me the author chose the solution first, then stated the problem in such a way that their chosen solutions appears to be the best option.)

I recommend that you begin by listing the consequences. Find all the ways that the future will be unlike the past, if we choose that path. Look for second-order effects–the consequences of the consequences.

Look for interactions. How does this approach combine with other systems, processes, or people?

As you make this list of consequences, try to avoid coloring your thoughts about the consequences by what your intentions are. Whether you proposed a technical system, a process change, or a policy difference, once the change is made your intentions are irrelevant. Only the resulting system state matters. Anything the system allows will be done regardless of whether that matches your intended application. Therefore, think beyond the intended outcome or purpose of your approach. How could this be accidentally misused? Or deliberately abused?

Armed with this list, you will be ready to think about how the consequences affect you and your organization. This is when you judge whether the effect of those consequences creates a future that you like better than today.

See also: Rawl’s Veil of Ignorance, Unintended Consequences