标签归档:需求

聊聊工作方法

## 如何做事

工作说简单点就是解决问题,具体到产品经理,是接做需求。关于问题&需求的定义和处理,基础的问题层面,之前写过《聊聊问题解决之道》《问题解决三部曲之思路》,需求层面,之前写过《理解需求》《理解需求2》《如何判断需求的优先级》,这次想从工作方法论的角度补充些内容。

### 前期

首先,不要因为不是产品问题就忽略。只要是问题,就应该先了解下,看看问题背后更深层次的问题是什么,看看作为产品经理能做些什么。一个项目的成功,产品只是其中一方面,凡是影响项目的事情,都应该关注。

对于问题,一个基本思路是搞清是什么、为什么和怎么办。搞清是什么很重要,之前有一次研发让向对接部门要 “发布证书” 等材料,我没有直接转给对方,而是先百度了下,然后反馈了一个问题清单给研发,最终确认还需要 “开发证书”、“描述文件”。为什么这么做呢?原因之一是要对自己的话(含转发)负责,如果不了解是什么,对方多问两句,很容易陷入 “一问三不知” 的境地,然后转身去问自己的研发,然后又转给对方,来来回回,成了一个 “传话筒”,耽误时间的同时也显得不专业。

了解问题时先搜索,“不问能百度到答案的问题” 是职场基本礼仪,我们尊重对方的时间,同时对问题有一定了解时,沟通会更加高效,也能避免被忽悠。信息来源中,官方文档优先,之后再和研发做二次确认,因为情况可能有变化。很多时候问题是复杂的,单凭个人未必能搞清楚,需要集体智慧,这也是沟通的目的之一。为了更好地协作,我们应该对上下游同事的工作有所了解,知乎上有个经典问题:“产品经理需要懂技术吗”,个人看法是不需要懂具体实现,但要懂原理,不仅仅是沟通的问题,而是作为产品设计者,我们需要尽可能保证所有环节合理。

对于问题,搞清为什么更加重要,那是问题的来源,之前在《聊聊问题解决之道》中谈过:“别把解决方案误当作问题的定义,因为很多时候产品经理收到的需求并不是问题,而是运营、商务同学提出的解决方案,如果我们只是基于解决方案去讨论,很可能失去提出更好尤其是更系统解决方案的机会”。

面对需求方,不要轻易说不行,而是先试试看,也不要轻易说行,而是先评估下,能确定时间点的反馈时间点,不能的回复尽快,最终的优先级和时间投入看 ROI。上级安排的任务,基本非做不可,但 ROI 低的可以视情况少花点时间,达到基本要求即可。还有一点是不要总等着需求方、上级安排任务,而是自己主动思考,自己提出问题,这也是从 “研发产品” 到 “业务产品” 的转变。

### 中期

立项时涉及资源协调,这也牵涉到沟通的另一个目的:说服,可以看一些沟通、谈判相关的书籍提高说服能力。另外,即使对方答应了,也要持续跟进,工作中吃过几次亏后,就会明白 “不要相信任何人的承诺,做好二次、三次跟进确认”,尤其每次打交道的对象不同,不要期待你碰到的都是 “最佳产研”,尤其跨部门沟通时。

沟通的过程,一是对问题的认知对齐;二是相关信息获取全,每个人的视角不同,获取更多信息有助于更好地解决问题,这里的 “每个人” 是指 “具体的负责人”。有一次我们找合作部门要接口文档,对方研发负责人亲自发了出来,然后我们根据这个去开发了,但后续跟对方研发小哥沟通时,被告知我们之前收到的文档不是最新版,然后他一直在等我们找他,有点无语,但也是我们遗漏了关键人所致。

对此的教训:一是拉群时将相关方都拉进来,这样有疑问可以直接沟通,同时因为人都在,还有可能提前暴露出问题;二是开发过程中注意风险管理,谨记不出问题是小概率事件,项目期间主动跟进核实,有影响结果的点,及时处理。

### 后期

