编辑导读：产品经理在近几年的热度越来越高，成为了很多人继程序员之后最想从事的岗位。但是，任何一个岗位都有其闪光点和辛酸史，产品经理亦是。本文作者总结了自己从事产品经理这么些年形成的感悟，和大家分享。

简介：

“很多人都表示对产品有兴趣，我觉得对产品来说问题在于如何做成一个好产品，而不是去做什么样的产品” 十年老司机：老虎色

最近项目验收，在和业务方做交接沟通发生“博弈”，在激烈的争论后，我松开掐着他脚脖子的双手，他也放下我的袜子，然后友好的协商了下一步的工作计划，我们得出两个结论：

• 基于业务方来说，需求不是提出来的，而是用来解决问题的，能提出来的就不是业务需求了。解决问题，不仅仅说是满足就可以，还要用优秀来评价。
• 基于需求、时间、人力、成本的考虑，用最小的代价去解决问题，是处于大家都认可的情况下得出的结果。没有所谓的一拍脑袋就能够决定的事情，也没有说产品有话语权来决定，而是推进、落地、执行、产出。

如果说人人都是产品经理，这句话是对的，那么能够做一个好产品的人真心不多，很多人需要受困于各种条件的限定，没有足够长的撬棍、也没有足够坚挺的支点，然后就让你去撬动地球，我撬动个锤子。

之前在和一帮产品人进行沙龙的时候，讨论了8个过来的产品人要知道的产品内容：

1. 什么是产品模式
2. 什么是产品
3. 做产品的挑战有哪些
4. 什么人适合做产品
5. 做产品有什么缺点
6. 做产品是一种投入，那么投入和产出之间的平衡怎么定义
7. 到目前为止，你做的成功的产品有什么
8. 对后来者，有什么产品话说

针对这些浓缩的问题，我们也进行的分析和讨论，发现有很多的问题不能够用概括的方式来表达，就像臭豆腐好吃，是怎么好吃？是吃臭的味道还是吃香的味道？是吃原汁的还是要加点榨菜和香菜？不能一句话概况，这样很多的适合是没办法去理解的。

所以基于这8个问题，重新找了一些5-10年左右、经历过创业、在大厂工作过的产品人，再次延伸出以下47个问题。这些问题并非覆盖的很全面，而是针对一些日常应用、大众关心、需进行思考的工作问题进行梳理。

01 我们希望的产品是什么 ？

顾客希望企业的产品能够解决质量、解决速度、解决性价比、解决使用、解决服务的问题。

企业希望产品能够给用户提供解决方案、改变用户的行为、提升用户的认知、带来商业价值（金钱、流量、名利）。

产品经理希望产品是基于自己主导，在企业有限的资源下，交付出性价比最高的，能够解决用户问题，改变市场情况，用户满意的产品。

02 做产品是不是会比其他岗位好？

理想的产品是能一人之下，万人之上的生活，挥手指点江山。

但实际的产品也是和其他岗位的工种一样，针对工作，没有好和不好，只有你当前的岗位工作要求，你的职责要求，你的个人素养要求和你的产出成果。只不过产品会更承上启下一些，接触的更多，了解的更多，成长的更多。而且现在产品经理被市场炒的比较火热。

03 各公司之间的产品有什么区别？

每个公司、每个部门、每条产品线，对应的产品各自不相同。相同的是都是在做产品设计，不同的是有人在做产品规划设计，有人在做产品业务功能，有人负责产品设计输出。

从层级上区分：老板、总监、资深、高级、经理、助理、实习生。

从业务上来分有：B端产品、C端产品、G端产品；前台产品、后台产品、移动端产品；软件产品、硬件产品；医疗产品、电商产品、社交产品等。

从薪酬上来区分：有月薪几千，也有年薪几十万或上百万的。

04 哪些公司会有产品岗？

任何一家公司都可以有产品，任何一家公司也可以没有产品。

有产品：由产品来承接业务需求，做需求归纳，版本定义，需求评审，跟进项目，测试上线，数据统计，迭代等工作。专人专职效果更好。

没有产品：老板/业务方/上级下指令，由各自职能部门去安排做事，其他岗位的人分别代替产品兼职完成对应的工作，一般用于指令性项目和小团队项目，目标很明确，团队协同输出一致就可以。

05 做产品有什么好处？

能够在更多的时候有创新思考的能力，喜欢针对一个流程进行深思，很多的时候能够换位思考去定义问题，喜欢针对问题找准症状解刨深挖，富有更多的创造力和想象的空间。

可以贯通行业中的本质需求，无论是融资还是运营，对外宣讲都能够对答如流；可以有效的促成人际关系之间的沟通，无论是团队还是项目，对内都能够牢牢掌控。

