传统企业在转型进入互联网的时候往往会认为开发最核而忽略了产品的经理的重要性，其实在转型的过程中，产品经理也是一个必不可少的角色。那么对于传统企业来说，为什么产品经理是必不可少的？文章为你解读。

一，你为什么需要产品经理

经常有很多传统行业的老板向我咨询如何通过互联网展开业务。针对业务逻辑层面的咨询还能够理解，但有一部分咨询，却是因为被骗了来倒苦水。因为不懂行，所以进入互联网行业后，各种被骗各种吃亏，让人听得真是无奈叹息。

譬如有的老板因为轻信人言，把产品外包，两百万花下去，结果对方做的整套产品里，只有登录和注册这两个功能基本可用，弄得老板连哭都没地哭。譬如有的老板因为没有找到合适的人员负责整个产品的开发，导致产品进度一拖再拖，最后耐心耗尽，只能放弃。譬如有的老板因为公司里没人懂技术，明明招的是开发人员，却只能空谈项目，而没法问技术水平。结果对方怎么说怎么信，招进来才发现很多基本的功能都实现不了。譬如有的老板找人开发，结果对方到网上下载一套成熟的模板，稍微改了下（就改了名字logo之类，后来使用过程中老板发现还没改完），然后要价三四十万。老板最开始还以为买了便宜货……

这样的故事听得多了，给我的感觉就是：这骗钱也太容易了。于是我就觉得有必要把这事给大家理一下。具体说清楚传统行业的老板要想进入互联网的话，要怎么做？招什么样的人，哪些岗位不可或缺，必须得有。当然此文是写给传统行业里想进互联网行业的老板的，而不是写给互联网从业者看的。文章里谈到的一切，在互联网从业者看来，都是自然而然的事。但传统行业的从业者，却未必就知道了。

我的建议是，如果是想通过产品提供服务的话，则产品尽量不外包。这有三个原因：

第一，就是你不知道对方技术靠谱与否，人靠谱与否。

到时候逻辑随便乱写，改都没法改。或者延误工期，功能细节上偷工减料等等各种毛病。除非你有个懂的人给你把关，否则外包就是自讨苦吃。

第二，需求细节在开发过程中会有变动，而外包方一般不会改需求。

因为这会延长开发周期，他们肯定不接受，除非又加钱。对方这时候漫天要价，你将毫无办法。

第三，后期没法维护。

开发完成就交付验收，验收结束就结束了。使用过程中遇到问题，外包方一般是不会管的，要管又是加钱的事。但任何产品，必须经过一段时间的使用，才能发现大部分问题。单纯依靠测试，是不可能发现所有问题的。经常会有逻辑层面的隐藏bug，只能在使用过程中才能发现。这时候就算交钱给改，这个过程也很漫长，用户体验不好。

既然不外包，那怎么办呢？这个就要分析业务的需求了。对于那些能够通过微信展开的业务，尽量通过微信去承载，开发成本低，传播成本也低，用户使用成本也低。如果非要自己开发app的话，那么自己组建团队就是必须的。本文的建议主要面向那些想自己组建团队的老板。这样的老板目前给我的感觉，是越来越多了。也不晓得是不是因为媒体大力鼓吹互联网+，结果这把火把传统行业的人也烧得焦虑了。

虽然人们常说早期员工都要老板自己面试，但专业问题，老板自己其实是面试不了的。传统行业的老板，本来就不懂产品和技术，所以就只能面试人品，怎么面试专业技能？所以，我的建议，是老板花所有精力，找到这两个职位的人：产品经理和技术总监。这两个职位，缺一不可。这两个职位如果找到靠谱的人，那么后面的事，包括招聘与技能面试等，交给他们，比老板自己操作，靠谱得多。他们会根据老板的需求，或业务的需要，去确定产品功能与表现，并据此确定开发团队的规模与经费预算等等。换句话说，老板负责与产品经理对接，产品经理负责与开发和设计人员对接。所以，怎么样去找到这两个职位的人，是产品能否成功上线并正常运行的核心因素。

