产品经理技能树一

如果无法正常显示，请先停止浏览器的去广告插件。

1. 需求篇（一）需求的基本框架需要将用户需求的基本结构=（哪些）用户+（什么）场景+期待目的找到用户需求这儿的用户可以指真实用户、业务、运营、老板…… 转化成产品需求的基本结构=（哪些）模块/功能+交互+逻辑+…… 解决的是为哪些用户在什么场景下做的哪些功能点，目的是什么？目的解决用户问题产品狗聚集地

2. 需求篇（二）需求分析方法三大步：明确问题 → 拆解问题 → 解决方案明确问题之前需要判断真伪需求，其中需求的来源：明确问题：提出的问题要聚焦，明确。不能泛，模糊。要有用户、场景、问题。还要明确该需求带来的价值。需求最终是要交换成价值的。正确的问题VS错误的问题：明确需求的价值：产品狗聚集地

3. 需求篇（三）需求分析方法三大步：明确问题 → 拆解问题 → 解决方案拆解问题的5个维度：积极层面：通常可以拆解出怎么做对用户来讲可以产生更积极的情感。案例解析：某视频APP，用户次日留存率低于30%，需要提高次日留存率否定层面：通常可以拆解，即使不做什么，依然可以产生好的结果。转移层面：转移指的是不直接单独解决当前用户的问题，通过转移法，用户转移、问题转移等。拆解层面：把当前问题刨根问底的拆，挖掘更多的可能性、找到问题本质。脑洞层面：这个更多的靠灵感、经验等进行头脑风暴，补充其他维度考虑不到的地方。产品狗聚集地

4. 需求篇（四）需求分析方法三大步：明确问题 → 拆解问题 → 解决方案产品狗聚集地拆解方案：一开始思考解决方案的时候也不要去考虑实现的可行性，尽管去提供。等所有的解决方案都列出来之后，再进行方案分析、评估、排序。需求收集表（如下）将需求收集表按照当月的OKR做一个紧急优先程度排期表，并合理分配给相关同事

5. 竞品分析篇（一）你的目的是什么？你到底需要分析什么？只有先搞清楚了你的目的，你才能知道到底该去重点分析些什么，也才能让你的分析价值和效率变得更高。竞品分析全图：竞品分析快速法： 1.功能架构+产品特色交互+核心流程需求场景产品调研业务形态功能点调研产品体验市场调研业务流程功能架构交互体验页面布局（UI）数据呈现功能迭代运营路径商业模式 2.运营路径（通过版本迭代记录） 3.商业模式（怎么赚钱和怎么花钱的）行业市场前景产品狗聚集地

6. 竞品分析篇（二）我们该如何选择竞品？ 1.核心服务+核心用户都基本相同的产品（直接竞品）——分析产品优劣势直接对比（业务形态多样化） 2.核心用户群高度相同，暂时不提供我们的核心功能与服务，但可能通过后期升级很容易加上相关功能的产品——便于做后续产品规划和产品路线图 3.目标人群可能不太相同，但某些产品功能模块和服务流程比较相近的产品——便于业务流程、交互细节等细节梳理参考 4.目标人群有一定共性，产品提供的核心服务不太一样，但在特定场景下对于同一类用户需求和用户的使用时间形成挤占的产品。——用户的需求、场景和深层次的使用动机（衍生的模块可以梳理）产品狗聚集地

7. 竞品分析篇（三）梳理竞品分析基础六步——永远不会错产品狗聚集地细节看产品功能架构产品核心流程用Xmind把竞品的功能清单梳理出来用Visio把竞品的用户核心路径整理出来特色功能和交互整理产品的特色功能点和优秀的交互全局看产品运营体系商业模式用鱼骨图通过版本迭代记录梳理运营模块用商业九步法整理竞品商业模式产品整体数据表现整体产品基础数据

8. PRD（需求文档）篇（一）完整的产品功能描述主要包括两方面：功能点无遗漏和功能描述完整。产品狗聚集地 PRD文档主要针对这四类人：产品经理设计师开发工程师可以通过产品功能描述自查清单来系统的梳理产品功能点和描述， PRD可以帮助产品经理更加透彻和完整的梳理产品，同时，产品经理可以通过PRD和其他人员进行高效的沟通。交互设计师——可以通过功能点及其描述自查来检查自己的交互稿是否遗漏特殊情况、异常情况、极限情况等等。可以通过功能点及其描述自查清单来检查自己的程序开发是否符合 PRD中的相关要求。 UI设计师——可以参考原型了解产品经理的想法，结合自己的思考输出UI界面测试工程师输出可以将PRD中的功能描述和用例转化为测试用例的一部分，进行产品可用性测试。

