产品经理与扑克赌徒
一些教训和感受
Brandon Chu 翻译：Kevin嚼薯片
过去，我曾是一个扑克老手。我已经玩过不下数百万手，一点也没有夸张。从在中学走廊时的0.25美元投注游戏，到在大学时同一时间玩30个线上赌桌，再到在拉斯维加斯时参加世界大赛，我很有把握地说我对扑克游戏有很深入的领会。
随着时间的推移，我从玩扑克牌中学到的东西也能适用于生活中的一切，连产品管理也不例外。事实上，跟我其他所有的职业相比，我一直惊讶这两者有着如此多的相似之处…
他们都是以不完整的信息为中心。
处理模糊因素和灰色地带是产品管理的一部分。时间线是很难预测的，因为软件系统本来就是无法预知的。产品成功与否也是不能保证的，因为用户问题和解决方案总是被认可但却从没经过长期考验。
最厉害的扑克赌徒总是善于吸收他么周边的信号从而减少对策的模糊性。投注模式，肢体语言，以及心理学是让直觉达到极致并驱使每一次投注、跟注、弃牌的输入项。
同样地，产品经理也是善于吸收用户的反馈，分析数据，和能把握产品市场的脉搏。当产品经理（恰当地）着重于使用数据驱动开发，用户研究将很少地起决定性作用，并且慢慢地会对驱动策略有一些方向感知。
最厉害的扑克赌徒会经常弃牌。
厉害的扑克赌徒经常弃牌，因为只有少数情况值得去玩。
一个产品经理有无穷无尽的可以构建的功能点，但选择正确的功能，同时懂得经常对内部利益相关者和用户说“不”，才是成功的秘诀。
对扑克游戏，它需要很大的耐心去坐3个小时而不玩一把。而对产品管理，在作出选择时也需要同样的自律。
每一个决定最终都归结为期望值。
在扑克赌局中，每一个决定都能被模型化为赌徒脑中的一些简单分析。
这有20美元的赌注总额，我必须放入多于10美元去跟注和看对方手牌。因此，如果我至少有1:2（即33%）的机会去赢得赌注总额，我应该跟注。根据我与这为对手的历史情况来看，我想她可以拿着8张可能的手牌，而只有4张手牌（50%）能击败我。
我需要至少33%但我有50%的胜利机率。我就跟注。
对于大多数产品决策来说这种分析方式有点像白日梦，但框架其实是相同的。例如失败与回报大小的风险对比是怎样？例如在接下来几个月中投入100万美元的公司资源去搭建这个功能的预期投资回报率是怎样？
这里的关键点是有提取所有对公司有价值的产品开发产出——无论是直接销售或间接的用户声誉度——的能力，不管用什么方法去判断。
只要对预期的投资回报率进行评估，就能简单地以最有价值的方式去构建项目。
不是所有的赌徒都有相同数量的筹码。
在扑克赌局中，一个赌徒的财富及其所下的赌注量会影响到他们玩这个游戏的方式。一个百万富翁很难会认真对待20美元的投注，尽管他们决定去跟注。
作为产品经理，当去考虑竞争威胁和应对策略时，在合理的场景中去评估每个对手是非常重要的。
是否我们正在考虑向对手X扩张的领域太过小了？
是否历史已经证明了即使对他们自身毫无意义，但他们还是会跟进我们？
他们是否有足够的资源在这里竞争？
如果他们决定进入我们的领域，我们是否有足够的资源去应对？
你可以借鉴到相同的游戏（行业）中去，但重要的是要对每个对手有同理心，并且在游戏中要对他们的意图经过深思熟虑。
一旦下注，只有赢和输。
如果你下注到了错误的项目，而向中途抽身，你极有可能浪费了你已经投入了的所有资源。如果你决定无论如何也要发布，你将需要长期为新增的复杂逻辑和去维护代码库而埋单。
在扑克赌局中，你只会在获胜几率极大地倾向于你时投注。厉害的赌徒极少会虚张声势，而如果他们这样做了，只会在第一轮点数看上去非常合理的情况下生效。
尽量低降低你下注的下行风险对于最终赢得所有的赌注是非常有必要的。锉开每个开发周期为最小的功能，可以提供最有意义的产品验证，且当你发现赢的机会时，再下大注码和赢得金钱。
如果你觉得这篇文章有价值，请在文章底部为我的文章点和打赏。
Product Management is a lot like Playing Poker
Some lessons from the felt
BY Brandon Chu
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.
网友评论