一般情况下，老板们是能够准确描述自己所需要的功能的，或者能够准确描述自己的业务。但仅此而已。老板很难将功能和业务需要变成需求，并将其产品化。这时候就需要产品经理出马，与老板各种沟通，来分析老板的需要，或公司的业务，从而设计产品表现，并给出原型图。开发人员只有拿到原型图，知道了每个页面的功能，才能定数据结构和接口，才能开发。而设计师也只有拿到原型图，知道了产品的交互细节，才能做设计。

而且老板的需求经常很发散，会想到不同的点。如果都一股脑儿全开发出来，那就累死开发人员了。所以这时候就需要产品经理帮助梳理核心功能和辅助功能，合理分配每个版本的功能迭代，逐步完善功能，优化交互与体验。

举个最简单的例子，老板说我要实现这个功能：用户在线上进行交易了，就对交易双方进行激励。这就是老板提的需求，只用一句话就描述完了。但要将其产品化，那方案就多了去了：譬如物质激励层面，可以有返现奖励，可以有优惠券奖励，可以有积分奖励，等等。不同的奖励方案，将会涉及到不同的延伸功能，及与产品其他功能的联动等等。其效果也不一样。

譬如积分激励，就涉及到积分的赋值与价值体系。都有哪些行为可获得积分？积分可用在内部消费吗？还是可与第三方打通共用？或者可用来兑换吗？官方可从积分消耗里抽成以获取收益吗？等等。或者荣誉激励层面，也可以有多种激励方式。这些就是产品经理要做的事，去分析老板的需要，给出最优的产品方案，最大程度的实现老板的目标，和用户的价值。并和开发人员对接，优化产品，最低成本的将产品开发出来。

二，一个实际的案例，告诉你产品经理会做些什么事

很多老板不理解，觉得我有程序员了啊，干嘛还要产品经理。在互联网行业，这个不是问题。相当于在地产行业，没人会问为什么有了建筑公司，还要开发公司干嘛？但传统行业的老板们常常不理解，觉得不需要产品经理：交给程序员就好了嘛？问题是，如果真交给程序员，老板直接和程序员对接的话，那就会把老板累死，而把程序员气死了。

因为我是产品出身，所以在这个部分，我就给出一个常见的案例——产品的注册页面，来详细的描述一个产品经理的工作内容和思考细节，从而展示为什么老板们必须要产品经理这个职位。为什么这个职位对老板们来说，它绝对不可或缺？因为产品有很多体验与细节，这些是老板们绝对想不到的。但没有这些细节，产品将会非常粗糙甚至漏洞百出，没法使用。那你的钱就真的就是白花了。做好一款产品，别说体验优秀，哪怕让其基本可用，都绝对不是老板们所想的，我说了需求，然后程序员就开始开发那么简单。

很多产品都要求用户注册。一个简单的注册页面，可能用户停留时间都不超过2、30秒，看起来简单之极。但就是这么个简单的页面，简单到老板几乎不会去考虑，其实对于产品经理来说，要考虑的则有很多。

第一个要考虑的，是我们的产品要不要用户注册呢？这涉及到追问注册的意义。

这就是老板们一般不会去想，但产品经理却必须想得非常清楚的一个问题。因为注册是一个产品里非常基础性的功能。在传统行业，老板们开个店，消费者来买了东西就走人了，哪去找注册这个事？但互联网，如果没有注册这个事，对产品的价值的伤害，往往是无形却异常巨大的。当初百度的总裁李彦宏亲自站台，搞轻应用，结果仅仅两三年，就无声无影了。导致这个巨大的失败的一个非常核心的原因，就是百度没有成熟的账号体系。而账号体系，就是建立于注册的基础之上。没有注册，就没有用户关系管理，没有用户行为记录……用户价值模型的建构就无从谈起。

在通常情况下，注册至少会起到四个作用。