定时同步进度、汇报结果给需求方和上级。有两个非常好的做事方式:一是 “更让人有安全感的表达方式是:凡事有交代,件件有着落,事事有回音”;二是 “复杂的事情简单做,简单的事情重复做,重复的事情坚持做、用心做”。

关于做事,网上有个经典方法:请示工作说方案,汇报工作说结果,总结工作说流程,布置工作说标准,关心下级问过程,交接工作讲道德,回忆工作说感受。另外,@LinkedSee 说:“没有什么诀窍,只是对人真诚对事负责…… 大家一起把工程师意识先背的滚瓜烂熟,然后一言一行恪守承诺:1、别人交办的事情,请第一时间给出预计完成的时间点(批注:如果不确定时间点,表明态度,现在就问,问到后给对方回复)。2、过程之中注意按时通报进展。3、如果预计要延迟,延迟多久,提前多久通报。4、如果请求别人做事情,请给出期望完成的时间点”。

## 如何做人

### 宏观

一些公司的 slogan 可以参考,比如百度的 “简单可依赖”,字节跳动的 “开放谦逊、坦诚清晰、务实敢为”。开放谦逊指 “内心阳光,信任伙伴,乐于助人和求助,合作成大事,格局大,上个台阶想问题,对外敏锐谦虚,ego 小,听得进意见”;坦诚清晰指 “敢当面表达真实想法,能承认错误,不装不爱面子,实事求是,暴露问题,反对向上管理,准确、简洁、直接,有条理有重点”;务实敢为指 “直接体验,深入事实,不自嗨,注重效果,能突破有担当,打破定式,尝试多种可能,快速迭代”。

不过每个公司、团队都有自己的文化,因此很重要的一点是入乡随俗。本身去到一个新环境就可能会有一段适应期,环境像一面镜子,自己的不适应某种程度也是一种提示,提示自己在哪些地方可以做得更好。如果一段时间后确实适应不了,离开永远是选项之一。

### 微观

说白了就是尊重对方,人是情绪性动物,被尊重的感觉很重要。作为我们来讲,关系也应该是做好事情的一部分,我们的目标是,既把事情做好,也把关系搞好。即友 @张小姐Shining 发过一条动态:“以前觉得搞好关系是一个特别落后特别国企的词,作为高效率的互联网从业人员,要简单直接、坦诚清晰、直击要害。现在有点懂搞好关系的意义了,因为好的关系确实可以为沟通提供一个愉快的氛围,在这个氛围里,对方可以和你共情,能够愿意去理解你的逻辑,愿意听你的叙述,情感上认同你,理智上才愿意接纳你的观点和论证”。另外,注意一些沟通细节,比如肯定时可以直接点,否定时务必谨慎、委婉,多用 yes and 来沟通。

工作中情绪要少一些,绝大多数时候情绪无益于问题解决,而且还会影响双方后续合作,情绪应该是手段而非其他。保持理解、宽容的心态,优秀的打工人是可以兼容不同类型队友的,对于那些难搞的人,则可以百度学习下与之打交道的方法。

聊聊问题解决之道

## 背景

某一视角而言,生活就是不断地解决各种问题,那有没有什么方法论有助于我们更高效地解决问题呢?有的,之前看《你的灯亮着吗》收获良多,现在该书内容基础上补充优化如下:

## 定义

1、谁遇到了问题,是不是问题

首先,搞清楚谁遇到了问题,同时 “确定服务对象,也就是解决问题是为了让谁满意”,很多时候除了问题遭遇者本人,也是为了让其他人满意,比如同事转过来一个 TA 朋友遇到的产品 bug。

微观视角下,“问题的本质是理想状态和现实状态之间的差别”,但最好从各相关方视角分析一遍,因为每个相关方关注的点都不一样,甚至对于某些相关方,目前发生的根本不算问题。具体分析中,放低自我,避免先入为主,也就是所谓的做产品需要同理心。

其次,核实情况查明原因,《理解需求》中提过:“如果是 bug,请先核实真实性,之前就遇到过用户反馈身份验证失败,但实际是自己输错了密码,TA 以为自己输的是对的。如果是建议,需要进行逻辑分析和市场检验,我们可以按 “角色 – 场景 – 任务” 的方式去思考,即谁在什么情况下遇到了什么问题,怎么一步步解决的,有可能放到具体场景中后会发现这是一个伪需求,无需满足。”

