‘So again, why did we do this?’

Making rational choices and documenting them is an underexposed element in the design process and in the (corporate) startup. This shortcoming can lead to a lot of hassle and rework. How do you prevent that?

‘“Then why did we choose this flow again?” It is a question that can just pop up in your Corporate Startup. “That’s what we learned in interviews, I believe,” someone says. But which interviews? And how significant was that data? And is that still up to date, now that we have adjusted matters? What were actually our alternatives? And based on what arguments did we then decide for this? It now actually feels like such a strange solution.

And those are only the questions from the team itself. In most Corporate Startups all kinds of stakeholders also play a role. Think of the responsible managers or maybe even the Executive Board. And they weren’t even part of the actual decision making.

If the goals are achieved, there is rarely anyone who wants to delve into the choices made or the argumentation behind them. But if they are not, the team and stakeholders are often interested in the decision-making, often including all sorts of details. “But why did you choose this particular flow, when the competitor has such success with that other solution?” “Well, eeehm …” and you look at your teammates in utter despair.

You would like to return to that moment in front of the scrum board or at the table. Or a more realistic option; look it up somewhere. But the reason that you have not processed everything into thick documentation folders is that as a corporate startup you want to work Lean and Agile. We do not want to write large documents, or fill page-long Corporate Decision Making Balanced Score Cards. That’s the whole reason we were going to work in this new way, right?

In this blog I want to make a stand for rational decision making and Agile documentation.

Rational decision-making

First of all, we should of course discuss the decision-making itself. How rational are the decisions taken in your startup? Often the arguments go everywhere, and a decision is made in a fairly magical process. Nice, that’s done, and now let’s get back to work! In my experience, the job is actually about making decisions. Because do not be mistaken; that is the hardest thing there is. There are different perspectives, interests, arguments at different levels and uncertainties that come with each alternative.

In addition, the circumstances under which a decision is made often play a role. “Let’s just quickly fix it before lunch!” is surely a recognizable phenomenon. Or “quick, we already lost so much time yesterday!” Finally, egos often are in play. The decision-maker is just like a human being. “Last time we did everything that you suggested.” Or “who has a degree in this, you or me?” Naturally we want to spend as little time as possible on those kinds of arguments.

And although I am a big fan of decisions by intuition, in my experience that is often not an interesting solution in this kind of design process. In my work at TU Delft, scientific reasoning is eminently one of the skills we teach design students. Make. Rational. Choices.

The best and fastest way to do that is with Pros and Cons. It will take you no more than twenty minutes. How?

Step 1: Alternatives
Have someone note the alternatives side by side, preferably quickly and concisely. What are the options that we can choose from? Is that clear for everyone? Where is further detail needed? It is important that the alternatives are worked out equally, rather than one being a poorly outlined barrel full of uncertainties and the other a shiny and glamourous production-ready prototype. Keep it Agile, and do not spend more time than necessary to build a choice. Timeboxes also work well here.

Step 2: Diverge
Everyone on the team then takes three minutes for themselves to diverge on the pros and cons of each solution — in other words, to look at them ‘broadly’. Advantages are written on green post-its, disadvantages on red ones. You will discover that lots of original and useful arguments will appear, much more than when you immediately start discussing the obvious arguments. Each person then pastes the post-its — possibly while commenting — on the board with the various alternatives, and then the team quickly sorts them into categories. Together you supplement where necessary. Stop once everything is clear. This takes about five minutes, all in all.

You then paste the post-its per person — eventually while commenting — on the board with the various alternatives, and cluster for a moment. Together you supplement where necessary. Stop once everything is clear. This takes a minute or five, all in all.

Step 3: Weighing
Often not all arguments count equally heavily. So you have to agree on how to weigh them. How often the different arguments appeared on the board can be an indication, but that does not necessarily have to be the case. Maybe they are just the no-brainers that pop into people’s heads first. You can give a weight to the various arguments. For example, put one, two or three exclamation marks on them. This will take five minutes or so.

Step 3: Decision making
If an option clearly stands out head and shoulders, you can choose it. Well, great! If that’s not the case, there are a few possibilities.

Option one: you still lack information. In that case you clearly write on a post-it which info you still need, who will arrange it, and when the next planned decision will be. Think of tasks like ‘Find out what the impact on the server load is’, ‘calculate what that means for the business case’ or ‘validate whether users understand it’.

Another possibility is that the options are really matched. Then you need a different decision-making process. ‘Toss a coin’, I sometimes say. Intuitively it’s a strange choice to leave something so important to chance, but if the result suddenly doesn’t feel right, the options were apparently not really equivalent.

For example, I also recommend that anyone who still cannot choose from two ski chalets after 15 minutes of viewing them online, to do heads or tails. After all, if it would have made a difference, you would have already chosen.

Documentation can be really Agile

Rational decision-making is one, but if we do not document it we will still be in the dark again three months later.

So how do we document decision-making? In Scrum, for example, we take a quick photo of the board with the pros and cons. Nice and fast and no trouble. Pictures are categorized by date and location, and are therefore easily retrievable.

If you make a shared textdoc and paste the photos there, the advantage is that anyone with full-text search can easily find things later. Then just add a few tags that refer to the decision and that you expect to search by later. It does not have to look good, because that only takes time.

Make decision-making a ritual

Decision making is ideally suited to make into a ritual. With a clear format, a clear timebox, and a clear way of recording. You can follow my approach, but it is agile, so inspect & adapt until you drop.

Finally, you take dozens of conscious decisions in your innovation process every day. What are you using this method for? I would say: for those decisions that you expect to need again in the future.

Imagine that in three months you will find yourself staring at your product with your team in full despair, standing in front of the Executive Board or sitting at the table with your investor. Is this one of the choices that someone is going to ask about? Then you now know how to make sure you won’t be at a loss for words.