20170602
产品的核心是解决问题，定义清楚客观问题和解决方案能解决的问题之间的差别非常重要
上头说要某产品题量我们来不及做了，让用户自己录吧。
于是产品经理出了一个方案，在课件旁加一个自定义课件，让用户自己录。这是一个表层的解决方案。
产品设计其实是一个问题定义和解决方案批判性思考的过程。
问题定义不应该是上头说的这句话，而是站在用户立场和公司立场分别是，用户想要匹配的考题。公司想要在人手不足的情况下解决用户这个问题。
如果用户想要匹配的题，我们却让用户自己录，这中间是有很大差别的。定义清楚问题和解决方案之间的差异很重要。
目前的解决方案就有以下问题需要思考：
1用户真的希望自己录吗？既然没有现成的题，自己录又解决了他什么问题呢？如果希望自己录，他们愿意花多长时间录？谁录？怎么录？
2.用户自己现在是怎么（maybe别扭地）解决这个问题的，新方案有比他现有的替代方案好吗？
3.录了希望怎么用？用户原本是希望课件里的题目就是匹配的，现在我们提供的是另外的单独课件，他用起来方便吗？是希望边讲知识点边讲题，还是集中时间讲几道题？需要和常规课件中的题目一样，打印答案吗？
4.用户希望用多少道题？现在的5道只是系统现状，但是每讲有几十个知识点，他用起来够吗？
5.调研的时候，选择的用户也很重要。不应该随机选择，而应该选择存在不匹配问题的机构，重点客户肯定要有样例。
20170602 产品经理规划和画饼的能力
新来的副总监，前百度PM，非常看重规划和画饼。
我之前没有强烈在这方面自我约束，但是这两点对团队和合作部门的好处是巨大的。
规划让大家对半年内要做的事情有明确、具体的预期，谁即将需要谁的支持，需要多少技术资源，紧急的事情能在什么时间做完。
画饼让大家住着茅草屋，被眼前的苟且折磨疯了的时候，知道诗和远方在哪里，以及我们有没有往这个方向去。1年3年都可以忍，但忍了能换来啥？产品经理如何让人信服自己对这个产品比其他人都懂，都有底气？让人看到曙光，想跟着干？不会让其他部门瞎吐槽和乱指点？
20170605 再复杂的产品也有单点突破机会
TO B的产品，往往必须做很多功能才能支撑起客户的业务。
但是，再复杂的产品也有最突出的突破点。但是，不同时期不同。
比如我们现在就是，备课标准化，复制老师快。
当其他产品也有这个功能时，我们是教研牛。
当其他产品教研也有时，我们就是，招生强。
20170606产品经理应该花大头的时间在调研和思考，而不是解决BUG
最近的状态超级不爽。
公司效率真低下。
PM缺乏调研和思考，就会形成只能唯上/唯业务方的局面。但唯上就往往会导致方案不实用，不全面，更谈不上超前和出色。自己的成长也很少。
但是不应该因为工作任务和氛围随波逐流，自己应该有意识地去做一个合格PM应该做的事情。
20170615帮助用户理解信息的方法
整理有序
化整为零，化抽象为细节，掰开给他看，不要让他自己去琢磨。
20170616提高时间管理能力的小习惯
每天用便利贴记录最重要的事情和期望完成时间，然后全力以赴。
有打断的事情，不要立即开始做，工作事情排进待办事项，记录下来，生活琐事写在另一个便利贴。
计划频繁失效时记录每一次失效原因，然后复盘。
沉浸式思考时关闭微信。
20170616产品经理要警惕自己陷于细节
陷入执行一个有一个的方案和任务。
却忘记了抬头看看行业方向，产品立足之地，发展动态。
20170619卫哲的3+1思考法
- 需求明确吗？（是你觉得用户有问题，还是用户自己觉得有痛点/欲望）最想解决这个问题的用户是谁？什么场景产生的问题？（笼统地定义没有意义）
- 需求有多迫切？有多少人有这样的问题？这个问题现有的解决方案是什么？ 频次高吗？
- 改变有多大？用了新方案后，用户怎么解决这个问题？好处是什么？用户有多在意这个好处？（YC创业课说的是，用户愿意为此买单吗，评价欲望是否强烈）
新方案有没有彻底解决他的问题？为产品设定的使用场景什么时候发生？是否真的会发生？ - 改变后，产品数据有何变化？（排除干扰因素后最能体现产品效果的数据，衡量价值有没有被认可，提供了多大的价值。）
20170619 克服用户调研的惰性
最近忘掉做不好用户调研，想赶项目的种种借口，一口气打了300多个电话。对用户需求的认识和以前比至少提升了50%。
和业务方讨论需求不再是隔靴搔痒了，有底气了。
【重要TIP】产品经理就应该比任何人都懂自己的用户。
20170717 项目管理的核心——里程碑
一个超过2周的项目一定要有每周的里程碑，不然完全必须绝对会延期！！
20170717 可用性测试的必要性
开始开发之前一定一定要找用户测试下你的方案。
自以为很明显、或者别的产品已经验证过的方案，往往拿到你自己项目中上线后发现傻眼了。
20170724 合作部门的进度不能把控怎么办
项目立项会应该把所有业务方、技术方都叫到一起，确定项目的整体里程碑（不光是技术里程碑），明确各方职责，这样他们能知道自己的事情对整个项目的影响，不用反复提醒；
项目进展应该每周定时、总体发给全员。
20170814 你认为用户有问题不代表用户也认为自己有问题
发现问题，去和相关的人聊一聊都能发现。
分析问题的原因，站在自己的立场上也能分析出一套看起来过得去的。
但解决问题，一定要了解对方的心理，当时的诉求，痛点，使用习惯。
20171102 要结合用户的场景考虑各种最简方案
用户在什么场景下用，他使用的场景和频次是你所期待的最理想的方案吗？
比如你期待用户完成新手任务，拿手机完成就比拿电脑完成效率更高。
一个不成熟的复杂方案会成为产品日后的负担。
20171206 抓住用户最渴望的诉求，超出预期地解决问题
任何产品都应该有一个最核心的用户诉求---学懂？熟人社交？
在这个诉求上，应该衡量你是否已经彻底解决了他的问题
而且是超出他预期体验地解决问题
8秒不行要2秒
大概懂了不行要彻底弄懂
在此之前不要去解决其他的问题
增加任何功能都不要影响他解决原本的问题
