原腾讯产品经理分享全套：产品经理工作指南

以及一些刚入坑的朋友们很好奇产品从0~1到底要做些什么工作，需要哪些文档资料等。

因产品经理日常工作没有明确定义和标准，所以笔者针对上述问题结合自身工作经历，和大家聊一下：一个产品从0~1，或是一个诉求到产品功能的诞生，需要做些什么事情、输入什么内容，又如何保证输出内容的完善。

《产品经理工作指南》文章，核心只针对产品功能、设计方面，不囊括日常沟通、项目管理、资源协调等方面；文章将从产品评估、产品需求、产品结构及流程、原型设计及逻辑规则四个方面进行阐述。

一、产品评估

产品从0-1，首要任务是进行充分的产品评估，评估你和你的产品是否有可能性，而不是立马去分析需求，进行产品设计、投入开发。而产品评估的内容涉及以下14项：

背景、痛点：用户存在什么不能忍受的且持续反复出现的问题。
产品价值：产品要解决什么问题。
目标用户/市场：为谁解决这个问题。
解决方案：如何解决这个问题，产品核心所在，我们的产品核心功能。
产品目标：目标一定是可以用数据去衡量的（没有出现数据的目标不是合格的目标），而这个目标则是可以被拆解到各项目子线上，各项目子线再根据这个目标去制定对应的策略。
度量指标：怎么判断产品的成功与否。
市场规模：成功的机会有多大。
市场时机：切入市场的时机合适么。
竞争格局：有哪些同类产品、竞品；对手的功能和体验如何。
竞争优势：为什么我们最适合做这个产品；是否还有竞争对手未满足用户痛点可共产品进行差异化。这一点很重要，企业一定要形成自己的护城河，不然在这个模仿的时代，很容易被别人取代。
渠道、营销策略：是否有现成的合作伙伴，如何寻找客户，如何把产品推向市场。
必要条件：解决方案必须满足的条件是什么，缺少必要条件会导致失败。
成本分析：产品开发成本、拉取客户成本、销售产品成本、人力资源成本等。
收入分析：盈利模式有哪些、收入、毛利等。

在进行好所有的产品评估之后，并且评估结果是这个产品真的值得做，那我们方可进行下一步，不然乘早结束为好，以免浪费不必要的财力物力。

当然通常会出现公司领导、老板强烈要求必须要做的情况，那我们应做的是除了服从命令立即执行之外尽量做一份产品评估报告给领导（或许领导在做之前并没有考虑这么多，也或许站在领导的角度有更深层次的考虑，不过有了这份报告，说不定就会发生一些改变），如果明知山有虎偏向虎山行，既然领导、老板坚持那就做了，但是有这么一份产品评估报告，总能够避免一些不必要的坑！

二、产品需求自查

在产品评估之后、产品设计之前，我们还要进行产品需求自查的工作。包括以下内容：需求收集；需求分析；需求管理。

2.1 需求收集

如何收集需求，从哪些渠道去收集需求？

需求收集的方式和渠道有很多种，如：用户访谈、调查问卷、实地调研、数据分析、业务部门诉求等。除此之外，还包括：线上产品bug修复、性能优化、用户体验提升等等，都是需求收集的范围，总之，用适合当前公司、当前产品的方式去做即可。

2.2 需求分析/筛选

收集的需求是否经过认真地需求分析？

听用户的但不要照着做！特别是用户自以为是的需求，（这里的用户不仅仅指ToC产品的用户，还包括老板、领导、运营、客服同事等等）我们要将收集来的需求，运用kano模型、四象限法则等方法过滤掉无用需求、反向需求，挖掘出深层次的含义，找到的真实需求，并表达为产品的解决方案，即转化为真正的产品需求并为产品需求排定优先级！

2.3 需求管理

①需求问题池

将收集好的需求放进需求问题池，标明：需求描述、需求来源、提出时间、状态、解决方案、分析人、处理时间。

需求描述：阐述清楚‘用户’的问题、诉求及希望达到的目标；
需求来源：注明问题的来源，在需求分析后必要的情况下和关系人进行回复、沟通；
状态：包括未分析、不予解决、确认为产品需求；
解决方案：特别是针对不予解决的需求，一定要备注好因为什么原因不予解决，比如该需求是伪需求、重复需求或者有另外实现方式等等。

②需求跟踪矩阵

将需求问题池中问题，经过需求分析后，转化为产品需求的需求汇总到需求跟踪矩阵中，记录好每个需求从确认到规划到开发到测试上下的每个状态，方便准确的跟踪需求状态。

矩阵包括：需求功能名称、需求概述、需求类型、需求属性、优先级、需求来源、需求状态、对应原型及文档、需求完成时间、责任人、备注等。

