产品经理工作基本法
最近读了一本书,《从点子到产品》是锤子科技的产品经理——刘飞,写的一本关于产品经理价值观和方法轮的书。对产品经理还是很有帮助,书里面总结了产品经理日常工作的一些方法论,实用性较强。在此,我总结了书中建议和我个人的一些基本方法,希望能帮助大家。
本文的内容结构如下:
- 提出问题
- 书籍内容框架
- 总结归纳重点内容
- 得出成长建议
提出问题
初级产品经理常问的问题一般有:怎么进行需求分析,如何设计功能,怎么推动项目开发,怎么跟开发沟通等等。这些问题都是产品经理日常工作中的主要内容,每一个单独拿出来讲都可以讲上大半天、大有乾坤,所以产品新人感到疑惑也正常。
所以这里基于书中内容和笔者日常工作,归纳总结了对应的方法。
内容框架
第一部分:主要讲述从粗略的点子到具体的方案,要经历的步骤。
包括找到产品核心价值、挖掘用户痛点、定义MVP(最小化可行产品)。
第二部分:主要讲述如何落实方案,以及如何进行用户研究、需求分析和产品设计。
包括如何深挖需求、进行用户研究和提高用户体验。
第三部分:主要讲述在落实方案的过程中要掌握的方法和管理技巧。
包括需求池管理、文档管理和工作流管理。
第四部分:主要讲述产品经理在工作和成长过程中要考虑的一些问题。
包括如何处理问题、如何沟通、产品经理成长等。
本文主要讲前三部分,第四部门将另开文章讲述。
总结归纳
1.关于找到产品核心价值、挖掘用户痛点、定义MVP。
产品从0到1的过程需要验证很多东西,包括产品设计合理性、盈利合理性、产品结构合理性和团队可实施性。
产品新人刚入职时,可能心中对于产品会有很多想法,脑海有很多点子,但是能通过这些合理性要求的点子却不会很多。我们在做产品时,最忌讳的是拍脑袋决定做什么功能,现在互联网产品的用户成本很高,如果流失一个用户,损失的就是真金白银。这就要求产品经理在做产品设计时需要更加严谨、理性。
产品的核心价值就是产品解决用户问题的最优方案。任何产品存在的意义就是为了解决问题,比如微信,解决了人们高效沟通的问题;Airbnd不仅解决了游客旅行租房的问题,还解决了房东出租空房的难题。确保产品真正的解决用户问题,并给出超预期的解决方案就是产品的核心价值。
书中探讨了做MVP产品的理由:快速投入市场验证需求和快速吸引用户。我也认同这两点理由,现在的互联网发展非常迅速,如果等到产品所有功能都开发完毕才投入市场,可能早已错失良机,而且繁重的产品进行迭代更新显得巨大笨重。
如何设计MVP,参考方法——奥卡姆剃刀法。大意是“如无必要,勿增实体”。做产品时我们也可以遵循这个原理,把预期完整的方案简单罗列出来,然后从最不重要的部分一点一点砍掉其中的功能。直到再砍下去正常功能就无法使用为止,这时候的版本就可以算是最基础的一个版本了。但要保证这个最基础的版本能够解决用户基本的问题。
如何找出痛点,书中说到可以通过:分析数据和用户反馈。用户留存数据、使用频次都证明了用户对于产品都依赖度,可以知道用户是否需要产品;商业数据比如付费率和升级率同理。如果有机会收集到大量的用户反馈,并从中分析筛选出最多人反馈的问题或者是用户喜欢产品的原因,也能找到用户的痛点。
2.如何深挖需求,进行用户研究并提高用户体验
产品经理不应该只关注于表面需求,深层需求才是问题的原因,找到问题的根,然后从根部解决问题是挖掘需求的意义。书中通过人性和场景两个维度讨论深挖需求。
-
基于场景讨论需求,面向的是具体的人和事,有具体的数据和事例作为基础,解决的是具体的问题。部分产品经理习惯于脱离场景讨论需求,凭借自己的猜想和理解去设计功能,没有具体的事例作参考,这样设计出来的产品往往是空中楼阁,不接地气,用户用不起来。只有把具体的场景,人、事和环境都带进去讨论需求,设计出来的功能才能更实用,因为这是确确实实地解决生活中的某个问题。
-
基于人性讨论深挖需求,就是利用人的七情六欲、贪嗔痴、善恶是非观去理解需求,深挖需求。书中举了一些例子,比如说,用户反馈是我想赶快减肥,看上去表层需求是想要一个能快速减肥的服务或产品,深层需求是想成为一个体态优美的人,人性需求是虚荣心、得到尊重和欣赏。基于人性讨论的需求,是具有普适性的,如果能准确抓住人性,那么产品便能击中用户痛点。
关于用户研究。用户研究常用方法有,问卷调查、用户访谈、可用性测试、用户行为数据分析。这些方法各有利弊,问卷调查,成本低、快速但专业性强;用户访谈,灵活方便、容易但耗时;可用性测试,科学、真实但成本较高;用户行为数据分析,真实有效、说服力强。用户研究但目的是输出一些结论,分为定性和定量。定性则是输出一些人物画像,用于产品分析或着竞品分析。定量则是输出一些数据结论,辅助决策。
提高用户体验则是通过优化设计,让用户在使用产品时体验更好。书中介绍但较为零散,如果读者想认真学一下设计,可参考《设计心理学1-4》,里面有更专业的知识。
3.如何管理需求文档、需求池和工作流管理
关于需求文档,书中说到,好的文档应当满足:没有逻辑硬伤、没有疏漏、逻辑清晰和可读性强。文档的结构应该是“总—分—总”结构,先把产品框架描述清楚,然后再对业务进行拆分,抽象出功能模块将拆分出来的子业务组合在一起形成功能框架。
大部分产品经理痛恨写需求文档,不仅耗时间精力,而且看文档的人也没耐心,所以久而久之,目前大部分公司的情况是:产品经理画好原型,然后在原型旁边备注说明,这就算是需求文档了。其实这样的需求文档也没有太大问题,只要能把问题和需求描述清楚,也能算是合格的需求文档。接下来,说说怎么样的需求文档是合格的需求文档。
好的需求文档需要满足:
- 结构清晰,逻辑性强。
很多产品经理在描述需求时,没有把业务逻辑说清楚,技术同学便会对功能流程云里雾里,不知所云。对于业务逻辑复杂的,产品经理需要绘制流程图加以说明,有时候解释半天的问题,把图画出来大家就很容易理解。而且产品经理在绘制业务流程图时,对需求也会有更深的理解,可以核查设计上的逻辑漏洞。
另外,产品经理还需要整理出功能的信息结构,数据流图,严谨完整的信息结构图和清晰的数据流图不仅让技术同学更准确开发,也让UI设计师的设计方案更合理,这是提高协同效率的重要方法。
- 需求描述明确,没有疏漏。
技术同事不仅仅是执行的工具,所以产品经理更要把功能描述清楚,只有让技术同事准确理解需求,开发出来的功能才能符合预期。作为一个严谨的产品经理,在描述需求时,也可以注明场景,帮助技术同事理解需求。另外,对于异常情况,产品经理也要在文档里写清楚,这不仅可以减少出bug的概率,也可以让测试同学在测试过程中提高效率。
需求文档最重要的是把问题和需求说清楚,这样的需求文档才是能提高协同效率。
需求池管理
需求的管理是产品经理的重要工作之一,决定了哪些需求先做、后做。
需求池的管理可以用excel表格管理,或是在线表格管理。因为需求多了以后,需要快速筛选和计算。
既然要决定需求的优先级,所以我们要有用来衡量需求优先级的标准。我们可以通过KANO模型来对需求进行筛选。
简化版KANO模型.png
我们需要关心的是期待型、惊喜型和必要型的需求,挑出这三类需求后,我们可以通过需求方、需求背景和价值来进一步排序优先级,根据情况分为P0,P1,P2.
然后每周定期进行需求排期,需求排期主要作用是:排序需求优先级,指定产品负责人,开发负责人,功能上线时间。关于排期,对一些优先级高的需求进行开发排期,一般优先开发P0和P1的功能需求,在时间允许的时候也可以开发P2需求;关于指定负责人,一般来说,系统的某个功能模块是由专门的产品经理和技术同事负责,以后出现的相关需求都是由他们负责,这样的好处是负责人对功能模块会比较清晰、熟悉,开发效率较高。
绝大部分情况下,如果排期评审会完成了,则这一版本的迭代需求也关闭窗口了,不再添加新需求。但是,有某些特殊情况下,产品经理不得不临时“插队”加入新需求,出现这种情况的主要原因是:产品功能设计方案不完整、需求方的主观变动和客观上的不可抗因素。这也就是技术同事痛恨的频繁改需求。
-
产品功能设计方案不完整。对于这个问题,主要取决于产品经理自身能力和产品经理内部评审的有效。产品经理在设计方案时,需要逻辑严谨,罗列可能出现的情况,以及解决方案,尽量避免遗漏。产品经理内部评审时,产品经理不仅需要给其他产品经理讲清楚功能作用与业务逻辑,还需要记录其他产品经理的问题和建议,在会后进行修改设计。
-
需求方的主观变动。这个问题可能是因为需求方起初没有描述清楚问题,对自己对需求也不明确。所以产品经理在开始对用户访谈时一定要下大功夫,帮助需求方明确需求,理清问题。
-
客观上的不可抗因素。这种情况下是可能出现的, 比如2018年初很火的直播答题,很多团队都在做这种项目,但是由于政策原因,项目不得不关闭,这种时候,产品经理需要跟团队解释清楚原因,只要把客观情况描述清楚,技术同事也会理解。
工作流管理
看过一本书《卓有成效的管理者》,里面提到,管理是把事情做对,而领导是做对的事情。时间是非常稀缺的资源,所以管理者在工作中,应当做更多有效性产出的工作,而有效的工作流可以帮助实现这一目标。
需求收集——记录需求方,需求背景,用户目标,用户问题,收集时间等。在与内部业务部门收集需求时,一般是固定时间段收集需求,最好是统一每个部门的需求接口人,统一需求描述格式,需求排期后,需要把排期表公示,跟各部门同步信息。
邮件通知——在邮件说明本次会议的背景,主题,材料,参会人员,会议时间和地点。如果会议主题内容比较多,尽可能的跟重要的参与人员事先沟通,在线下达成共识后,开会时就会少花很多力气。
会议纪要——会议纪要需要记录本次的会议主题,发言人顺序以及主要发言内容,主要的矛盾,已经产出的解决方案和待解决的矛盾,以及后续动作。会议纪要能够让会议的成果更加明确,成员对于会议目标也更清晰。之后要是有什么问题,也可以通过翻阅会议纪要了解。
bug反馈——记录bug现象,发生时的场景,用户名,影响范围,bug优先级等。在微信群、qq群或论坛收到用户反馈时,首先要记录bug的信息,记录清楚后,根据bug的影响范围和优先级来判断是否需要紧急修复;如果影响较小的bug,则可以排到下一版本系统更新时一起上线。
产品经理日常工作中,还有很多工作可以制成标准的工作流,这些标准的工作流能让工作专业、搞笑,即使出了问题也能快速定位原因,能够在繁忙的工作中减少不必要的麻烦。
成长建议
刚入门的产品经理不能光靠阅读一本书或者几篇文章就以为掌握了产品经理的工作方法,只有通过不断的在工作中实践,完善方法论,能够帮助自己解决问题,能够提升效率的法子才是最适合自己的。
另外,工作是一个通过专业技能来完成目标的过程,在工作过程中会跟多部门和同事沟通协作,每个人都是想维护自己的利益,完成工作目标。产品经理要有双赢思维,判断事情如何解决最有利时,要确保的是“对大家有利”以及“对产品有利”,这样对心态才能确保协作的价值最大化。