互联网时代的产品经理

第一篇：互联网时代的产品经理

互联网产品经理分析产品的思路是什么？

产品经理的分析思路不仅是本职必备的能力，还可以为其它行业提供借鉴。

一般大家对产品经理中的“产品”的理解是一个具体的产品，比如一个实体的东西、软件、或服务。而我的理解是，任何东西或者事物都可以看作为一个产品，产品经理的工作和思维模式是知道如何做好一个东西或者一件事情。当你可以用产品经理的思维模式去思考工作的时候可能可以把工作做得更好。工作上遇到的很多问题都可以拆分成这几个部分：

•

•

•

•

• 目标(解决什么痛点，达到什么目的?) 用户(谁会受到影响?) 产品(做什么?)

准备工作(调研、思考、搜索、询问) 条件(时间、资源)

工作要做的就是回答：“用户”使用什么样子的“产品” 才能达到“目标”?举个例子：公司想优化面试流程。背景：当前面试没有很具体的流程，每个面试官都问自己想问的问题，最后也不太确定候选人好不好。 目标：

1. 让面试效率更高 2. 让筛选更精准 用户：面试官、应聘者

条件：尽量让面试者有好的体验;面试官不需要花太多额外时间 思考：1. 要评估候选人，首先需要知道面试岗位具体会做什么;先确认每个岗位的预期

2. 面试有好几轮，每个候选人都见所有人效率比较低 3. 面试题目容易重复，需要统一一下面试题 产品(结论)=新的面试流程： 1. 面试前所有面试官都同步岗位的预期 2. 面试分几轮，每轮有明确的考察侧重点，从简单到难 3. 当候选人结束每一轮面试后确定需不需要进入下一轮

不管什么岗位，你都需要使用一些产品思维来解决问题，也许能够事半功倍。

我是齿轮易创，一家由顶尖风险机构投资的技术服务提供商，目前已为亚马逊、印象笔记、中国移动、中国南航等跨国企业提供了定制技术服务，也为咪蒙、定制狮、inDeco等中小型企业客户进行了服务支持。累计服务500+企业，行业口碑良好，新客户一部分来源老客户自发口碑背书推荐。

我们不仅仅提供技术开发支持，更重要的是提供产品咨询。通过分析客户的需求，给予全方位的产品方案。我们为包括全国交通第一律所元甲律所在内的法律、电商、医疗等20+行业提供过定制CRM系统。我们的服务内容包括但不限于Web端官网及业务系统、APP、小程序、H5等。

具体信息可以搜索齿轮易创官网，如有需求请在官网右上角提交需求或右下角和我们在线交流，工作时间及时回复。

更多相关案例查看请查阅齿轮易创官网“案例”及“博客”内容，更可以关注齿轮易创微信订阅号与我们交流。

第二篇：互联网产品经理的全方位解读

过去一年，「互联网产品经理」无疑是国内互联网行业最火爆的职位之一。似乎就在一夜之间，挂着这个 Title 的人翻了一倍，一些原本做营销策划、运营的人也自称产品经理。更甚的是，不少计算机相关专业的学生都希望毕业之后成为一名产品经理，尽管很多人对于这一职位的工作职责、能力要求知之甚少。除了互联网行业的整体升温、成熟带来的工作细分之外，也有一些是信息不对称造成的。在他们看来，产品经理不需要自己动手写代码、做设计，只需要写写文档、在一边指手划脚即可，而且 Title 里的「经理」二字印在名片上倍儿有面子。

实际上，真正的产品经理并不是一个低门槛的职位。它要求是能够对一款产品真正负责的人，不仅包括前期的需求调研和分析，中期的产品策划和设计，还有后期的数据分析和产品运营及迭代。从工作内容的广度来看，产品经理对能力的要求比研发工程师和设计师都要高得多。这样一个对公司的产品决策和管理有重要影响的角色，在目前很多互联网公司里，其实际扮演的工作角色更接近于「产品设计师」，即偏重原型设计、交互设计等，这在一定程度上助长了「人人都是产品经理」的假象。

互联网产品经理不仅工作范围广，职位特点决定了他的知识面也要广。在一些互联网公司，招聘产品经理时除了基本的表达和写作能力之外，还要重点考察对于设计、心理学、社会学、历史、市场营销等各方面的能力。「做产品」是一个既感性又理性的过程，纵有很多前辈同行的经验传承和指导，也不乏各种面向产品经理的会议和培训，但落到实处总难免犯一些错误。有些是经验不足导致，而另一些则是产品经理对于「人性」的理解不足。

从我自己的角度来说，做了近三年的互联网产品，的确犯过一些错误。有大有小，道理相通，总结记录让人成长。

错误一：没想清楚

不知什么时候起，互联网产品里开始流行一种「天下武功，唯快不破」的说法。这个说法误导了很多人，好像只要有一个想法就应该立即动手，边做边改。实则不然，绝大多数失败的产品，问题就出在没有想清楚，比如不确定用户的需求程度，或者做到一半需要架构或需求变更，推翻重来。为了快而使得需求只做了一半，这跟「捡了芝麻，丢了西瓜」没什么两样。 互联网产品同质化越来越严重，重复造轮子没什么意义。移动私密社交应用 Path 2.0 上线之后，国内出现了一窝蜂的抄袭，其实不乏 1:1 的照搬。我觉得绝大部分 Copycat 都没有想清楚一件事情：在国内做熟人关系的社交，如何能摆脱腾讯的阴影?倒不是说只要腾讯在做的事情其他团队都不能做，而是具体在这个点的，其他团队不具备任何优势，漂亮的 UI 不能解决更多的问题。

产品经理的基本出发点应该是「把事情做对」，而不是「赶出来」。这就要求前期多花一些时间在需求调研上，想清楚才动手，这也防止了后期频繁的需求变更。在《启示录 : 打造用户喜爱的产品》这本书里，作者 Marty Cagan 特别强调了充分的需求调研的重要性。 错误二：想做更多

