产品经理工作指南上

　　笔者整理了上、下两篇《产品经理工作指南》文章，核心只针对产品功能、设计方面，不囊括日常沟通、项目管理、资源协调等方面；文章将从产品评估、产品需求、产品结构及流程、原型设计及逻辑规则四个方面进行阐述。enjoy~
　　一年前，结合自身工作经历谈到《如何用Axure输出一份结构清晰的prd 》文章发布后收到很多小伙伴的相关反馈，截止目前为止来自小伙伴们的反馈中主要为以下几个方面：
　　需求分析不够透彻
　　产品设计不够严谨
　　异常流程考虑不够全面
　　逻辑规则不够完善
　　以及一些刚入坑的朋友们很好奇产品从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或者管理平台等产品，也可以简单的理解为用户操作流程，你如何进行操作，系统如何进行反馈。其中需要充分考虑流程设计是否合理、异常流程是否设计、逆向流程的设计是否考虑周全，以及操作的容错性等。
　　如下图：
　　本文为《产品经理工作指南（上）》，以上内容就是产品评估、产品需求、产品结构及流程三部分内容。因篇幅有限，原型设计及逻辑规则稍后会在《产品经理工作指南（下）》中为大家分享，敬请期待！