WWDC2016 将会有哪些新内容？这是我们的预测
06-18
作者：李光 腾讯产品规划 写这篇文章的初衷是为了总结一下我从业务运维岗位转入产品狗后发生的事情产品经理的职位。半年多从头开始的痛苦经历。
同时，作为一名产品新学员，对于产品经理这个职位以及如何做2B产品也有了一些理解和思考！如果把这篇文章看成是一个产品需求，那么这个需求中的角色和场景是什么？对我工作半年多的新产品同学的回顾和总结。积累了几年的工作经验，想转行到非产品岗位（比如PM、开发、运维）。
通过这篇文章你可以了解到产品经理是做什么的？需要什么能力？如何做好产品经理的工作？ （建议阅读全文）对于0-1岁的新产品同学，我们可以互相确认、互相学习、互相交流、互相提高。从这篇文章中，你可以了解新产品经理的成长之路和陷阱，无需任何人指导。
也许它也可以帮助你绕过这些陷阱！ （建议在路上阅读本章）有C端产品经理经验、刚刚进入2B端产品的同学。你可以通过这篇文章了解一个新2B产品经理对2B产品的理解。
也许这些小点可以帮到你！ （建议大家一起练习2B章节）先简单自我介绍一下。加入鹅厂后，我一直在手Q的业务运维岗位，负责手Q的产品运维。
据说这个职位接触产品最多。场景是，由于活动和产品功能引起的资源需求问题，应该和产品经理PK。
在调职之前，我对产品经理这个职位的理解其实很不清楚。去年下半年，中心尝试组建团队，做外部运维产品。
目标是让智云这个我们内部打磨多年的DevOps最佳实践平台走向全球（团队成员全部来自业务运维岗位），一下子就变成了产品狗。那时我以为自己没吃过猪肉，也没见过猪跑。
毕竟内部的操作系统我已经规划好了，也熟悉了运维所用的操作系统。后来的经历充分验证了无知者无畏这句话！ 1 这里我们先按顺序澄清一些基本概念： ● 什么是产品？产品经理到底是什么？ 2B产品经理的价值是什么？产品经理的工作内容包括哪些？产品经理需要具备哪些能力？产品团队的角色是什么？ 2 产品是什么？产品是指能够提供给市场、供人们使用和消费、能够满足人们一定需要的任何东西，包括有形物品、无形服务、组织、概念或者它们的组合。
是不是觉得有点抽象？这句话的关键词是市场、使用、消费、需求。就日常生活而言，每天路边买的热干面都是产品，腾达12楼的包子也是产品。
它们还满足我们吃饱的需要。同样，手Q、微信也是满足我们沟通、连接需求的产品。
3 产品经理到底是什么？ （产品经理）产品经理这个词其实是一个比较宽泛的术语，具有一定的行业属性。这里所说的产品经理的定义，特指IT行业或互联网行业中的一个职能，负责IT（互联网）产品的规划设计、生命周期管理。
这句话的关键词是规划、设计、管理。 这是书上介绍的《启示录：打造用户喜爱的产品》 产品经理的主要任务是探索产品的价值、可用性、可行性。
以前看到这句话的时候，我不太理解，但现在回想起来，我完全同意。这里我再多说几句。
产品经理这个职位本身就有矛盾的属性，加上经理这个词，感觉就应该有权利。事实上，毛贤根本没有任何权利！ 1、行业进入门槛低。
与业务运维岗位相比，该岗位没有太多刚性的技能指标，但真正上手并做好却相当困难。以往，经过与同行的交流，新同学入行后基本存在三大问题。
、产品思维、做产品的能力、对行业产品的感受。其中，做产品的能力是比较量化的指标，而产品的思考和感受则有点难以量化（每个人的解读可能不同）2、也有人说，每一个产品经理都是潜在的CEO（乔帮主、小马） 、雷军等行业大神），但同时他也是全能的替罪羊，毫无盲点地背锅。
4 2B产品经理的价值是什么？一般来说，谈到价值的时候，就会出现各种大词。我这里就不用大话了，而是接地气地描述一下。
笔者认为，产品经理的价值可以用一句话说清楚。帮助你服务的团队（公司）设计（进化）出能够满足用户需求的正确产品，并直接或间接赚回真金白银。
是不是感觉有点粘？但这就是产品。如果设计和实施的产品不能直接或间接帮助赚钱。
所以这个产品实际上是失败的。卖不出去的馒头就留在库存里。
那么这些包子并没有创造出应有的价值吗？这句话的关键词是设计（进化）、满足、需求、正确性、赚钱。 5. 产品经理的工作内容包括哪些？根据我对产品经理岗位的了解以及这六个月的主要工作，我把产品经理的具体工作内容总结如下，其实就是一个产品实施的主要步骤（线性顺序）。
1、市场调研与分析：主要是大商业环境的调研与分析？蛋糕够大吗？这个量的蛋糕能放多久？蛋糕可以做大吗？目前行业内的重量级选手有哪些？有哪些成熟的商业竞品？谁是我们的客户？这些客户有哪些共性、细分、潜在需求等？这部分对于刚入行的产品经理来说其实是有一定难度的。感觉无从下手。
印象中我们也是用了兄弟部门成熟团队给老板们做的汇报PPT，然后按照葫芦画瓢拆解出来的。 。
尤其是涉及到大规模的环境分析，如果没有BI团队的介入，基本上是无法处理的。即使可以参考一些行业数据，也无法保证其有效性和准确性。
2、产品规划：规划产品的定位，确定用户群体的分类（谁会使用）？如何使用？ （场景），这部分一般输出产品功能图（思维导图），解释清楚就够了。 3、产品设计：定义产品体验和价值，设计产品结构和功能。
在这一部分中，输出整个产品（功能）的原型设计。这里通过原型展示了整体的产品体验和功能点框架。
建议尝试输出具有基本交互的高保真产品原型。这样会让内部审核更加清晰，也可以减少后期和开发兄弟沟通的成本。
4、需求文档：描述与原型一起组成功能集的详细需求的文档（TAPD），可以让开发兄弟提供他们认为最容易理解的结构，产品经理可以填写内容。 5、需求实现：与开发同学紧密配合，完成需求的开发和上线。
6、产品验收：开发自测完成后，由产品经理进行主要功能的验收。这里的主要目的是检查业务逻辑是否符合产品经理的设计。
至于产品质量，这里暂时不考虑。这个水平主要是通过测试和开发来保证的。
7. 用户手册和场景描述视频：用户帮助文档。这部分用户文档实际上可以分为产品手册和典型场景文档。
典型场景文档是产品手册的子集。但从后续的交付情况来看，用户基本不怎么看文档，所以我们还录制了场景使用视频，方便用户使用。
8、迭代优化：收集分析用户反馈，探索优化点和新需求。迭代、优化、升级产品。
6产品经理需要具备哪些能力？根据上述产品经理的主要工作内容，我们基本可以勾勒出一个产品经理所需要的能力，3+N能力模型，3个核心能力+N个基础能力。1、能够使用Axure RP（产品原型图）工具进行写作，能够在整个产品设计和实现过程中，针对不同的人、不同的角色，把事情讲清楚、透彻。
能够在介绍用户时讲述用户故事，并使用户故事更加丰富。能够编写团队成员和用户可以理解的文档。
4、了解设计和交互，避免设计反人类的交互流程和更好的页面布局。 5.了解技术。
这并不意味着您必须知识渊博。毕竟你不是一个具体开发的学生，而是你有一定的技术背景和开发。
我们可以一起聊天。 6、行业业务能力。
比如说，如果我是企业运维出身，那么我明白运维是做什么的？如何进行运维？运维需要什么样的工具平台？ 7、懂一些数据分析，知道自己需要什么样的运营数据作为后续迭代优化的基准。 8、了解项目管理思维能力，能说会写，及行业业务能力。
这三项是核心能力，其余的是基础能力。 7 产品团队由哪些角色组成？一个完整的产品团队将会有以下角色： 产品经理 设计（视觉和交互） 技术（前台、后端、测试、售前、售后） 运营 营销 业务PM 当我们的团队刚开始的时候，只有我和另一个人。
一名同学和两名产品经理共同负责智云自动化平台产品线的设计和实现。剩下的都是系内运营和开发的同学。
他们会开玩笑说我们和创业公司唯一的区别就是不会破产，不用担心发不出工资。其余与初创公司相同。
不过看这个旅程，前中期，只要有三个角色（产品、开发、设计），基本上就可以跑。小团队最大的优势就是沟通成本极低。
这些枪没有问题。有什么不清楚的地方在白板前讨论，然后就去做。
如果遇到问题，请讨论！通过以上，想跳槽的同学和新产品的同学已经可以更清楚的知道产品经理是做什么的了？产品落地的主要步骤是什么？其实在路上做产品就和做产品经理玩游戏是一样的。也是一个升级打怪的过程，一层层升级。
让我谈谈这六个月来我的收获和陷阱。一般来说，成熟的团队都会有导师来指导你，但因为我们是初创团队，所以团队里并没有真正的产品经理。
每个人都是在实践中学习，所以更多的东西是自己实现的。可能我的经历更适合自驾游的同学。
1 小学：找到一种开始的方法（画画、阅读、移动和跟随）。在这个阶段，您是该行业的新手。
你对产品实现商业化的整个流程并不熟悉，基本上是盲目的。在寻找入门方法时，我自己的优势和劣势是什么？ 1 优势：熟悉运维如何进行？我知道运维的痛点（因为团队输出运维平台产品），我主导过运营系统的建设，了解系统和功能实现的一些基本套路。
我见过并使用过很多操作系统和开发多年，懂得如何与开发人员沟通，懂得项目管理 2 缺点 没有完全体验到一个商业产品从0到1的完整流程 不会画原型 不会写PRD 无法胜过产品分析 3 此阶段关键绘图：熟悉Axure RP，临摹对照别人的系统画原型。有时间就借鉴一下公司级的平台系统，算是一个很大的收获。
绘图是澄清想法和熟悉基本页面交互的好方法。看：多看看国外的产品，看看老外是怎么做的。
有些人看了当时的排名后无法理解，不过没关系，有一个印象就好，以后总会有机会确认的。阅读：多看书，看方法论书+有针对性的指导书。
行动：开始尝试进行竞争产品分析。即使分析得很不成熟，但多做几次就会慢慢有感觉了。
拆解：当时我已经有了要完成的功能模块。开始之前，我先对比了内部平台，尝试拆解业务逻辑。
想一想为什么要这样做？这涵盖了哪些场景？不这样做会有什么后果？跟进：跟进需求，确保需求按计划实施并符合设计。 4 我当时遇到的坑是构建一个内部操作系统是做商业产品的基础。
事实上，有很大的区别。如果有人使用内部操作系统，并不意味着你擅长它，而可能只是你的目标用户没有选择。
可以用这个。内部运营体系缺乏版本规划（产品路线图）、运营和硬性质量指标要求。
大多数内部运营体系只是提出需求而不是制造产品。需求的加法深刻体现在内部运营体系上，而产品更需要减法而不是加法（聚焦、延伸、扩展、投入产出比等）。
我刚刚了解到，刚开始的时候，你没有能够判断你所知道的方法和流程是否适用于你的工作场景，这将为未来铺平道路。 2中学：实践&熟悉（负责功能模块） 经过第一阶段的基础，可以说基本了解了一些做产品的基本套路，也接触到了一些小需求。
您可以开始逐步上手完整功能模块的规划和实施。1、这个阶段的重点是了解和熟悉商业产品从0到1的规划和实施流程，并做竞品分析，因为第一阶段竞品分析比较浅。
这里我总结一下用洋葱皮法来分析竞品。功能，网上有很多竞品分析的方法论。
还可以参考：分析用户群体、分析用户场景、分析用户故事、分析用户功能点、使用频率、分析现有功能、覆盖率分析、传达28原则（20%功能）的概念即可满足80%用户的使用场景）满足用户、发现需求、思考共性场景。你不能只听用户的声音，识别虚假需求，思考用户真正的需求是什么？确定需要多少产品功能？功能优先级是什么？做好业务逻辑构思和交互体验2当时遇到的坑是不善于对需求进行裁减合并，贪图大而全，像技术人员一样思考，总是力求全面，不漏掉场景，不善于定位需求的目的、目标和要求，完成的分析过于注重产品交互体验，追求需求场景和表现形式的完美。
3大学：全球视野和产品线规划（重点是如何做减法，定义主产品线）。到了这个阶段之后，基本上就可以尝试把握住整个了。
现在有了产品线，我们需要更清晰地思考以下几个问题：产品线的总体目标和蓝图是什么？大用户故事是什么？这个阶段更多的思考不是简单地叠加需求，而是明确产品路线图上每个功能点的价值和意义，并将分散的点连接起来。想清楚每个大时间点（版本交付时间）要做什么？什么不该做？所做的事情的价值在哪里？不做会有什么影响？如何关闭版本之间的功能循环？如何保证全局逻辑自洽？如何概述版本之间的进展？ 1 此阶段的重点是掌握并运用MVP原则。
MVP是《精益创业》提出的概念。其实概念大家都可以理解，但是在实现过程中会出现各种陷阱。
我将在这里分享。 ○ 抓住核心流程，MVP是一个过程，而且是一个持续的过程 ○ MVP不是单一的产品形态 ○ 做MVP要有明确的目标 ○ 尽量多用轮子（尽量借用内部成熟的模块，跨领域）团队和外部合作伙伴都可以），这对于我们不成熟的团队尤为关键。
什么事都靠我们自己来做是不可能的，自己做只会把我们自己累垮。 ● 做出权衡和平衡。
不该做的事情不要做，浪费人力。对于初创团队来说，有时这是一场与时间的赛跑。
要求是不可能实现的，所以做之前一定要想清楚。版本规划与迭代 用户故事演化 产品（功能）生命周期 ○ 设计规划：产品的可用性 ○ 研发生产：产品的可行性 ○ 销售：产品的价值。
○ 运营○ 市场反馈 以上三个阶段是我目前个人的升级路径。还有很长的路要走。
我正在慢慢思考。稍后我会理解并运用到实践中，与大家交流。
4 思考了需求池管理之后，我决定把需求管理单独出来写一下。为什么？因为需求管理实际上贯穿了接下来的两个阶段，而且也是相当重要的。
1、需求来源分类：老板需求。相信每个产品学员都会遇到客户反馈的需求。
产品主线的需求是在客户场景中定义的（抛开伪需求）。负责的同学根据这些信息规划产品线。
他们认为我的产品五类需求都遇到了：主线必须做的功能性订单需求、下单必须做的需求、合作伙伴的需求。那么这五类要求是好还是坏、合理还是不合理呢？现阶段我觉得其实没有这样的事情。
每个需求都有其特定的背景和固化场景的特定目标。这些类型的要求必须在时间或功能上发生冲突。
这个时候产品同学和团队就需要讨论和评估什么该做，什么不该做。产品经理首先要思考清楚。
需求管理一定要做，否则产品经理就是消防员（总是做紧急的事情，会让人失去目标）。不仅产品线混乱，最终的产品也完全不同。
也许产品经理自己都晕了。您可以阅读详细的需求管理方法《普拉姆原则》。
下面是我根据这个方法论和实践总结出来的一个需求分析模板。需求提交公司优先级是指当您有多个客户时每个客户重要性的定义。
为什么我们需要在客户公司内设立内部职位？因为不同岗位提出的需求有时会影响到订单制定者，比如客户的CTO提出的需求和一线员工提出的需求就不能认为是一样的。这是现实！还有一点没有在表中呈现，因为很难客观衡量，那就是销售对客户的控制程度，即销售在下订单时对自己能够处理的信心有多大。
5 产品经理的自我修养现阶段我觉得产品经理的修养可以用6个字来概括。多看：多看行业，多看竞品，多听：多听第一手客户声音。
如果无法直接与客户沟通，那么信息来源渠道就必须高保真，不能过度失真。多思考：多思考用户故事、产品价值和产品蓝图。
必须做的、不能做的、必须推迟的，多做、多说：多与同行沟通，多尝试：适度尝试，失败的成本是团队可以承受的，而不是失去客户、出局：避免 这种心态类似于产品经理应该避免的几个陷阱： 自我推销：我认为还可以，趋于完美，但实际上没有人使用。采取行动之前先思考清楚：避免在产品中埋藏明显的逻辑缺陷或功能之间的不一致。
有时你宁愿放慢速度并清晰地思考。过度坚持：除非你已经非常优秀并且被公认为产品专家，否则最好倾听和理解。
功能大而全：多思考MVP原则。细节决定成败：负责产品线时，应该更多地考虑整体方向，而不是小细节。
并不是说细节不重要，而是细节可以通过后续的迭代来完善。一起来实践2B吧 1. 2B产品特点 ■ 解决工作中的具体问题，或者将现有流程系统化，提高效率 ■ 用户在行业内有一定的专业背景，发货前会对用户进行专业培训 ■ 容错率成本很低，试错成本也很高（2C端的小步骤、快速迭代、几天或一周一个小版本目前不太适合） ■ 对产品本身的质量要求非常高高的。
如果客户的业务失败或者现有网络出现故障，那绝对是一件大事。 ■ 运维平台提供的功能必须齐全，必须包含所有必要的功能，即使一开始每个功能的深度不是很深。
B端用户更看重一站式解决方案，而不是多个平台的混合使用。多平台企业整体IT成本和用户学习成本较高。
■ 相比C端、B端，体验和交互更加轻松。如果一开始有点难看也没什么大问题。
只要交互流畅，能够顺利完成，B端用户对于交互体验的容忍度非常高。原因就在于平台的核心。
还是要完成具体的任务。之前听销售人员说过，好的2B产品可以帮助使用该产品的用户做好自己的工作。
换句话说，2B产品必须是可靠的。我非常同意这句话！ 2. 2B产品设计思路 ■ 设计的产品业务逻辑要求高，业务流程上下文相关性强 ■ 业务规则复杂，场景更加细分 ■ 功能要先水平堆叠，再深入应该纵向探索。
应包含的功能必须有节奏，主要功能的方向必须能够闭环 ■ 在大多数场景下，功能的完善度和质量永远会优先于交互体验（视觉）等。这并不是为了都说体验不重要，但2B产品应该优先帮助用户完成工作。
■ 设计中需要多个角色。比如，从组织架构上看，一个大平台基本上会有一线员工、中层管理者、高层管理者三种角色。
他们对平台的看法不同，期望的功能也不同。 。
■ 权限应该详细。不同的职位在平台中应该有不同的权限。
■ 管理用户预期的操作行为 ■ 简化用户的操作成本 3. 陷阱 ■ 过分强调交互体验，消耗大量时间和精力。我现在设计的基本原则之一就是能够顺利完成既定的操作和操作流程设计，反人类也没关系。
至于点击鼠标的多少，其他交互的细节并不是什么大问题，交互本身也需要时间打磨。 ■ 业务逻辑不清晰，简单的功能点逻辑无法闭环。
总结：产品经理的实践之路还很漫长，成长为一名优秀的产品经理难度相当大。如果你想继续下去，你必须保持对产品的热爱和好奇心，多思考不同的产品，多思考。
产品经理是一个非常有趣的职位，尤其是当你看着一个产品从无到有，逐渐被用户认可时，是一件非常有成就感的事情。书籍清单：附上我看过的产品经理相关书籍，并给出一些小建议。
据说现在市面上2C产品的书籍很多，但2B产品的却很少。 《杰出产品经理》对工作有指导意义，书中的一些方法论可以直接应用。
《人人都是产品经理》现在应该是2.0了。对工作具有指导意义。
书中的一些方法论可以直接应用。 《简约至上》 我买的时候已经印了25次了，可以让你了解与应用交互设计的基本原理和方法。
《启示录：打造用户喜爱的产品》 比较全面、先进的方法论，而且还涉及到团队建设。
版权声明：本文内容由互联网用户自发贡献，本站不拥有所有权，不承担相关法律责任。如果发现本站有涉嫌抄袭的内容，欢迎发送邮件 举报，并提供相关证据，一经查实，本站将立刻删除涉嫌侵权内容。
标签：
相关文章
06-17
06-17
06-18
06-17
06-06
06-18
最新文章
【玩转GPU】ControlNet初学者生存指南
【实战】获取小程序中用户的城市信息（附源码）
包雪雪简单介绍Vue.js：开学
Go进阶：使用Gin框架简单实现服务端渲染
线程池介绍及实际案例分享
JMeter 注释 18 - JMeter 常用配置组件介绍
基于Sentry的大数据权限解决方案
【云+社区年度征文集】GPE监控介绍及使用