PM读产品启示录一书+对比微软敏捷开发流程(原书PDF下载)
💡本期话题：
人员：
结识一位财务部的朋友的重要性
流程：
评估产品机会的文档的重心是什么？
何时估算项目成本?
为什么大多创业团队都以失败告终？
产品验证/测试怎么做？
敏捷开发流程-多线程进行产品开发
产品：
产品原则是什么？常见错误你犯了吗？
被误解的PM，产品真的全靠凭空想象和创造力？
总结：
产品经理日常反省清单
大公司的PM应该格外注意什么(刻意练习)？
PM在工作过程中，除了CS skill另外需要考虑很多组织架构和业务流程的问题，我刚来微软会直接参与到产品流程中，但是这么做时不禁在想为什么目前的业务流程是这个样子的。启示录这本书会给出很多流程的假设，读完后会了解到该业流程的历史解决办法是什么样子，为什么现在的流程是较好的解决办法。
个人觉得书中对B端PM更有指导性作用，但是不排除对C端PM同样具有价值。
我刚到微软时有一个project是让我去做一个金融+NLP平台，当时市面上金融+NLP的项目有 研报生成平台，问答robot，可视化研报 等产品形式，我可以在其中任意选择方向来做。很少情况下PM会给到这样范围很广的命题，但是如果有，最开始的一步产品机会评估就尤为关键，这一步骤可以取代过时的市场需求文档。
动手设计产品前，先明确产品要解决什么问题，为谁解决问题，以及评估产品的标准。
为了评估产品机会，要求产品经理回答如下十个问题：
1.产品要解决什么问题? (产品价值)
2.为谁解决这个问题? ( 目标市场)
3.成功的机会有多大? ( 市场规模)
4.怎样判断产品成功与否? (度量指标或收益指标)
5.有哪些同类产品? (竞争格局)
6.为什么我们最适合做这个产品? ( 竞争优势)
7.时机合适吗? ( 市场时机)
8.如何把产品推向市场? ( 营销组合策略)
9.成功的必要条件是什么?(解决方案要满足的条件)
10.根据以上问题，给出评估结论。(继续或放弃 )
该文档的核心目的是在调研过程中发现的特殊需求，而不是去描述解决方案。
产品经理往往把待解决的和解决方案放在一起考虑，当具体解决方案遇到困难时，他们会放弃产品机会。这是典型的“把洗澡水和孩子一起泼掉”的做法。
评估产品机会的目的在于:淘汰馊主意，避免浪费时间和金钱;挑选合适的产品机会，团结团队，理解产品，整合资源。
举个例子🌰这个文档中需要搞清楚产品的需求、依赖因素和约束条件。比方说，如果要通过系统集成商来销售产品，对方可能会对产品的扩展性、合作方式提出要求。
多数产品经理对产品/公司的营利模式理解非常有限。但是了解产品收益模式，产品成本，产品收益却十分重要。结交一位懂财务的朋友能让产品经理受益匪浅。
我不止一次从财务人员那里获得有用的信息，每次都给我不小的惊喜。这些信息暗示着绝佳的产品机会。我曾经问财务部的朋友，为什么其他人不知道这样的机会?他回答说，因为没有人问过他。财务人员的工作通常费力不讨好，而且有着严格的财务进度要求，他们不会跑到你面前推销机会，你应该主动去找他们。 --Marty Cagan
这种帮助主要表现在以下三个方面。
1.帮助你了解产品
请他们帮你评估产品，看看公司的投入是否划算，他们对产品的预测如何。
2.帮助你了解用户
我们通常只能利用软件工具了解用户在网上的活动，但是财务部门掌握着交易记录、支付信息、客户数据和经营报表。要注意哪些信息是你有权获取的，以及应该怎样利用这些信息。
3.确认商业上的可行性
你有一个绝好的主意，但你不知道这种商业模式是否行得通，怎么办?财务部门的朋友能帮忙。你提供信息，他们帮你分析整合。当你与高管讨论产品的可行性时，能得到财务部门的支持真是再妙不过了。
所有的公司都会执行探索产品的流程，只不过有些公司不是利用产品原型完成这项工作，而是孤注一掷，用实际产品搭上全部开发时间进行产品探索。
处于创业阶段的公司更应该重视产品探索流程，在确定有价值的、可用的、可行的产品解决方案后，再全面转入执行阶段。在此之前不需要招聘大量开发人员，可以让已有的开发人员也可以参与探索产品，或者利用这段时间准备基础软件设施。
注意一句话“让已有的开发人员也可以参与探索产品”。
其实，不只是创业团队，这个举动在成熟的团队里同样具有指导意义，在微软内部开发产品时，从一开始的Lo-fi模型，PM就会安排与Dev团队的会议来探讨产品的可行性，保证产品不会浪费时间在不可行的产品上。Dev也会及时提出对于产品的concern以便PM做调整。
产品原则体现了公司创始人的passion和企业的culture与goal。
产品原则很关键，我在面试时也会经常去询问对方公司的产品原则是什么，以便我更好的了解我所在的团队是如何协作的。例如🌰Airbnb是非常重视用户体验的公司，滴滴和美团是很注重商业化的，抖音推荐团队对产品的影响很大，而Microsoft和Google都是非常dev-driven的公司，这些客观的特点会对产品造成一定的影响🙆♂️
所以，产品原则是整个产品线的战略指南，PM明白该公司产品原则后就可以在面对产品问题时可以根据这套价值判断框架，帮助公司作出正确的决策。
比如一个case：某电影网站的产品原则是相信社区用户的影评比专业人士的影评更有价值。如果某家制片厂希望借网站发表评论，产品团队就可以根据这条产品原则决定是否采纳。
罗列出产品原则还不够，还要按原则的重要性排序。
所有产品都希望做到既易于使用又安全可靠，但总有需要优先考虑的原则。最重要的究竟是易用性，还是可靠性? 所以产品原则可以适当详细。
制定产品原则时容易出现两类错误。第一类是原则过于空泛，失去了指导作用。第二类是把设计原则误当成产品原则，比如，为用户提供清晰的导航路径(方便用户完成下一步操作)属于常见的设则，不是产品原则。
尽管软件行业早就有估算成本的传统，但直到今天仍然容易出现混乱的估算结果。混乱的原因在于管理层总是希望尽早获悉成本信息，但开发人员往往要较晚才能精确估算成本(至少要等到具体的解决方案出炉)。结果是 要么过早估算导致结果与实际出入很大，要么很晚估计结果虽然准确，但远远超出预算，让管理层很难接受。
所以，软件开发可以分为两个阶段进行成本估算
1、在评估产品机会时做粗略估算--还记得文章开头的第一点吗
2、在确定最终的产品形态后做详细估算--最终产品形态指的是Hi-fi
开始研发产品前，应该先评估产品机会。
评估产品机会的目的是看产品创意宣称要解决的问题是否有价值。此时，解决方案尚未出炉，手头仅有产品创意和待解决的问题，所以产品团队只能大致估算项目的规模(建议分成小型、中型、大型三个等级)。再根据项目规模粗略估算项目成本。虽然这种估算与实际情况会有出入，但通常不会出现跨级别的误差。
确认产品机会有价值，粗略估算的成本也可以接受，管理层才能允许项目组着手定义产品解决方案。理想情况下，详细的产品解决方案应该包含可供用户测试的高保真原型。
在定义解决方案的过程中，产品经理和交互设计师需要一位开发人员的协助来评估不同解决方案的成本。然后产品经理和交互设计师根据评估结果进一步调整解决方案。待完整的产品说明文档形成后，即可根据文档细节生成详细、可靠的成本估算结果。此时，手头有了详细的产品说明文档、可信的成本估算结果，管理层可以很方便地决定是否开始开发产品。
产品验证是指在正式开发前，依据产品说明文档和Hi-fi，需要进行以下三项重要的验证。
可行性测试
首先要明确在现有的技术条件下，能否成功开发出产品。邀请架构师和开发人员深度参与技术调研，寻找可行的方案。
重点是让开发人员寻找产品设计里那些难以克服的障碍，现在发现远比损失了时间和资金后发现来得好。
可用性测试
交互设计师应该与产品经理密切合作，想方设法突出产品的功能特性，让不同类型的用户都能明白如何使用。
可用性测试往往能发现没能成功实现的产品需求，如果测试得当的话，甚至能发现原本被忽略的产品需求。最好规划多次迭代测试，确保实现最佳的用户体验效果。
请注意，为了测试可用性，即使要模拟复杂的后台处理过程也是值得的，关键是要评估用户体验的实际效果。
价值测试
最后，仅仅知道产品能够开发出来、方便使用，这还不够。同样要紧的是知道用户是否觉得你的产品有用，是否愿意购买，有多喜欢产品的设计。
价值测试可以和可用性测试同时进行，使用的原型也是一样的。
这里，大家应该能够发现公司是把Hi-fi当作描述产品的最终方式而不是prd文档。因为比起写在纸上的文档，产品原型更加有效，它可以加深PM对产品的理解，让用户去验证产品的创意，避免开发团队浪费时间和精力开发没有把握的产品。
拒绝瀑布式的开发模型，需求调研和产品设计同步开展，开发与测试交叉进行，互相影响，逐步迭代。
1、需求调研和产品设计同步：
敏捷方法里有个概念叫“sprint zero”翻译过来是“第零次迭代”，指产品经理和用户体验设计师同步完成产品设计并迭代的工作后，再交由开发人员开始迭代开发。
请注意，尽管我提倡需求调研和产品设计都要在软件开发前完成，但是在此期间至少应该邀请一位软件开发人员检查设计工作，他可以协助你评估设计的可行性和成本，作出更明智的决策
2、开发与测试交叉进行：
结合我在微软的经历，比如一次sprint是两周的时间，那么PM需要在每两周的第一周去完成测试文档，在第二周的时候向其中填充真实的数据(B端产品)，这样一个sprint结束后就可以去做阶段性测试。这样在产品在最后完成时往往不会有什么大问题。
在大公司里工作需克服重重障碍，为产品争取支持和资源很不容易。但是一旦你掌握了充分利用大公司资源的方法，将会如鱼得水。以下三点对大公司PM尤其重要，当刻意练习。
1、分享信息
分享信息不管在哪种组织里，沟通都是难题，大公司尤其如此。许多人把它看成私有财产，藏起来不愿与人分享。其实有舍才有得，分享信息会让你获得更多的朋友和资源，作为交换，别人也会毫无保留地分享信息给你。充分共享信息对你自己和公司都有好处，这叫共赢。
2、向上司借力
学会利用上司的关系，可以更好地开展工作。如果你的上司在公司里威望很高，你应该学会向他借力，利用他的人脉关系，传播你的理念，多向他请教，了解公司文化和组织结构。如果需要上司出面说服公司高管，你一定要事前做好充分的准备，为他提供翔实可靠的资料和信息，用实力取得他的信任，让他放心地当你的说客。
3、传播你的产品理念
多向同事传播你的产品理念，向大家描绘产品愿景，介绍产品策略，演示产品原型，分享用户反馈信息。不要低估了内部宣传潜移默化的作用。让大家(包括没有直接业务联系的部门同事)不遗余力地支持你。
许多公司认为，要想在市场上崭露头角，必须发现新的热点，开拓新的市场。媒体的炒作也助长了这种风气。大家都在挖空心思寻找下一个热门产品。
其实成功的产品往往不是什么新鲜事物，只是新瓶装老酒，之所以成功，是因为这个“新瓶”做得更好、更方便、更便宜，改变了消费者对“老酒”的印象。
谷歌便是一个典型的例子。他们初入搜索领域时，遭到了很多人的白眼。大家认为搜索引擎市场已经饱和。还记得ltaVista.Infoseek、Snap吗? 初出茅庐的谷歌想在这个领域分一杯羹几乎不可能。不曾想，谷歌专注于提供有价值的信息，厚积薄发，颠覆了整个市场格局。
同样， 苹果公司推出iPod时，市场上的MP3播放器不下百种，但iPod以其卓越的功能很快引领了市场潮流。
想在成熟的市场抢占一席之地，精明的公司至少要手握两件“法宝”。
第一，对目标市场了如指掌，对现有产品的缺陷洞若观火。我喜欢通过产品可用性测试掌握产品情况，包括自己的产品和竞争对手的产品。
第二，跟踪最新的技术趋势。新技术层出不穷，让之前无法实现的方案变得可能。虽然谁都没有把握永远走在技术的前列，把最新的技术融入产品设计中，但你只要做到一次，你的产品将所向披靡。
记住，优秀的产品经理应该抓住现有技术与用户需求的契合点。苹果和谷歌深谙此道。市场机遇无处不在，你要做的是挖掘需求，运用新技术解决用户的老问题。
为什么产品经理的工作如此费时?因为出色的产品经理永远时刻关注产品的现状与未来。以下是产品经理无时无刻不在思考的问题。
1. 产品能吸引目标消费者的关注吗?
2.产品的设计是否人性化，是否易于操作?
3.产品能在竞争中取胜吗?即使是面对未来风云变化的市场，依旧有取胜的把握吗?
4.我了解目标用户吗?产品是否能得到他们的认可?
5.产品是否有别于市面上的其他产品?我能在两分钟内向公司高管清楚地阐明这些差别吗?能在一分钟内向客户解释清楚吗? 能在半分钟内向经验丰富的行业分析师解释清楚吗?产品能正常运行吗?
7.产品是否完整?用户对产品的印象如何?销售业绩如何?销售任务能否顺利完成?
8.产品的特色是否与目标用户的需求一致? 产品特色是否鲜明?
9.产品值钱吗?值多少钱?为什么值这么多钱?用户会选择更便宜的产品吗?
10.我了解其他团队成员对产品的看法吗?他们觉得产品好在哪里?他们的看法是否与我的观点一致?
好啦～ 这一期内容比较多，但是提到的所有问题都是PM现实中真正面对的问题，阅读时可以结合你在公司时实际遇到的困惑，再仔细思考这些问题，希望这本书可以给你一些答案。