How to make a decision - my current practice

Here is how I have been making 40+ decisions in a year - a simple yet efficient, structured framework that you can start using today.

This “decision leaders” project aims to dig into decision-making processes. But before diving into more elaborated decision strategies, I wanted to keep and share an accurate picture of my current practice here at Partoo.

Partoo went from scratch to about 80+ people. As co-founder, I successively undertook the position of CTO, CPO, and lately Product Manager. Necessarily, with rapid growth came increasing complexity, including in making decisions. A large part of any Product role amounts to the choices you make. In this context, I found it harder to identify and align stakeholders and communicate explicitly on decisions. A brief look into what a RACI matrix meant offered little help. The real eye-opener appeared during the talk “How Alan stopped having meetings” (originally in French “Pourquoi et comment Alan a supprimé les réunions ?”) organized by LPC in May, 2nd 2019 - you can watch it here.

At this event, Thomas Rolf - Product Manager at Alan, which is an outstanding health tech startup - presented a framework that I still use to date. Since then, I created not less than 40+ such documents to guide my decisions and align my teammates.

The secret: a structured document with each section for a given purpose

Below is a close-to-reality example of a document inspired by a real use case I had.

You can access the decision doc Notion template here - it features additional instructions.

A few details and tips I want to stress out:

• About the name of the file: it must be straightforward whether the decision is closed or not. I use a prefix [open] or [closed] to do so.

• About the context: it must be concise - no more than three short bullet points if you want your colleagues to read it.

• About the options: I saw a better commitment when I made short commented videos describing options using Loom software. Especially for UX decisions. Also, each option should have a short name - so that it is easy to relate to them.

• About the timeline: I usually add one or two extra steps I will follow once the decision is closed. It helps stakeholders gain context about where this decision sits.

• About the comments: make sure to write your comment first by stating which option you prefer. It also indicates that by the date you mentioned on the timeline, if no one takes part in the decision, you will be selecting your preferred option.

• About the “decision taken” section: I generally add it at the top of the document once the decision is closed. It makes it super clear about what was agreed upon for later consultation of the material.

A flexible structure with many advantages

I found myself using this structure for a wide range of decisions from strategy (e.g., what should we offer to this partner in this situation) down to UX details (e.g., represented in the screenshot above). I remember Thomas Rolf mentioning that it could even work for branding purposes.

After practicing this framework for about a year, I noticed multiple advantages.

In preparing the document, I often realize any shortcomings I had not anticipated. For example, I often adapt any mock-ups to make them more realistic in terms of usage so that the stakeholders can be closer to a practical use case. Doing so always comes up with unanticipated details.

In communicating the decision, it simplified my email messages. Now, all I need to write is a one-liner for the decision, the name of the options, and the timeline by which I want to close it. I see my colleagues more and more autonomous when interacting with these decision documents. At first, I regularly had to go to the person and guide them through the text. By now, I think that seeing the same document structure every time makes it easier for anyone to go through.

In aligning stakeholders, this generally improved their support since it gave them a chance to participate in the debate. At the same time, it also offers to be asynchronous - you don’t have to stop whatever you are dealing with to give your opinion and select the option you think best fits. Furthermore, it offers total transparency for anyone in the company. All the decision documents I created are accessible to anyone.

Finally, I guess that there also is an unfair advantage related to anchoring bias since I had not seen many cases when a stakeholder gave an additional option. It often boils down to one of the options listed.

However, if I had to mention any limits, I would think of two.

First, we are using Google Docs as a note-taking app. Even though everyone is used to writing documents with Google Docs, reading a Google Docs document is always a bit painful. I do think that the reading experience is severely undermined - and this includes precious decision docs.

Second, it is evident that it costs more time than deciding on pure intuition. About the latter, I often anticipate the significant decisions I want to make during the span of a given project. It generally adds up to four or five decision documents on average for projects that are one or two months long.

That’s it. This is how I have been tackling decisions at Partoo for more than a year to great success, in my opinion. It seems well-suited for decisions for which you can only think of (or you only want to present) a small number of options. Again, I can not be more grateful to Thomas Rolf, who shared this framework.

Ready to give it a chance? You can copy/paste from the decision doc Notion template here and start using it today. I can’t wait to hear from you.

---