06 产品的瓶颈在哪里？

年龄问题：互联网行业中有一句话，超过35岁就没什么地方要了。可是35岁，正是一个经历充沛、经验充足、有沉淀的时候啊，怎么就被埋没了呢。

业务能力问题：隔行如隔山，我们局外人就是有什么事看在眼里，也是猪八戒吃人参果，食而不知其味。不在一个行业里摸爬滚打三年，根本算不上行业的人，哪怕是基于互联网行业的应用，少于一年的时间，你也是个门外汉而已。

思维问题：年纪轻说办事不牢，年纪大说思想陈旧，我也很为难啊~如果你没有话语权和决策权，那么你永远也想不到老板是要什么，只能一边听一边去改，然后重复劳作。

再上进问题：做产品就要持续的学习，要不断的给自己增加内容，产品本职是产品思维与产品设计，协同管理还要有项目管理和人际沟通，为了扩充新的知识还需要学习行业知识和心理学。

07做产品是不是必须要懂技术？

这句话真正的含义是：你要不要做一个全栈工程师，既融资-路演，市场-调研，运营-数据，产品-思考，设计-交互，研发-代码，测试-逻辑，上线-讲解，用户-体验。拿得起放得下，上得了厅堂，下的了厨房。

如果你能多懂一些其他的内容，那么在对话沟通的时候会更好的和别人融合。当然，如果你不懂，那么你把自己本职的工作做好，那么也可以。只要不是你又不懂，然后还要嘲讽别人，就行。

08 大厂和小公司经理有什么区别？

大厂：专人专职，一个萝卜一个坑位，你在大多数的时候只需要专门的负责好自己的事务，还要各种开会，对接好上下游就可以了。在大厂，你可以更加稳定的去做产品，有更多的经历投入在产品的生活中，并且还有“标准”的规范来约束你，还有各种人才可以协同完成解决方案。

小公司：记住找产品这三个字就可以了。需要出个方案-找产品。这个需求按照现在的情况实现不了-找产品。下周要去做个宣讲-找产品。外围接口对接谁联系啊-找产品。这次团建去哪里啊-找产品。在小公司，你需要做到全能，需要更多的发挥你的个人能力去搞定各种事情，小公司没那么多的规矩，一切以目标为导向，能干，能干好，那么你就OK。

09 普通和优秀的产品区别是什么？

一般性的区分从工作年限、工作场地、薪资来区分。

有思考的区分会从底层开始区分，同样一件事情，你所对应的定义是怎么理解的。

• 针对场景定位-优秀产品
• 针对客流理解-普通产品
• 针对价值定位-优秀产品
• 针对收费理解-普通产品
• 针对用户细分-优秀产品
• 针对功能理解-普通产品

10 技术型和管理型产品有什么不同？

技术型产品更看重你的业务能力，主要负责解决问题，对内沟通、协同；对外宣传、输出。做技术型产品，有核心的业务能力，基本处于公司的核心团队内，属于不可或缺的人才，属于标准的中流砥柱，在获得老板的信任后，可以独立带线，获取更大的资源。

管理型产品更看重你协调能力，更多精力在于人员管理、定位、方向、汇报。更加贴合公司和老板的需要，因为和上层走的更近，所以自身的优势比较多一些。而且管理型产品，会有较多的人力资源可以管控，所以很多的时候，站得更高看得更多。管理型人才大多数会在公司呆个3-5年以上，会由低中层进入中高层，虽然技术能力可能提升不多，但人脉、关系、资源会提升很多。

11 让老板来当产品不行？

行，没有什么是不行的，毕竟人人都是产品经理。但做一个好的产品出来，还是很为难老板的，毕竟不是人人都是乔布斯、也不是人人都是雷军、更不是人人都是张小龙。

产品要对整个生命周期进行负责，不能只提出目标和要结果，过程要梳理、要跟进、要落地。

使用MVP是有根据的有计划的去做，去实施PMF落地，而不是拍一拍脑子，干就完了。

做产品要负责，要担当，要懂得取舍，要有数据支撑，不能当甩手掌柜。

12 做产品要会哪些技能应用？

工具：Axure、幕客、墨刀等，至少确保一个是常用的。Xmind、Word、PPT、项目管理工具要熟练。

沟通：看企业使用钉钉、微信，还是内部自研的沟通，但要有存放文档、会议邀请、在线会议等常用功能。还有一张灵巧点的嘴。

思考：幕布、语雀、石墨文档等可以用来做规范归类的应用。

学习：脑子、输出的笔记。

13 做产品应具备的商业化指的是什么？

