以下为捞的干货：
1.用kano模型分析需求优先级：
作为一个需求对应的功能，“行”描述的是“如果有的话”，用户会“开心”、“无所谓”还是“不开心”; “列”描述的是“如果没有的话”的情况。具体分析如下。
矛盾：如果用户觉得功能存在和不存在都很开心，或者都不开心，显然是有问题的，这种矛盾的情况是存在逻辑问题的，不予考虑。
错误：如果功能不存在让用户很开心，或者功能存在让用户不开心，那么这个功能显然是错误的功能，不予考虑。
无关：如果功能存在和不存在，用户都觉得无所谓，那功能也就无关紧要了，同样不予考虑。
最重要的就是以下三类需求：
必要：如果功能存在，用户并没有特别的感觉，但功能不存在，用户会不开心。这说明这个功能是要满足基本需求的，也就是大家常说的“痛点”。
期待：如果功能存在用户很开心，功能不存在用户很不开心，这就是满足用户最直接、最明显的需求了，因为在用户内心已经有所期待。
惊喜：如果功能不存在的时候用户并没有感觉，说明对这个功能，用户之前没有预期，但功能存在用户很开心，也就是说达到了惊喜的效果。这就是我们在第2章所说的能够超预期满足用户。
2.需求开发优先级（d为所需时间）：
3.花了大量精力在没必要的事情上的原因，其一，你做的事情其实应该是别人做的；其二，你做的事情应该有避免重复劳动的更高效的方法。
4.运用双赢心态与技术沟通
前面提到了，在跟同事的协作当中“双赢”是很重要的思想。别小看这个耳熟能详的词，我们在处理很多事情时其实并不会意识得到“双赢”的重要性。
在很多语境里，产品经理和程序员都是对抗的关系，这让很多产品经理误把程序员当成“要处理的问题”。严格来说倒也没错，跟程序员有良好的协作确实是要认真对待、当成一项任务完成的，但把程序员本人当成问题，却容易把他们变成对抗的、有矛盾的一方。
5.说的对
在遇到问题时，有的产品经理首先想的是说服程序员，想要“赢过”程序员。有时很多问题是需要妥协的，在一些并没有太大影响的细节上跟程序员争执。
6.衡量标准和工作方法有问题，看起来很努力，但努力都白费～
在工作到我们身心疲惫的时候，总是会产生充实感，觉得我们做了很多事情。可是任务的完成并不以充实感为准，而是以真正产生的作用为准。做调研时分析了一整天报告，看得眼都花了、手都在抖，认为调研任务圆满完成了，但其实反思下来并没有看到几篇有价值的报告。要反省这么劳累还没有产生价值，是不是调研的方法有问题，而不是自我感觉良好。
7.关于逻辑分析，仅讨论几种我经常遇到的逻辑错误，它们能够覆盖大部分的场景。
• 混淆因果关系和相关性
因果关系有先后顺序
• 概念有歧义或者偷换概念
以同城配送行业为例，订单和运单就是不能混淆的两个概念。
• 逻辑关系混乱、不熟悉归纳演绎
• 假设错误
我们通常会给逻辑分析设定一个假设，即使有时没有刻意去设定，也会有很多潜在的假设。
• 轻易断言
在要警惕的假设中还有一种特殊的情况，那就是假定只有一种或几种方案来解决问题。尝试找到更好的理论。
• 太过主观臆断：别人说的是事实，可以相信，如果是个观点，则保持警惕
• 片面归纳：老人言未必都对
• 比喻过度
• 被统计数据欺骗：比如人均收入的平均数
8.跟技术沟通的时候：给出答案，但最好也要给出具体的问题和背景，对他们来说能够对方案的理解更加深入。
之前一直以为跟技术讲背景讲原因会很啰嗦，他们也不太爱听，知道我今天看了这本书才明白～
9.整理知识的好方法，如下图，按照分类丰富而不是按照时间去丰富：
