【产品思维】聊聊我理解的产品思维

闲谈

窝在宿舍床上,抱着一桶泡面啃,嘴里念念有词:再不更新文章别人会不会以为我这个号已经挂掉了,思来想去,觉得今天必须得凿一篇文章以证清白。公众号维护一个多月现在才40多个关注人,好丢面子 (´-ι_-`)。

说正经话

今天想分享的内容是PM同学经常会听到的一个词:产品sense。这里想结合自己的经历,讲讲什么是产品sense。阅读文章之前,温馨提醒:

  • 系个人产出,能力有限,内容如有偏颇,还望在公众号里面留言,必定回复;
  • 产品思维不单单是PM需要,我想对于所有从事非技术职位的同学,体验一下这类思考问题的思路,想必有些积极意义;
  • 人人都是产品经理?我觉得是;人人都能成为产品经理?就比较扯淡了;

从5个方面来表述一下什么是产品思维。

一、以目标用户诉求为导向

这个短语里面有两个关键词:目标用户和诉求。

先解释第一个,什么是目标用户?对于任何一款产品而言,不可能所有的用户的都是它的目标用户。快手短视频很火,可是它的产品调性让我不喜欢使用,我不是它的目标用户;基金定投能够让财富增值,但是很多学生并不会投资,因为学生群体也不是基金产品的目标用户。作为产品管理的参与人,尤其是在接手新产品的时候,找准产品的目标用户,显得尤其重要,因为它关系着日后的工作决策是否切实有效。

那什么又是诉求?咬文嚼字的文字游戏就不玩儿了,诉求指的就是用户最需要的解决方案,诉求并不意味着用户需要,因为很多时候用户也并不知道自己需要什么。比如我说“我想吃东西”,给我拿个汉堡我会觉得开心,但是给我一碗饭我也会很满足,因为我的诉求并不是我想吃什么,而是“我饿了”。用户的言语表达具有临时性和突变性,而更具有参考价值的则是用户的行为,这也是用户研究存在的一个很大的意义。

我们常规思考问题的场景,更多的是以个人或者既得利益方作为出发点,无可厚非,因为很多情况我们的行为都是服务于我们自己。但如果从职于产品方向,则在面临问题时第一反应需要站在目标用户的角度去思考,讲究同理心,也就是换位思考。这也是为什么说成为产品经理之前必须要先成为产品的目标用户,毕竟“知己知彼,方能百战不殆”。

二、用流程的方式回归问题

这一句话有点拗口,语文不咋地的我也不知道怎么用一个短语来表达自己的想法。其实质就是,在处理问题或者设计方案时,学会以第一人称视角走完产品流程,在体验流程的过程中去发现问题并从中解决。产品服务于用户,用户在使用产品的过程中就必定会产生前后环节的衔接,而产品在设计之初也需要明确,哪条线是我们希望用户去走完的。

流程回归和换位思考有相似之处,不过前者讲究落地执行,后者则侧重需求分析。其实这种思考方式在小学老师教我们看统计图时就有所体现,先看横轴,在看纵轴,然后结合两种信息再分析独立的点。这样有条理的分析思路能帮助我们规避无用功的投入以及避免落下一下有价值的要素。行为总是有先有后的,这不过这次,我们是换成了用户这类角色。

现在很多需求产出的场景,往往是在某个环节或者某个功能点进行优化,较多忽略了在全局流程的层次来看待问题。当然我说这句话很容易被打,毕竟产品越做越大,要是每次都重复一遍流程思考,也就不适合互联网“小步快跑,快速迭代”的模式。两者存在冲突,但是依旧可以兼容,比如制定迭代几个周期就进行一次回归复盘,减少不必要功能的累加。一些“死胡同”性质的功能不能说失败,但是是有缺陷的。

三、时刻保持成本收益意识

这一点对于老资历的PM来说基本OK,可能也是因为被老板怼多了,工作经历丰富,成本收益意识也就形成了条件反射。那么对于像我酱紫的菜鸟PM,起初经常会觉得产品需要为用户提供良好的用户体验,因此一味的想把产品上所有影响流程的不足一一修复,可是往往忽略了需求的收益以及耗费成本

其实多被RD小哥哥吼几次,多被设计小姐姐怼几下,多被老板骂几回,多学点技术设计知识,差不多就能形成成本收益意识的条件反射了(* ̄∇ ̄*)。

需求设计的成本大概包括以下几个方面:

  • 技术成本:大多数需求实现是需要RD小哥哥一行行代码敲出来的。因此PM就需要了解一些客户端、服务端以及数据库方面的知识,免得提出的需求毫无人性;
  • 设计成本:不要以为设计小姐姐长得好看就好欺负,怼起人来也是不落下风,如果提出一些稀奇古怪的交互需求,恐怕做个动效都得花很久,基本的审美意识和交互知识,还是很必要的;
  • 资金成本:这方面主要体现在运营活动,比如红包激励、H5抽奖活动等等,都需要初步计算资金预算成本是多少,花出去的钱,一分都不能浪费;

那么相对成本而言,收益的评估维度又包括哪些?

因为这个不同产品的KPI量化指标不同,也没办法去一一衡量收益的维度,不过大致总结就是三方面:

  • 为公司挣钱;
  • 为公司省钱;
  • 不挣钱也不省钱,但是是为公司主航道业务而服务;

另外需要强调一点,无论是描述成本或者收益,量化指标非常重要,很多情况下无论是RD还是设计还是老板,最关心的就是需求的凭据,而凭据最有效的呈现方式就是数据。因为这方面自己栽了不少跟头,所以想单独拎出来讲。

四、凭数据和事实说话

无论是做产品还是市场or别的业务型岗位,数据往往是逃不过的一个工作要素。在上一篇文章《【需求评审】谈谈产品需求如何被“接生”》我在结尾处谈到了数据作为支撑需求评审的重要性。可能是因为自己从小就比较恐惧数学的原因,过去很多场景下自己的需求都是凭借用户调研或者简单的数据分析就开始产出了,对数据的挖掘程度还远远不够。随着几次磕磕碰碰的需求评审,越来越意识到数据在工作当中的重要性。数据分析作为PM的核心能力之一,需要去不断强化。

这一部分内容自己很难给出具体的case,想提醒的就是,实际工作和在学校很大的不同,就是在工作时的任何一个场景,无时无刻都在付出成本,而说服上级或公司提供这种成本,则就需要给出凭据,PM需要通过给出凭据来获取公司资源,而凭据呈递最有效的方式,就是数据。

似乎回到了当年“学好数理化,走遍天下都不怕”支配的恐惧。

五、懂得协调资源分配

这一部分可能显得比较虚,什么是资源,怎样协调,这些情况都是根据自己公司的业务状况而定。而PM需要做的,就是合理的将大问题根据拆解为小问题,能够定位问题的原因并将其交付专业同学解决。比如定位问题属于交互类交付给设计同学,问题出现在客户端则就交付给客户端RD,如果服务器宕机那么就需要让OP同学去解决,如果产品需要新用户则就要求运营去策划活动。在整个产品生命周期管理的过程中,各种各样的问题会层出不穷,PM利用产品思维在问题面前快速有效的去推动解决就显得极其重要。

资源协调和推动很考验PM的综合素质,尤其是在面临具体问题的时候更加如此,而且PM没有管理层那样的具体资源调度的实权,就好比古代战争时筹划谋略的军师,能够利用各种军事策略跟敌军战斗,但是最终调度军队的只能是元帅。所以,想要当产品大军中的元帅,骚年们,努力吧。

复盘:

我认知下的产品sense:

1、以目标用户诉求为导向;

2、用流程方式回归问题;

3、时刻保持成本收益意识;

4、凭数据和事实说话;

5、懂得协调资源分配;

——欢迎扫码关注“滔滔有话讲”——

【需求评审】谈谈产品需求如何被“接生”

洗完澡盘腿在床上,思索着今天应该需要写啥。

自己出校门实习也有了一段时间,待过大公司,待过小公司,也待过不大不小的公司。在每一次产品的版本迭代环节,总结来看,PM工作流程大致可分为以下几个阶段:

  • 需求收集:主要是需求池的维护,产出优化的初步思路。需求来源可能是用户反馈、boss要求、数据分析产出等等渠道;
  • 需求分析:明确背景,量化需求收益和成本,根据团队开发能力和其他限制因素筛选需求方案,以及排定需求优先级;
  • 需求设计:此阶段需要产出落地页设计方案,明确页面跳转逻辑以及服务端策略;
  • 需求评审:在包括组内feature评审,详细策略评审以及技术评审,目的在于明确风险点以及开发排期;
  • 开发跟踪:跟进开发排期进度,协调设计和其他资源;
  • 跟进提测:包括组件提测和全量提测,跟进修复可能的bug;
  • 上线观察:主要就是上线后的效果观察,若有A/B测试则需要对比分析需求的ROI;
  • 产出迭代项目,重复步骤一;

篇幅所限,没办法在一篇文章内描述完所有的流程,这次针对产品工作流程的“接生”环节——需求评审,谈谈聊一聊。

一、需求评审的“地位”

为什么没按照工作流程从头开始讲,为什么自己会将“需求评审”称作“接生”。PM这块儿一直有一个段子叫做“产品就像是一个孩子,PM、RD负责生孩子,运营负责养孩子”。如果把需求评审之前称为“受孕”,那么需求评审也就是“接生”的阶段。因为需求怎么做,能不能做,能做到多大程度,多少人来做这个需求,都需要在评审环节完成结论产出。避免需求被拍死,就需要PM在评审环节做好充分准备。

另外,PM舌战RD撕逼的场景,往往会在这个环节体现的淋漓尽致。

二、需求评审的几个阶段

  • feature 评审:基本由PM组内参与,主要是核对需求要点,避免发生需求冲突;
  • 组内策略评审:基本由PM组内参与或者少数设计同学,评审需求的策略逻辑是否合理以及初步设计方案,明确待优化项;
  • 组内策略优化评审:基本由PM组内参与或者少数设计同学,明确上一版评审基础上需求疑点,本阶段评审结论为定稿方案;
  • 技术评审:参与需求开发的全员参与,完成需求讲解和排期确定;
  • 排期方案制定:包括明确各个各个承接方具体的工作安排和负责内容;

三、需求评审“评”什么

如果把需求评审本身当做是一个产品,那么参与需求评审的成员也就是这个“产品”的用户。这些“用户”大致分为:PM、客户端RD、服务端RD、运营、数据组、QA、UI、UE以及各自部门的老板。我根据团队内不同成员的诉求角度,先来拆一拆这些“用户”都各自需要什么:

  • PM:完成需求内容的讲解,完成质疑解惑,需要明确需求承接方以及排期情况;
  • RD:了解需求的技术成本,明确每个需求的确切策略以及需求背景和收益;
  • 设计:了解需求的设计成本,用户体验因素的考量;
  • 运营:需要了解该需求是否需要适配推广或者运营方案;
  • 数据:需要明确需求收益的评估维度和评估方案;
  • QA:了解需求存在的风险点,排查用户以及技术层面的风险;
  • boss:了解成本、为业务或者公司带来的收益以及评估策略;

OK,取上述“用户”诉求的并集,其实就能够得出在需求评审的环节中PM需要讲解的内容,也可大致作为撰写PRD的内容框架。

  • 需求背景:功能诉求产出的原因,最合理、最有效的需求背景就是用数据支撑。数据需要贯穿评审的每个环节,包括明确需求收益、数据评估等等;
  • feature list:也就是所有本次待评审需求的整理集合,需要明确需求的优先级,各个需求的story子例,评审成员能够通过list一览整个版本的需求信息,也方便整理开发排期。
  • 需求详细:RD需要明确每一个需求的详细策略,同时QA也需要通过策略来检验需求是否存在冲突和异常风险,为了便于策略沟通和理解,评审内容能上图就上图(用户流程图、布局框架图、逻辑跳转原型图等等),对于设计同学来讲,若有设计需求,则还需要产出基本的demo样例,方便成员在实际开发前了解需求的呈现形式。
  • 评估体系:包括客户端打点统计,明确打点评估维度,便于在开发上线后做需求收益的评估工作。

四、啰嗦几句

1、PM是需求评审的决策者

往往很多时候,由于需求准备不足或者思考深度不够,在面临需求PK或者答疑环节,很容易被其他成员“带着跑”,以至于出现最终拍板的需求并非之前组内通过的需求方案。面临此类情况,为了推进评审进度,最好的处理方式就是暂停该需求的评审,进入下个评审环节,待会后明确清楚再定夺是否开发该需求。

2、数据是支撑需求的有力工具

就如同每个人都遵守法律一样,做决策时数据往往就是最有力的的武器。当出现团队意见分歧或者不认可,PM需要拿出数据来为自己的观点提供辅助,基于事实和数据做出的决策会比靠感觉和经验更有力度。

3、学会团队激励

以前看过很多帖子都说,技术评审环节可以减少背景、收益等要素内容,因为RD只关心需求怎么实现。但是事实并非如此,任何一个合格的RD,包括设计、QA在内,都绝对不只是一个落地实现需求的“机器人”,他们都会关心自己的工作目的是什么,收益是什么。因此在上线评估阶段,PM可以根据成员分工排期以邮件形式周知收益状况,让实际参与落地上线的同学了解到他们的工作最终为产品带来了什么。成就感的建立,往往也能为PM的可信任感增分不少。

(其实上面的话很多是我老板教我们的~~~)

复盘文章内容:

1、需求评审是产品工作流程的关键环节,直接决定了需求能否从idea到落地实现;

2、需求评审阶段主要分为PM内部评审、团队技术评审和排期制定;

3、评审内容大致包括需求背景、目的收益、详细策略、落地页设计和收益评估维度;

4、PM需要利用数据增强话语权和可信度,另外也需要通过收益数据来激励团队成员;

欢迎关注“滔滔有话讲”