首先要了解下什么是商业化：将你的产物以一种应用/服务/售卖的方式投入市场，消费者支付费用，给企业/个人带来利润，并且可以持续盈利。

其次要定义当前的产品有哪些点可以商业化：金钱、用户信息、流量、实物、广告、品牌、知识产权、服务、内容、灰产、技术等。

同时还要决定在什么阶段去做商业化：预收费、实际使用、后付费、附加值、其他转化.

最后是确保产品的优秀性：知名性、广泛性、易用性、时效性、实用性、持续性、服务性。

14 新人能做产品吗？

能，所有人都能做，只是你能做到什么程度还不太好说。

不要迷信你有个创意性的想法就能打造出一片天地，也不要相信加油没问题你能行的，更不要觉得这个很简单我也能搞的出来。

作为新人，熟练掌握产品技能，了解行业知识，能够顺利的推进项目进行，这就是基础的三点内容。

15 无行业经验能做产品吗？

能，别说没有行业经验了，就是你没产品经验也一样能，同样还是你能做到什么程度还不太好说。

比如说医疗行业，如果你不知道行业规则，那么就很难切入到行业中去。关于临床诊断描述，一个字的偏差或许就是另外一种情况。所以很多公司在招聘时，会喜欢要在行业内做过的，这样有经验会更好的融入业务中，可以进行平等“对话”。

16 如何快速融入一个行业，成为内人？

所谓的快速融入，其实没有什么取巧的办法，在当前你所能做的就是用自己的其他优势去弥补自己的缺点。

然后就是跟着销售出去跑客户，在实践中锻炼。找到公司的前辈去询问之前的逻辑。去背熟公司的业务手册。出错要反思，要记录，要攻克。

多学多背多实践，就是最好的成长办法。

17 产品需求经常变动，控制不住怎么办？

首先看变动的来源：是因为老板/业务方进行需求转变，还是项目落地后发现预期效果不理想，或者是市场上的风向变了。如果是后面两种，那就是需要用MVP的方式去做敏捷开发，这个是没办法的。但如果是第一种，那就是需求把控的问题了，不能来了需求就接，接了就要做。产品要做的第二步事情是需求整理归纳，第三步对需求进行产品设计，第四步是定义排期。

其次看变动的原因：如果上面能控的住，那么这里就是按照正常的流程走就可以。如果控不住，那么就要考虑最小改动的成本，以达到节省的目的。其实还要看第一步在接收需求时，对其真伪的判断，真需求一定要触发核心点来满足，伪需求可以通过其他方式来解决。

还有就是看变动：马上改，和延后改是两种结果，不光要看产品的决策权，还要看产品对需求的把控能力。能卡在需求设计前解决的变更一定是要在前面去搞定，真的是要了必要变更的时候，那么要尽快的梳理好解决方案。背锅不是问题，转变为执行力也可以。

18 做产品如何确保团队的进度？

普通的产品经理会日日跟进进度，询问过程，提前最好预备方案，去撒娇卖萌和其他人员进行沟通，确保准点无误的交付。

优秀的产品经理会讲故事，会带动团队自主跑步，用情怀去解决问题。

要规范好人员职责和时间进度表。

要确保各节点接收信息通畅，各节点直接对流流畅，各节点能够完善交付。

要向上管理好你的领导，没事跟着他后面溜达溜达，有事需要推领导出来镇场子。

19 如何用MVP的方式去做产品设计？

MVP是指最小可行性设计，那么基于应用点场景需要砍掉很多的流程。比如健身房购卡消费的流程，需要包含用户注册（第三方）、选卡（单卡）、支付（对公账户）、收到验证（短信）、使用（卡号）、查看（有效期）。基于这个流程去做最小的简易操作，舍弃掉大量功能，仅保留一个“最小、可行”的产品方案。

20 如何用产品思维去做产品设计？

产品思维是指基于互联网的大众需求、多样化、轻量级、易用性为前提去做解决方案，所以这里考虑的问题绝不是一对一的概念，而是1+1＞2。

电子阅读中，如何加强用户的阅读体验？通过翻页时的声音提示，通过翻页的效果，通过全屏式的效果，给用户带来沉浸式阅读体验。同时，改变背景冰冷的颜色，替换为纸张感觉的暖色，带一点花纹和倒影效果，这都是从用户感知得到的结果。还有就是设定免打扰模式、长按选择、下划线、分享、阅读时长等这些都是基于用户需求得到的结果。