特别需要注意的一点是,“别把解决方案误当作问题的定义”,因为很多时候产品经理收到的需求并不是问题,而是运营、商务同学提出的解决方案,如果我们只是基于解决方案去讨论,很可能失去提出更好尤其是更系统解决方案的机会。

2、谁是制造者,谁是解决者

问题的制造者多是我们自己,而且多是解决之前的问题时考虑不够全面导致的新的问题,当然谁制造的问题不是最重要的,重要的是解决问题以及如何避免类似的问题再次出现。

至于解决者,工作中需要主动性,自己也可以是解决者,但某些情况下,不在其位,不谋其政,同时 “一个人眼中的罪行在另外一个人眼中可能是美德”,解决者无法中立,只能平衡。

## 分析

1、要不要解决

从宏观视角看与目标的关联性,如果关联性较低,暂缓解决,因为还有更重要(有助于拉近与长短期目标间距离)的事情要做。有些问题重要,答案却未必重要,还有些问题不解决它反而更好。

2、何时解决

问题的影响范围多大、程度多深,解决方案的 ROI 如何,《如何判断需求的优先级》中提过:“要做的有很多,每件事都有收益,也都有成本(含机会成本),就当前而言,要不要做,先做什么后做什么,怎么做。收益层面,现实中面临的往往是两难甚至多难选择,短期收益和长期收益、正向收益和负向收益等,如何平衡。成本层面,时间、人力等,如何支持。”

## 解决

1、自己解决

大部分问题都能解决,如果问题抽象难以下手,可以考虑操作性定义化、分解细化,查尔斯・F・凯特说:“问题表述清楚了,就解决了一半”。再个,思考方案时结构化思维,比如要提高产品的 DAU,从用户生命周期的角度,可以考虑如何拉新用户、促活老用户、召回流失用户,从用户需求的角度,可以考虑如何满足更多需求,滴滴就从出租车做到了各种车。

认知层面,每种方案都有正负向影响,即可能带来新问题,但只要大问题在变小,复杂问题在变简单,就没问题。执行层面,很多时候,解决当前主要的问题即可,同时基于现有资源,部分问题可能需要退而求其次考虑临时方案。曾经收到运营提的提数需求,如果设计开发上线新的运营管理后台模块,开发测试资源不支持,因此协商后选择短期内:运营发提数邮件,研发协助手动提数。

对于结果,第一步,保证逻辑;第二步,超越逻辑,保证优雅。换句话说,服务对象觉得满意才是真的满意。早前滴滴爆出乘客安全问题,虽然滴滴在安全方面已经胜过出租车,但用户认为滴滴需要负责,那滴滴就应该承担更大的责任,不管是进一步提高司机准入门槛、与公安机关合作还是让乘客更直观地感知到滴滴的安全措施。

2、他人解决

“如果一个人处于解决问题的位置却并不受问题困扰,那就采取一些行动使他能亲身体验到问题”,比如工作中遇到对方响应问题消极,该发邮件抄送双方领导还得发。

## 扩展阅读

1、文章:如何解决问题
2、书籍:《决策思维》

如何判断需求的优先级

产品经理平时打交道最多的就是各种需求,需求的来源有很多,包括用户侧、同事侧(上级、商务、产品、设计、研发、测试、运营等)和自己的调研等。

要做的有很多,每件事都有收益,也都有成本(含机会成本),就当前而言,要不要做,先做什么后做什么,怎么做。收益层面,现实中面临的往往是两难甚至多难选择,短期收益和长期收益、正向收益和负向收益等,如何平衡。成本层面,时间、人力等,如何支持。

## 设计阶段

设计阶段主要是根据收益判断优先级并设计产品方案,需求按 P1、P2、P3 标记,P1 最优先,同时说明理由,写不清楚理由的需求不应该列入需求池中。

