Improving decision making with all stakeholders

Building digital products in a high paced environment requires various major decisions to be made quickly and with clarity for all stakeholders:

• Which tech stack is best for the job?
• Which APIs and Libraries can help us build the product quicker?
• Since the XYZ API that we implemented actually doesn’t work as we expected, which alternatives should we use?
• Both feature A and B are very important, but we can only build one — which one should it be?
• We are getting behind in our timeline, what should we do?

For a PM, these stakeholders can be an external client, a CEO, a CTO, CMO, an investor, etc… And some of them may be non-technical, which makes the communication about some aspects of digital products more complex.

The common approach is to go on meetings to explain the situation and make a decision. But if communication is not very good during these meetings, more often than not what happens is:

• Different stakeholders have a different understanding of the situation, or may not understand it at all. This results in confusing longer than ideal meetings, and many times without proper closure.
• Stakeholders will believe they understand the situation and the decision being made, when they’ve not. Few weeks later though, when they see the result, they will be badly surprised since this is not what they expected.
• They may panic when realising the challenge they have upfront and enter in an emotional state which makes them stop listening adequately. They may even start looking for the culprit of the issue (if there is one) or why they weren’t informed of this before, instead of focusing in solving the problem.

Thus, unless you are a really good communicator and with great persuasion skills, for important and complex matters as these, jumping on meetings may seem more efficient but it’s often not the best solution — at least when done by itself.

Write a memo

Instead, the approach I’ve found to be the most effective is to first write a short document with the following structure:

Describe the situation in a succinct but clear way

This requires some good writing skills, but what’s great about writing is that you can always read and rewrite, and ask your teammates for feedback, until you believe it’s good enough.

Many times this will involve technical aspects which various of the stakeholders don’t understand. And as a Product Manager, if you don’t understand what’s happening well enough, you must speak with your technical colleagues until you do — this is important also for you to be able to identify which layers of the situation are relevant to communicate or not, and to be able to translate them to non-technical people.

Identify potential paths (and suggest which one may be best)

If you identify a problem but don’t propose a solution, there are good chances that the stakeholders will panic (or have some variation of that).

It’s your job to immediately identify different options and, if you feel it to be right, suggest what you believe to be the best approach. If there’s no good options that you know off, then say it as well — don’t leave things in vacuum.

In total this may be just a 1, 2 or 3 pages document — not a 10+ page report, please — you want stakeholders to read it, so save your gibberish and go straight to the points.

Meet

Now, yes, you can go on a meeting. Hopefully, if you were able to communicate the situation and solutions clearly, by now every stakeholder is aligned about the current status and with good understanding of the potential solutions.

Now you can use the meeting clarify any questions they may have and make a good decision, in an efficient and effective manner.