为什么我们有时候会说这个产品做的不错，就是这个产品细节打磨的很好，考虑到用户所考虑到的需求，定位用户所处场景所需要解决的问题，还有一个关键点：核心一定是优美的，其他都是辅助性的提升。比如微信的购物功能做的很好，发文件可以发很大体量的文件，支付也很便利，但就是对话过程不怎么样，那么你们还会去用微信吗？

21 身为一个产品如何确保业务需求？

一般来说，需求来了，正常接纳，需求分析，产品设计，计划排期，跟进研发，交付结果，查看反馈这一套流程下来基本就足够了。

但在很多的时候，产品会被问到：为什么我们没有Saas模式；为什么别人可以自动语音转文字；为什么别人的页面可以自适应大小；为什么这个要求要一个月以后才能上线。

此刻只回答一句“因为爱情”那是不行的。首先产品一定要有一个需求池，在这里会融合大大小小的业务需求、需求来源、需求优先级、计划排期。然后还要有一个当月、季度、半年、年度、三年的规划，在这里要按照北极星指标去做执行。最后是结合业务需求、市场需求、用户需求、资本需求，不断再优化和迭代目标，最终达成业务需求的完善和满足。

22 你就是个工具人？

初阶产品0-1年，1-2年左右，其实真的就是个工具人的概念，在大多数的时候，就是去做执行，一直写文档，一直画原型，一直要去做执行的命令。

但如果你是到了3年左右，那么你就要有独立思考的能力。当然这里我们不是说前面2年就不需要思考，而是在实际的工作，更多的是看你的执行能力和你的软件掌握能力。

所以刻意去锻炼产品思维，是一个很重要的提升自己的能力的方法。比如我现在坚持每日小思考已经坚持了近1100次。

输出：前面两步完成后，就是要强化自己的表达能力，需要把内心的想法表达出来，通过语言、文字、图形等方式“告诉”别人，让他人能够理解你。

学习：听专业的课程，看书，跟着大佬学习，与别人进行深入的沟通，这都是学习的方法。

观察：在日常的生活中，观看生活的细节。看同样的一件事情，别人是如何思考和解答的，还有就是基于不同的场景、层次，回答的内容有什么不相同的地方。

23 什么是产品智能化应用？

当产物遇到互联网，就变成了互联网+。当产业遇到了大数据，就变成了智慧应用。那么基于物联网、互联网、大数据、人功能智能等技术进行综合支撑的，所具备的产物会超越用户需求，超越市场需求去满足各种问题，所带来的产业服务就成了智能化应用，而这个前提是有一个“产品”来承载。无论这个产品是短视频基于算法推荐，还是电动汽车具备无人驾驶功能，或者是智慧城市的应用。

严格意义上来说，所有带上智能属性的硬件产品，都能算是智能硬件产品，大到智慧城市、智慧医疗、智慧交通，小到智能电视、智能手机、智能APP等。

这里的关键有两点：

• 大数据：通过结论得到数据，通过数据分析背后的扭转逻辑，通过数据结果去改变产品或改变用户或改变市场。
• 代替人工：把原来用人进行机械的操作变为用电脑去识别、交互、应用。

24 什么时候需要把产品做到极致？

按照产品生命周期，需要在第二个阶段-成长期，打磨极致的产品设计。第一个阶段是需要把产品落地，让产品基于市场、需求先诞生出来，在这里会反复调整方向，会在不同的赛道进行探索，同时还要有序的规避，避免浪太大。在第二个阶段：经过市场打磨，用户深耕后，进行精细化操作，这里不断的版本升级，就是为了优化用户体验，增加用户粘度，做数据增长。

按照用户体验来说：在开始打磨产品时候就要考虑极致的概念，非必要性的应用，如果连流程都不通常，界面也不美观，那用户也什么停留的必要。你不是12306-必要性，也不是微信-用户群体效益，更不是拼多多-有钱，你只能在每一步都要慎重的考虑，既要大众化、又要小优美。

按照用户体验来说：在开始打磨产品时候就要考虑极致的概念，非必要性的应用，如果连流程都不通常，界面也不美观，那用户也什么停留的必要。你不是12306-必要性，也不是微信-用户群体效益，更不是拼多多-有钱，你只能在每一步都要慎重的考虑，既要大众化、又要小优美。

25 做如何保证业务需求和功能实现同步？

做产品的一个重要能力就是要会把握平衡，因为在很多的时候，我们不得不面临着已经谈好的需求要被更改，已经商议好的排期会被压缩，已经正在做的项目被抽走人手，原本是你要花100块钱买10个雪糕，等你回来时候，你只带回来了4个老冰棍和3瓶矿泉水。

怎么办？怎么办？很多的时候是不知道要怎么办？