收益包括两方面:一是(对用户的)影响范围和程度,对多少用户产生了多大的影响,核心用户、非核心用户还是涉及多个核心用户群,正向影响、负向影响还是两者兼而有之,比如滴滴前段调整了拼车价格策略,原来是拼成拼不成乘客端都是拼车价(低于快车价),现在是拼成拼车价拼不成快车价,乘客端体验是下降的,同时从《俞军产品方法论》“关于拼车价值分配问题的权衡” 一节中获知方案对司机端也有影响;二是对公司的影响如何,比如可能短期亏损但战略意义很大,美团在南京上海打车做得一般,也迟迟没有进入北京,但美团并没有关闭打车业务,之后还高价收购了摩拜单车,对于美团而言,满足用户的衣食住行需求才是目标,而收益的确认需要结合目标来进行。

就日常而言,问题(BUG)修复>新增功能>产品优化,但并不是说 BUG 在所有情况下都要第一时间解决,响应是必须的,但查明原因后还要评估,如果 BUG 影响的只是一小部分用户,同时现有开发计划很重要,那就考虑有没有临时或线下处理方案。产品优化需求一般会排到最后,因为既然是优化,说明原有功能是可用的,流程是能走通的,只是说体验可以做得更好。

## 评审阶段

评审阶段主要是根据实施成本再排序。跟研发测试(含设计、运营等)讨论产品方案,一是需求层面,对需求的判断有无问题,个人视角往往有局限,即使需求判断没有问题,团队成员也有了参与感,有利于后续实施,二是方案层面,有没有更合适的方案,现有方案有没有漏洞,方案的实施成本如何,当然产品经理设计方案时也要根据经验将实施成本考虑进去。

某种程度,产品的设计研发上线过程也是一个产品,如何保证期间的用户体验良好,可以想想,提前考虑成本只是其中一点。对于技术问题,不清楚的先百度,然后再咨询研发,咨询研发时要考虑对方的时间,在不影响对方现有工作的前提下进行。之前就遇到过一个对产品经理要求比较高的研发同学,但他回复问题是非常专业的,也让我学到很多。

评审完成后,基本就确定了本期要做的需求,然后研发测试那边开发、准备测试用例,产品这边跟进的同时考虑下一期需求并设计方案,依此循环往复。对于需求,总的来说,就是要做 ROI 高的,包括短期 ROI,也包括长期 ROI。

## 扩展阅读

1、问答:产品经理如何分析和管理需求

理解需求2

之前在《理解需求》中聊了需求的特点和管理,这里聊下需求的分析和调研。

## 分析

需求是什么?归根到底,就是某些人遇到了某些问题有待解决。我们可以从 “5w1h” 的角度进行分析,即 who(用户)@when&where(场景)遇到了 what(问题),然后 how(怎么一步步解决的)&why(为什么)。

其中场景在移动时代更重要了,同时 why 包括 why 这样处理和 why 是我们,why 是我们又包括两方面:一是价值,@俞军 提出的 “产品价值 = 新体验 – 旧体验 – 迁移成本” 很好地概况了这点,当然该公式更适合 C 端产品;二是可持续性,以瑞幸咖啡为例,比如市场竞争,星巴克也搞起了咖啡外送同时喜茶、奈雪の茶等新式茶饮也很受欢迎,再比如成本管理,优惠券能发多久是可以衡量的。

## 调研

解决用户的问题是一切的基础,我们对问题认识越深,越有可能提出好的产品方案。问题本身是客观存在,我们需要的只是全方位的了解,了解问题可以从两方面考虑:一是听其言,二是观其行。

### 听其言

1、用户反馈

反馈渠道包括产品内和产品外,产品内即系统自建渠道如官网、应用中的意见反馈功能,产品外包括用户在线上平台如百度贴吧、百度知道、App Store、微博、知乎、微信公众号等发布的以及通过商务、运营同事线下反馈过来的。对于用户的声音,我们需要更加重视,因为愿意发声的要么是问题真的严重,要么是真爱。

2、用户访谈

