强者生存论

在休息的一段时间,我很想写一篇文章(服务器被整,很多文章丢了,慢慢更新回来),关于最近碰到的以及别人说到的,总想着有很多的话想要说,但总提不出起口。闲暇时总觉得有时间写点什么,但真到要写时才发现无从说起,趁着周末即将过去,自己还有一点精力,想写一篇强者生存论。
离开论。离开乐淘是必然,但同样看到了电商的一些出路,我一直觉得我只会在一定的阶段出现,完成自己的使命,然后离开,这一年半的乐淘之旅是最充实快乐的,也是学的最快的一段时间,以至于在离开那天在楼下看了好久才离开。毕胜说他电商毕业了,同样,我也毕业了。乐淘选择了另一条路上开始寻求新的方向,我也开始寻找新的方向。这一年半里,我看到了数据疯狂的增长,同样看到转型后的数据回落的过程,过山车的感觉真的很刺激,要有一颗强大的心脏,我想所有做电商的人有一颗强大的心脏是必须的,同样你会发现电商很多CEO说的话并不可信,融资金额、订单突破、流量百分之几百的增长……别信这些鬼话,这些都是为了吸引别人的眼球,真正赚钱的电商都是蒙头赚钱,傻子才会天天在微博上叫嚷着要打倒谁,要把谁挤出这个市场。真正给用户提供好的用户体验,能为用户省钱的,都基本上成为这个市场的主导力量了。这个市场上除了淘宝、天猫,我想至少现在没有看到强者了。弱肉强食的现象在这个市场越发明显,很多电商已经逐渐的退出了这个市场,大鱼吃小鱼的现象也会越来越多,相信这并不是坏事,移动市场的掘起,同样会给电商很多的机会。错过了,或许真的错过了,说给某些公司听。
努力论。市场需要什么样的人才?这是我思考比较多的一个问题,在不同的公司有不同的需求,很多时候只要把一个产品做到精细就行,但如果在一家创业公司,在一个创业团队,更需要的是他的全面人才,专才还是全才这个问题已经争论很久了,当我第二次去拜访小米时,我能明显感觉到这一年间的差距了,如果说去年还处于水平相接近状态,但这一年他们对Android的专注已经让我望尘莫及了,这是个快速发展阶段,以快取胜已经成为移动互联网现阶段最好的手段。除了接受新鲜事物,同样得加强自身的学习。现阶段最可怕的就是比你强的人比你更努力。保持一颗学习的心,接收新事物的心,让自己变的更强,没有永远的强者,只有不努力的人。
退休论。王微在七夕退休论--“七夕夜晚,七年土豆,今晚正式退休。谢谢每个的兄弟姐妹,也谢谢路上每个经过的人在故事里留下的一笔色彩。。。下一个有趣的梦里再见”。如果哪天我的财富足够让我退休,我想我会毫不犹豫的选择退休,然后去做自己喜欢的事。创业是一件痛并快乐的事,如果说2011年我一直想创业,那么我会告诉你2012年我放弃了。这也是我离开乐淘后见了VC后我很倘然的面对并接受的一个事实,在中国的创业投资者看的是团队,而不是一个好点子,同样如何熬到B轮融资也是一件该思考的事,当BOSS问我最近有啥好想法或好的方向时,我真不知道如何回答,我觉得在国外可以很好成功的产品在国内确如此曲折,我害怕,我迷茫,在离开乐淘时,CTO也同样劝我别想创业,对于电商没有再过多的言语。如果可以,我想选择创业一次退休。
公司论。人是最孤独的,人是矛盾的。对于团队的选择,不同的人有不同的选择。选择乐淘时,我选择的是一个方向,从创业团队开始,到最后离开,我可以重新组建起一个团队到新的公司,更或许说我可以很好的组织一帮人做自己喜欢的事。到底是你成就了公司,还是公司成就了你?有人选择了大公司做一颗螺丝钉,有人选择了小公司做一个杠杆,有人选择了光环,有人选择了默默无闻。已经没必要为谁成就谁来争论了,相信强者并不在乎环境,同样可以创造出更多的辉煌。
产品论。以产品取胜的公司有哪家?环视行业一圈,真没有一家可以说自己的产品NB到可以盈利的地步。产品的运营出来的,苹果在船长大叔的掌舵下,越来越稳,除了产品本身,更有他的运营能力。one more thing,这句神圣的话每次从乔布斯口中说出总有另外的感觉,他赋予产品另种神秘感,这是全世界范围内还没有第二个人可以达到这样的高度。产品超出用户预期才会获得用户赞美,用户需要的就是接受额外的惊喜。产品,给人的不再是功能的完善,而是更好的用户体验。
死亡论。生命周期是赋予给每件事物最好的解释名词,某些APP已死,送完终后,让回忆里有曾经的快乐,痛苦夹杂着的片段。除了感谢还是感谢,感谢有这样的机会,感谢有这样的过程,感谢有这群可爱的人,因为它的出生,我们聚在一起,因为它的死亡,我们离开了。这就是现实,这就是追求,想过无数救活方案,但我们还是放弃了,不是不愿意,而是不值。
性格论。兴趣相投的人才可以走到一块,我同样相信性格互补。一个团队并不是完美的,也不存在最强的团队之说,只是我们在相互过程中弥补了对方的优缺点,才让我们可以走的更远,我相信性格缺陷,奇葩年年有,就看缘份有多少然后见的人有多少。性格或许很多时候就决定了这个人会是怎么样的人,同样可以看出这人是否会成功。
面相论。你真的会看面相吗?其实从人的面目表情可以看出这是个怎么样的人,喜欢笑的人从来不会差到哪去(当然这种笑来自于内心),但同样害怕会伪装的,那样欺骗的不仅仅是你,还有他自己。
强者,在这个市场生存,你要不顾一切地要一个美丽的按钮,一个美丽的滚动条,一个美丽的机器,一个美丽的产品,一个美丽的生态圈,一个美丽的公司,一个美丽的家庭,一个美丽的人,你要先不顾一切地相信你想要的,然后再谈妥协。所有的挫折,都只是我们在创造的过程中,不得不妥协的一些事罢了。

