被“绑架”的产品经理

你是被“绑架”的产品经理吗?

看多了,听多了,对于“绑架”这个词或许更适合很多的产品经理,个性张扬的年代,很多产品经理已经被拘束了,没有了想法,没有了激情,更失去了很多机会,特别是在浮躁的一线城市,当没有足够的时间思考时,你只有被架着走的份,不断变化的需求,繁忙的加班,众人的埋怨,自己也逐渐的迷失了自己谁改变谁已经不再重要,一个产品经理,比专业技能比不上团队中任何一员,那你凭什么在团队中立足,用什么让团队走的更远,变的更强?在这人人都是产品经理的年代,每个人都有自己的产品想法,技术要能实现,UI又想酷、炫,交互又想要好的交互效果,而上级除了要有用户,还得要求加入商务,运营得想如何把产品玩转起来,市场BD得想如何获得更多的合适……这不是一个简单的产品了,产品经理如何驾驭?

为什么会被“绑架”?

谁是产品最有发言权的人?CEO。毫无疑问,这个是最直接的答案,CEO是最大的产品经理,如果不服从只有走人的份,多少人是为了老板做产品,多少产品因为这样而变的“笨重”。
谁是产品最核心的成员?没有。因为团队中每个人都不可或缺。从来不相信一个人可以撑起一个产品,但我更相信一个团队可以将产品做强,做大。
谁最可缺?产品经理。移动互联网时代,最缺的是产品经理,最不缺的还是产品经理,看过太多技术直接替代产品经理的现象,或许有时需要的不是产品经理,而是项目经理。

怎么做到不被“绑架”?
学会say no。拒绝一些不合理的需求,人人都是产品经理,但并不代表谁都有权利决定产品的方向和功能。这是你的强项,这也是你要承受的,会挨批,会有不理解,但请保持一颗强大的内心,产品经理必须要有一颗承受的住打击的内心。
懂点技术。或许你可以不懂写代码,但请懂一点技术,不是要你去写代码,而是你知道某些功能会实现你可以在其它产品上看到。当遇到想做的,去谷歌、百度,去咨询,去探讨,没有实践就没有发言权。实践并不一定是自己的,而可以学习的。
判断力。你必须要有分析判断能力,哪个市场你能进入,哪些产品你不能接,谎言和浮躁已经成为行业的代名词,遇到好的公司是你的幸运,遇到不适合自己的当断则断,有时薪资、机遇会成为影响判断力的因素,请给自己一个冷静的时间。
放下、宽容。产品经理很多时候不会放下,抓着一堆遥不可及的东西,想要让上面高兴,也想让自己得到重视,其实你什么也不是,每个人都有一定的价值,但并不是不可缺,你得学会将自己放下,对别人宽容一点,也对自己宽容一点。

不想继续写下去了,多年之后会感谢这些年被“绑架”,让我走的更远,走的更加坚定。产品经理是服务型的,很多时候为了产品、团队在牺牲自己的利益和方向。只是因为有爱,有想做产品的一颗热诚的心。这也是可以坚持一直走下去的勇气,我们有千万次放弃的机会,但我们没有,因为我们是一名产品经理,我们字典里没有放弃这二个字。

产品过程管理