需求设定时，针对每个需求就要保证完整功能和核心功能两个方向的定义，同时还要有对应的优先级，一旦发生意外情况，先保优先级高的，然后在保核心内容，其他的该砍就砍，此刻不需要心软。

另外产品经理要有自己的话语权，你要能够决定哪些能够上，上了就要去研发，研发了就要落地，不能一个命令下来了被动的去执行。即时不行，也要去争取，最少在表面上，你把样子做出来，后面的人也看得到。可以多次不成功，这个不用担心，正常的事情，但只要成功了一次，那么你就可以以此为台阶，让自己上升一个高度。

26 当需求很多时，如何排定优先级？

当你早上要去上班时，你选择开车还是坐地铁，是不是要先考虑下今天是不是周一早上会不会堵车？这里就是你要做一个选择的判断。那么同样，针对需求，你也要根据实际的业务场景来进行判断，当前需求是不是很紧急，是不是到了必须要去制作的情况，是不是已经阻塞到了用户的行动，是不是影响到了系统的运营，是不是给公司的盈利造成了困扰。只要有一条是，那么就需要马上去解决。

在很多的时候，我们没那么多的精力使用kano模型、需求四象限来进行定义，那么就可以用波士顿矩阵来进行一个定义区分，这样既简单化，又有一定的依据。

27 当你去做改变时，是给用户做加法还是减法？

我们在做需求时，其实大多数都是去增加需求，但这个增加的需求是否能减少用户的应用流程，这是定义需求是否优秀的一个标准。

原本一个小区有5个快递柜，现在都统一使用一家公司的系统，但系统更换时，原系统已发出去的取件码不能被新系统识别。

加法：用户来取件，输入原取件码，系统提示“系统已升级为XX，取件码错误”，需要让用户点击忘记密码，然后输入手机号，输入发货单号，系统进行校验，匹配成功后，重新给用户发送一个验证码，用户输入后，取出快递。

减法：用户来取件，输入原取件码，系统提示“系统已升级为XX，请输入手机号”，系统进行校验，匹配成功后，自动打开柜门，让用户取出快递。

说明：不同系统之间的合并，是要校验用户信息、取件码、系统三者吻合，那么就不同系统的合并后，需要通过取件码先去识别对应的原系统，此刻已能够匹配到用户信息，用户只需要输入一个校验，新系统识别出信息吻合，就可以给出正确判断。不需要让用户在去手动操作校验，安全性的提升在于内部的逻辑转化，用户拿着取件码来取件，此刻是已带着手机过来，在做一步手机号校验对于安全性提升的需求也没有那么的强烈，所以这一步可以减去。而且快递柜都有摄像头，发生偷窃的情况也很好查找。

28 产品和项目的区别是什么？

首先我们要明确一个事情：两者之间既互补又不和，可相互兼职但又是独立存在。

对于一个产物：

• 项目经理：有个就行，别管是亲生的还是领养的，早点独立早点走。
• 产品经理：我要亲自生一个孩子，从生的过程，富养成人，还要看着长大，买房、结婚、生娃，直到老去。

对于目标：

• 项目经理：甲方就是爸爸，爸爸你好。
• 产品经理：市场、用户就是上帝，上帝说要有光于是就有了光。

对于交付：

• 项目经理：好了，满足了，上线。
• 产品经理：调研、需求、设计、研发、测试、上线、迭代后进行交付。

对于变更：

• 项目经理：请走流程，请递交审批，请重新评审。
• 产品经理：哥吃饭了吗？姐一起喝奶茶吗？在给改一个呗？我保证，这真的真的就是最最最后一个了。

对于职责：

• 项目经理：规定的时间内，一定的可调配人员，完成对应的任务。
• 产品经理：用户体验、市场需求、商业化、价值产出。

29 为什么不能以项目制去管理产品？

结合上面说的内容，我们知道项目是以交付为前提，一个事件就是一个项目，在当前的时间中会有多个角色，一个角色完成后释放出去，内容转移给下一个角色。但对于产品来说当前团队的人员是固定的，针对不同的角色，在对应的排期内都有不同的任务分配，不可能等一个版本完成后然后全部重新开始。

项目一般要求较为严格的规范流程，要有完善的业务流程、规范的人员排期定义、严格的变更流程、以及定义好的交付时间。而产品在很多的时候都需要进入敏捷开发的模式，在各种阶段要实时解读市场进行灵活调整，这也是产品人经常和其他职能部门产生冲突的主要原因。

30 产品不方便监管项目的原因是什么？

其一：产品是一个没有实权的角色，产品是从创意进行产出，由其他部门辅助进行完成结果的输出，不然单纯就一个产品想法，如何能够落地呢。所以产品管项目有名无权，很难办。