9. PRD（需求文档）篇（二） PRD原则 1.先总体，再细分：结合产品功能架构图来进行主要功能点的检查，在主要功能点完整的基础之上，再深入到主要功能点下的细节功能进行自查。（从模块到功能） 2.有顺序，依次检查：这个和撰写PRD中的功能点和描述是一致的，可以依据PRD功能描述撰写的标准综合运用以下顺序进行自查：产品功能点需求：用户需求→后台需求（数据监控等）；功能在系统中的位置：前台界面→用户管理后台(个人中心)→官方管理后台；业务流程：步骤1→步骤2→步骤3→步骤3.1→步骤3.2…… 功能主次关系：主要功能（场景or流程）→次要功能（场景or流程）；功能点在页面布局中的位置：从上→下、从左→右；按照软件状态：基本状态→特殊状态→异常状态；产品狗聚集地 3.随时关注，及时更新：很多遗漏的点不是自查一遍就可以检查出来的，说不定某个时间，就突然想起了某一个功能点的遗漏。同时PRD作为交流沟通的工具之一，需要跟进交流的结果，因此我们要随时关注，并做到及时更新。最好在正式交付其他人员时，完成功能点及其描述的梳理。

10. PRD（需求文档）篇（三）产品自查——流程和页面布局基本状态特殊和异常状态 1.功能框架和流程的功能点是否完整？特别是注意流程中的主导航常驻or页面返回，是否是从哪来回哪去？不要出现一个页面点击某个 button不知道去哪的问题； 1.特殊流程是否缺失？比如登录流程中是否缺失忘记登录密码的流程；启动页和用户引导页等； 2.流程描述是否完整？比如A→B页面跳转是否描述完整（包括交互触发方式：单击or长按or 滑动；触发区域：整条Button or Button的某个区域；触发前中后状态：加载时间、动效、中间状态等等）；再比如是否有不可点击的效果，如：你的按钮此时处于不可用状态，那么一定要灰掉，或者拿掉按钮，否则会给用户误导； 3.页面布局是否完整？比如页面标题栏、导航栏等否缺失？页面反馈（弹窗or加载状态进度提示等）是否缺失； 2.页面布局是否考虑横竖屏问题？ 3.页面布局是否考虑不同屏幕尺寸自适应问题？ 4.不同模式下页面情况说明：夜间模式？编辑模式？无图模式？等产品狗聚集地

11. PRD（需求文档）篇（四）产品自查——产品内容基本状态特殊和异常状态 1.描述内容是静态or动态数据调用？如静态的标题title，动态的文本内容调用等； 1.数据内容为空如何处理？是否支持离线功能？是否有空数据界面设计，引导用户去执行操作； 2.内容描述是否完整？顶部标题、按钮里的文字等；文本是否错误等； 2.内容长度是否有限制？比如内容展示是否限制字数，点击查看更多？昵称描述不得超出多少字？密码不得低于多少字符等等； 3.内容加载方式描述是否完整？本地缓存or刷新加载网络新内容等； 4.输入框内容描述是否完整？是否有初始内容？输入后是否有联系功能（比如搜索）； 3.内容违禁如何处理？敏感词、违禁内容（如：涉及版权、专利、隐私等图片)等如何处理； 4.数据内容过期or删除or违禁后如何展示？比如某内容发布后因为违禁被编辑删除，那么用户再次点击后怎么展示等； 5.用户内容输入是否描述完整？比如输入框输入空格、特殊字符如何处理？用户输入是否保产品狗聚集地留历史记录？等等；

12. PRD（需求文档）篇（五）产品自查——账号状态及用户权限用户注册和账号管理功能都会涉及到用户不同登录状态（登录、非登录、账号异常、账号被冻结等）和用户等级和权限（会员和非会员、付费和非付费用户等），因此要说明清楚不同账号状态及用户权限下显示的内容和功能。基本状态特殊和异常状态 1.不同账号状态说明：登录状态、非登录状态不同情况是否说明完整？ 1.是否说明清楚一个账号多终端登录问题？检查一个帐户登录多台手机时，原手机里的用户需要被踢出，是否给予用户友好提示？ 2.不同用户等级和权限说明：不同等级用户有哪些权限？在页面展示上有什么不同？ 3.不同账号状态切换时是否有特殊展示？ 2.是否考虑了多账号切换问题？是否保留历史账号？ 3.是否支持第三方账号登录？登录后如何绑定自有账号？产品狗聚集地