• 一是起到门禁的作用。用户注册后，成为用户体系的一员，享受产品为自己的用户提供的各种待遇。非注册用户则没有这些待遇。这就类似于门禁，将注册用户和非注册用户区分开了。
• 二是起到区分的作用。每个用户有不同的ID，以便与其他注册用户做区分。
• 三是构建用户关系链条，包括用户间的关系，及用户与服务方的关系两个维度。
• 四是基于用户的行为，构建用户价值模型。

当然其实注册这个行为，有着更为复杂的社会学背景。这涉及到产品社会学的知识。一方面，一个产品，其实是一个小型的独立的社会体系。个体需要在这个全新的社会结构里被标识，并定位。另一方面，就是没有名字的对象，是无价值的对象。所以要想产生价值，名字是首先需要明确的。所以古代皇帝最喜欢干的一件事，就是给喜欢的大臣赐名。而我们普通人，也会给自己喜欢的人或动物或物体等取一个名字。产品里给用户赋名，即便是用户自己取的，这对产品来说也至关重要。具体的分析这里不展开，反正给对象赋名，其意义非常重大。但老板们提功能需求时，却一般都不会考虑到这个基础性的功能点。

问题是，虽然用户赋名很重要，但如果产品非得注册才能使用，用户的首次使用成本就有些高。所以产品经理就需要思考，注册是不是必须的？ 一般情况下，如果是内容型的产品，那么越是精准的、细分的内容，或独家的内容，用户需求越精准。用户越接受注册。而如果是大众型的内容，用户就越不愿意注册：一是此类内容获取的渠道有很多，二是这类内容的可替代性强。

而如果是工具型的产品，就看业务逻辑，是否有延伸。譬如便签、计算器、相机等等这类产品，基本不需要注册。但如果引入了云服务，譬如云端存储便签或照片，那就需要注册了。或者有其他商业模式延伸，譬如很多产品提供增值收费功能，那也需要注册了。 而如果是社交型、交易型（譬如电商等等产品）、业务型（譬如找工作找资源等等产品）等产品、那就都必须注册，否则没法区分不同对象的行为。所以这就需要产品经理根据公司的业务或老板提的需求去分析，要不要注册。

第二个要考虑的，是即便需要注册，那还有个注册时机的问题：先注册后使用，用户首次使用成本高，这是窄入口。

先体验后注册，用户首次使用成本低，这是宽入口。当然宽入口更优于窄入口，所以很多新闻、资讯类软件不是一开始就要注册，而是你想参与互动时（譬如点赞、评论等）才需要注册。但如果产品功能基于用户ID才能展开，最典型的譬如社交类产品，那就必须先注册，否则没法使用。

第三个要考虑的，是用户注册时，在输入框里所要填写的用于登录的账号信息。

是只能填手机号？还是可以填写邮箱？还是系统自动赋予？譬如QQ，就是系统赋予的账号。不过这种一般比较少见，因为用户的使用成本非常高。而密码呢？有字符数要求吗？有特殊符号要求吗？有组合要求以便提高密码复杂度吗？等等。而如果填写错误或未填写，产品交互又是什么？是不能点击注册按钮？还是切换焦点时提示？还是点击注册按钮时提示填写错误？

第四个要考虑的，是用户名与头像、性别。

用户名是否允许重复？可以填哪些数值类型？是否允许特殊字符？最大长度是多少…… 现在很多产品，不允许重名，所以用户只能把昵称填得稀奇古怪的。这就是产品经理没有深刻理解名字的价值的原因所导致的。前面说过，给用户赋名非常重要。用户给自己或他人赋名，这具有神圣的仪式感。但禁止重名，破坏了仪式感的神圣性，让名字的价值大打折扣甚至不再有价值。但另一方面，如果允许重名，却又不便于传播与检索。所以很多产品就禁止重名。这就是产品经理面对冲突的问题时，所做出的取舍。这也是老板们不会考虑，但产品经理不得不认真思考的问题。

至于头像，可以不添加吗？还是必须添加？只能从手机里选取吗？还是可以拍照？图片有什么大小、形状方面的要求吗？等等。性别呢？注册时必填吗？还是可以以后再填？未填的用户，给默认性别吗？因为这个数值常常是与产品的其他功能相关联的，所以产品经理需要做细致的分析思考。