其二：项目管理是确保人人有事做，事事有安排，安排有结果。如果是从产品的角度考虑，那就是把人圈进来，然后深度绑定，即使当前没事，也要为下一次做好准备，很忌讳临时抽调人手去解决，因为更换人手后还要重新交代前因后果。

其三：基于拓展市场需求，基于抢占市场资源，利用平台进行软件的快速开发，一般使用敏捷思想作为指导，力求功能完善、使用便捷、价格适中，以期解决信息化建设中的实际问题。这里会舍弃很多标准化的流程和规范，以速度为优先级去处理，这讲究违背了项目管理的要求。

31 产品经理代替项目经理有何难处？

这个问题和上面的问题类似，项目经理要懂些技术，要能够了解每个人的水平如何，和产品经理的区别在于可直接指派职能部门人员进行管理，而不是协商。

项目经理是根据任务去做导向输出，对应目标是以交付为结果；而产品是要在业务输出的过程中反复去打磨。

做管理最大的困难不是解决问题，而是发现问题。项目经理恐怕最大的体会就是要按计划执行，可以多多少少都有偏差，但基本都在可控的范围内。作为项目经理，一个从整体角度确保项目的角色，最重要的工作就是发现偏差、判断偏差的影响、确认变更内容、用稳妥的方式确保变更被导入。而产品较难去把控住这点。

32 项目中没有产品，会不会带来额外的负担？

话说，在公司没有谁都可以，只要有老板在，所以不存在什么主观的理由，如果一定要找一个理由，那么：这个我也可以兼职做下，只要钱到位，没什么是解决不了的事情，如果不行，那么请付我双倍薪资。

前面我们说了老板是不是产品，其实也得到了一个可以适用的理由。那么市场、运营、UI、前端、研发、测试这些其实也可以做产品啊，只要有一颗能够思考的心，能够基于产品的角度去考虑、能够以市场/用户的视角去看待问题，那么产品也能够做出来。正所谓人人都是产品经理，这话是没有错的。

或许这些人做的不够好，也许这些人会比专职的产品经理做的更好，事在人为，没有什么绝对的事情。负担，要看压在谁的身上了。

33 如何确保产品经理在团队中的位置？

先说不好：没有什么职位是取代不了的，只是现在有这个岗位需要，而你又是性价比合适的人。我们都说离开了舞台什么都不是，因为你站在了公司这个舞台上，舞台给你曝光的机会，若你自身不能发光，那么你还得靠舞台的灯光照亮你。所以，拥有专业的技能经验，拥有丰富的行业经验，拥有良好的管理经验，拥有和善的沟通经验，是确保你在团队中稳定的基础技能。同时还要学会思考、学习更多的知识，还有站队。

然后再说好：作为管理，是跟随公司做方向指引的人，奔着北极星指标而去的人，其他的职能部门在一定的约束条件下都需要按照你的定义去行动。你可以在一定的情况下按照自己的喜好去设定产品，并且要求职能部门按照你的规则去做定义。当你成功时，黄袍加身，光芒万丈；当你失败时，不要紧，再来一次。

34 如何确保产品经理的人身安全？

身为一个产品，还要考虑人身安全，这不存在的~你要是欺负我，我就哭给你看~

玩笑归玩笑，当产品一定要会开车，调节下气氛还是很不错的，但正儿八经的时候还要要拿能力来说话。像什么手机壳变色，不用学习就能够上手的操作这类地东西没有实际的铺垫，就当玩笑说说算了，非要较真做出来，那也得有理有据的说明，不能空口一句话。

通过讲故事，将其他职能部门的人带入到当前环境中，告诉他们来龙去脉，让他们理解事件的过程，并且加上一些基于思考的想法。沟通最好的结果是双方就问题探讨，然后得出一个达成共识的结果，而不是最后打成一片。

35 产品可以不管技术实现吗？

当然“不可以”，做产品是要懂点技术的，要能够简单看懂点代码，要知道一些技术“名词”，还要了解点新旧技术的应用。

产品人在要求需求时，不是说要定义“现有技术人员技术边界和惯用实现逻辑”，而是考虑技术边界和逻辑的技术实现成本和收益之间的关系。不能为了当前团队技术不行砍掉合理需求，也不能为了实现复杂需求完全不考虑技术成本。所以理论上来说，产品经理在设计产品时，只需考虑产品应该考虑的事情，比如用户需求和公司业务两者的权衡。但是这只是理论，在实际情况中。

一般来说，都是要去考虑技术的实现逻辑的，这样你才能够知道这个设计有没有性价比、需要怎么做、做这个东西需要花费多少资源、这些都是需要产品去考虑的。而且，如果你设计时，提供了技术实现逻辑的话，无论合理与否，开发同学们都是更愿意和你沟通交流，这样久而久之，就能产出更好的方案了。

