如何说服他开车带眼镜【人人都是产品经理:9056】

一个同事,视力不好,要学开车,我们都说他一定要配眼镜,但他多年习惯了不带,有点不愿意。我的说法是会看不清人,撞到,比如晚上会很危险,他说肯定不会;同事说,你到了路口会看不清路牌上的字,得减速,结果他认可了。

  • 结论一:我不开车,所以体会不到痛处,也就说不出用户关心的关键,所以,熟悉用户很重要,否则你真的猜不出他是怎么想的。
  • 结论二:站在用户的角度考虑问题,而不要站在一些莫名其妙的角度(比如本例我站在路人的角度,也是我的日常角色,虽说也很重要,但毕竟痛感不强烈)。

产品设计体会(6030)对症下药,找到用户的刚性需求

做产品必须找到用户的刚性需求。何谓刚性需求?我们常说的一个例子,成(防绿坝插入此句)人网站就是满足了刚性需求,在这个前提下,就算注册流程做得再烂,下载一个文件需要点10次鼠标,用户的粘性照样嗷嗷的高。所以,找到了刚性需求,方向正确,后面的事情做起来都简单很多。

前两天听了卫哲同学的一个分享,其中对我们用户——中小企业——需求的理解让我印象深刻,记录一些点滴,并融入了自己的理解,供讨论。

  • 作为产品经理,乃至每一个人,都要不停的想,不断的问自己:用户痛在哪里?痛有多深?止痛药多少钱?
  • 中小企业的需求,开源>节流,效率<效果:大企业的时间值钱,所以愿意花钱买时间;中小企业的时间不值钱,纯粹靠帮助他们省时间是赚不到钱的:对大企业,提升“效率”的服务可以赚钱,他要雇很多“农民”做的事情(指劳动力密集型的工作,没有贬低的意思),我们都可以关注,当“农民”做到手酸的时候,就是我们可以收钱的时候;而中小企业,一共就一个“农民”,还很便宜,你帮他省了点时间,他聊QQ、偷菜去了……所以需要提升“效果”的服务,帮他搞到更多的订单、客户,让他先发展壮大起来。
  • 满足需求的节奏感:从Meet@Alibaba到Work@Alibaba,第一,Complete Trade,完成贸易,比如订单、收款;第二,Beyond Trade,超越贸易,比如资金、人才。对中小企业,首先要生存,必须拿到订单、抓住客户,这是刚性需求;然后要成长,需要资金、人才,是刚性需求;在满足了这些需求之后,才可能从“让天下没有难做的生意”到“让天下没有难管的生意”,生意做大了,会自然而然产生发展的需求,才到管理软件的需求。对头疼得想撞墙的用户,就先给他杜冷丁打下去,不要说“你体质不好,我给你开一副中药调理,半年后肯定壮汉一条……”
  • 止痛药的售卖思路:从远古时期的买断,到会员制,一年一卖,为了卖出价(比如几千块一年),所以必须把很多功能打包堆砌在一起。回顾上面两条,这样卖的东西就很有“管理软件”的感觉,不是说不能这样做,而是这条路会很辛苦,并且不是唯一的路。而现在可以看到的另一条路就是打散了卖,把管理软件化整为零为无形的服务,功能模块化,做到“一拆二插三深入”,先把自己拆了,然后插入现有服务,最后“随风潜入夜,润如细无声”。除了按时间卖,我们还可以多多思考按“效果”卖,真正的P4P(pay for performance),时间对每个人都是公平的,所以对大企业也只能收中小企业那么多钱,这对中小企业反而是不公平的。“效果”的变形,可以是Leads数、交易额、转账额……
  • 中小企业付钱买药的人:收钱的时候,要分清中小企业中,老板业务员能动的钱,我们的中小企业中,业务员通常是有一定资金的自主决定权的,要利用好。越是数额小、紧紧绑定业务过程的钱,业务员越能自行决定。卖软件的思路是“业务员预先请款(如果有的话),老板做购买决策,付钱,业务员使用”,我们的痛苦在于“客户”与“用户”的分离,买的人和用的人不同。“一拆二插三深入”以后,改造服务的收费模式为“业务员先用,再去找老板报销”,比如业务员跑业务的过程中,自己做一些宣传资料是可以报销的,会比原有的的方式顺畅很多。对于老板,把握住他们“就算不上网、不用电脑,但是用手机”的特点,无论如何,看来移动的趋势大家都逃不掉。

找到用户的刚性需求,最痛的地方以后,有节奏的用合适的方式把止痛药卖给合适的人,之后的产品设计过程中,各种技术、工具才能发挥最大的作用。

产品设计体会(1014)需求,如何确定“做多少”

【小广告】今天在我的强烈要求下,出院了,进入在家休息阶段,本周六去医院拆线,发一篇庆祝~~~