需求功能名称：简要说明功能定义，比如：新增电子发票、优化意见反馈、优化账单详情页；
需求概述：大致阐述该需求的主要功能及效果，比如：支持用户所有消费订单进行开电子发票；
需求类型：即该需求的分类，包括原本的产品规划的新增功能、运营/客服/老板等部门提的内部需求、bug修复、体验优化、性能优化等等；
需求属性：原始需求、修改需求、增加需求、删除需求，主要为了记录该需求进入需求跟踪矩阵后的变更情况（个人认为该属性的记录十分重要），即便通过需求分析，转化为真正的产品需求，在实际设计、开发过程中，仍存在增、删、改等变更情况，所以一定要记录好每个需求的属性，并在每次版本迭代后，进行复盘，统计4种属性的需求数量，若原始需求比例过少，就需要认真反思自己在需求分析过程中是不是考虑不全面、分析不严谨等等；
对应需求文档及原型：简单标注需求对应的原型或者文档所在位置，方便快速检索、查看。

三、产品结构及流程自查

通过需求分析，整理好真实的产品需求之后，就开始进入具体的设计阶段。

如果是新产品或者某个大的功能模块，需要提前进行产品功能结构设计，涉及较为复杂的流程，还需考虑是否绘制时序图、业务流程图等进行分析。

3.1 产品功能结构图

是否有产品功能结构图、产品模块划分是否合理、功能层级、分类是否合理，产品模块是否包含该有的功能、产品模块是否有优化的地方，同时需要将功能结构图和信息图区分开来，网上有很多关于产品功能结构图和信息结构图的区分，本文不再作过多的阐述。

3.2 系统交互图

也称为时序图，描述对象是如何交互的，消息是如何在对象间发送和接收的，通常用来描述前端、客户端、服务端或者本系统和其他系统之间的数据交互逻辑。如下图：

3.3 业务流程图

业务流程图主要是为了描述作业顺序和管理信息的流向，业务流程图的绘制是按照业务的实际处理步骤和过程进行的。对于APP或者管理平台等产品，也可以简单的理解为用户操作流程，你如何进行操作，系统如何进行反馈。其中需要充分考虑流程设计是否合理、异常流程是否设计、逆向流程的设计是否考虑周全，以及操作的容错性等。

如下图：

四、原型设计及逻辑规则自查

原型设计及逻辑规则自查是在原型设计过程中伴随着进行的思考，以及在原型初稿完成、制定相应的逻辑规则时，根据每个点进行核查。核查的内容较多，也是初入门的小伙伴最容易遗漏的地方，下面将逐一介绍需要核查的内容：

前置条件

首先，要思考产品中各项功能使用的前置条件，比如：是否开启权限、是否登录、是否会员、是否在功能白名单下…

前置必要条件：APP中功能使用是否需要定位权限、相机开启权限、图片访问权限、网络访问权限、地理访问权限、通知发送权限等，是否有针对用户拒绝权限后的处理方式。
登录状态：已登录/未登录，未登录状态下允许做哪些操作、看哪些数据，哪些操作是登录后才能做的，不同状态下所能做的操作和数据一定要区分开。
会员体系：对于有会员体系的产品，需要区分普通用户、付费用户，VIP1~VIP6等……
功能白名单：部分新功能只对小部分用户开放，进行市场测试，反馈新功能使用情况，此时需要设计功能白名单，该功能只对在白名单内的用户可见并可以使用。
管理后台：不同用户、不同角色拥有不同的权限，不同权限可操作功能、可查看数据不同，需要控制好权限分配，

最基本的是：用户名/密码输入规则限制、是否有记住密码、是否支持密码复制粘贴、是否支持密码明文/密文切换显示，是否有忘记密码处理流程。
针对APP：是否支持第三方登录，用户拒绝授权第三方登录，是否有反馈结果页面。
针对后台管理系统：用户初次登录是否引导用户修改密码；为了安全起见，通常考虑不设计记住密码，忘记密码可采用管理员重置的方式。
登录状态的有效期是多长，过期后需要重新登录。
输入账号、密码后还未登录时刷新页面，是否清空账号和密码；退出登录后，是否清空账号和密码。
是否支持同一账号多设备登录；是否支持移动端、PC端同时登录；不允许多设备登录情况下，一个设备登录，另一个账号是否需要自动下线；自动下线账户再次登录后是否有警示提醒等。
高频登录是否锁死；短时间内密码错误超过n次是否输入图形验证码等进行校验。

界面呈现——数据

针对具体页面内容，最最最重要的，就是考虑 数据来源！数据来源！数据来源！一些PM在设计的时候天马行空，想要页面展示什么就加什么，根本不考虑数据来源，待开发阶段被程序员反问时候，又一脸懵逼了。
另外还要考虑：一个页面展示多少条数据；多少条数据进行一次刷新；刷新一次加载多少条数据。
加载失败如何显示：广告、图片、视频、附件。
在无数据时展示的缺省图、无网络时展示的缺省图，切勿因为无数据就空白页面反馈给用户，让用户不知所措，这一点在逻辑规则中备注并提示好UI人员。
超出容器部分（无法完整显示的数据）怎么展示：换行、隐藏、分页。
字数是否有长度限制，超过限制时如何处理。
数据过期如何提示用户。
数据按照什么规则排序。
数据是否要按特定的格式显示；数据是否存在极值；数据的计量单。