喜欢乔布斯的one more thing,因为这句话的出现总会带来惊喜,我也希望用这句话带给自己新的惊喜。

献给曾经的“黄埔军校”

下午石头在群里说了上家公司的变化,问我是不是应该写篇文章纪念一下曾经的“军校”,一下子还真没领悟过来“军校”是什么意思,后来才领悟回来,曾经的“黄埔军校”。离开“黄埔军校”整整四个月了,选在了2011年情人节那天我离开了它,有些巧合,但是必然,今天再次说起它时,真的觉得时间过的好快,这过去的四个月,曾经的“黄埔军校”已经发生了太多的变化了。

为何曾公司为“黄埔军校”?那有微软、腾讯、迅雷、百度、淘宝、阿里……一系列行业内顶尖的精英聚集,那有60几个产品经理,200多个UED,600多个研发……1600多号人(顶峰时期),在为一个网站拼搏,为了做国内首家“SNS+电子商务”的平台,当群英荟萃的时候会是怎么样呢,于是有了黄埔一期、黄埔二期、黄埔三期……黄埔一期最早是在2010年10月10日前进入“黄埔军校”,二期则是2011年2月2日前进入的,三期是在2月14后进入的……

曾经的“黄埔军校”何等风光,挖了很多大公司的牛人、团队,于是有了PUEC(产品用户体验中心),更曾经行业内有公司曾明文公布说加入他们公司后不能跳槽到“黄埔军校”作为签合同的一个条款。当然也闹出了不少笑话,有人自称淘宝CTO,淘宝何时有这样的职位,当然也不排除有滥竽充数的,比如从淘宝商城的一个普通运营人员一下成为“黄埔军校”的GM,也有来可升职成为VP的,这也为曾经风光的“黄埔军校”留下了败笔。

在那你有宽松的工作环境,在科技园里,有一幢楼都是你可以走动的地方,在那你可以累了就下楼走走,河边坐坐的感觉也不错,在那你可以体验到加班是一件常有的事,但可以坐在玩CS的办公环境里加班通宵或许又有另一番感觉。在那你可以拿到比较丰厚的薪资,因为“黄埔军校”会给出比行业内高20%-50%的薪资来吸引人才,但真正溶入团队的又有多少呢?