以微博产品为例，微博解决了用户「我当前在干什么」这个碎片化的表达需求。而从小语文教师就教育我们，一个故事的三要素，应该是「人物、时间、地点」。在 2010 年第三季度，

当时我们想在微博里也同时解决用户「我在哪里」的需求，即发表微博时附带上他的位置信息，并希望以此构成与竞争对手的差异化。

事后来看，即使这一功能的推出比后来新浪和腾讯微博类似功能早了一年，但这是一个典型的未经调研、产品经理自己意淫出来的需求。微博既有的使用场景和流程，与签到分享位置无关;且微博里的用户关系半生不熟，向这样一群人分享自己的地理位置，动力也不足。结果显而易见，花了近一个季度做出来的项目，数据表现平平，称之为「失败」并不为过。更大的隐形问题是，产品一旦上线，下线需要更大的决心;这不仅增加了用户使用产品的复杂度，且带来了难以避免的巨大维护成本。

做加法是容易的，能够控制欲望「不做什么」更困难，也更重要，产品经理需要有做减法的魄力和决心。当遇到「可加可不加」的功能时，回到原点重新思考，如果不加这个功能会有什么损失?这个事情是否在产品的长远路线上?

错误三：忽视可用性测试

作为工作的基本门槛，绝大部分产品经理本人都是产品的「超级用户」。但产品经理并不能以个体代表所有「用户」说话，在很多情况下，产品的目标用户群、用户场景和需求都是多样且复杂的。

因此，尽量早地开始做可用性测试很有必要，用户会用脚投票。不要因为没有眼动仪就不做用户观察，也不要因为没有用户研究人员就不做用研分析。作为产品经理，少一分矫情，多一分实干，简单绘制原型草图，并直接找几个身边的朋友就能开工。事实上，在网站可用性测试中，一般针对 5 个人就能发现 85% 的可用性问题。尤其是在产品定位、产品架构等层面，多与目标用户聊天沟通会有意外的收获。

错误四：忽略创新的风险和成本

还是以微博为例，评论、转发功能决定了整个社区的信息流通和消费模式，正是由于微博信息的短、平、快等特征，才建立起了微博相对于其它产品形式的核心优势。而对于微博这种市场竞争激烈的大众产品而言，关于评论、转发功能，竞争对手往往已经有了相对成熟的解决方案，这些解决方案经过了用户的验证。越是基础的功能，创新的成本和风险越大，对于产品团队的能力要求也越高。在这个问题上，网易微博曾经有过几次对转发和评论的改版，带来的负面效果也是很大的，核心用户的流失和骂声都不少。几次折腾之后，现在线上所采用的解决方案依然是照搬了新浪微博的模式——这是最保险和最保守的做法。而几次改版给团队和用户带来的损失更是难以挽回的。

当然我并不是说产品经理不应该去尝试创新， 而是要看清楚这个「创新」在整个产品里处于哪个层级，它对资源、团队能力的要求如何。另一方面，如果是对产品进行重新定位，服务于另一个用户群或者解决不一样场景下的问题，这样的「创新」往往具备更大的威力。 错误五：细节决定成败

在中国互联网市场，绝大部分产品都有大量的竞争对手，虎视眈眈。在产品大方向正确的前提下，快速上线最简单最基础的产品版本，并保持迭代小跑比什么都重要。此时不要相信「细

节决定成败」，而要相信「战略决定命运」。产品经理不能过度思考和追求完美主义，要把注意力放在可能会发生的积极事情上面，不要过分关注不太可能会发生的负面事件上。 在微博项目里，我早期花了大量的时间在交互效果上，比如切换页面要最炫的 Ajax、新旧微博内容之间的分割线反复雕花、展示微博发布时间的文案反复修改…等等，而没有将更多的时间花在用户沟通访谈、需求分析与产品讨论上。事后看数据才发现，这些我认为会影响到「用户体验」的细节，只有极少数用户会注意到，这是一种浪费资源和精力的行为。 错误六：误读数据

数据是对产品运行状况的客观反应，它为找出问题并优化提供了一扇窗口。对于任何一个上线几个月的产品来说，产品经理都可以找到大把数据可以利用。而在「如何看数据」这个层面上，产品经理很容易根据自己的预设来挑选数据，这样导致了所看数据片面和失真的情况，不能真实反应出产品全貌。

亚马逊 CEO 杰夫•贝索斯(Jeff Bezos)在 2005 年的致股东信里提到，数据是基于过去的递归呈现，不能为未来的创新带来直接价值。但不可忽视的是，通过详实的数据分析，产品经理可以发现一些新的需求点。

值得注意的是，即使是在产品前期，产品本身的数据有限甚至为空时，产品经理也可以充分利用搜索引擎、其它数据平台获取到想要的外部数据。大可不必因为「没有数据」而停止往下走。唯一的问题是，你想要从哪些数据中得到什么?

错误

七、照搬经验

很多产品经理在亲历一两款产品之后，都会有一些自己的想法。在下次遇到类似的功能时，会习惯性地直接照搬经验。但每一个产品面向的用户需求、使用场景都在时刻变化，即使是自己总结的经验，换一个项目也不能直接使用。依然要经过缜密分析，将事情放在整个产品盘子里，抽身出来客观看之。

实际上，只有极少数人能够将工作中的经历总结提炼成属于自己的方法论，并不断完善饱和。通过与其他人的交流、自己的坚持记录和总结，都可以不断巩固自己的方法论。

八、没有认清产品全局

遵循「以用户为中心」(User-Centered Design)的产品设计思想，从用户的角度进行思考和设计是产品经理的基本功。以社区类产品为例，产品经理要能够对于以下问题有深入了解：用户完整的使用流程;核心用户的关键路径和节点;用户的激励和引导模式;信息的生产、组织、流通、呈现和消费模式;UGC 的氛围和机制……等等。 每个环节最重要的产品功能和核心指标是什么，分别需要怎样的外部资源支持，如何通过设计有效率的产品机制为运营加分…这些都要求产品经理跳出当前的具体事务，看到产品全盘并意识到有哪些问题亟待解决。