第五个要考虑的，是只需要填登录账号、用户名和密码？还是需要填其他更多信息？还是用户名都先不用不填，系统赋予一个默认值？是在同一个页面完成，还是多个页面分步完成？ 要不要在注册时获取更多信息，也有很多考虑。

这既涉及到用户隐私，又涉及到用户体验，还涉及到产品的价值主张。

一般情况下，资源型或业务型的产品，都会要求用户提供更多信息。产品需要根据用户提供的信息，来做有针对性的资源匹配或信息推送。而且用户是因为资源或业务而来的，目的很明确，预期也很明确。这时候，对平台的信息收集行为的接受度更高。譬如拉勾等找工作类软件，都会要求用户先填写职业信息和职业诉求。

而如果用户是以浏览信息为主，并不构成更多层次的消费行为，那么要求用户填写更多信息，就会构成用户的使用障碍，导致用户放弃。一般来说，用户的使用目的越明确，或产品提供的价值越具有稀缺性，则越容易收集用户的信息。

第六个要考虑的，是要不要验证注册行为，以避免机器注册的情况。

如何验证？短信？邮件？还是验证码？早年常用邮箱验证和验证码验证，目前更多的是短信验证。

第七个要考虑的，是要不要邀请码？

一般情况下，为了激励用户传播产品，或保证用户的质量，通常都会在注册时填写邀请码。

第八个要考虑的，是要不要采用第三方社交账号登录的方式。

第三方帐号登录的意义至少有三个，一是借助用户自己的社交网络，可快速分享传播。二是用户操作简便快捷，体验好。三是用户接受度高。 所以如果是内容型的产品，因为大多数的内容的价值都在分享中放大，所以最好可以允许甚至鼓励第三方账号登录，这样便于用户快速将内容分享到自己的社交网络里。而对于工具型或资源型的产品来说，就没那么强烈的分享需求。这时候要考虑的，就是要不要打造自己的帐号体系与用户体验之间的权衡。

第九个要考虑的，是登录入口。

如果是一个老用户换新手机，重新下载产品，那这时候当然不能再让他注册。所以一般在注册页面，也会提供登录入口。现在有很多产品，为了方便用户，将登录和注册融为一体，通过手机验证码注册或登录。既保证了安全，又提高了用户体验。

第十个要考虑的，是用户协议。

用户协议的价值，是描述产品所提供的服务及禁止事项等，目的就是一个：规避风险与损失。尽量把风险与损失都转嫁给用户，这是绝大多数互联网产品的用户协议里的核心议题。这么做说起来有点不厚道，但这里面确实也有很多的不得已。不过这也确实算是行业弊病吧。

那么用户协议的内容是什么？这个就需要由产品经理清楚的描述产品的各种功能，所涉及到的各种数据与信息。然后律师会据此给出对应的协议，用以规避产品可能面临的各种风险。

当然以上并不是全部，还有很多细节需要思考。譬如如果用户在线上的身份和线下的身份能够对应时，那么昵称和真实姓名的关系如何处理等等。

所以再强调一遍：当产品经理把这些问题都想清楚了，才能给出具有完整的数据结构和字段、交互的原型图。开发人员据此原型图的功能描述，才能定数据结构和接口，才能做开发。而设计人员据此原型图，才能设计出不同的交互下的设计稿。而这一切，都是老板所不会去做也无法去做的。但对于一个产品来说，没有这些基础的功能与交互细节，产品就不完整，甚至有可能都没法使用。这就是为什么老板需要一个产品经理的原因：

• 老板提想法、找方向，定业务，并告知产品经理；
• 产品经理负责理清业务逻辑，将其产品化，并告知开发人员和设计师；
• 开发人员根据产品经理的原型图和设计师的设计稿，最终开发出产品。

作者：笨笨，多年互联网经验，一直在做产品。创过业，对社交网络、内容管理、工具价值等都有深入研究。

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