界面呈现——控件、组件

控件是否可点击（不可用状态如何呈现）；是否可拖动；可点击区域等。
控件操作方式：点击；滑动；拖动；缩放；摇一摇。
控件获得焦点时/失去焦点时状态。
提示状态、规则如何：小红点/小气泡。

往深入讲，还需要考虑：

控件样式是否符合用户认知：比如‘垃圾桶’代表删除，最好别定义为新增功能。
控件交互行为是否具有一致性：比如有的地方新增是弹窗，有的地方新增又跳转新的页面。
控件样式是否具有一致性：同样是新增，在两个列表菜单放的位置不同，一个左边、一个右边，按钮样式不同。

这些就需要产品设计拥有一定经验后好好判断。

界面呈现——输入与选择

输入限制（数据类型；长度限制；有无不允许输入的字符）；是否必填；是否检验唯一性。
是否为用户提供了默认值；有默认值的情况下用户输入数据后默认值怎么处理、呈现。
输入前/输入中/输入后、输入超过阀值四种情况的处理以及相应界面呈现、提示等。
是否保存输入数据：刷新后是否还存在；页面跳转后再回到当前页面数据是否还存在；流程性数据填写操作退出或中断或返回上一步是否保存数据。
有无提交限制：多次提交弹出图形验证码、限制多长时间内不能再次输入。
是否指定了键盘类型和键盘引起的页面滚动。
是否设置了搜索匹配项规则。

界面呈现——文案

用户每次操作后，是否有相应的提示文案；特定功能、新功能是否有文案解释帮助用户理解；重要的操作是否有警示文案；某些操作是否添加操作说明。
往更深层次思考，则需要考：文案的句式是否一致；用词是否一致/准确；文案是否有温度感。

交互过程与反馈

操作成功/操作失败时如何给用户反馈，系统如何处理，是否有自动备份等。
操作是否可撤回/操作过程中是否允许取消、关键操作之前是否给予弹窗提示/警告。
是否设计了防止误操作提示，常见的需要二次确认避免误操作的场景：付款、覆盖、退出、删除、提交、离开、修改、替换。

异常情况——网络状态

针对图片较多、有视频等等需考虑，不同网络状态下，系统给与不同情况反馈。

4G切换到WiFi：是否显示更高清内容。
WiFi切换4G：是否呈现呈现普通质量的图片、视频播放是否暂停，如果继续播放将使用运营商网络并产生流量费用。
弱网：结合实际业务，只加载文字不加载图片，用缺省图代替，尽量保证主流程走通。
无网：从有网到无网，在该页面进行所有操作如何反馈？弹窗、toast、还是刷新一个无网的缺省图、该页面给刷新网络按钮。

异常情况——刷新

关于常见的刷新，需要考虑。

刷新前：页面、数据如何展示。
刷新中：如何给用户良好反馈。
刷新后：刷新成功/失败对应的文案提示。
刷新规则：刷新触发条件是什么，一次刷新加载多少数据？

系统机制

推送机制：对于常见的消息推送，需要包含：推送内容、推送对象、触发推送的时机、点击推送后跳转地方，缺一不可。

中断机制：对产品使用中突发的中段需考虑程序如何处理，比如：退出登录、来电、程序进入后台、杀死程序、网络中断、关机等等，发生上述突发中段，数据同步、数据中段如何处理，用户操作有何反馈都需要列出来，以便开发人员在编码时候进行开发。

删除机制：涉及产品中所有需要删除的地方，备注说明清楚采用物理删除还是逻辑删除

物理删除：直接从数据库层面彻底删除，删除的数据无法找回。
逻辑删除：仅仅是逻辑和界面展示上删除，数据库中还存有该数据，必要时可以恢复。

其他

除以上之外，还有一些其他细节，如：

图片上传：是否变形、是否需要裁剪；是否限制大小控制流量、压缩图片等。
加载：自动加载or手动加载；加载中样式；加载失败如何显示；无新数据加载如何展示。
排序：排序规则；排序更新频率；是否有置顶；是否有影响排序的因素。
缓存：哪些数据可以缓存；缓存更新规则；缓存删除规则。
查询：精确查询or模糊查询；查询的范围。

以上即为关于原型设计及逻辑规则的自查部分的内容。

PS：《产品经理工作指南》上下篇均来自笔者平时工作经历中的积累，仅属个人拙见，如您有更好的意见或建议，可以在评论区回复。

除此之外，也欢迎大家添加微信共同交流探讨产品相关的内容，不过不欢迎添加微信后的第一句话是：把你的模板发一下给我吧！请不要做伸手党哈！

文章由PM28网编辑，作者：海阁，如若转载，请注明出处：http://www.pm28.com/2867.html欢迎投稿