另一方面，从项目管理的角度来看，产品经理要时刻清楚产品的愿景和目标是什么，达到这一目标有哪些关键的里程碑(Milestone)，短期及中长期分别要解决什么问题……只有心

里对整盘产品大棋了如指掌，才明晰当前正在做的事情的价值是什么。在遇到问题时，才能够敢于坚持，或者有的放矢。不管是在大公司还是小公司，真正的产品经理永远要想清楚这些问题，不能寄希望于其他团队成员。

九、沟通不足

作为项目成员的中枢角色，产品经理是互联网公司里与人打交道最多的职位。与工程师和设计师的沟通不足，最常见的后果就是对方对产品的理解有偏差时即已开工。导致后面不仅需要更多的时间进行二次沟通和解释，且给设计和工程上造成的损失也是巨大的，一定程度上的推翻重来比从零开始更加困难。

从产品流程上来说，比较好的沟通方式是提前沟通，在立项阶段就可以让设计师、工程师一起参与项目讨论，这不仅避免了后期的多轮重复沟通，也更利于产品经理向他们传递更多的产品理念，培养感情，增强产品经理在团队中的威信。

十、保持学习

如上文所说，产品经理不仅要求兼具知识的广度和深度，同时还要有良好的书写和口头表达能力、对平级和上下级的管理能力、跨部门的沟通和协调能力;时刻清晰产品的定位和愿景，使之走在正确的道理上不变形，并在团队内部持续传递产品价值观，不断建立其他人对自己的信任。当然，懂设计和编程等都会为产品能力加分。

达到这么多的要求成为完美并非易事，只有保持开放的学习心态才能够不断前进。不妨试想一下，如果没有现在公司的平台和资源支持，让你从头创业做一款产品，能做成什么样? 以上所写并非全部，回过头来看，有一些即使重头来做也未必能完全做对做好。在特定的时间空间里，产品经理这个既理性又感性的工作角色，总会面临各种各样的困难，完全杜绝错误并不可能。某种意义上，产品经理唯有积累方法论，规避重复犯错，将事情放在大环境里进行反复斟酌和思考，才能做出尽量接近正确的决定。

星无尘博客http:// /欢迎转载，转载请注明作者和出处。谢谢

第三篇：互联网产品经理的核心竞争力

互联网产品经理的核心竞争力是什么?如何培养?

来自：知乎 23小时前 |

阅读原文

人的核心竞争力是什么，一般来说，是指个人对目标位置(或其他想要获取的东西)的适合程度的关键考虑点，这是一个相对来说，比较相对的问题，在不同的情境下会有不同的回答。

没耐心看的人，这里我放个脱水版的思维导图：

比如我们都在讨论交流沟通技术能力如何，台上一名大腹便便的领导轻挑牙签，弹了出去，说：“你们扯JB蛋，劳资能喝酒，能看人眼色做事，晓得怎么糊弄上面威逼下面，这TM才是核心竞争力，我才能在这位置坐得这么稳。”

谁能说他错了?

于是，我愿意为这个问题指定一个问题范围，然后来回答它。即，我下面考虑的是，针对互联网产品经理这个职位，我有哪些核心竞争力。另外有一个必须要提的题外话是，为了让这点文字不变成自吹自擂，我不如针对我的这些核心竞争力是怎么来的，做一些具体实在的解释，做个分享。相信这也是大家最想知道的。

我按我理解的优先次序，来把它们列出来，希望能对大家有所帮助。

1、那么第一点让我来说这个：热爱与激情

又是这两个词语，你甚至可以把它们拼接成一个词语”热情“，但是我硬要把它们分开是有原因的。“热情，热情!我有热情!”，许多人这么说着，然后问HR，你们公司加班不?

这是一个很看起来有失偏颇的观点，许多人会来与我争论，工作和生活应当分开。我也赞同。但是，我热爱的东西，为什么我工作之外，生活之时，不能也想想它?我想想它就开心啊，就来劲啊。于是我每天除了上厕所吃饭睡觉都在做工作了，或者准确地说，不应把上厕所去掉，因为我上厕所的时候会看新闻、研究app的体验、琢磨游戏的可玩性根源;也不应把吃饭去掉，每次吃饭我无数次想到一个东西，就停箸闷思，有时候把筷子停在了嘴巴里面几分钟才知道;也不能完全把睡觉去掉，我不止一次地梦到那些东西了。

这是我同时打着几份工，并让每边都满意，自己也过得身累心不累的原因。互联网这个行当，有趣有趣，1024的伙计们，咱们一起在这里再拼10年好吗?热爱与激情，嘿，哪有那么容易?

2、超快的学习速度，这是可培养的

依旧是个炒烂了的东西，但是学习速度，真的说得再重要也不怕，绝大部分的硬能力都是可学得的，当然，天赋所限，会有学习速度的差异，但是实际上，我始终认为，这种差异恰好就来源于上面那点(热爱与激情)。

如果你真的对一件事情充满热情，你一定会想方设法地寻找方法、路子、导师和实践经验去学它做它。凡事就怕有心，实在是一个被人忽视的至理名言。你听过哪个热爱某个游戏(比如DOTA)的人，会和你说这游戏我学它学得痛苦死了难死了?

学习速度的培养其实没有多少方法，如果一定要我说，我愿意说，请你爱上它。

3、优秀的思考和总结能力

嗯，怎么说明我的思考总结能力比较优秀呢?我突然想笑，因为我想到了前段时间大名鼎鼎的刘俐俐那一句“刚才不就可以证明”。这句话安放不此，感觉无比恰当啊。我又想到了韩寒的无奈，如果你不愿意相信我思考总结能力不错，我再说得天花乱坠，那你也能说是别人教我说的，我在别的地方看到的，不是自己的思考的。这真是没办法解释呢。