36 关于选定哪种技术，产品能说了算吗？

这个当然不能，这个问题和上面一个问题从本质上来说是反向的。专业的事情要交给专业的人来做。

如果这个问题是由你来定义，你当然可以说明白。但如果这个区域不属于你的范畴，那么专业的人会用他的思路去帮你解答和完善。

37 是不是能力很强的产品经理价格都很贵？

看地区、看行业、看公司、看个人、看运气。

如果是在超一线城市，金融/人工智能/独角兽，世界500强公司，做过一线产品的10年真正大牛，年薪弄个50万不成问题的，好的能破80甚至100。

如果是在三四线小城市，常规的行业，公司一种佛系的生活方式，只有三五年水平，且能力一般的产品，年薪十来万也大有人在。

在什么地方，做什么事情，你处于什么档位，这都是相对平衡的标准，当然也有凭运气好，入职早，能够升级的，但这毕竟是少数人。

但有一点是需要肯定的：如果一个产品的能力很强，那么他一定会向上管理，他一定能够洞察到行业的风向，他一定能够用强有力的业务能力去管理团队，他一定能够有自己的价值衡量标准，也能够体现出自己贵的道理，毕竟能够用钱来解决的都是小事。

38 如果要优化掉一个产品经理，可以用什么办法？

让其他人代替掉他的职位，不给他新的产品规划，更换他的岗位职责，谈走人。可以用的办法太多，没什么是绝对的事情，一个岗位而已，哪怕是你站在核心层里，该被替换的时候一样会被替换。

当公司不需要你的时候，任何的借口都可以成为你离开的理由，无论是N+1还是直接被开除，到了这个时候，是你就是你而已。

同是产品人，何必为难自己人。这个话题打住吧。

39 当你需要背锅时，你要怎么办？

情况1：没办法的时候，只能推产品出来，因为你没有规划好，因为你没有把控住需求，因为你不懂业务逻辑等各种原因，导致产品失败，导致项目不成功，导致公司亏损，所以需要你起来承担这个责任。怎么办？其实这个时候没有什么怎么办，要么就走，要么就只能承担，不管你是不是刚来，不管你是不是接替了别人的位置导致，不管其他的什么理由，你此刻在，那么就是你来顶这个事情。

情况2：承接责任，立场转变。有能力的人从不怕背锅，他们思考的是这个事情我如何解决掉，而且要把这个事情转变为给自己上升的加分项。就像我在前面的公司，接手一个离职A交给离职B的2页文档，里面告知了两年的工作内容，还有一个延期了一个月等着上线的需求，外围部门没有资源，内部知道这个项目的人都走光了，此刻你的决定就是影响你个人发展的决策点。当你干完了这一票，以后再遇到这样的事情，你就有经验了，就能够调整更大的难度，也能赢得更多的信任。

40 研发出来的内容，不是产品评审后的东西怎么办？

对于擅自修改需求的时刻，要做出理性的判断，不要直接一棒子打死，其实很多的时候还是可以区分一下的。

• 如果是无关大雅的内容，比如按钮从左边移到右边，那在一定的程度上是可以理解的，并且此刻也可以做个AB测试，进行试探。同时，还可以和相关人员进行探讨，为什么需求评审时没有提，为什么制作过程时不提出，为什么内部测试后不反馈，为什么直到最后才告知产品。
• 如果是涉及到大的业务改动，这没有商量的余地，产品的业务需求是经历调研、分析决策下来的，不能是因为某些人员觉得不符合自己要求就可以进行变更。
• 如果是比之前改得更好，改成了更优的方案，那么当然欢迎。很多的时候都是在制作的过程中发现更好的解决办法，这个我们当然欢迎。

这个问题的关键点在于：无论是哪种情况，产品要第一时间知道变更情况，以便做出决策，并且对给出的结果要了解情况，不要打乱了自己当前的计划和后面的排期计划。

41 老板、业务提的紧急需求如何处理？

收到紧急需求后，马上接收，并且马上进行分析，并且马上做出紧急程度的判断。

产品此刻要做决策，是不是马上要去做，如果做完能有什么影响；如果不去做会带来什么后果。

识别判断，识别判断，识别判断，再三强调这一点，接收一定要积极主动快速，然后决定什么时候做，怎么做。

42 在传统企业做互联网产品，受到的阻力会有哪些？