直接问能获取更多深层次信息。访谈中有两点很重要:一是开放的心态,用户对产品的理解很可能和我们不一样,多听听他们的理解和他们的使用习惯;二是批判性思维,包括区分事实和观点、确认事实等,确认事实中很重要的一点是提问足够具体、深入,同时最好有数据、截图等证明,因为有时候用户并不是真正地了解自己,同时人的记忆也不完全可靠。

3、问卷调查

问卷的设计和投放是一项比较专业的工作,建议学点统计学知识,有助于提高问卷调查的效果和效率。其中需要关注的点包括如何找到潜在目标用户、如何鼓励他们参与进来、如何设计题目以测试回答的真实性和提高问卷的完成率等。

### 观其行

1、亲身体验

自己是产品的重度用户是最理想的情况,这样对细节的理解会更深,同时可以持续记录自己在每个阶段不同场景下的使用体验,但并不是所有产品经理都有这个机会,尤其对很多 B 端产品经理而言,此时我们可以采取线下轮岗等方式短期内成为自己产品的用户。亲身体验很重要,因为是第一手资料。

2、线下观察

对于 C 端产品,不管是平时观察亲戚朋友的使用,还是在地铁中观察陌生人的使用,都能获取一定量的信息,而对于 B 端产品,线下观察会相对困难一些,更多地需要考虑通过其他方式进行调研。

3、数据分析

数据分析的好处,一方面是能获取群体数据,让我们可以从整体层面看待用户的使用情况,另一方面,行为相比言语可信度和效力都更高。比如人人都在说要锻炼和学习,但 “身体是诚实的”,健身房年卡的消费次数、得到知乎付费课程的学习完成度、微博微信抖音快手的使用时长等都能说明问题。当然光看数据也不够,因为数据反映的是结果(what),原因(why)还需要研究。当我们没有头绪时,可以考虑 “用户访谈”,如果说数据分析是 “最好” 的 “知其然”,那用户访谈就是 “最好” 的 “知其所以然”。BTW,理解和解读数据这事,需要本事,也需要良心。

理解需求

## 特点

1、层次化

抖音是我的常用应用之一,它满足我的什么需求呢?第一层,看短视频;第二层,各种有意思的内容,比如 360 游戏客服小姐姐,声音好听,段子有趣,比如难搞哦小姐姐,笑起来真好看,一直说难搞哦也挺好玩,再比如油百万小姐姐,看看滑稽戏,听听英语;第三层,有时是休息放松,有时是打发时间;第四层,按照马斯洛的需求层次理论,对应了一定的生理和自我实现需求。再扯远点,如果某天发现自己和某位小姐姐是老乡,特意关注小姐姐的直播,对应了归属与爱的需求,然后直播时送礼物,小姐姐当众说谢谢,对应了自尊的需求。

深入理解需求是为了更好地满足需求,同时如果我们能满足用户深层次的需求,就更能建立产品竞争力,不容易被其他产品超越。抖音、快手火爆以来,其他内容平台的活跃度受到了影响,其中今日头条和映客是比较明显的,微博和喜马拉雅是本可以发展得更好的,同时,书影音和游戏类产品的使用时长也受到了影响,因为都是娱乐方式,这块 Questmobile 的 2018 年年度报告有说明。至于如何深入理解需求,连问五个具体是什么或为什么是很好的方式。

2、场景化

需求最终会落实到个体,统计数据也是基于一个个用户的使用累积起来的。很明显的一点,每个人都有自己的想法,需求并不完全相同,比如玩抖音,我只看视频,关注的那些博主拍视频,其中有的是表达自我,有的是跟风从众,还有的是专职工作。相对不那么明显的是,同一个人不同场景下的需求也会不一样,比如有些人平常不怎么玩抖音,但在车站、机场也会玩玩,因为这会儿往往比较无聊。近期传出 “抖音将登陆国内 80% 高铁列车城市,在高铁电视上播放非遗、旅行、美食、萌宠类短视频内容”,先不说好不好,但抖音是抓住了旅途场景的特点的。

3、模糊化