呜，想到一个不错的法子来证明，看看我的和知乎专页和博客吧，http://kant.cc。这上面的内容，大抵都是我的思考和总结，我向来在写东西时，不用搜索引擎(所以词语用错就莫怪了)。总结能力这块，还有些别的东西，就是不可公布的了，要有职业操守呵。

按惯例，该说这东西怎么培养了。其实，如果你擅长思考，你大致已经看到了，我的办法是：写博客，自主主动地写优秀的文字。不是要让你写出惊天地泣鬼神的东西来震撼世界，而是要让你写出一篇篇自己比较满意的文字，在这过程中，你就不可避免地持续思考了。对了，写博客这种事情，三分钟热度就算了，否则坚持不下来的，别想着会有多么大的鼓励和动力，你只靠自己，请参照第一点。

4、软素质

软素质是个潜移默化中形成的东西，但是如果你有意识地去培养，相对更加容易形成。这很难坚持，所以前提依旧是，请参照第一点。

让我把我的软素质按我理解的重要程度排个名次：

●良好的沟通表达能力。这是基本，基础。沟通表达不是要你话多，而是让对方更容易理解你，更愿意理解你。这算个相对好培养的能力。

●良好逻辑能力。这也是基本能力，这点我也说不清楚怎么培养，多看些逻辑思维方面的书，然后遇事多思考，多提问并解答，是个路子(不保证好)。

●理性、数据感、证据感强烈。前面三点算是说服能力的几大构成因素了。所以我不把说服能力列出来了。理性、数据感、证据感让人感觉你的话有说服力，逻辑能力让你自己能把话和分析材料组织好，沟通表达能力让你把话正确地说出来(否则再有说服力也没用。)。

●积极主动。无比重要，培养方法请继续参照第一大点。

●时间管理能力。这一点恐怕越走到后面越会清楚它的重要性，否则时间会越来越不够用(别只会觉得领导不干事)。用好工具是个办法，但更重要的仍是自己的心态，对自己严格要求是必须的前提。时间管理还体现在高效保质，这是我信奉的。

●可怕的细致入微。这个可有趣了，也没那么好培养的。这东西体现出来可让人蛋疼了，我诸多强迫症和体验狂热症的根源恐怕在此，我受不了不对齐的图标，受不了粗糙的字体，受不了杂乱的电脑桌面，受不了设计差劲的app或logo。细致入微也是我每提一个刺，旁人便会说，这没事吧?谁会感觉得到?我还是梗着脖子地想着，用户就算说不出口，但一定感觉得到这种差劲，一定会感到不舒服。这有时会导致危险。对了，细致入微也是爱情和睦的保证，亲测哦!

对软素质，我比对硬能力更加敏感在意。主要原因在于，我以为它们更难学，更难培养，即使我有自豪的学习速度，但也不能保证朝夕之间能获取这些我现在最想获得的素质：胸怀、眼界、复杂协调能力等宏观素质。

对了，责任感没有提到，不是我忘记了，而是我实在觉得，这个东西如果没有，你都不需要看下去了。(其实有了第一大点，责任感是可以预见的)

6、硬能力

硬能力没什么好说，努力去学吧。我也是废寝忘食学来的，有许多能力现在只是皮毛。

●较深的技术积累。好好去做吧，技术的确枯燥，但如果你真的喜欢它，你又感觉它无比神奇。再简单的项目，几个项目开发下来，你也会变得对技术有所感悟。别等，立刻去做。做开发很累啊，但是你如果试试了，会发现，自己带的项目一步步朝前进并完美收尾，是非常有成就感的，切身体会。

●较深的产品心得体会。心得体会只有能过长期的学习和积累才能获得，而且你必须要有自己的思考和吸收。或者更严格地说，产品体会只能通过亲力亲为地跟着做一次产品，才能获得，我现在就是腆着脸说说。

●良好的产品sense。有点看天赋的东西。不过我向来觉得，绝大部分人和身边人竞争的时候，他对事物的努力程度和热爱程度，还远远没有达到需要拼天赋的时候。

●良好的产品分析和策略分析能力。这是工作中学来的东西了，同样是腆着脸说说的了，牛人在侧，让人无比悲戚啊。你在上学也没关系，看新闻的时候，多思考多分析多总结，慢慢就走出路子了。

●对运营和营销有一定的理解。真诚感激亮哥和其他在知乎上让我有所获的回答者们，这一处你们帮我不浅。

硬能力方面，我目前最缺乏，或者说我最希望获取的，主要是商业敏感，这个不是朝夕的事，持续努力吧亲。其他硬能力我都有信心获取。

7、对爱的感恩和对蔑视的蔑视

谁帮过我的，没齿难忘。我才活到二十来岁，也算有些波折，好在遇到的贵人实在是很多。实在是他们都不像我这样喜欢丢人现眼，一个个点名恐怕不礼貌。大恩不言谢。

人的成长过程总不会太顺，甚至太顺还不好。人总会遇到点挫折、忽视甚至蔑视。这时，蔑视回去吧少年!他时若遂青云志，敢笑黄巢不丈夫。奔着这点念头去努力，而不是受着那点挫折就跪倒。

对爱的感恩和对蔑视的蔑视，会让你随着本心专注地前行，却也不会忘记了身边的关怀。

第四篇：互联网产品经理几种必备文档的介绍

【摘要】

互联网产品经理几种必备文档的介绍

【全文】

BRD Business Requirements Document，商业需求文档。这是产品声明周期中最早的问的文档，再早就应该是脑中的构思了，其内容涉及市场分析，销售策略，盈利预测等，通常是和老大们过的ppt，所以也就比较短小精炼，没有产品细节。

