策略型如何在完整的产品循环中发挥作用

　　本文笔者将分别从产品循环的每个环节入手，阐述策略型pm在完整产品循环中的工作方法和应发挥的作用。
　　一、发现问题
　　发现问题通常有以下三种方法：
　　1。线上效果评估
　　线上效果评估，最常见的方式是：利用随机查询集合，逐个在线上检索查看质量。
　　若为了更快更明显的看到问题，通常会和竞品进行比较。很多时候，竞品的做法或效果，未必是最好，为了从理想角度探究效果，我们也采用以理想为标杆的对比和发现问题。
　　这种方式的好处是：全面发现问题、问题影响面客观、容易量化，例行开展还可以进行历史数据比较，观察产品的变化情况；而问题是，线上整体效果越好，发现问题需要花费的力气就越大即发现问题的效率非最高。
　　在以评估为手段的问题发现中，pm需要清楚把握用户需求，根据线上实际效果，对用户的满足状态给出判断，需要给出每次查询用户面临什么样的问题，以及严重程度。
　　2。线上监控
　　在网页搜索技术分支增加、策略日渐复杂的趋势下，人工去排查系统每个模块给用户带来的影响，是一种非常不经济的方式。线上监控作为一种自动、实时、针对效果的问题发现方法，日趋重要。
　　其中，自动是指利用机器去执行；实时，是可以持续不断地对效果进行监控，且能在问题产生第一时间获知。自动和实时，都大大减少了人力成本。
　　针对效果是指：针对实际用户感受（或影响因素）进行监控。
　　监控的问题是：精度有限，特别是针对网页搜索效果的监控精度，提升过程比较缓慢。所以，目前的监控，还比较多的停留在一些相对粗粒度的统计指标。如：autorank、位置点击率、结果站点展现、站点导流情况等。
　　也正因为精度有限，监控往往难以直接定位问题，而是和其他人工手段配合确定最后的问题。
　　pm在监控工作中的职责，主要体现在：将用户感受的每个影响要素进行拆解，并找到相对独立的、可机器量化的指标，这些指标往往就是监控点。
　　比如：建立衡量线上检索效果的autorank监控，pm首先要清楚，结果好坏会在哪些方面体现比如结果相关度权重、资源质量、用户搜索停留点击行为等等。
　　接下来，结果的相关度权重、资源质量判断，准确性依赖现有策略，策略效果会直接影响监控的有效性，所以效果监控不适合将以上两点作为监控指标或主要监控指标。而用户行为这个指标相对独立，受扰动因素较小，所以合适作为监控指标，这也是前面强调独立的原因。
　　3。平时产品使用中发现的badcase
　　即我们平时说的报case。
　　这个方法发现的问题，来源于平时的个人使用中遇到的体验较差或不合预期的查询。在过去很长一段时间内，case驱动成为网页搜索改进的重要途径。
　　这种方法发现问题，有个明显的缺陷即随机，发现问题难以全面，且难以量化，难以得出问题在线上的整体影响面。但是，对每一个问题的深入分析，可能帮我们发现用户体验上的明显问题，或找到系统中的严重症结。
　　涉及分析的内容，会在下文展开。
　　以上，是发现问题的三个主要方法，作为pm产品工作的第一步，掌握发现问题的方法，保证不偏不漏，这是非常重要的。
　　二、提出、描述问题
　　把问题描述清楚，需要做好两方面：一个是对问题的衡量，一个是问题的解决预期。
　　1。问题的衡量
　　首先，问题的衡量需包括：
　　问题的广度：指问题产生了多大范围的影响，在网页搜索，这个范围影响，通常用收到影响的查询占比来反映。
　　问题的深度：即该问题对用户体验造成伤害的程度。
　　这个点上，不太容易有量化的衡量，但对严重问题的判断，仍有一些原则可以遵循。如：很多用户每天通过aladdin结果来获取股票信息，而突然某一天，股票aladdin结果消失，这个就破坏了用户稳定的预期。
　　再如：搜新浪，出搜狐结果，也难以让人接受，这是因为超出了用户的理解范围；而在某些spam问题上，破窗效应导致对用户体验威胁加重趋势明显，也应算在严重问题范畴内。
　　2。明确解决预期
　　其次，明确解决预期，也需要基于两点：
　　1）理想情况的描绘
　　提出问题只是第一步，这个问题上要做到什么效果即目标是什么，也需要pm有清楚的判断。只知道问题而不知道效果目标，工作无法有效开展。
　　2）理想情况是一回事，能否达到是另外一回事。
　　因为理想情况的实现会受到很多因素的限制。有不低比例的查询，因为话题过于冷僻，互联网几乎不存在与之匹配的资源。
　　在资源到位之前，一味的要求相关性提升是不合适的，这样很容易造成rd（特别是没经验的rd）辛苦开发了很久，却对效果没有帮助。而目标调整为，保证有资源的查询效果提升或至少要召回google能召回的好资源，这样就合理很多。
　　在实际工作中，我们往往对问题衡量做的较好，而对解决预期重视不够，这就是为什么有些pm觉得做完评估或调研工作就结束了，或者觉得自己难以给出优先级判断。缺乏对问题解决的合理预期，会导致pm难以进行后面的工作，无法形成完整产品循环，还会导致rd对需求目标的理解有偏，资源投入和实际产出不匹配。
　　三、判断决策
　　1。两个问题
　　方向或策略定位问题和目标清楚之后，pm还应主导回答两个问题：该策略方向定位是什么，解决什么问题？该策略方向不解决哪些问题（或什么情况下不必发挥作用）？
　　第一个问题想必很多pm都是可以回答的，而主动思考第二个问题的人却并不多。缺乏对第二个问题的思考，会导致pm对策略方向的认识不完整，以及在后续执行过程中，偏离目标、工作开展失控。
　　举两个例子：
　　第一，地域扩展策略。
　　要解决的问题是：同一查搜索词下，不同地区用户的目标结果不一致的问题，如招商银行网点。根据该问题表象，可以提炼出对搜索结果有本地域需求的查询。
　　其解决思路是：在这类查询下，基于用户地理位置信息，插入与用户地域匹配的结果。在这个定位下，北京招商银行，也是地域扩展策略的目标查询了。
　　如果再补充一个问题，地域扩展策略不影响什么样的查询，在一定量的query标注后就会发现：北京招商银行这样的查询，意图非常清楚，和用户所在地域没有关系，没有必要进行地域结果扩展。这个时候，我们可以及时对地域扩展策略的定位进行修订即对有潜在本地需求的查询，提供地域差异性结果。
　　第二个例子：检索扩展提示。
　　改功能其中一个定位，是当用户输入存在非常用写法或错别字的时候，给予提示，使得用户避免query改写操作，找到更理想的资源。
　　如果没有不做什么约束，检索扩展就很有可能出现这样的问题：
　　例如：
　　query谍中谍4，检索扩展提示：您要找的是不是：碟中谍4，搜索结果页地址。
　　该query命中非常用写法的条件，但是结果非常好，不影响用户找到所需资源，此刻提示的价值就非常小了，且这种提示的价值，相比对用户注意力的干扰不值一提。
　　基于这类case，检索扩展的这个定位可以完善成是当用户输入存在非常用写法或错别字导致结果不佳的时候，给以提示，以使用户避免query改写操作，找到更理想的资源。
　　补充一句：不做什么这个问题的答案，有可能依赖pm产品经验或良好的用户感觉判断，对于一些新人，也可以通过一定量的数据分析找到。
　　综上，弄清两个问题，明确策略方向定位，背后是这样的产品决策原则：任何问题的改进，都应明确在一定的范围内，不应对问题范围外的点所有不必要影响。而这两个问题的答案，需要在项目启动前明确，并向rd进行清晰传达。
　　2。优先级
　　优先级的判断，一般项目来说，比较性价比是比较有效的办法。在问题或需求描述的环节，pm应该就改进空间给出说明，同时rd会给出解决方案需要的代价。
　　这里的收益空间不仅仅是影响广度，很多问题的影响面非常小，但是对用户或对生态产生持续（或深刻）消极影响，且这种消极影响会以难以控制的速度扩散，spam就是典型的例子。
　　还有一些情况，需要做短长期的权衡，比如：一些符合趋势的改变，即便现在的面很小，也应该酌情提升优先级，以避免将来应对不够及时。
　　3。方案的风险判断
　　策略型pm最容易看到的是效果上的的风险，除此之外，用户习惯和感知、系统复杂性、随着时间推移的可扩展性，也应在考虑范围内。
　　举一个感知风险的例子：我们系统中有很多需求改写策略，这些策略的原理，是通过挖掘用户行为或语料，得到一些query之间的信息。在用户搜索时，在结果中插入相关query的结果（如同义词结果），来召回更多相关结果。
　　在query与资源的相关性判断中，可能不会有什么问题，但是在结果摘要展现时，若同义词和用户输入query在字面上相差较多，会有不飘红的情况，第一眼看上去非常突兀，这会导致用户在看到结果时，付出较多的反应成本。
　　而系统复杂性和未来的扩展性，虽然pm无法直接回答这些问题，但是需要通过提醒和追问的方式，让rd去进行相应的思考。
　　4。阶段性效果衡量
　　在提需求的时候，我们已经描述理想状态了，但是在实际开发过程中，由于技术上或数据上的种种原因，很难一次性做到完美，针对阶段性工作，pm需要给出衡量方式。而衡量的途径，就是制定标准，给出不同程度的效果的定义，在这个基础上量化工作效果。
　　四、推进落实
　　策略型pm在这个环节事情相对简单，主要是保证关键时间点确认，及时和rd了解困难，从用户角度提出一些思路建议，必要时，积极争取资源解决困难。当项目进行中发现目标需要调整时，pm需要及时组织沟通，重新制定目标和衡量方法，让参与同事达成一致，并形成正式通告。
　　对于项目中增加新成员或负责人转手的情况，pm也需要推动或落实背景和目标的传达，确保项目执行中没有偏差。
　　五、效果确认
　　这个环节主要是确认效果和风险，评估标准应与前面按目标制定的评估标准一致，此环节的工作会决定策略上线或进一步迭代。同时，对于影响面大的策略，最好再次review风险
　　六、开始下一次循环
　　每一次改进的上线，形式上会让人觉得事情做完了。但是，除了问题修复类型的工作外，对于一些持续改进的方向，还需要事后的监控机制。
　　这个不仅是对项目上线后线上效果的再摸底，也能使得pm对该类问题能够做到长期心中有数，且持续的监控，也是保证问题及时发现不遗漏的方法，参见第一环节。
　　七、其他
　　负责一个产品的pm，要清楚把握一个产品不同的发展阶段即产品周期。
　　同样地，策略型pm，也应该清楚每个策略的发展周期，包括：策略目前在线上发挥什么样的作用？是否要做进一步的深化或扩展？外界变化或内部其他替代性策略功能的上线会对策略的贡献有什么样的影响？这个策略接下来应做如何调整，改进升级，或是收敛投入，甚至下线？