“黄埔军校”培训了多少年轻的产品经理,你在别的公司或许只是个产品专员,或刚开始做产品的一员,但你在那给到的title一定会是“产品经理”,在那你或许花不了多少钱,呆个一年半载你可以存一笔钱,因为那已经在很偏的郊区了,在那你可以有爱情,因为“黄埔军校”里有很多美女,但你有时间去恋爱吗?你要陪她在科技园里逛河边?当然也不排除有人从七楼往各楼层跑,就为了去看看哪层美女多。

在那你会有一个从传统行业转来做互联网的BOSS,他最经常的一句话“我在互联网是个外行”,于是有另外一个产品经理这么说“是的,他是个外行,他一直在用自己的行为来证明他是个外行”。他可以下午只有他一个人演讲,当然他也可以彻夜的和你谈产品,从晚上九点开始到凌晨三四点。有这样激情的BOSS到底“黄埔军校”缺什么呢?那就留给下一任去解答吧。

离开“黄埔军校”四个月了,回忆的日子占了很大一部分,我曾多次和朋友说起,如果我还在那,或许我现在很轻松,半夜时分我可以走上街道去吃宵,周末可以很晚睡,可以和朋友一起玩三国杀,可以进厨房做几道可口的饭菜,喝点小酒。那有免费饮料的火锅店,以至于经常想起朋友一群在那狂饮的情景。

对于“黄埔军校”怀着感激的情,怀着怀念的心,同时带着很多美好的回忆,一定回曾经的“黄埔军校”再次走走,吃那美味的火锅,半夜上街吃烧烤……

向曾经的“黄埔军校”致敬……

为什么用户要为产品买单

为什么用户要用你的产品?
为什么用户要为你的产品买单?
为什么你的产品值这个钱?
你的产品与其它产品有什么区别?
为什么用户宁愿只付这个价钱的钱?
……

产品从无到有一直存在着一个根本的问题——这个产品是干什么的?一切的根源都是从这开始,因为知道产品是干什么的才知道如何挖掘出它的商业价值所在,还是那句话,没有哪位老板愿意为免费的产品买单的。如何让用户花的钱物有所值,心甘情愿的去花这个钱,这个话题一直围绕着产品收费问题上。如何让用户觉得产品值?同时愿意花这个钱去用它?

一个产品是否值得用户买单,得从这个产品最原始的需求说起,这个产品用来干什么的,为什么需要这个产品,用户不用这个产品会怎么样,是否市场上已有这类产品,与其它产品相比新产品会有什么优势,哪怕你的产品只比别人多一点功能,都会成为你战胜其它产品的因素之一。

一个产品能不能打动人的心除了从根本上知道用户为什么要用你的产品外,还有用户体验,在做产品过程中还是会发现很多用户因为繁琐的操作放弃了产品或投入其它产品的怀抱,这也是现在很多企业可以超越其它产品的“黑洞”所在,腾讯影音为什么可以成功从暴风影音手中夺取那么多用户,我想更多的是产品体验及性能上已经超越了对手。

产品对于一个用户心理过程:简洁、方便、能用、实用、易用、好用、够用

简洁:谷歌够简洁吧?所以赢得了世界第一搜索引擎的称号。一个产品的简洁不仅体现在界面上,同时更体现在功能及操作上,让用户以最快的最直接的方式找到产品的核心功能或用户最需要的功能。简洁的界面,是产品的第一印象,也是让用户接受的第一感观。
方便:不是快捷,而是方便。很多产品把快捷和方便混成一体,觉得快捷的产品一定很方便,web qq与QQ客户端哪个好用?答案是仁者见仁,智者见智。但说到方便,相信更多的人会选择客户端,开机就可以自动启动QQ,多个产品接口,都成为QQ客户端受用欢迎喜欢的理由,同样成为无线行业的切入点。
能用:产品最根本的功能,它能用的起来,能用仅仅代表产品出来,更多的时候是个稚型,一个仅仅满足用户最根本几个需求的功能。能用的产品不代表用户接受你的产品,而是说认识你的产品。
实用:用户不要很炫的效果,但一定要实用,为什么用你的产品是因为你可以解决他存在的问题,你可以有广告,但一定要实用,能根本的解决用户问题。
易用:用户是傻瓜吗?没有一个用户喜欢承 认自己是傻瓜,除了给用户一定的想像空间,尽可能将功能做的简单易懂,你面对的用户群体可能是十来岁的小孩,同时也可能是四五十岁的大叔大妈级的用户,易用将是你抓住用户最根本所在。
好用:一个产品的好坏往往将决定用户的停留问题,好用的产品将会获得更多的口碑效应。对产品的评价永远只有好用、不好用二种答案,说“还行”、“过得去”等这类用户不是真正的用户,对产品要求高,也是你对用户负责的表现。
够用:用户对产品的需求永远不满足的,别为了满足用户而改变自己产品的规划,够用,不是让你把功能全做齐,而是将功能有所取舍,很多用户对于产品的功能只用了60%的功能,而另外的40%不是他们不需要,但却不可少的。