商业需求文档重点放在定义项目的商业需求。BRD要能说出客户碰到的一个或多个商业问题，并且通过公司的产品能够解决这些问题。接着一个 —— 通常是新产品或者现有产品的改进来解决这些问题。BRD也可能包括一个高级的商业案例，例如收益预测，市场竞争分析和销售/策略。BRD通常是由拥有产品经理，产品营销经理或者分析师头衔的人撰写的。在小公司，可能由高级主管或者甚至创始人撰写。BRD通常是一份连续的1-3页Word文档，或者不超过10页的Powerpoint文档。

MRD Market Requirements Document，市场需求文档。获得老大的认同后，产品进入实施，需要先出MRD，具体来说要有更细致的市场与竞争对手分析，通过哪些功能来实现商业目的，功能/非功能需求分哪几块，功能的优先级等等。实际工作中，这个阶段PD可能的产出物有Mind Manager的思维图，Excel的Feature List等。

市场需求文档(MRD)重点放在为一个被提议的新产品或者现有产品的改进定义市场需求。与BRD指出商业问题和解决这些问题的解决方案不同，MRD更深入提议解决方案的细节。它包括一些或者所有这些细节：

a. 解决商业问题所需要的特色 b. 市场竞争分析 c. 功能和非功能需求 d. 特色/需求的优先级 e. 用例

MRD通常是由拥有产品经理，产品营销经理或者行业分析师头衔的人撰写的。MRD通常是一份连续的5-25页Word文档，或者正如之后描述那样在一些机构中甚至更长。

PRD Product Requirements Document，产品需求文档。进步一细化，这部分是PD写得最多的内容，也就是传统意义上的需求分析，我们这里主要指UC(use case)文档。主要内容有，功能使用的具体描述(每个UC一般有用例简述、行为者、前置条件、后置条件、UI描述、流程/子流程/分支流程，等几大块)，Visio做的功能点业务流程，界面的说明，demo等。Demo方面，可能用dreamweaver、ps甚至画图板简单画一下，有时候也会有UI/UE支持，出高保真的demo，开发将来可以直接用的那种。

产品需求文档(PRD)重点放在为一个被提议的新产品或者现有产品的改进定义市场需求。与MRD侧重于从市场需要角度看需求的不同，PRD侧重于从产品本身角度看待需求。通常在特点和功能需求上更深入细节，并也可能包括屏幕截图和界面流程。在那些MRD不包括具体需求和用例的机构中，PRD就包含这些具体内容。PRD通常是由拥有产品经理，行业分析师或者产品分析师头衔的人撰写的。PRD通常是一份连续的20-50页Word文档，或者针对复杂产品甚至更长。

提醒：一些机构将这里描述的MRD和PRD合并成一个文档，并称最后的文档为MRD。在这种情况下，MRD包括本段描述的内容，也包括上一段描述PRD的内容，并且可能超过50页。

FSD Functional Specifications Document，功能详细说明。有一点像“概要设计”，这步就开始往开发衔接了，产品UI、业务逻辑的细节都要确定，细化文档并保持更新。相应的，有很多内容，比如表结构设计，要由项目经理来编写了。

功能规格文档(FSD)把焦点集中在实现，定义产品功能需求的全部细节。FSD可能通过一张张的截屏和一条条功能点来定义产品规格。这是一份可以直接让工程师创建产品的文档。与MRD和PRD侧重于以市场需要和产品角度看需求不同，FSD把重点放在了以表格形式定义产品细节，再让工程师实现这些细节。FSD也可能包括完整的屏幕截图和UI设计细节。FSD通常是由拥有产品分析师，工程领导或者项目经理头衔的人撰写的 – 作者通常属于工程部门。通常一个连续几十页的Word或类似文档。

写好MRD的10种技巧

MRD-“市场需求文档”，是产品经理或者产品市场经理编写的一个产品的说明需求的文档。这些文档用于计划一个新产品或修正一个已有的产品，是被工程师团队开发产品时使用。

在硅谷的一些公司，MRD仅仅覆盖high-level的功能。在这种情况下，产品经理通过创建了另一个文档-通常指的是PRD(产品需求文档)来定义更加详细的产品需求。

在本文中，我用术语“MRD”泛指所有那些由产品管理和/或产品市场团队创建的，为工程师团队传达产品需求为目的的文档。

写好MRD的10种技巧

1、从用户角度的编写

从用户角度编写需求内容。使用“用例(Use Case)”和“用户角色(User Personas)”来达到这个。考虑用以下两种方法来详细说明你们公司正在开发的SFA(sales force auation)软件的“Login”的功能性。

方法A：

用户通过一个要求用户提供证书的登陆界面，然后软件允许用户带着特定的权限进入系统。软件鉴别这些证书，在鉴定通过的基础上允许用户访问那些他们有权限访问软件的功能部件。

方法B：

Mike是一个销售经理，Cathy是一个销售代表。当他们打开软件，他们看到登陆界面。他们通过用户名和密码进入系统。如果用户名和密码是正确的，他们能登进系统。一旦登陆进系统，Mike能访问软件所有的功能部件。Cathy只能访问那些对销售代表有有效的功能部件。

哪个方法更加容易阅读和理解?就我的看法,毫无疑问，"方法B"。还有，它同时减少了令人烦恼的阅读!

2、使用Screen Shots 使用Screen Shots或者mockup来你的想法。我们中很多人都听说过“一张图片好比一千个文字”。当提到写MRD的时候，一个screen shot好比一千个文字!

举个例子,看看下面这个screen shot，你需要多少字来描述?我想可能不只一千个字。

3、用简单的语言编写

在我超过11年的行业中，我通常注意到的(更多是令我懊恼)一件事是用很做作的语言来写的MRD。我想这个主要是因为MRD听起来是正式的和专业的原因吧。

相反，想象你写的MRD是写给你的在工程师团队工作的朋友。你的目标是帮助他理解你需要什么，以便于他能开发产品实现这些需要。这个将有助于你避开陷入那些令读者人厌烦(有时他们会把MRD撕碎然后再碎片喂给碎纸机)的用做作的语言的陷阱。

还有：