需求来源有很多,包括我们的观察、用户的反馈等,很多时候需求是模糊的,不准确的,比如经典案例:“用户只会告诉你需要一辆快和舒适的马车,不会告诉你需要一辆汽车”,福特的意思是用户非专业人士,产品设计者应结合用户意见提出更专业的解决方案。“获得的信息是 want,我们要找的是 need”、“用户诉求不等于需求” 等说法也都在告诉我们,要找到问题背后的问题,找到用户的动机。BTW,福特这句话是针对一般情况说的,在其他情况(场景)下,汽车未必是最好甚至未必是好的解决方案,比如有些同学去布拉格旅游,想坐马车,体验一下当地的传统文化,再拍拍照片、抖音,你如果跟 TA 说,“不,你需要一辆汽车”,结果可想而知。

## 应对

1、全面与否

收集需求时,首先,问清楚,包括前因后果,同时区分好事实和观点,事实确认一遍,观点待议;其次,问完整,避免有遗漏,获取的信息越全面,决策越明智;再次,收集完还要思考,因为呈现出来的可能是冰山一角,如果只解决这表面的问题,就是 “头痛医头,脚痛医脚”。

2、真实与否

对于需求,如果是 bug,请先核实真实性,之前就遇到过用户反馈身份验证失败,但实际是自己输错了密码,TA 以为自己输的是对的。如果是建议,需要进行逻辑分析和市场检验,我们可以按 “角色 – 场景 – 任务” 的方式去思考,即谁在什么情况下遇到了什么问题,怎么一步步解决的,有可能放到具体场景中后会发现这是一个伪需求,无需满足。当然,判断未必都靠谱,因此假设之余还要求证,“实践是检验真理的标准”。

3、重要与否

确定是真需求后,就要开始考虑需求的优先级,结合产品目标,是雪中送碳还是锦上添花?是新增功能,还是优化已有功能,还是修复 bug,影响多少用户?需求方有没有提解决方案,方案的正向、负向影响如何,有没有更好的方案?方案完成后,在后续需求评审会上,研发测试同学还会结合技术实现、资源情况等再排一次优先级,但需求本身的重要性是第一位的,很多时候即使工作量大点,研发测试同学也是会去做的,有时候他们说不好实现实际是对需求不认可,这点要留意。

## 扩展阅读

1、书籍:王诗沐《幕后产品》刘飞《产品思维》

如何评估产品的商业价值?

借鉴游戏、电商中的概念,产品的商业价值(天花板)=ARPU*(用户数 * 付费率)*LT,具体可以从以下四个方面来评估:
1、用户群:大众 or 小众
2、需求强度:强需求 or 弱需求 or 伪需求 // 可通过用户付费意愿性来评估
3、客单价:高客单价 or 低客单价 // 交易相关性
4、需求频度:高频 or 低频 // 复购率

P.s.
1、以上内容都需要经过实际调研,比如上周和同学吃饭,他提到养老院的用户群没有预想得那么大,比如需要排除掉农村老人,因为社会称许问题,农村子女不太能接受把父母送到养老院,同时他还提到住养老院并不代表没钱,有些老人是因为子女在国外不方便照顾去的养老院。
2、数据是动态的,要从未来看现在,比如在 2014 年时就应该考虑到外卖行业的用户群和需求强度会随着 80、90 后进入社会不断上升。当然预测是很难的,不然历史上也不会有那么多优秀的公司挂掉,我们需要的是持续跟进评估。
3、关于客单价,互联网产品商业模式很重要的一个特点是,未必直接向 C 端用户收费,比如百度是向有推广需求的企业收费,淘宝是向有推广需求的卖家收费,PC 互联网时代的 360 是通过 360 安全卫士推广 360 浏览器,然后再通过网址导航、搜索广告等盈利。
4、作为产品设计者,我们需要充分挖掘每个用户的价值,其中付费的,按付费金额算价值,没有付费的,那就请 TA 贡献围观、宣传等其他价值。非付费用户也很重要,比如王者荣耀、和平精英等游戏,如果周边没有人玩,有多少付费用户会去玩?买皮肤给谁看?买装备和谁战斗?