13. PRD（需求文档）篇（六）产品自查——后台交互及管理需求后台交互和管理需求涉及到消息推送、数据更新方式、软件权限和后台监管等方面的需求。 PUSH消息软件权限及安全性是否说明必要的push消息业务规则？什么情况需要push消息?push什么内容等等软件权限说明是否完整？什么功能，在什么情况下，需要调用什么样的权限？位置or通讯录 or联网or照片等等数据更新说明 1.需要说明哪些地方需要用户手动刷新？哪些地方需要自动刷新？哪些地方是手动+自动刷新？ 2.说明哪些地方从后台切换回前台时需要进行数据更新？ 3.需要说明哪些内容需要实时更新，哪些需要定时更新？ 4.说明数据展示部分的处理逻辑，是每次从服务端请求，还是有缓存到本地？后台数据监控及管理需求 1.后台有哪些数据检测点？需要监控哪些数据？ 2.后台有哪些功能点，为前端提供哪些数据内容？敏感词、违禁内容如何屏蔽？等等 3.如何进行内容推荐和排序等等产品狗聚集地

14. 产品规划篇（一）从以下几个方面的去衡量产品是否有发展前景： 1.客户（用户）有很强烈的需求，产品可以真实的解决客户（用户）的痛点。 2.产品的业务规模可以成长到很大的体量。 3.产品有很好的预期资本回报，投入资源能得到很好的盈利，为公司带来商业价值。 4.产品经得起时间的考验，可以持续的为客户（用户），为公司提供价值。产品狗聚集地

15. 产品规划篇（二）基于产品在不同阶段为哪些目标用户去解决什么需求，产品目标是什么？产品种子期：（会用MVP策略）最小可行性产品快速验证市场，获取初期用户；产品狗聚集地产品成长期：需要快速扩张，获取大量用户，提升活跃和留存率，这个阶段会有很多增长型策略，同时也会考虑防御性策略，让自己的弱势最小化病努力避免风险；产品成熟期：需要获取营收，会有很多商业性策略，同时也会开始多元化经营，努力让优势最大化，减少风险消除威胁因素；产品衰退期：可以最后促进用户消费获取一波营收，也可以设法延长产品生命周期，如增加产品用途，带来新的价值。还可以在适当时机果断地淘汰老产品，发展新产品，实现产品的更新换代。（产品二次增长策略）

16. 产品规划篇（三）拆分前端和后端整体的产品模块和大致的功能清单输出产品规划的产品路线图在产品成长期需要构建整个产品蓝图（产品规划需求）产品狗聚集地配合公司的OKR （Q季度OKR、运营OKR……）进行产品版本迭代

17. 产品规划篇（四）举例：智慧社区O2O —— 产品蓝图产品狗聚集地

18. 产品规划篇（五）举例：智慧社区O2O —— 产品线拆分产品狗聚集地

19. 产品规划篇（六）举例：智慧社区O2O —— 产品线C端、B端和admin端模块细分产品狗聚集地 C端对应功能模块 B端对应功能模块 admin端对应功能模块

20. 产品规划篇（七）举例：智慧社区O2O —— 结合业务OKR输出产品路线图产品狗聚集地产品业务侧整体OKR 产品路线图

21. 评审篇（一）开始阶段——和业务方确认需求讲清楚需求目的是什么?解决方案方向是什么?大致的成本和收益。用来决定这个需求到底是否开始做。业务方月度OKR规划和业务确认需求和业务确认产品路径每月20号收集提前10天提前3天（Demo演示）超级重要！！！！因为这是坑点。重点过产品狗聚集地

22. 评审篇（二）中间阶段——和产品部、技术部主要负责人初审需求产品部：内部过审，给出核心主流程，核心产品解决方案此时的方案较粗糙。产品狗聚集地初审方案模块牵连点确认版本需求清单产品解决方案和核心流程其他产品模块如何配合内部过审通过技术部负责人：一般会在开发周期提前一周与各技术负责人过稿，主要是粗略评估技术障碍、技术工作量等。初审方案产品解决方案和核心流程讨论技术难点工作量估算便于后续规划和当前业务核心解决方案评估大致工作周期并同步知悉业务方快速过

23. 评审篇（三）评审阶段——和产品设计部、项目组全部成员细节评审需求产品设计部:内部过审，给出完整方案，包含中高保真原型、完善边界条件、完善异常Case等。项目组全体成员:开发前3天过稿，和项目组全体成员过稿，主要是精细的讲解需求。仔细过产品狗聚集地

24. 项目跟进篇项目从0到1历经四节点：产品狗聚集地输出流程阶段业务需求池重大版本会议纪要产品需求池需求收集产品版本启动需求澄清需求确认需求分析需求评估需求优先级敲定需求竞品分析业务规划业务需求讨论项目启动需求评审版本研发测试用例上线报告数据监控版本测试产品上线每天站立会周会版本复盘项目执行&监控项目收尾