a)保持简短的语句，把长的语句分解成多个小的语句。 b)避免大篇幅的连续文本，把他们分解成多个小的章节。 c)把大块文本内容分解成，screen shots，表格、重点列表等等。

4、小心的使用模板

我发现MRD模板非常有用。他们的几个好处包括： a) 模板提供了一个标准的格式，使那些不得不阅读大量MRD的读者更加容易阅读。

b) 模板让新的产品经理快速的写MRD变得容易，因为公司与公司之间的MRD内容是不同的。

c) 模板确保你不会忘记所有需要在MRD中覆盖描述的部分;

然而，一些公司过分的使用模板。一个硅谷最大的公司之一有一个所有部分被强制使用的近60页的模板。我觉得这个让人觉得非常难以忍受并且有几个负面的作用：

a) 产品经理害怕但又不得不写MRD - 几乎和不得不和Dick Cheney去南德克萨斯打猎一样(译者按：副总统Dick Cheney在南德克萨斯打猎时意外的打伤了和自己一起去的打猎伙伴)。

b) 工程师团队害怕但又不得不阅读MRD。 c) 写MRD和读MRD都需要花大量的时间。

我你使用MRD模板，但确保他们不要过分的长。还有如果需要，确信产品经理可以灵活的跳过模板某些部分和创建新的内容。

5、区分需求的优先级

在这些年里，我从来没有碰到一个工程师团队实现了MRD里包括的所有特性的没有删减的项目-通常由于那些我们控制之外因素!

这就是说作为MRD作者的产品经理，当出现需要决定取舍的时候，应该提供一个办帮助让他们决定那些特性要实现那些可以推迟。

区分需求的优先级是一个最好的能帮助完成这个事情的办法。我发现把需求分等级就像P1，P2，P3...这样工作的刚刚好。在这个分类中-P1是最高优先级，P2是第二高优先级等等。

最好的决定一个已经明确的需求的优先级方法这个需求实现后的好处-包括你的客户和你的公司。在实际实践中，最好是和其他多种因素一起综合决定。

我推荐你只要包括P1，P2，P3的需求在你的MRD中，在多数的项目中更低的优先级可能未必会实现。还有这样也让MRD变得更加容易读。

6、说明"是什么"和"为什么"，但不要"如何" 产品经理为理解客户的需求负责，然后基于这些理解定义什么和为什么需要开发. 有一件比任何事情让开发者发疯就像在几英里外都能听到的汽笛在他们耳边尖叫一样的是一个令人痛苦的详细描述了怎样实现每一个需求细节的MRD。

考虑你们公司正在开发的以下两种描述CRM“Login”功能的方法。 推荐-描述“是什么”

Mike是一个销售经理，当他打开我们的CRM软件，他会看到一个登陆界面...登陆界面建议提供“记住我”复选框。如果Mike在点击登陆按钮之前选择了该复选框，我们的软件将记住并且在他下次来到登陆界面时自动填写他的名字。

不推荐-描述“怎么样”

Mike是一个销售经理，当他打开我们的CRM软件，他会看到一个登陆界面...登陆界面建议提供“记住我”复选框。如果Mike在点击登陆按钮之前选择了该复选框-将通过Javascript 保存他的名字以cookie的方式写到他的硬盘。当cookie写到硬盘后，用户名和密码将被发送到服务器。下一次Mike来到登陆界面时，Javascript 将读取他的cookie，成功读取后，Javascript 将是适当的DOM命令填充登陆页面上的用户名。好的产品经理擅长理解用户的需求和描述什么需要实现，好的工程师擅长决定怎么样实现它。好的工程师希望能自由的决定怎么样最好的实现用户希望得到的东西。

我注意到有背景的产品经理尤其喜欢描述“如何实现”。如果这些描述的就是你，应该从现在开始不要再做这样的事了。工程师们将会感谢你。

附：这里有一些例外的情况-当在描述“是什么”中描述“怎么样”是必要的，当描述“是什么”的最好的方式和/或唯一的方式就是描述“怎么样”的情况。

7、覆盖非功能性需求

尽管功能性需求描述产品的功能，非功能性需求描述系统特性，如：

a)性能 b)可伸缩性 c)可用性 d)国际化 e)等等... 我注意到因为许多产品经理和产品市场人员认为这些是“技术细节”，而在MRD中被忽略。我发现这些是我的MRD中非常重要的一部分，工程师们会非常感激在MRD中定义这些需求。

要点：当写非功能性需求的时候，尽可能的是使他们可度量(可测试)。否则，QA不能测试它们，你将没有办法知道完成的产品是否已经实现了这些非功能性需求。

8、评审&修正

我有一个朋友-我们叫他Matt(他的真名叫Steve)。Matt在硅谷一家成功的公司做产品经理工作。最近我在午餐的时候碰到他是告诉我一个非常有趣的故事。

他们雇用了一个有三年的产品经理。在他被雇用的几个月里，不知何故他让他的产品经理同事和工程师一样疏远他。

他是罪犯?他基本上认为他的MRD就像一个法令。他写了它，但不想和任何人评审或在反馈的基础上修改它。他仅仅想工程师团队没有问任何问题的拿着它并实现它们!

不要像Matt的同事那样。确信做到和你的产品经理伙伴和工程师团队评审你的MRD。保持一个敞开的思想然后在评审反馈的基础上更新MRD。这将帮助你写出更好的MRD，工程师将喜欢你(或者至少少恨你一些)，你的团队也将创造更好的产品。

9、定义市场目标和定位

大部分我看到过MRD在覆盖了市场目标(谁将买和使用户你的产品)和定位(与竞争对手的产品比你的产品定位怎么样的)的方面做的很好。

我还看到过一些没有描述市场目标和定位的MRD，他们通常会这样争辩：“为什么工程师们需要知道这些?拿到定义了什么是需要的还不够吗?”