这个问题可以理解为标准的项目管理制度和敏捷开发发生冲突时如何打架。传统企业的模式相对规范，需要汇报，需要决策，需要论证依据，需要看到投入产出比，相对走得很稳当。而互联网产品的应用就是使用快打的方式，发现了就要马上去想解决方案，针对多个方向做业务输出，一旦发现有利润点，就要投入加大资源做产出。

• 在传统企业，要学会排资论辈，要讲究领导关系；
• 在传统企业，要学会汇报，要会说，会写，会看颜色；
• 在传统企业，要学会放松，要等待，要按照命令去做事；
• 在传统企业，可以有更多的时间去认真的思考，有强大的资源做后盾，有实际可以落地的市场做应用实验，有很多有才华的人可以跟着你做智囊团，有犯错的机会。

43 相对传统企业，在互联网行业做产品有什么好处？

如上题，在传统企业做不行的地方，在互联网行业都行。

你能够去做打破传统的事情，你能够去突破想象去做事，你能够做跨越当前层级的事情，只要你敢想，你能说得出来，那么公司就能给你安排一帮大牛做支援。

互联网行业有着较大的压力，日常996就是标配，遇到紧急的项目何止007呢？但换回来的不止是金钱上的奖励，还有你的行业经验和能力的提升。

如果你觉得在一线城市买房没有指望，那么你入去人工智能、金融等独角兽企业中，一个试点成功，复制出一片可以做事的点，然后融资，然后上市，然后实现人生自由。最简单的一个例子：拼多多在2020年市值超过1000亿美元，只用了5年的时间。

44 学习PMP是否对产品经理有帮助？

产品经理里很多的知识和内容都是从项目管理中诞生出来的，像我们常提到的“四象限法则”、“头脑风暴”、“亲和图”等，这些产品所需要的应用，项目也一样能够用到。产品经理要做的市场调研、产品定义及设计、项目管理、产品宣介、产品市场、产品生命周期管理等方面的工作。而其中如你所见，项目管理也占到了重要的一环。

既然两者是相互相同的概念，那么学习一下PMP还是很有帮助的，而且有张证书也不错，只是相对于实际的工作，PMP的某些标准模式并不适用而已。

45 产品经理需要考什么证书？

普通话？四级？认真的考虑了一下，产品经理有GPST认证、CPM产品经理认证、GPST精益产品经理认证、还有北师大新闻传播学院产品经理硕士专业，国际TRIZ学会、软考之类的，这些都可以看下。

证书，相对产品经理或者对其他岗位来说，都只一个证明，证明有认证学习过，并且经过测试符合了要求，是属于自己的一个加分项。但产品经理目前大多是培训学校出来，经过几个月的培训，用通用理论+实战项目，帮你在较短的时间给塞进去一堆的知识，帮助你尽快的进入到这个岗位中去，然后你自己再逐步的消化和吸收。

46 为什么互联网公司招聘那么多高学历的产品实习生？

这个其实是很多公司的定义标准，越来越多的公司都需要高学历的人，每个公司都会有人才储备的计划，希望从新人里提拔出一些“先锋”或者“未来的将军”，这就是管培生的由来。

现在的互联网应用，不但是一个产品负责全面的产品管理，而是对产品进行各种节点的拆分，这里就需要大量的人手来处理业务逻辑。正常点的情况下，一个5年的高级产品经理，可以有效地带动几个新人分别去处理几条不同的产品线，而这当中只需要半年到一年左右的时间。但这里有一个要点：大部分经过高学历的人都有比较好的学习能力、较强的逻辑能力、良好的精神，并且沟通能力比较好，也会接触大量新鲜的事务，会有同理心。对应公司的：可塑性高、踏实稳重，自然就是性价比高的选择了。

这里没有在歧视学历的问题，我自己也是低学历，但我当年是有能力就能干，能入老板的眼，肯吃苦，就有上进的空间。现在学历则是一道门槛。

47 为什么很多的产品喜欢做创新？

先问一个问题：如果产品人员在为“已完成的产品中提出一堆的优化改进问题”和“在一个新的行业领域中做创新需求应用”中选择，大多数产品人都会选择后者。当然，产品人不一定只有一个选择，但如果是对现已存在的产品优化是下一步，那么就不要指望他们有很开心的笑容和很高的效率。

做创新，能够带动起一片新的天地，产品人都有一颗不屈服的心，舞台足够大，那么我就要足够闪亮。

去维护别人的事情，做好了就是你的本分，做不好还要背锅，有点难。

以上的内容，就是联合数十位大厂的高级产品、业务专家共同商讨定义的内容，我们保持着简单、易懂、通用的原则进行内容梳理，并且尽量使用口语化的表达方式，让各位能够快速的理解内容。

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

题图来自Unsplash，基于CC0协议