域名频道资讯站
我们一直在努力制造惊吓

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


本文笔者将分别从产品循环的每个环节入手,阐述策略型pm在完整产品循环中的工作方法和应发挥的作用。

策略型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,也应该清楚每个策略的发展周期,包括:策略目前在线上发挥什么样的作用?是否要做进一步的深化或扩展?外界变化或内部其他替代性策略/功能的上线会对策略的贡献有什么样的影响?这个策略接下来应做如何调整,改进升级,或是收敛投入,甚至下线?

 

本文素材来自互联网

赞(0)
分享到: 更多 (0)

中国专业的网站域名及网站空间提供商

买域名买空间