这些问题(谁将买和使用户你的产品和与竞争对手的产品比你的产品定位怎么样的)的确有一些正面价值，我发现许多工程师想知道为什么一个产品或特性要开发，谁将使用他们，什么是他们可以另外选择办法。

这些信息帮助他们和产品组的其他成员想象最终用户并从而更好的为创造成功的产品工作。我的建议的尽可能的(在MRD中)包含这些信息。- 它们不一定要很详细，只要包含几个段落就足够了。

10、包含一个术语表

如果你的MRD使用了新术语或在非通用的地方是使用了常用术语-确保在MRD后面包含一个术语表。

当你像这样说“我们的软件将提供SME用户通过选择WAP或PSMS开MRC帐单”时，术语表将确保你的所有读者(有些可能不是技术人员)理解你的意思是什么。

第五篇：互联网教育产品的平台论：从电商平台说起 人人都是产品经理

互联网教育产品的平台论：从电商平台说起

人人都是产品

经理

如果统计创业公司在PPT里最高频的词汇，那么“平台”一词一定是出现最多的。

所有人都知道，打造所谓“平台级”的产品是非常不容易的。产品经理爱说这个词，投资人爱听这个词，但是什么是“平台”，以及“平台”产品有何规律和关键，却是很少被谈及的。本文的主题虽是讨论教育平台，但鉴于现在世面上还含有特别成功的教育平台产品，所以先看一看其他领域的平台产品的案例，看看是什么让它们成为平台，以便我们反过来思考教育领域的机会。

首先我们看一下最有名的淘宝。

我们都知道，淘宝之所以成为中国最大的电商平台，最重要的原因是它率先推出“支付宝”，提供了信用中介，让买卖双方解决了基本的支付/交付的信用难题，从而使电子购物具备了基本的可行性。

那么，淘宝之后，何以出现了京东这个大型电商平台? 回想一下你第一件在京东买的商品，京东是靠什么起家的?没错，各类电子产品，这类产品的共性是：

严格的标品。

绝大多数用户搞不清楚，很难辨认水货、翻新或者是商品否做过手脚。 商品平均单价高。

综上，我认为京东能在淘宝确立自己电商平台地位后，找到自己的一席之地，起到决定性作用的，并不是刘强东得意的自建物流战略，而是京东选择了电子产品市场，并且初期完全采用了自营的形式。

淘宝虽然解决了基本的支付/交付信用难题，但一开始就生为平台的淘宝，解决假货和水货问题上，成本非常高。而对高价的电子产品而言，用户恰恰是最怕买到问题产品的，京东在笔记本电脑，手机等电子产品需求大爆发的期间崛起，恰恰就是靠自营解决了用户的甄别难题，与淘宝差异化竞争，在市场上取得立足之地，最终发展壮大为真正的电商平台。

回顾上述国内两大电商平台形成的关键点，我们后见之明的发现，原来电商平台形成的背后逻辑，是各自解决了两个信息不透明的问题。其一，支付与交付的基本信用，这个是针对所有网上交易的基础;其二，是正品问题，这个对高单价的电子产品尤为重要。 当然，买家评论、帮助店主学会运营、七天退货，提升物流等问题也都发挥了很重要的作用，但这些问题并不是最根本的。买一个东西，能不能收到，和收到的和自己想要一样不一样，是用户两个最根本的需要，解决这两个信息不对称问题的产品也才最终形成了电商平台。

那么教育领域的产品，面临什么样的问题呢?

这时，我们需要正向推导，即把刚才从现有产品案例出发，反推背后逻辑和用户核心需求的过程反过来。那么，我们的问题就可以改成，一个教育平台，他的用户为什么要使用这个平台，它能为用户解决什么问题?在教育领域，是否存在着独有的信息不对称，需要这个平台去解决?

在探究这个问题之前，我们先要明确：互联网教育平台，最终的盈利模式，一定是要让用户掏钱为自己学的内容买单。之所以这么说，是因为用户有各种途径学习，知乎、专业论坛、网络文章、公开课、身边朋友等等„„而互联网教育平台，并不是要满足这些泛学习的需求，或者更准确的说，这些轻度或者泛化的学习需求无法形成一个集中的平台，无论是教授者还是学习者都没有充分了理由聚集在一个平台上。 我们需要明确的问题就是：学员用户学习的目的是什么?进一步说：用户掏钱学习的目的是什么?

其实说穿了，人们进行学习这个行为，终极的目的只有两个，要么是“好玩”，要么是“有用”。

“好玩”这个事情先放在一边，因为用户自己有兴趣的东西，他可以通过各种形式去获取，无论是书籍还是网络，在信息爆炸的时代，不可能有个以兴趣为导向的互联网教育产品成为平台级产品，因为信息源头太多，用户需求分散且迥异。 而“有用”作为一种刚需，人们付费学习的动力强得多，而且在线下就有这样的例子，那就是各种各样的大学和职业院校。有用有很多具体情况，比如说为了留学，为了或者某种证书„„但终极的来看，大部分还是为了提升自己在职场上的竞争力。因此表面上看，付费学习是老师和学生之间的事情，平台只要解决两者之间的问题就可以了，而实际上，我们却忽视了为付费学习的结果最终“埋单”的主体——用人单位。为什么大家都想考清华、北大、剑桥、哈佛?因为这些院校保持着自己的高入门水准和稳定的教学研发质量，最终用人单位可以通过这些院校提供的证书，低成本的筛选出相对靠谱的人。没错这些院校也有不靠谱的人，但是总体概率大大降低，大家都抢着去的优秀公司，用这些院校的毕业证书来筛选人才，招聘的成本可以大大降低。而如前一个段落描述，当前网上的教育平台，能做到这一点的很少，甚至很多都没有以此为目标。这就是打造教育平台的核心——认证。

