Product Management is a lot like Playing Poker
Some lessons from the felt
--
In my life, I’ve played a lot of poker. I’m talking millions of hands, with no exaggeration. From $0.25 buy-in games in the middle school hallways, to playing 30 online tables at a time in college, to playing in the world series in Las Vegas, suffice it to say I’ve developed a pretty good grasp of the game.
Time and time again, the lessons I learned playing poker have been applicable to everything in life, and product management is no different. In fact, compared to all my other careers, I’ve been amazed at how many parallels there are…
They revolve around imperfect information.
Dealing with ambiguity is part of product management. Timelines are difficult to predict because of the unpredictability of software. Product success is never guaranteed because the customer problem and the solution are always being validated but never proven.
The best poker players are always absorbing the signals around them to reduce ambiguity in making decisions. Betting patterns, body language, and psychology are the inputs that culminate into a gut feel that drives every bet, call, and fold.
Similarly, product management is all about absorbing user feedback, analyzing data, and having a pulse on the markets the product serves. With as much emphasis PMs (rightly) place on data driven development, research is rarely conclusive and there will be an aspect of feel that drives strategy.
The best players do a lot of folding.
Good poker players fold a lot because there are only a few situations that are worth playing in.
A PM has endless features they can build, but success comes in choosing the right ones and saying “no” a lot to both internal stakeholders and customers.
In poker it takes a lot of patience to sit for three hours and not play a hand. In product management, being selective can take just as much discipline.
Every decision comes down to expected value.
In poker, every decision can be modelled out with some simple analysis that takes place in a player’s head.
There’s $20 in the pot, I have to put in $10 more to call and see the opponent’s hand. Therefore, if I have at least a 1:2 chance (~33%) of winning the pot, I should call. Based on my history with this opponent, I think she could hold 8 possible hands, and only 4 of those hands (50%) beat mine.
I needed at least 33% and I have 50%. I call.
This level of analysis is a pipe dream for most product decisions, but the framework should be the same. What is the risk of failure vs. the size of the reward? What is the expected ROI of using $1million of company resources to build this feature over the next few months?
The trick is being able to distill all possible product development outcomes — whether straightforward like sales or indirect like customer goodwill — into the value they deliver to the company, however measured.
Once expected ROI is assessed, one simply builds the project with the highest value.
Not all players have the same amount of chips.
In poker, a player’s wealth relative to the stakes being wagered can affect how they play the game. A millionaire player would be hard pressed to take a $20 buy-in game seriously, if they decide to play at all.
When considering competitive threats and strategies as a product manager, it’s important to assess each competitor in the right context.
- Is the space we’re considering expanding into too small for competitor X?
- Has history shown they will follow us even if it doesn’t make sense for them?
- Do they have the resources to compete here?
- Do we have the resources, if they decide to enter?
You may play in the same game (industry), but it’s important to empathize with each opponent and play your game with their intentions considered.
Once you bet, you either win or lose.
If you bet wrong on a project,and decide to pull the plug mid-development, you’ve likely wasted all the resources you put in. If you decide to ship it anyways, you’ll be paying for it over the long term through increased complexity and maintenance of the codebase.
In poker, you only bet big when the odds are heavily in your favour. Good players rarely bluff, and if they do, it only works because the first point is so reasonable.
Mitigate your downside risk by betting as little as is necessary to win the pot. File down every development cycle into the smallest features that can provide meaningful validation, and when you’ve found a winner, bet big and cash out.
Binge reading Product Management?
Here’s a few other posts to satisfy your hunger
The Black Box of Product Management
Why Product Management Exists
Product Partnerships: The Making of a Partnership
Focusing on why and how product partnerships form, part 1 of 2
7 Heuristics for being a Product Director
Lessons learned as a Product Director at FreshBooks