最近公司产品部出了不少问题,对于很多产品经理、UED、研发等都造成了很多的困难和不解,除了产品经理自身的责任,同时对于市场提供的意见也没有进行调研和数据分析,造成产品很多在上线不久后就面临着重新推倒重来的情况,一直以为作为市场主导的互联网公司就面临着产品会受到市场的影响而做出的产品处于跟风状态。这不应该是一个正常互联网公司应该做的,同时也不是一个产品经理用抄袭来完成产品的过程。
对于比较混乱的产品管理流程,我对产品管理流程进行了产品管理阶段细分:
1、数据化
“没有调查就没有发言权”。处于互联网日新月异的环境来说,数据显得格外的重要,做出一套CMS为了更好的配合产品化,同时对于产品发展方向,及市场已存在、潜在的竞争对手来说都是一个很重要的分析方向。
2、概念化
一个新的产品理念的提出必然要有一个概念化的过程,可以来自市场,也可以来自于产品创新。“裸购”,一个全新的产品理念的提出对于用户的冲击不仅仅只是视觉上的,而更应该是产品本身。至今没理解裸购的概念,但市场上已经大大小小的广告到处都提出了裸购二个词。概念化阶段最怕的就是“胎死腹中”,没有足够的资源,或者没得到公司高层的认同,以及市场的配合,概念化就变成了一纸空文。
3、模型化
当由理论变为原型需要进行不论的PK,与老板PK、与市场PK,甚至与研发PK,告诉他们这个产品是个什么样的产品,会给公司带来什么,不论是用户还是效益,给市场、老板、研发等一个模型化的产品,告诉他们这个产品可以带来什么,同时存在的问题,需要他们配合的问题,模型化很多是进行不断的PK过程。产品经理应该有足够的模型化理念去说服老板、市场,而不是被老板和市场说服,按照他们的理念去做一个满屏都是广告的产品。
4、产品化
模型化后不再接受其它人员的任何修改意见,任何建议将归入产品二期。产品经理需要强势的拒绝产品过程中添加任何需求,不论来自市场还是老板,产品化的过程产品经理将作为主导向。对于产品化的过程中同样遇到了不少问题,从产品经理开始到产品发布应该有一个流程:

5、商品化
产品的正式发布前必然要经过公司内部相关人员了解产品,培训是个必不可少的过程。现在很多产品发布公司内部人员都不知道,或者说直接运营人员都不知道产品是干嘛用的,造成很多时候产品内部人员处于迷糊状态,这样对于一个产品来说是件很悲哀的事。同时让市场知道产品最核心的功能,最能够吸引用户的地方,而不是让市场反过来问你。
6、市场化
这或许是运营型产品经理应该考虑的问题,但检验一款产品的好坏还是得由市场反应说的算。而产品经理更多的是协助市场了解用户的使用情况及用户反馈,给产品下一步发展提供数据参考,协助解决遇到的产品问题。

附件图说明一下产品经理产品过程管理中的事项:

产品部确实遇到了问题,但看到的还是积极解决的一面,产品部不是设计部,不再是个只会画原型的设计师,而应该对产品长期规划负责,对产品市场负责。宁愿多做一点,少一点问题,而不应该由市场牵着东拼西凑出来的产品,更不是由每个不相关人员提出一个问题就应该为之解决的傀儡,产品经理需要强势,需要对整个产品强势,对于整个产品管理过程负责。

仅是对于公司存在的一些问题提出一些产品管理流程建议,希望更多的产品经理知道自己是个什么样的角色,如何更好的去管理一个产品。

手机UI设计检测要素

最近忙的有点乱,对于无线的关注一直在看产品的UI,因为手上的无线项目全在筹建中,对于UI设计的要求也在与同僚中耳熟目染中慢慢的接触了新的手机UI设计要素,同时也是对自己产品手机UI设计的要求,也为自己筹建的无线项目组定立一些手机规则,为了统一打造有点属于自己的产品,加入一些元素,手机UI一直被我称为产品的“脸面”,一款好的手机产品一定有一套优秀的手机UI界面。

手机UI从产品的图标开始,直到退出手机产品为止。产品的UI从产品概念开始,直到产品的生命周期结束,产品的UI一直深入着用户的心。一个好产品UI评价标准会影响一个产品的品牌和用户群体,这也是EICO对于魅族和Weico的价值所在,结合做过的产品对UI设计检测要素进行了整理。

最近发生了很多问题,包括食物中毒等生活小插曲,但无线生活还在继续,喜欢无线,所以无限。

产品经理之聆听用户的声音

公司的产品进入了公测期间,每天都有新的用户加入,加个合作方的强有力的广告效应,产品已经开始逐渐的步入正轨,经历了大半年了,从产品无限期被停搁,到产品重新获得新生,作为产品经理,我经历了整个过程,而也是唯一一个坚持现在的人,而在产品公测期间我当了一天的客服,去聆听用户的声音,看着满屏的旺旺信息,心里有种莫名的感动。

