见山
产品判断
见山 · 产品判断力
在复杂之后，重新看见问题本身。
这本书讲的是产品经理的判断力——在信息不完整、目标还在变化的时候，怎么把问题看清楚，又怎么把判断变成可复用的方法。二十一章从认知、需求、用户，走到架构、商业、增长与组织，拆的是判断的各个面向。
5 篇21 章序与后记约 23.8 万字读完约 27 小时
认知篇
先把「产品经理到底在判断什么」说清楚
第一篇 认知篇
先把「产品经理到底在判断什么」说清楚
你一定参加过这样的会：方案讲得很完整，交互、字段、异常路径挨个过了一遍，快结束的时候大家点头，一句「没问题，排进去吧」，事情就这么定下来。整个过程里没有人问一句「这件事该不该做」，因为到那时候，答案早就在所有人心里了。倒不是谁不上心，方案能做到这个程度，说明团队专业，每一步都扎实。只是越扎实的东西越不容易被质疑：一个漏洞百出的想法会被当场问住，一个挑不出毛病的方案反而能一路排进版本，直到上线之后才有人觉得，好像哪里不太对。
这样的项目我见过不少，回头看，问题很少出在执行上，每个环节都挑不出毛病，没被回答的，是排在所有环节前面那个问题：这件事到底该不该做。它早就成了前提，不需要再回答，方案越完整，这个问题越显得多余，等到重新想起这件事的时候，项目已经推到很后面了。这一篇想谈的就是判断本身。你一天里要拍的决定不少，需要停下来想一想的并没有几个：判断一个产品好不好，依据的是什么；一条需求摆在面前，看到的到底是这条需求本身，还是它背后要解决的事；说到理解用户，凭什么认定自己懂；几个判断撞在一起的时候，又该听谁的。
产品经理凭什么判断？
方法论篇
判断，不是想清楚就够了
第二篇 方法论篇
判断，不是想清楚就够了
「想清楚」这三个字，在产品工作里被用得有点随便。评审会上有人说「我想清楚了」，散会后一聊，才发现大家想的根本不是同一件事；方案改到第三遍，所有人都觉得这回终于想清楚了，上线之后回头看，最该想的那件事，一次都没碰过。想清楚，只是判断的第一步。往后还有一段更长的路：要经得起验证，还要在事实变了以后知道该往哪走。这段路很少有人专门讲，不像思考那样有成就感，也不像交付那样有进度可看。
第一篇谈的是它从哪儿来，这一篇要往前走一段：一个判断做出来了，凭什么说它站得住。想清楚只是一半，另一半是把你想清楚的东西，做成别人能接过手的样子。你心里清楚的那件事，到了别人那儿往往就是模糊的一团，中间隔着一次翻译：把脑子里那点确定，翻成别人能检验、能继续用的东西。这件事听着不难，做起来很难，它要求一个人在自己也没底的时候，还能稳住，不急着交出去。
判断要怎么做，才算真的做到？
产品架构篇
判断，要为还没发生的事负责
第三篇 产品架构篇
判断，要为还没发生的事负责
一件事做过三遍以后，看它的眼光就变了。第一次只想着做成，第二次会想上一次是怎么做的，到第三遍，人很容易冒出一个念头：这件事能不能只做一次。这个念头很自然，可往往走不到底，多半停在「这次先这么做，以后再说」这句话上，后半句没人接着问：你怎么知道它以后还会出现？可这件事需要的证据，现在拿不到，往后会不会再来，现场还没来，用户会怎么反应也没人知道，更没有试错的机会。你手上有的，只是前面那几次。
判断做出来的时候，要解决的只是眼下这一次。可一旦被摆进系统，后面每一个相似的场景都要照着走一遍，省下来的力气是几十次、上百次的；反过来，要是偏了，也同样偏在几十次、上百次上。这类事的回报和代价，都不落在做决定的那一刻。前面几篇谈的，最后都落在具体的一件事上：要不要做，怎么才算做对，判断的对象已经摆在桌面上，好坏总能看出一部分。这一篇，判断的对象换成了还没发生的事。
这些还没发生的事，谁来替它们负责？
商业与增长篇
判断，得看它还能不能继续
第四篇 商业与增长篇
判断，得看它还能不能继续
产品做出来、跑起来、有人在用，到这一步，事情是能交代过去的：该过的过了，指标比上个月好看一点，参与的人各自回去做自己的事，会也就散了。散会前有人会留一句「先这样，能跑起来就行」，说这话的人并不敷衍，很多事确实可以这样做。只是「跑起来」只说明它动起来了，手头的事一结，也没人再催着要结论，后面那一段路更长，也更容易被放过去。判断常常做在事情发生之前：做不做，想清楚没有，哪几件事得提前定下来。
事情交付出去，这一轮就算过去，往后是另一段。这一篇要看的就是后面那段。产品跑起来之后，判断并没有结束，只是换了你要回答的东西：方案里能不能讲通已经不要紧，要紧的是这件事还走不走得下去，值不值得再投一笔，别人愿不愿意再为它买单，铺开之后会不会走样，用过的人还认不认。这些在交付那天都回答不了，得往下走一段才看得清，看清了你才知道该加码还是收手。
这一次过去了，下一次它还在不在？
组织与发展篇
判断，得经得住换一个人、换一段时间
第五篇 组织与发展篇
判断，得经得住换一个人、换一段时间
一支团队跑顺的时候很容易让人产生错觉。该定的事都定了，该说的也都说清楚了，没有人需要追着问；项目一个接一个往前走，排期上排得整整齐齐，回过头看也挑不出毛病。恰恰是这样一支团队，才最容易把机制带来的稳定误认成自己的能力。「我们一直是这么做的」，这话本身没错，但它只说明这件事还转得动。真到了要调岗、要换一条业务线、要重新搭班子的那一天，才发现这些年积累下来的东西要重新分一遍：哪些是你真的会，哪些只是当时那个位置上才成立。
到这里为止，讲的都是一个人怎么判断：做什么、不做什么，一个方向该怎么定，什么时候该停。这些事，想清楚就能往下走。换一个前提：把这个人拿掉，它还立不立得住？在一个个具体的项目里，还认不认得同一个问题；在一支换过人的团队里，还接不接得住；环境变过一轮，还成不成立。问题往往就出在这些地方。项目做着做着，要解决的问题已经换了；做法只长在一个人身上；判断在环境变了以后悄悄过期，这三种当时都没人觉得是问题。
判断还跟着你走吗？
