From Decision Maker to Decision Supporter

My dad gave my new son a book of fun pen/marker doodles. I’m using them in posts.As a product manager, it is your responsibility to make sure that the best possible decisions get made…not to necessarily make those decisions.

Sometimes you’ll have the best idea, especially when it comes to areas requiring deep domain knowledge. Most of the time, you won’t, nor will you necessarily be the best arbiter/judge of ideas. To elicit better ideas — to make better decisions — the talented people on the team (you included) will need context, data, space, opportunities to iterate on and improve ideas, tactics for reducing cognitive bias, and access to facilitation/decision-making frameworks. You may even be called on to break a tie occasionally, though it is better to establish an open-to-all framework that does that for you. The same with judging “success” — better to establish a model/framework vs. being the thumb-upper, thumb-downer.

You’ll find that some organizations think otherwise. Their PMs are rewarded for being in “pitch mode”, for being “bold and decisive”, and for having all the answers. In these environments, the outcome(s) almost don’t matter. It’s all about the theater and certainty safety-blanket.

In other organizations, the team is “too busy” to make decisions. “Can the PM get their act together and put together a good roadmap!” Meanwhile the PM is being peppered with feature requests/ideas (hence the scattered, non-congruent roadmap filled with other people’s ideas). It’s a lose-lose situation. Neither model — rockstar pitch-machine-PM or PM as team-capacity auctioneer (and team as reluctant ticket-taker) — is a good model.

Doesn’t the PM own the problem, and the team own the solution? Hmmm. “The problem” is still, typically, a decision on where to focus. Why that problem instead of the myriad of other problems? Is it the best decision? How do we know? The problem vs. solution dichotomy quickly breaks down when you realize that every problem is a nested solution to a higher level problem.

Again, the PM might be the savviest person in the room when it comes to the particular decision at hand. If so, the PM’s focus should be on sharing the context and rationale behind their decision, and inviting the team (and customers/users) to aggressively stress-test their ideas. Most often you’ll find that ideas are pretty cheap.

To summarize…always strive to support the highest decision quality possible given current constraints (like time). Work to support the team’s Reasonable Decision Throughput. Put a premium on continuous learning and context building…otherwise the team might as well flip a coin. Your product will benefit. And in the long run, so will your career.

Think you really do have the best ideas? Prove it.

From Decision Maker to Decision Supporter was originally published in Hacker Noon on Medium, where people are continuing the conversation by highlighting and responding to this story.