用户对于产品有自己的要求,产品经理经常为了1%的用户,花上99%的精力。而事实证明正是这1%的用户,带来了产品大部分的收益来源。产品凭什么让用户买单,除了满足用户的需求外,更应该深入了解和分析用户。用户永远不会自动的掏出自己钱包里的钱,那就用你的产品去打动他们,优秀的用户体验,完善的产品功能,做一款满足用户真正需要的产品。

这是在做完公司淘宝的手机卖家助理的产品后想到的,同时也是在这家公司的最后一个产品。离开一家公司,离开一个团队,放弃了自己喜欢的一个产品,原来会有这么多的伤感,从淘宝手机手机卖家助理,喜欢无线,还是会在无线行业继续走下去,等待重新无线征程。

产品评审那点事

在产品评审时是否有时候被一位高层打断,明确指出此产品与企业业务发展方向不符,不能实施?是否在讲解产品时,有些人员似懂非懂?是否产品评审太激烈时经常会忘记一些意见收集……
相信类似上面这些情况在你在过产品时也遇到过,产品评审做为产品把关的重要环节,产品评审的重要性不言而喻。那产品评审到底是怎么一回事呢?
评审,顾名思义就是关于审查和批准项目计划,产品变更和工作进展评价的一个步骤。
产品评审在产品过程中占着很重要的一个环节,是对产品成型,产品质量,产品进展等环节的检测和评估过程。

评审的重要性:
1.需求是开发最重要的一个输入,好的开始是成功的一半! 所以,产品需求的质量很大程度上决定了产品质量。
2.产品风险常常是软件开发过程中最大的一个风险 ,要降低需求阶段带来的风险,就要把需求评审做好。
3.产品评审做不好的后果:
1)需求变更
2)产品目标不明确
3)产品周期不可规划
4)产品功能不可实现
导致后续工作难于开展或经常出现变更。
4、产品经理:“不识庐山真面目,只缘身在此山中”,需求是自己写的,容易受到固定思维的限制,所以,需要一双没有看过这个需求的眼睛来检查一下,有什么问题。
产品需求的不同层次:
目标性需求:定义了整个产品需要达到的目标;——高层关注
功能性需求:定义了整个产品必须完成的任务;——中层关注
操作性需求:定义了完成每个任务的具体的人机交互;——执行人员关注
在做产品评审的时候,应该根据不同的产品需求层次,进行不同的评审。

那么究竟如何做好产品评审呢?

建议一:分层次评审
我们知道用户的需求是可以分层次的,一般而言可以分成如下的层次:
目标性需求:定义了整个产品需要达到的目标;
功能性需求:定义了整个产品必须完成的任务;
操作性需求:定义了完成每个任务的具体的人机交互;
目标性需求是企业的高层管理人员所关注的,功能性需求是企业的中层管理人员所关注的,操作性需求是企业的具体操作人员所关注的。对不同层次的需求,其描述形式是有区别的,参与评审的人员也是不同的。如果让具体的操作人员去评审目标性需求,可能会很容易地导致“捡了芝麻,丢了西瓜”的现象,如果让高层的管理人员也去评审那些操作性需求,无疑是一种资源浪费的情形。

建议二:正式评审与非正式评审结合
正式评审是指通过开评审会的形式,组织多个专家(可以是多个不同类型的产品经理,也可以为产品相关部门的负责人),将产品涉及到的人员集合在一起,并定义好参与评审人员的角色和职责,对产品进行正规的会议评审。而非正式的评审并没有这种严格的组织形式(也就是所谓的头脑风暴法),一般也不需要将人员集合在一起评审,而是通过电子邮件甚至是网络聊天等多种形式对需求进行评审。2种形式各有利弊,但往往非正式的评审比正式的评审效率更高,更容易发现问题。因此在评审时,应该更灵活地利用这2种方式。