敏捷(Agile的一个特点,先确定项目时间,专业点叫“迭代周期”,然后有一个人员相对固定的团队,意味着项目资源,要保证项目品质,根据项目的“多快好省”原则,最后能变得只能是量——项目范围,前段写过一篇如何做好“老板项目”里也有相关描述。

那么,某个项目里,做多少需求到底怎么定?这个过程不妨用下图来表示,这张图也是PD的需求过程图中的一小部分,即“PD @ alisoft做什么”这张图里最左边一个箭头里的“需求分析”那个小框,以后有机会再把全图展开来说。

同学们可以先回顾一下之前说过的excel功能列表需求管理表格,产品团队的一项日常工作就是采集产品干系人,即“广义用户”,提过来的各种需求,并整理转化为产品需求即图中的“需求转化”,通常转化之前我们用mindmap较自由的表达,转化之后就成了excel里的功能列表。采集到这个需求的PD,自己可以先“确定属性”,即这个需求是属于产品的哪个模块?是基本、扩展、增值功能?是功能、性能、用户体验方面的?等等,属性的维度大家可以按照产品的不同自由定义,原则是为了便于需求的管理。

这样我们得到的feature list,就有必要每隔一段时间、或是新需求积累到一定数量、或是由特别事件触发,拿出来大家一起过一遍,这是最关键的,即图中用红色突出的“确定商业价值(产品内PK”。我们的经验,商业价值由单个PD确定风险很大,所以这个步骤是PD团队集体讨论,再叫上有必要的干系人,比如销售、服务。对于商业价值可以从多个维度描述,并加权平均得到综合的商业价值,详细描述可参见单向需求卡片,但绝大多数情况下,我们发现只用一个值的高中低,或者54321分来衡量就足够了。具体讨论的时候,大家充分表达意见,最终往往是会场上级别最高的人综合以后说一个数字,这是现实,也是一种高效的办法,我想过投票、群体打分的方式,可是实施起来成本太高。

注意一点,讨论商业价值的会议上,会把所有状态为“待讨论”的功能点都过一遍,散会的时候,它们的状态一定要变化,或是进入“需求中”、或是被“拒绝”、或是“暂缓”。拒绝的需求是被认为对产品的商业目的没有价值的,而暂缓的需求是“有价值,但是现在不做”的,通常要表明重启的条件,比如“3个月后再拿出来讨论”、“某相关产品实现某功能后再拿出来讨论”等等。

对于状态变为“需求中”的功能点,下一步就是初定工作量了,因为需求不明确,所以只是简单的评估,和真实情况的匹配程度很取决于经验,要靠不断的实践来反复修正。我们通常经历的项目,三大类人力资源是“产品、开发、测试”,用团队里的瓶颈资源做评估基准,所以我们一般评估每个功能点的开发工程师工作量,因为在我们的团队里通常产品、测试资源相对可以调配,这个大家视自己团队的情况灵活应用。具体的评估,通常是类似技术经理的角色来做,评估者按照自己做需要多少时间,乘以一个系数确定,这个系数一般大于1

继续,既然对于每个迭代周期,我们有多少时间、多少人是早就知道的,那么可用工作量是多少“人日”,也就知道了。有了每个功能点的商业价值和工作量,很自然的就能算出性价比,简单的说即“商业价值/开发工作量”,我们把feature list按照性价比从大到小排序,再对应考察每行评估出来的开发工作量,从上到下依次纳入项目,我们的可用工作量能做多少个功能点,一目了然。

上面谈到的这些,也就是一步步确定某个项目能做多少需求的过程。

最后,我们把这些要做的功能点合在一起,把“需求打包”,再往下就要做这个项目的BRD了。BRD通过,立项之后,再全程跟踪某个需求的进度,上述整个过程就是一步步确定某个需求的各种属性的过程,而对某个需求的描述,可以用下面的表格来表示(不妨起个名字叫做“一个需求的DNA”),表中红色星号表示的项目,是我心目中的必填项。

这个过程完全是定量的,也就回答了“做多少”的问题。但,真实情况哪会这么简单明了,下面再说几个需要注意的地方。

第一,需求打包最好打类似的功能点,是否类似取决于需求的属性,“确定属性”这步做的事情起作用了,一般来说业务上有逻辑关系的需求才会包含一个项目里,否则就是一个纯粹修修补补的“小需求项目”了。

第二,需求依赖,功能点互相之间有依赖关系,那没办法,只能先做某些功能,应该在feature list里注明;功能点与人力资源之间的依赖关系也会经常存在,在这里评估工作量的时候不会考虑“谁来做”的问题,但是在后续立项,组建团队的时候需要注意,当然长期来说,为了避免这类风险,提升与平衡团队成员的能力是王道。

第三,功能点的粒度大小问题,商业价值很高的功能,如果细分的话,我们也会发现其中有价值相对低的部分,所以功能点的粒度应该尽量细,前提是细化引起的管理成本上升在可接受的范围内。具体细到多少,也只能具体情况具体分析,我想工作量的最小单位总不能超过“5人日”吧。