这也正是淘宝教育，跟谁学等“教育平台”为何做不起来的原因，电商的思维和解决问题的方法，注定是忽视用人单位这个第三方的，电商之前解决的问题，就是在买卖家双方之间。而急于扩大品类，引进大量良莠不齐的教育内容提供者，表面上看是在向“平台”大步迈进，实际上恰恰是削弱了自身品牌的“稳定性”，也就是削弱了打通用人单位和学员之间信息壁垒的能力。

提到“认证”，想必很多人会大摇其头，理由归结下来不外乎如下几点。

各大高校有国家认可的证书，有法律效力和公信力，互联网平台做不到。

社会在变化，以后越来越多的人会为提高自己的素质和见识而学习(比如罗胖的app，得到)，提高职业竞争力这块市场不用去和传统公司抢。

高校的教学和研发成本相当高，经营下来是赔钱的，大多数要依靠国家的支持或者社会的捐助。互联网公司想自己做，根本就只能是赔钱买卖。

认证是个结果，并不是追求的目标，它本身需要优秀的老师，科学的教学方法和工具，这些才是根本。

针对这几点，我的理解分别如下。

(1)公信力问题，其实并不是问题。互联网时代，甚至更早的重大创新，从来没有哪项创新一开始就是合法或者有政府背书的。Uber,淘宝，无人驾驶技术，无论哪一个都面临法律的空缺，甚至违法地方法律的窘境，但是这从来不是阻碍创新的原因。现代教育的前身，大学，本身也是从纯粹民间的书院、教会学校等组织演化而来，在漫长的岁月里并没有什么国家背书。

(2)泛化的知识传播和系统性的教学从来不是同一种商品。前者可能会作为后者的一种辅助手段，但是两者的界限非常明显。未来还没到了每个人都为纯粹的兴趣而活的地步，中国更是距离其遥远，另外一方面，泛化的知识传播缺乏集中到某一平台的动力，很多垂直领域的论坛、微信公众号、视频网站内容产出者乃至问答类的知乎和百度知道等产品，已经满足了很多泛化的，碎片的学习需求。

(3)高校是个亏本生意，但互联网教育平台不是。因为网络本身具有传播信息边际成本极低的特性。当然网络自身在教学效果上有其局限性，解决好这个问题，需要产品在教学模式，学习工具，学习氛围营造，以及初期切入的学习细分领域等很多方面做好工作。

(4)这句话本身没错，如上面所说，很多方面需要做好才能保证认证效果。但是没有以认证为目标的话，就没有清晰的战略方向，导致方向迷茫混乱和战术上的弯路。比如，用户数量重要不重要?是不是要快速的搭建平台让良莠不齐的知识提供商入住?要不要加入纯粹兴趣爱好类的内容?测评类产品和功能的优先级是怎样的?社交对于我们重要不重要，怎么做学习上的社交?所以认清“认证”这个目标的核心地位，是解决战略问题的重要前提。

那么如何打造一个以“认证”为战略核心目标的产品呢?我大致的归结为如下几点建议，还请各位斧正。

第一，利基市场一定要选择传统成人教育较为薄弱的领域。比如职业教育、比如互联网新兴行业的必备技能。这是由颠覆式创新的一般规律决定的，也是由公信力的产生过程决定的，这种差异化的竞争能在初期为产品带来更稳定的用户群体。

第二，一开始一定要从“自营”做起。或者一定要保证教学内容的高品质和稳定性，不能为了短期利益或用户数量而急于开放“平台”，这样才可能梳理品牌乃至公信力，最终获得一种强的认证能力。

第三，技术上的关键是如何提供优质的录播课内容生成和学习工具。为什么是录播课?因为这才是降低成本，让大多数人都有可能接触到最优质系统性学习内容的根本方案。最优秀的教学者，时间的成本也是最高的，请他来做讲座都不容易，系统性的讲授怎么可能让他反复做?因此直播只能作为一种辅助，用于答疑解惑，或者辅助性的讨论、专题的学习。 第四，测评非常重要。这是提供有效认证的重要前提。某些自动化的测评工具简直本身就是很好的创业项目(比如批改作文)。

第五，要贴近用人单位的需要。他们为你的认证埋单，是最重要的结果。为了实现这一点，初期的创业公司可以考虑先从企业培训市场做起，或者至少更加注重和企业的相关合作，这一方面可以更快的增加品牌认知度，另一方面也可以反过来影响课程内容和教学方式的制定。

第六，K12，即中小幼市场，不是个好的切入点。如果你只是想赚钱，那么这在短期或者中期是个很好的市场。但要成为真正的互联网教育平台，中小幼并不理想，因为其绝大部分学习场景，都应该是在线下的，孩子的自制能力，心智成熟度等等原因，使他更适合线下学习，而且线下的中小学已经占用了学生大部分系统性学习的时间，在这个领域，做教育学习的工具还是有空间的，平台没戏。

第七，凡是有利于教学效果，和认证能力的事情，都可以做。这个要根据具体的公司能力和短期目标来看，举例来说，我认为在技术还不够发达的时候，适当的加入线下教学的环节并没有什么不可。

第八，凡是和认证相关性很小的方向，不要去做。这个看起来像是废话，既然认证是战略核心目标，那么按照人尽皆知的“聚焦”原则，无关的当然不要做。但这真的是难的，诱惑很多，比如很多提高用户粘性的功能。这里就要想清楚，我们满足的到底是用户的什么需求，核心价值在哪，单纯为了提高用户活跃而作的功能，如果对学习效果没有实质帮助，对提高认证的效力没有意义，就是有害的。

在不太遥远的未来，也许10年左右，互联网教育平台提供的学习成果证书，将超过90%的本科和大专，这是绝大多数求学者的福音，是个巨大的商业机会，把握这个机会也将真正的改变这个世界。 后记：

本文为本人在互联网教育领域从业2年来的一点思考，如能对大家有一点点启发，那正是本人的荣幸。

如果有朋友有兴趣就此问题，进行一步的讨论或者批评指正，那也很欢迎。

本文由 @杨晨 原创发布于人人都是产品经理。未经许可，禁止转载。