建议三:分阶段评审
应该在产品形成的过程中进行分阶段的评审,分阶段评审可以将原本需要进行的大规模评审拆分成各个小规模的评审,降低了产品返工的风险,提高了评审的质量。比如可以在形成目标性产品需求后进行一次评审,在形成系统的初次概要产品后进行一次评审,当对概要产品细分成几个部分,对每个部分进行各个评审,最终再对整体的需求进行评审。这样做法对于评审人员的理解能力以及产品经理组织评审的连惯性要求较高。

建议四:精心挑选评审人员
产品评审可能涉及的人员包括:高层管理人员、中层管理人员、潜在用户、开发人员、测试人员、交互、UI视觉等。在这些人员中由于大家所处的立场不同,对同一个问题的看法是不相同的,有些观点是和产品的目标有关系的,有些是关系不大的,不同的观点可能形成互补的关系。为了保证产品评审的质量和效率,需要精心挑选评审员。首先要保证使不同类型的人员的都要参与进来,否则很可能会漏掉了很重要的需求。其次在不同类型的人员中要选择那些真正和系统相关的,对系统有足够了解的人员参与进来,否则很可能使评审的效率降低或者最终不切实际的修改了系统的范围。

建议五:充分利用需求矩阵表
需求矩阵表是很好的评审工具,产品经理需将需求列出,通过个个功能需求进行讲解,以及涉及到人员及实现阶段、重要性等进行划分,让更多的人员了解产品需求是什么,以及涉及到的人员,了解各个需求对于产品影响,是否有独立性,产品需求之间的产品功能迭代。列出详细的产品需求,直观的表达给审评人员。

建议六:建立标准的评审流程
对正规的产品评审会需要建立正规的产品评审流程,按照流程中定义的活动进行规范的评审过程。比如在评审流程定义中可能规定评审的进入条件,评审需要提交的资料,每次评审会议的人员职责分配,评审的具体步骤,评审通过的条件等等。通过评审流程执行可能会避免一些人员对产品问题争吵的场面出现,让所有的人员定位好自己的产品评审领域,发挥人员的专业性。

建议七:做好评审后的跟踪工作
在评审后,需要根据评审人员提出的问题进行评价,以确定哪些问题是必须纠正的,哪些可以不纠正,并给出充分的客观的理由与证据。当确定需要纠正的问题后,要形成书面的需求变更的申请,进入需求变更的管理流程,并确保变更的执行,在变更完成后,要进行复审。切忌评审完毕后,没有对问题进行跟踪,而无法保证评审结果的落实,使前期的评审努力付之东流。

建议八:充分准备评审
评审质量的好坏很大程度上取决于在评审会议前的准备活动。常出现的问题是,需求文档在评审会议前并没有提前下发给参与评审会议的人员,没有留出更多更充分的时间让参与评审的人员阅读需求文档。更有甚者,没有执行需求评审的进入条件,在评审文档中存在大量的低级的错误或者没有在评审前进行沟通,文档中存在方向性的错误,从而导致评审的效率很低,质量很差。对评审的准备工作,也应当定义一个检查单,在评审之前对照检查单落实每项准备工作。

产品评审需要面对的问题还很多,做好准备的评审会让你的产品评审过程事办功倍,做好评审意见收集,把好产品“质量”关。

这是下午与公司的相关人员进行淘宝项目评审后总结的,当然在产品Beta版上线后还会进行产品评审,到时更多的是让用户来进行产品评审。产品评审也就那么点事,反应的是产品经理对产品流程及产品走向的理解,同时更是给其他相关人员心理一个底,让更多的人明白你做的产品是干什么的,为什么要这么做,以及如何去做,什么人去做,如何更好的去做,给所有人一个成功的信号传递—产品一定会成功。

如何写PRD

PRD是每个产品人员最经常看到的文档,还是有很多产品的朋友问我PRD怎么写,如何才能表达清楚意思。其实PRD并没有规定的格式,每个公司都可以根据自己公司的实际需要来写适合自己产品团队的PRD。

PRD(Product Requirement Document,产品需求文档),这对于任何一个产品经理来说都不会陌生的一个文档,一个PRD是衡量一个产品经理整体思维的标准,一个PRD可以看出一个产品经理在某个领域的专业性,同时也可以反应出一个产品经理的整体产品思维。