上品上线后,做了几天的客服后的感受:

用户群体分析——当一个产品面对的大众用户时,你得考虑用户上至四五十岁,下至十几岁,就拿手机安装软件来说,我一天收到不低于20个用户问到手机如何安装软件的方法。好几位都是三四十岁出来创业的用户,根本不知道软件安装是怎么一回事。用户群体分析对于产品来说显得格外的重要。

用户的骂声——用户的骂声对产品人员来说是一种鞭策,因为用户喜欢产品所以才会对产品提出更高的要求,他们不懂技术,他们不懂啥叫用户体验,但他们是产品的用户,他们拥有最多的发言权。用户骂声越多,说明这个产品值得用户关注,即对产品的提升将更快。

产品的商业价值——没有老板愿意花一大笔钱为用户提供免费的产品,没有用户愿意花钱买单的产品也不是好产品。一个产品经理如果不知道如何在产品中获得这款产品的商业价值是个失败的产品经理,植入广告?插播新闻?那种年代已经过去了。挖掘更多的商业价值已经成为一个产品经理的潜在标准了。

产品的规划——如果一期产品没有做好规划,没关系,用户会告诉你最希望得到的是什么,哪些功能是用户最需要的,用户承受的产品价位如何……这些用户心声会成为产品二期规划最重要的一部分信息。

免费无好货——别把用户当傻瓜,他们同样知道世界上没有免费的午餐,但他们有掏钱与不掏钱的权利,做为产品经理,你至少让用户知道钱花了值。其实很多用户愿意花钱享受好的服务,那就让你的产品让用户觉得花的值。

减少思考——用户不喜欢思考,尽量减少用户思考时间。用户已经花时间来用产品了,别让他们用更多的时间在做逻辑题上,简单、快捷的操作,减少用户操作思考时间,这才是用户真正想要的,宁愿将细节做细,让用户少问几个“我应该怎么做”。

速度——更新速度、更改bug速度、发现问题速度、响应速度……一切的一切都要跟上,当用户提出一个问题时,可能会连续引发一系列的问题,速度成为产品留住用户最好的体现方式,或许用户不懂,但你至少自己明白,这个问题已经存在了,同时需要第一时间解决它,及时告之用户,让用户感受到您重视他。

口碑营销——用户有权对产品进行评价,而且用户的评价比自身产品宣传更重要。这也是为什么出现越来越多枪手的原因。服务好每一个尽可能的潜在用户,将会为你产品赢得更多的潜在用户,要的就是用户对你的产品竖起大拇指。

潜在竞争对手——互联网没有永远的秘密。独舞的舞者永远是孤单寂寞的,有竞争才会进步,优胜劣汰,这符合市场的规律,提高竞争者进入相关产品的门槛,分析对手,别让用户说你的产品怎么比某某产品不好用。

后续服务——产品出来了,用户使用了,有问题找谁?用户群体的不同,对于产品的理解也不同,别有了产品丢了服务。更多的用户愿意为您的优质服务买单,而不是产品。

给用户安全感——当产品涉及到交易,账户登录等个人隐私问题时,不论是UI还是产品流程都要给用户一种安全感,减少用户忧虑与不安,哪怕是与像淘宝这类大型互联网合作的,还是很多用户提出质疑。

自我反省——作为一个产品经理经常问问自己做的产品是不是用户需要的,存在哪些不足,如何更加化产品,“当你对自己的产品已经厌烦时,说时你的产品已经要到更新换代的时候了”,这句话对于产品经理来说永远是个鞭策。

多多听听用户的声音,重视一下用户的产品体验,产品出来并不代表结束,而是重新开始,听听用户的骂声,给自己一点鞭策,只会让自己的产品之路走的更快,理远。听着不同用户的感谢声,以及看到地铁上用户用着自己的产品,那种心理感受真的很好。

如何写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″]