Motives and transparency

In chess, every piece must work in unison. Every move you make has a motive that ties into a larger strategy, and for your opponent to lose, they must not see it.

Unlike in chess (which is not a game of collaboration), If you’ve ever had to work with anyone, you may have found that providing background information is critical to achieving successful outcomes. Background can be the difference between “I have the stomach flu.” or “I have food poisoning.” Both can appear similar but have very different causes and potentially different treatments. Also, one is contagious.

This post was originally published in my Substack Newsletter, Roadmap Weekly.

For the sake of this post, let’s call that background motives and the process of explaining those motives transparency. I’ll start by giving some high-level context on why transparency is important, and then I’ll explain how we can uncover those motives when we need that background to do our job.

In chess, every piece must work in unison. Every move you make has a motive that ties into a larger strategy, and for your opponent to lose, they must not see it. To win, you must uncover the motives of the other player’s moves. This is an essential skill and valuable knowledge for anyone, not just Product Managers (or chess players).

The impact of transparency

The impact a high level of transparency can have is incredible, but transparency is more than just sharing the company’s strategic vision. It’s about being open and transparent about the motives (the factors) going into the decision-making processes and why decisions are being made. As a team or individual, having a clear understanding of what we’re trying to achieve is important.

Many teams and companies get this wrong. It’s common to share the strategy (the how) or vision, but the motives (the why) often get left out. Why we’re building something can change everything. Everyone’s work will suffer when motives aren’t communicated and understood. You can tie everything we do back to the strategy, but then you lose the context of “why” in your everyday work.

“We have decided to prioritize XYZ instead of ABC.” Does this sound familiar? Here’s how this could sound if we were being more transparent about the motives, “We want to prioritize XYZ because several customers have said they might leave if we don’t.” See what we added there? Motives, which give us context behind why something is being done.

Do you know what happens when you share the motives behind a decision? People reciprocate; they share important details related to the root problem and can help you find a better way to solve it.

That context helps align other teams and departments, too. If the customer’s concern is a missing feature, did the customer expect that feature when they signed up? Maybe your marketing wasn’t clear. Or, your pricing could be too aggressive for your current feature set. It’s not just engineering’s problem; success, marketing, and sales might have to get involved further upstream if this is a priority issue.

But if I’m transparent about how decisions are being made, won’t I be challenged on those decisions? Probably, but that’s a good thing. Being transparent is just part of this; you must also create psychological safety so people feel safe speaking up.

In our example above, the issue of a missing feature could be a distraction and not an issue at all. You’re never going to have all the features every user wants. If you’re stuck in an echo chamber, it’s easy for a few loud customer voices to derail you.

How to uncover motives and encourage transparency

Uncovering these motives can be challenging. When I think about this, I’m often reminded of teens, and how their outbursts are often driven by unknown motives. Many teenagers during the pandemic would get upset if not allowed to spend hours playing online video games. It wasn’t about the video games, for many, that was the only way they knew to spend time with their friends during lockdowns.

So, how do you uncover motives if they’re not being shared openly? The five whys (asking why until we get to the root issue) can help determine why a decision was made, but we can also learn a lot by re-framing the request. “If we build XYZ, what would success for that feature look like?”

This applies not only to working with customers and features, but also to internal stakeholders, business decisions, and prioritization changes. In our scenario from earlier, we have a top-down mandate to prioritize XYZ solution, but maybe you have a hunch this is the wrong thing to do. Here are some things to look at and questions to ask:

• What led to this decision?
• Why is this a priority?
• What’s being deprioritized as a result?
• What’s the potential impact of this solution?
• How can we validate without building or making significant changes?
• Have we explored alternative solutions?
• Let’s talk to stakeholders first and discover the root concern.
• Are there potential negative impacts of XYZ?
• What does success look like?
• What happens if we do nothing?
• What metrics can we measure to determine the success of this solution?

These questions are just a start. I’ve kept them generic enough that they could apply to anything from a feature request to a business decision to cutting budgets and eliminating positions. How exactly you uncover motives may differ, but the value remains.

Don’t get caught just following along as so many people already do. The adage, “If you have a question, someone else probably has it too,” is true. Let’s encourage transparency and ask these questions out loud. As you do it, it might catch on. Your company, product, and team will all be better as a result, and you’ll end up realizing your vision faster.

This post was originally published in my Substack Newsletter, Roadmap Weekly.