产品经理的整体思维体现在:
1、提炼核心需求
2、思考满足核心需求的方式
3、评估方式优劣选定方案
4、思考功能概要
5、思考支撑功能和关联功能
6、细化设计功能
7、子功能(功能间迭代)

PRD其实就是将以上的思维整体走向写出来,同时将产品的思想提炼出来,用文字表示给开发者,给UI、给视觉、给老板……PRD给的是一种思想,将产品的整体思想和核心需求灌输给产品的相关人员,都说PRD是个承上启下的功能,因为上接MRD,下对MRD进行技术性的描述。

网上已经有太多互联网公司的PRD文档,淘宝、百度、腾讯等这类大型互联网公司都有自己的PRD规范,适合企业的需要的PRD才是真正PRD。以淘宝的PRD为例,讲解一下PRD的主要内容。

1、文件命名(编号)
文件的编号很关键,因为产品迭代过程会有不同的文件版本,一般命名规则“公司名+产品名+PRD+D1.0”(以第一版为例),这样命名有利用版本号的迭代,如果是小的产品需求变动可以直接命名为“公司名-产品名-PRD-D1.01”,如果涉及到功能需求增加可以命名为“公司名-产品名-PRD-D1.1”,当出现产品第二版时,可以命名为“公司名-产品名-PRD-D2.0”。

2、修订控制页
一般有这么几项:编号、文档版本、修订章节、修订原因、修订日期、修改人。编号只是为了给个修改的顺序,文档版本显示的当前修改的内容是在哪个版本中出现,修订章节是具体到哪个章节哪个功能模块的修改,修订原因说明此功能修改的问题所在。修订日期以修改当日的日期为修订日期,修改人显示修改内容模块的人,可能是当前用户也可能是其它产品人员。

3、目录
不建议自己去添加一个新的目录,你可以去其它的文档中拷一个过来,不考虑目录的内容,等写完PRD可以再去更新。但建议用Mind manager来整理一下思路。

4、请与以下部门讨论PRD
PRD做为一个承接作用的“载体”,会与技术、运营、财务等人员的沟通,而与这些人员沟通的主题都将会出现在子功能或在细节细化的基本上,需要与相关人员确定“沟通内容”,这对于产品整体流程将是很重要的。同时对于产品核心功能的提取也是一个重要环节。产品经理很重要的一个职能就是沟通。例与客服中心:客服服务部,讨论的内容:预测客服成本、工作量;讨论客服如何支持;协助评估诈欺/数据窜改风险:欺诈/数据窜改风险、不正使用风险。这就是要写在与其它部门讨论PRD中的。一个产品经理需要考虑如何与其它部门之间的沟通合作,文档很大一部分的功能是提醒你要做的工作,同时不断补充将要面临的工作。

5、概述
概念就是总结,它包括的点有:名词说明、产品概述及目标、产品roadmap、产品风险。
名词说明:名称、说明。名称就是对文档中会出现的比较新的名称,说明则是对这些名称进行解释。
产品概述及目标:解释说明该产品是干什么的,为什么需要这样的产品。同时产品想要达到什么样的目标。产品概述及目标就是对产品核心功能讲解,同时希望可以达到的期望。
产品roadmap:产品分期目标,阶段描述,以及时间点的确定,产品是个不断演进的过程,很多时间一期产品只完成了产品70%的功能,二期才会继续去完善剩下的30%,同时有可能会推翻了重新推出第二版。产品roadmap并不及着全部规划好所有的阶段目标,而是更多的通过维护来保持产品的更新和迭代。
产品风险:描述产品可能存在的风险,比如商务谈判的风险,外部合作的风险,不当使用的风险等等。风险级别为高中低。

6、使用者需求
使用者需求一般只有个需求描述。需求描述有以下几项内容:目标客户、需求描述、场景描述、优先级。
目标客户即为产品的最终用户,确定产品的最终使用者。
需求描述是对目标客户的需求描述,表达用户最需要的是什么,找到用户的最根本需求。
场景描述,产品在哪种情况下会被用户使用,就是用户场景模拟。
优先级是指用户对于当前产品功能需求的优先级,哪些是用户最想要的功能优先级则排前。

