产品之旅：产品经理的方法论与实战进阶
2023-05-25 08:23:27 0 举报AI智能生成
登录查看完整内容
产品之旅：产品经理的方法论与实战进阶
作者其他创作
大纲/内容
（1）用户调研，包括用户访谈、问卷调查等定性与定量的分析方法。
（2）研究市场分析报告及文章。
（3）体验竞争对手的产品，了解用户对其的评价。
（4）与同事进行头脑风暴。
1 市场调研
（1）产品的愿景及定位。
（2）目标用户是谁，他们都有什么特征。
（3）先收集用户需求，再分析和筛选用户需求。
（4）根据需求搭建产品框架。
（5）确定产品的主流程及附属流程。
（6）产品的功能设计。
2 产品定义及设计
（1）每个版本的需求梳理及优先级安排工作。
（2）制订版本迭代计划。
（3）根据版本迭代计划制订项目计划。
（4）根据计划安排项目进展。
（5）向主管领导报告项目进展状况等。
3 版本迭代及项目管理
（1）产品上线前的准备工作。
（2）产品版本更新说明的撰写。
（3）产品内部培训。
（4）产品对外宣传。
4 产品上线及培训
（1）查看用户反馈，做一定的用户访谈，了解用户的心声。
（2）给产品进行埋点以采集数据。
（3）通过数据分析发现问题。
（4）根据数据表现及用户反馈改进产品。
（5）不断进行验证、迭代。
5 数据分析及优化体验
（1）协助项目经理写一份项目文档。
（2）协助运营部门写一份产品文案。
（3）帮助销售思考怎样让客户更好地理解产品。
（4）协助开发去做功能测试。
（5）协助客户经理一起和客户做项目支撑和服务。
6 各种协助、支撑和打杂
岗位职责
主要包含定性和定量两种调研手段，如用户访谈、问卷调查、情景再现、A/B测试等
用户调研
要明白竞品分析的出发点是什么，是为了全局还是为了某个单点功能。
要懂得区分竞品的种类（竞品分为直接竞品、间接竞品、潜在竞品）
需要分析每一个竞争对手是怎么做这个产品的，以及产品的优劣势，比如为什么有这个功能，其代表的用户需求是什么，这样做给用户带来了什么好处，不足之处又在哪里等。
竞品分析
数据包括该项目的市场体量、竞争对手数据和市场未来可能的增长数据等，通常来说，这要求产品经理能够阅读一定数量的行业分析报告，并根据行业数据给出自己对整个行业的理解和结论。
数据收集和分析
市场调研
涵盖了需求的收集、分析、筛选及需求的优先级排序。
需求管理
了解产品定位：产品定位一般来源于公司高层要求或公司战略，产品经理必须能理解产品定位，否则做出来的产品一般是不符合公司需要的。
产品总体规划：通过产品定位和产品调研对产品进行总体规划。
梳理产品架构：通过产品定位、规划及对目标用户的理解，梳理出产品的架构，前期可先引用轻量级的产品架构，在后期业务或用户场景拓展的时候再去扩展产品架构。
梳理产品流程：总体的业务流程规划，如果是系统级别的产品流程梳理，则一般需要同时串联各种角色。
· 误区一：设计产品原型的目的是让程序员能比较直观地了解产品功能和使用流程，是否是高保真并不是最重要的，切忌在这方面过于纠结。
· 误区二：很多产品经理一拿到需求就开始画原型，忽视了对需求的分析和梳理工作。
· 误区三：原型设计之前没有梳理清楚流程逻辑和功能点，导致原型设计返工频繁。
原型设计：原型设计是产品经理做得比较多的工作，这时就要尽可能地考虑用户体验了，原型设计的时候尽量避免以下三个误区。
PRD文档撰写：形式并不重要，重要的是条理清晰，描述准确，不要遗漏异常情况。
产品设计
版本开发计划
总体进度计划
与团队成员进行协调和沟通
负责向老板汇报项目进度、项目成果等
项目沟通
项目跟进
项目管理
数据埋点
数据使用及分析
根据数据去优化与迭代产品
数据分析
硬技能
指通过研究个体和群体对自身情绪和他人情绪的认知，培养驾驭情绪的能力，并由此产生良好的管理效果。简单来说，就是一种善于掌控自我、控制和调节自己和他人情绪的能力。
情绪管理
时间管理并不是把安排的所有事做完，而是有效运用时间。时间管理除了要决定做什么事，还要决定什么事不应该做。
· 一个To Do List，写上所有必须做的事，按照时间排序。
· 一个Watch List，写上所有遇到的需要不断跟进的事情。
· 一个Later List，写上其他所有的事情，所有你想做的或有时间再去做的事情。
给自己列任务清单
时间管理
目标管理是指以目标为导向，以人为中心，以成果为标准，使组织和个人取得最佳业绩的现代管理方法，又称成果管理。目标管理的方法是拆分和设立目标。
目标管理
产品经理应该通过工具（如印象笔记、有道云笔记等）建立知识体系，并不断完善，进行知识的收集消化、吸收创新。
知识管理
自我管理
将经典书籍作为核心进行系统性学习；对于网上充斥的信息，尤其是碎片化信息，要有选择地进行深度阅读。
系统的学习
促进我们对输入信息进行进一步转化和加工，产生自己独特的理解和思考，了解事物背后的底层运转逻辑。
思考
行动指的是表达和实践，快速提高自己某一领域的能力，最好的方法是分享或教给别人。
行动或实践
学习能力
1）所谓沟通，其实就是“了解需求，反馈所需”
2）沟通不是为了说服，而是为了更好地认识世界
沟通理念
1）懂得倾听
头脑风暴、信息分享、问题解决。
2）团队沟通
3）有自己的观点，敢于表达
沟通技巧
沟通能力
产品经理必须具有关注整个宏观市场环境的视野和能力，虽然在现实中大部分产品经理依旧在做执行层面的工作，对于大环境的关注可能主要集中在产品总监或更高领导层面。但是对于一个产品经理的长期成长而言，对整个大市场环境的关注，不但可以使产品经理具有更好的产品视野，也会让产品经理在产品设计的过程中更加敏锐，可以更好地对产品远景规划作出正确的判断。
商业感
要对产品和用户有感觉。
事物的原因，原因的原因，原因的原因的原因。
洞察力
一是看过了足够多好的东西，二是对细节孜孜不倦的追求。
审美能力
创造力和想象力是一样的，我们只能依靠生活中的点滴积累，平时注意观察、多体验生活、多思考、多领悟
创造力
产品感
软技能
MECE（Mutually Exclusive Collectively Exhaustive）是相互独立、完全穷尽的意思。相互独立，意味着能够将影响问题的原因拆分成有明确区分、互不重叠的各个因素。完全穷尽，意味着全面周密，毫无遗漏。
（1）我是不是把所有的可能因素都考虑到了，有没有遗漏？如果有，再去找。
（2）这些因素之间有没有互相重叠的部分？如果有，进行去重。
通常运用MECE都是从一个最高层的问题开始，逐层向下进行分解，实际运用中只需要不停问自己以下两个问题：
在产品经理的实际工作中，会经常运用到MECE原则，典型的有网站或App的注册登录流程梳理
在梳理产品流程的过程中，需要将产品的初始状态、常态、边界状态、错误状态都考虑清楚。
MECE原则
归纳是把具备某种相同属性的事物一一列举出来，然后寻找共通点。
演绎是把互相有影响的因素，按照因果顺序、时间顺序、重要程度排列出来，再寻找突破口。
（1）这个问题产生的背景是什么？（来龙去脉，历史原因）
（2）和这个问题有关的人物和因素有哪些？（记住MECE原则，用归纳法一一列举出来）
（3）哪些是导致这个问题的关键原因？
（4）哪些是导致这个问题的次要原因？
（5）解决这个问题有哪些方法？（用归纳法写出所有可能，用演绎法找到实施每种方法的具体步骤）
最直观的思维展现
归纳和演绎
演绎和归纳及MECE是分析思考过程；先说结论是思考以后的表述方法。
先说结论的人，在一开始就能够抓住别人的注意力，再通过层层递进的方式论证结论的正确性，听者就不会迷失方向。而能把结论讲清楚的人，往往也代表其有一整套完整的思考分析过程。
先说结论
逻辑思维
基础入门
1 发现市场痛点与初步的产品想法
2 做好竞品分析
（1）卖产品：低买高卖，通过售卖产品赚取差价，如各类电商网站、需要付费下载的App、企业SaaS软件服务等。
（2）卖流量：通常模式为先做好产品和内容，积累较大流量后进行广告售卖，如百度、腾讯、三大门户网站等；美丽说、蘑菇街这类电商导购其实也是卖流量。
（3）卖服务：为用户提供各类增值服务，如QQ的各类等级、钻、会员，网络游戏中的各种付费道具，以及其他各种付费会员网站。
（4）卖用户：这个有点属于灰色地带，某些互联网公司会出售用户资料来获利。
经典商业模式
（1）目标用户——目标用户群是谁，他们大概都有怎样的特性。
（2）价值主张——为什么用户会用你的产品，这款产品解决了用户什么样的痛点，典型的使用场景是怎样的。
（3）渠道——你和产品的用户如何产生联系，不管是你找到他们还是他们找到你，比如应用下载平台、微信公众号、互联网资讯、线下宣传、地推等。
（4）用户关系——用户接触到你的产品后，你们应建立怎样的关系。是一锤子买卖还是长期合作？能不能从用户身上获得持续的价值？用户口碑可不可以帮你发展更多的用户？
（5）收入来源——你怎样从提供的价值中取得收益，是售卖软件一次性收费，还是把平台做大售卖流量广告进行收费，抑或是租赁收费等其他赢利手段。
（6）核心资源——运转整个商业模式的核心要素，为了提供并销售这些价值，你必须拥有的资源，如资金、技术、人才，乃至流量、用户基数等。
（7）关键业务——商业运作中必须要从事的具体业务，就是产品具体如何服务于用户。一个商业模式可以有一个或多个关键业务，能有多少关键业务就要看整体的“盘子”大不大，阿里和微信就是两个截然不同的产品和商业生态，它们拥有的关键业务也是截然不同的。
（8）重要合作——哪些人或机构可以给予战略支持。比如腾讯内部的产品，基本只要上线就能够轻松获得千万级别的用户，就是因为有QQ的大力扶持。
（9）成本结构——你需要在哪些项目付出成本，成本决定了企业的生存时间，如果一开始没控制好成本，公司很难继续生存下去。
商业模式画布
3 产品的商业模式与运营推广
第一页，用几句话说明你发现目前市场中存在的空白点，或者存在的问题，以及这个问题有多严重。很多人写了三百张纸，抄上一些报告，投资人天天看这个，还需要你再告诉他吗？只需要一句话说清楚就可以。
第二页，你有什么解决方案，或者什么产品能够解决这个问题。你的方案或产品是什么，提供了怎样的功能？
第三页，你的产品面对的用户群是哪些？一定要有用户群的划分。
第四页，说明你的竞争力。为什么这件事情你能做，而别人不能做？或者如果这件事谁都能干，为什么要投资给你？你有什么特别的核心竞争力？有什么与众不同的地方？所以，关键不在于所干事情的大小，而在于你是否能比别人干得好，是否与别人干得不一样。
第五页，论证这个市场有多大，你认为这个市场的未来怎么样。
第六页，说明将如何挣钱。如果真的不知道怎么挣钱，你可以不说，可以老老实实地说，我不知道这个怎么挣钱，但是中国有1亿用户会用，肯定有它的价值。想不清楚如何挣钱没关系，投资人比你有经验，告诉他你的产品多有价值就行。
第七页，用简单的几句话告诉投资人，这个市场里有没有其他人在做，具体情况如何。不要说“我这个想法前无古人后无来者”这样的话，有其他人在做同样的事不可怕，重要的是你能不能对这个产业和行业有一个基本了解和客观认识，要说实话、干实事，可以进行一些简单的优劣分析。
第八页，突出自己的亮点。只要有一点比对方强就行。刚推出来的产品肯定有很多问题，说明你的优点在哪里。
第九页，做财务分析，可以做得简单一些。不要预计未来三年挣多少钱，没人会相信。说说未来一年或六个月需要多少钱，用这些钱干什么？
第十页，如果别人还愿意听下去，介绍一下自己的团队，如团队成员的优秀之处，以及自己做过什么。
BP撰写方法论
清晰、简洁、重点突出
观点要客观，不要套用模板
需要注意
4 商业计划书
绘模型
（1）需要：某些基本方面没有得到满足而产生的不足或短缺的感觉。
（2）欲望：想得到基本需要的具体满足物的愿望。
（3）需求：是对有能力购买且愿意购买的某个具体产品的欲望。
1 需求的本质
产品定位就是用一句话概括你的产品，包括使用人群、主要功能和产品特色。
用户需求主要包括三个要素：目标用户、使用场景、用户目标。
2 需求的前奏——产品定位及如何正确描述需求
通过问卷调查、用户访谈、行业数据报告等手段收集需求的方式。
找到同类竞争产品，深入体验竞品功能，为产品设计及需求收集寻求思路。
先明确讨论的议题，并且注意引导和发散大家的思维，让所有的人都能够参与其中。讨论时注意让参与者自由畅谈，并且不对他们产生的观点和说法进行任何批评，而且产生的观点要足够多。
头脑风暴
产品经理能够在用户的反馈中了解用户的使用情况，也能够通过用户反馈了解用户遇到的问题，以及用户的想法和期望。
用户反馈
包括常规的访客数据、浏览数据、在每个页面的浏览时长等概括数据，还包括比较精细的用户行为数据，如点击事件、转化漏斗、用户留存、用户画像等，这些都是产品数据的范畴。
3 需求收集——五种需求来源
比如当前技术不可能实现的或明显意义不大的、投入产出比比较低的、无匹配的产品使用场景的、明显不合理的需求等
筛掉明显不合理的需求
首先要了解需求的三个分类：用户描述的需求、用户实际想要的需求、用户的潜在需求
· 需求从哪里来，目标用户是谁？
· 有多少人有这样的需求？这个需求紧迫吗？
· 用户的痛点是什么？使用场景是什么？（用产品之前/后）
·（+1）怎么验证需求是否解决与解决效果如何？
“3+1思考法”去分析用户需求
做需求分析
少即多
需求的减法
4 需求分析和筛选
三个层次的用户需求：基本型需求、期望型需求和兴奋型需求
用户需求的重要性依次为：基本型需求>期望型需求>兴奋型需求。
KANO模型
判断需求重要性
考虑需求紧迫性
5 需求优先级排序
模块：一般来说，每个模块分为3～6个子模块是合理的，否则要考虑重新划分。
子模块：一级模块的二级分类。
功能：要给用户提供什么功能，给这个功能起一个名字。
功能描述：功能具体包含哪些操作，可以描述得具体一些。
用户价值描述：可以给用户提供什么价值。
需求优先级：这是整个Feature List工作的核心部分，判断的结果直接影响着将来产品的方向，只需要将之前评定的需求优先级照抄过来就好。
开发量：一般由研发部门的项目经理或开发者确定。
投入产出比：简单来说，就是商业价值除以开发工作量（或开发难度）。
备注：需要强调的或比较特殊的内容。
6 输出功能需求列表
不必考虑能不能做或者做了没用这样的限制，先不设置伪命题，只要觉得可以的都列出来，无论是靠谱的、不靠谱的，还是紧急的、不紧急的。
需求池需要产品经理经常去整理，不然就失去了需求池本身的意义。如果你不去整理，市场环境和用户行为都可能发生变化，任何一个产品的变化都是很快的，这个时间段的需求有可能过一段时间就失去意义了。
7 如何管理需求——需求池
描需求
在层级结构中，节点与其他相关节点之间存在父级/子级的关系。子节点代表着更狭义的概念，从属于代表着更广义类别的父节点。不是每个节点都有子节点，但是每个节点都有一个父节点，一直往上直到整个结构的父节点。层级关系的概念对于用户来说非常容易理解，同时软件也是倾向于层级的工作方式，因此这种类型的结构是最常见的。
层级结构（Hierarchical Structure）
自然结构不会遵循任何一致的模式。节点是逐一被连接起来的，同时这种结构没有太强烈的分类概念。自然结构对于探索一系列关系不明确或一直在演变的主题是很合适的。但是自然结构没有给用户提供一个清晰的指示，从而让用户能感觉他们在结构中的哪个部分。
自然结构（Organic Structures）
所谓线性结构，就是你用讲述故事的方式给用户介绍你的产品，多见于产品专题页、帮助文档的设计。
线性结构（Sequential Structures）
矩阵结构允许用户在节点与节点之间沿着两个或更多的‘维度’移动。由于每一个用户的需求都可以和矩阵中的一个‘轴’联系在一起，因此矩阵结构通常能帮助那些‘带着不同需求而来’的用户，使他们能在相同内容中寻找各自想要的东西。
矩阵结构（Matrix Structure）
典型的产品架构模型
做好分类
平衡用户与商业
为重要功能设置快捷入口
To C类的产品如何搭建产品架构
按功能模块进行划分
按业务逻辑进行划分
To B类产品如何搭建产品架构
易用性、稳定性、可扩展性
好的产品架构具有怎样的特性
搭框架
从产品经理的角度来理解，流程图其实就是一个用户使用产品的过程，基本的三要素是“从哪进—做什么—从哪走”。
用户操作行为流程图
本质就是可以通过角色、系统、模块的划分，将复杂的功能梳理切割清晰
泳道图
业务流程图（Transaction Flow）
页面流程图（Page Flow）
流程图
业务调研
梳理与呈现
评审与确认
确定产品流程
定流程
① 可以快速产出。
② 修改成本低。
低保真产品原型
① 便于梳理产品细节。
② 更容易让其他成员了解产品设计。
高保真产品原型
视觉设计师产出的UI设计稿
设计成品
产品原型
文字、下拉框、按钮、图标、图片等
界面元素
需要在原型设计上进行说明
数据逻辑
操作逻辑
设计原型时需要注意的事项
（1）产品概述及目标——背景介绍和产品目的。
（2）名词解释——声明文档中出现的名词的含义。
（3）数据词典——介绍本产品中数据的数据项、数据结构、数据流、数据存储、处理逻辑、外部实体等。
（4）文档阅读对象——声明本文档输出的阅读对象和注意事项。
1．概述
（1）产品整体流程——展示产品框架图和用户流程图。
（2）产品需求描述——描述产品核心功能：解决哪些情景下的哪些需求。
（3）产品版本规划——叙述产品版本迭代计划，包括版本号、主要模块、功能点、计划开发时间、计划结束时间、备注。
（4）产品框架——展示页面层级及备注信息。
（5）功能列表——展示产品功能名称、对应模块、功能说明、备注等信息。
2．产品描述
（1）流程图——包含流程图、顺序图和状态图等，这三种图都可以理解为UML图。
（2）界面原型——将产品概念具象化，也就是将交互原型设计稿贴上去。
（3）字段说明（包括数据词典）——描述产品功能页面包含哪些字段，以及字段的格式和限制要求等。
（4）业务说明（Use Case）——描述产品的业务场景及相关用户角色说明。
3．功能需求
（1）安全需求——能够抵挡住黑客的攻击，保证用户的数据不会丢失等。
（2）统计需求——梳理产品的埋点、统计需求，明确需要统计的相关指标。
（3）性能需求——产品最大并发数等。
（4）可用性需求——产品的加载速度、响应速度、浏览器的兼容性等。
4．非功能需求
产品需求文档（PRD）
1．简单，Don't make me think
2．以用户为中心
产品设计原则
抠细节
以用户需求进化为核心，采用迭代、循序渐进的方法进行软件开发的一种方法。
小步快跑，尽早交付
有项目计划，但也“拥抱变化”
版本周期内尽量不加任务
团队配置也要敏捷
敏捷开发也需要反思
特点
敏捷开发
分为五个阶段：需求分析、设计、编码、测试和维护
需求分析阶段通常定义系统的需求，明确系统的目标；
设计阶段通常确定系统使用什么数据库、系统模块的划分、各个模块的功能；
编码阶段用编程语言实现设计阶段的任务；
测试阶段主要测试功能是否实现，以及是否正确；
维护阶段根据用户新的需求重新修改系统，使系统运行正常，更加稳定。
瀑布式开发
抓住最核心的产品流程，剔除多余的功能或高级功能。
不同阶段的MVP目标不同
可以尝试任何产品形态
MVP（Minimum Viable Product，最小化可行产品）
首先你要有一个想法或灵感，然后通过MVP策略让产品快速上线，再通过数据来衡量用户的表现，如果反映好就保持并继续优化，如果反映不好就下线反思。
在精益分析方面，我们要做的就是不断试错，不断总结和分析，这样才能更好地知道产品迭代的方向是否正确。
精益分析
项目管理方法
项目目标
限制条件
人员分配
风险识别
任务分解
关键节点
成本规划
项目管理过程
产品经理负责产品研发、运营、成熟、衰退整个生命周期的把控。
项目经理则负责跟进一个项目，实现项目的范围、进度、成本、质量等目标，还要监督控制、协调管理整个项目过程，满足项目干系人的需求和期望。
产品经理和项目经理的差异
了解整个项目的来龙去脉，最好的方式是和上级或BOSS沟通
1）为什么要立项
明白整个项目的目标是什么，并找出最核心的目标
2）项目目标是什么
3）项目的相关人员有哪些
项目启动大会。清楚地传达项目要做什么、目标是什么、为什么要做、怎么做、谁来做等。
4）怎么立项
项目启动阶段
工作分解结构（WBS），指的是以可交付成果为导向，对项目要素进行的分组。
一般的工作任务分解方法有：按照产品的物理结构分解、按照产品的功能模块分解、按照实施过程分解、按照项目的地域分布分解等。比较常用的是先按功能模块分解，再结合产品的实施过程分解。
1）工作任务分解
定义的就是先做哪些任务，后做哪些任务。这时往往会用到在需求管理中使用到的KANO模型，通过明确任务的重要度和紧急度来梳理任务的优先级，优先处理重要且紧急的任务。
2）任务优先级安排
3）计划呈现——甘特图或其他
（1）客户没有参与项目。
（2）需求不明确或不完整。
（3）项目计划不合理。
（4）团队成员的精神状态不好。
（5）领导变更。
（6）技术风险。
4）风险控制
项目计划阶段
过程跟踪：主要是对项目执行过程的跟踪和监控，防止团队成员对计划理解产生偏差，导致执行阶段出现一些问题，跟踪的事物包括团队成员、任务、开支情况等。
例行项目会议：其实就是给项目制定一个固定的沟通渠道，这样才能让团队成员的沟通效率变高。
阶段性交付物审核：一个长期的项目计划一定是会被拆解为几个实施阶段的，那么对于阶段性的交付物就有必要进行审核了，这也是非常重要的一种监控手段。
里程碑报告：项目达到了一个里程碑时，就可以做一次里程碑报告。
变更管理：为了适应项目运行过程中与项目相关的各种因素的变化，保证项目目标的实现而对项目计划进行的一些调整。
项目执行和监控阶段
（1）编写测试计划、规划详细的测试方案、编写测试用例。
（2）根据测试计划搭建和维护测试环境。
（3）执行测试工作，提交测试报告，包括编写用于测试的自动测试脚本，完整地记录测试结果，编写完整的测试报告等相关的技术文档。
（4）对测试中发现的问题进行详细分析和准确定位，与开发人员讨论缺陷解决方案。
（5）提出对产品进一步改进的建议，对测试结果进行总结与统计分析，对测试进行跟踪，并提出反馈意见。
功能Bug测试
（1）是否进行高危函数扫描？
（2）是否进行安全漏洞扫描？
（3）是否有内存泄漏的检测和结果（如果是C/C++代码）？
（4）不必要log是否删除了，以及log信息是否清晰、完整、详细？
（5）是否影响其他相关模块功能的表现？
（6）自身系统压力是否已评估？
（7）后端支撑系统负载变化是否已评估？
开发人员走查
（1）需求清单是否有调整或更新？例如每个功能特性是否有确定的输入、处理、输出。
（2）需求文档是否补充完整或及时更新？例如交互图、设计稿是否已经更新。
（3）产品更新说明文档是否已经提交并进行客服培训。
（4）产品页面文案是否已检查（包括但不限于页面文字、广告语）。
（5）已有功能/标识的改动在其他模块是否覆盖完整？
（6）数据统计需求是否明确提出？数据是否正常上报？
产品走查
（1）页面的交互动作，操作及其反馈。
（2）交互控件的各种状态，初始态、常态、边界态、错误状态等的情况确认。
（3）其他交互细节，如默认值是否正确、第一屏的高度、产品文案等。
交互与设计走查
（1）产品的冷启动是否已经准备完毕，种子用户的招募工作是否已经开启？
（2）内容运营是否已经规划？内容的更新机制是否已经确认，并进行部署，是自动更新还是人工更新？
（3）活动运营是否已经规划？是否有专人负责？周期性的活动是否已经有配套的运营模板？
（4）用户运营是否已经规划？拉新、留存、促活的关键步骤都有哪些？
（5）新媒体运营的账号是否已经建立，是否有专人负责？
（6）渠道拓展是否已经规划？是否发展代理？是否要引入合作伙伴，合作伙伴的资质应该是怎样的？
运营人员走查
文档的归档和项目庆功
项目收尾总结
项目收尾阶段
好的项目管理流程
产品经理更多的是从用户需求出发，而设计师在保证产品的功能外则往往会注重产品的颜值表达；产品经理更依靠逻辑思维和结构化思维，设计师大多偏感性一些。
所以在产品设计的过程中，需要不断地和设计师沟通，提醒他们设计目标是什么，以及做这个产品功能依存的是怎样的一种逻辑。
1．从用户的角度出发
2．强调业务目标
3．用数据说话
4．提供一些竞品案例
沟通建议
产品经理VS设计师
1．逻辑和业务为先
2．平等相容
3．沟通后做记录
4．多表扬
产品经理VS程序员
编写测试用例之前，产品经理应该和测试工程师们好好宣讲产品，把产品建设的来龙去脉简单介绍一下，如产品定位、目标用户、主要的使用场景、解决用户的什么痛点等；还需要把每一个大的功能模块讲清楚，如核心操作流程、业务逻辑、边界情况、用户的使用场景、目标；也要告知产品主要是在什么系统、平台运行，有没有调用外部接口等。
产品经理VS测试工程师
1．明确产品定位和产品价值
2．明确运营流程
3．明确产品需求决策权
4．加强产品沟通
产品经理VS产品运营
把销售者作为公司的一个客户，这样在处理上述问题的时候就会更好地站在销售者、客服的角度来考虑问题。
产品经理也可以站在销售者的角度去思考，为什么他们对这个需求这么迫切和强烈，到底是因为他们自己觉得很有价值，还是客户向他们反馈这个需求很有价值；如果做这个需求，能给客户带去什么价值，能给销售者带来什么好处，对产品本身而言是提升还是下降。
产品经理VS销售
1．有数据时，数据第一
2．没数据时，逻辑第一
3．碰到逻辑也解决不了的问题时，谁负责谁决策
产品经理VS老板
沟通
（1）自有数据分析系统——企业内部使用的数据产品，如自建数据分析（BI）和推荐系统。公司自有的数据是最原始的数据，也是最可靠、最全面的。一般而言，有条件的情况下都以内部数据为准。
（2）第三方数据分析工具——这是借助外部工具获得的数据，如友盟、百度统计、cnzz统计、诸葛io、Growing io等。
（3）行业指数数据等——指用户均可使用的如Google Trends和百度指数、微信指数、淘宝指数等。
数据从哪里获取
1．用户行为统计
2．漏斗分析
3．留存分析
常见的数据分析模型
第一种：代码埋点。代码埋点是指在代码的关键部位植入N行代码，追踪用户的行为，得到想要的数据。简单来说，就是找节点，布代码，收数据。
第二种：框架式埋点。框架式埋点也称“可视化埋点”，框架式埋点很好地解决了代码埋点的埋点代价大和更新代价大两个问题。
第三种：无埋点。所谓的无埋点，只要页面上嵌入SDK，就可以采集页面上所有的点击行为，并通过界面配置的方式对关键行为进行定义，这样便完成了所谓的“无埋点”数据采集。使用这种方案，必须在产品中嵌入SDK，等于做了一个统一的埋点，所以“无埋点”的叫法实际上是“全埋点”的代名词。
主流的埋点技术
1．产品的目标及当下的首要问题
2．选择少量、重要的用户行为开始记录和分析
“用户行为”不等同于应用的页面（界面）或点击操作，其实这完全是两件事情。用户行为是更加具体的一个事件定义，比如用户“提交订单”这个行为，就可以定义为一个事件，但是如果用页面点击去定义它，则过于抽象不具体，不能让其他人很直观地感受到这个事件定义出来到底是做什么的。
3．定义事件
行为事件-描述
4．制作埋点表
5．与研发人员进行沟通
埋点过程
新功能是否受欢迎
对产品流程转化率是否有提升
对产品整体留存的影响
用户究竟如何使用新功能
如何通过数据分析衡量产品改版的效果
· 获取（Acquisition）：用户如何发现（并来到）你的产品？
· 激活（Activation）：用户的第一次使用体验如何？
· 留存（Retention）：用户是否还会回到产品（重复使用）？
· 收益（Revenue）：产品怎样（通过用户）赚钱？
· 推荐（Referral）：用户是否愿意告诉其他用户？
AARRR模型
产品之旅：产品经理的方法论与实战进阶
0 条评论
回复 删除
下一页