7、可选方案
列出所有可以选择的达到该产品目标的方案要点(主要思路),给各方案适当的评价,并推荐最优方案。你在做这个产品规划时一定有很多的备选方案,别放弃这些方案,永远没有过时的idea,只有最适合时机的idea。所以可以写出几个可选方案,或许是你下期产品改版一个方向。

8、效益成本分析
产品经理是个全才,在这点上得到了体验。产品经理得知道财务知识。很大一部分是产品的环境搭建成本和支持人员的成本。一般的效益成本分析包括三个方面:效益预测、产品技术中心成本、非产品技术中心支持成本。
效益预测是指提供在各种产品环境中的效益预测,并标明主要的变量及假设,最好能包含现在和过去的效益数据。如网站的PV值,软件的使用数都是效益预测数据。
产品技术中心成本是指设计及部署此产品的产品技术中心所需的资源需求,包括人力成本,软硬件支出等。很大时候这份成本需要由项目经理来协助,需要有什么样的人才加入产品中需与人力协助。
非产品技术中心支持成本,产品不是只有产品组完成的,同样需要其它部门的配合与协助。比如:需要客服部投入多少的资源用于该产品的服务,需要运营部投入多少的资源运营该产品。

9、功能需求
功能需求一般是由四部分组成,功能总览、功能详情、整合需求、BETA测试需求。
功能总览一般包括二个部分,一个是流程图,一个是功能表。流程图是对产品的整体走向的流程的规划,流程图是用来对产品整体功能的梳理。所以在做产品前建议所有的产品经理先梳理一下产品流程。功能表是将流程图文字化,同时将列出产品的功能点。
功能详情,这是所有的产品功能的描述和规划。包括以下内容:
简要说明:告诉此功能主要干什么的。
业务规则:每上产品在使用时都有自己的规则,而产品的业务规则则是将产品的流程细化。个人建议将这个功能的业务规则,包括一些细节,如排版形式、日期显示方式全定好,这样方便其它人员的沟通和理解。
界面原型:产品经理在这时做的原型界面只是显示的框架,别细化,这样会给交互和UI造成错觉。只需做一个简单的界面即可,更多的时候只是个框架图。
执行者:产品使用者。
前置条件:具体的操作。
后置条件:操作后的展示。在UC(user case)中后置条件又是另一种情况,所以对于建议在PRD中的前置条件和后置条件结果合起来。
主流程:把主流放在最后是有道理的,结合上面所说的,做出主流程说明。将此功能的流程走向做个分点说明。

10、整合需求
产品经理很重要的一个能力就是体现在产品整合能力上,利用公司现有的资源或外部资源(合作公司等)实现产品功能需求的整合。实现功能贯穿的同时,更多的如何在新产品上实现功能的拓展来辅助核心功能。

11、BETA测试需求
很多产品都有BETA版本放出,为了就是收求意见和一些性能测试。这部份内容不是必须的,但现在很多产品已经开始先推出BETA版本再推出正式版,当然也可以通过升级来解决。所以BETA测试需求并不是一定需要的。如果有BETA测试需求,则需写出BETA版测试的要求和期望达到的目标要求。

12、非功能性需求
都说产品经理是全才,在这点上得到彻底的体现。很多产品经理在这点上忽视了,但很多方面是用到的,只是在产品过程中弱化了。

一般情况下非功能性需求包括以下几个部分:产品营销需求、规则变更需求、产品服务需求、法务需求、财务需求、帮助需求、安全性需求等。与其说是全方位的掌握技能,还不如说是沟通,如何与不同的部门人员之间的沟通,让更多的人协助产品的正常使用与上线。

13、上、下线需求
上线时限需求:此产品预定上线日期?上线日期有无任何特殊依据或规定?
下线需求(活动类需求必须明确下线时间):此产品预定下线日期?下线日期有无任何特殊依据或规定?

14、运营计划
说明产品的后续运营计划。包括与运营部的协作运营。更多的是给产品经理如何让更多的产品功能展示给用户,产品经理是核心需求的把握者,参与到产品整体运营计划显得特别的重要。

……

写PRD并不是产品经理的全部工作,但却是不可少的一部分,很大程度上反应了产品经理的思维和产品核心功能把握上,同时对产品经理沟通、协调、规划等都得到了一定的验证,但每个产品经理的第一职能是会写一份让其它人员看得懂的PRD。

附上一份网上弄来的PRD,可以参考一下。[download id=”8″]