产品经理如何评估项目上线后效果

① 产品经理如何评估需求价值

如果我最初问消费者他们想要什么，他们会告诉我‘要一匹更快的马!’——亨利福特
每一个产品狗都应该很熟悉这句话，正如码农喜欢将’对象’、’实例化’，’高内聚、低耦合’等挂在嘴边一般，但熟悉的并不一定真正了解，而要在实践中做到，知和行并不是天然一致的。
用户需求是产品经理工作的基本出发点，不管是前期的行业调研、竞品分析，还是产品研发过程的沟通传达，还是产品上线后持续的迭代改进，头脑里都需要围绕用户需求展开。
产品经理要挖掘出真实的用户需求，是需要花些功夫的。用户需求，字面上看，由用户和需求两个词组成。分解来看，
首先，你的产品不是氧气，不是黄金，不可能所有人都需要，因此要确定具体的目标用户，越精准越好，通过用户研究来确定核心用户。然后去了解这些用户在现实生活中，或是在使用别的产品过程存在哪些问题，这些问题是用户们需要被满足，但尚未被满足的，即所谓的痛点。
挖掘核心用户的痛点，可以通过数据分析、用户访谈、可用性测试、问卷调查等方式，另外，在研究竞品的过程中，产品经理尽量让自己变成小白，初步去感受竞品的不足，并思考潜在的机会。
通过以上两步，就能给出用户画像了。简单的理解，用户画像就是真实用户的虚拟化表达，但具备了真实用户的典型特征，以此为基础，产品经理就要从用户和需求的分析中加工出用户需求了。

② 产品经理要怎么做一个复盘总结

很多公司（包括我所在的公司），要求员工要按时提交：每日工作总结、每周工作总结、月度述职报告、季度述职报告、半年度述职报告、年度述职报告。所以，我们每个人，每天都在做着复盘。有些是我们意识到，但更多的是我们无法意识到的复盘。

一、 首先，什么是复盘

一个项目，不管是0到1或者是版本迭代，基本都会包含以下几个核心阶段（见下图）。产品复盘就是把每个阶段中的具体工作进行分解，分析每一项工作的进展是否顺利，问题点在哪、以及如何更好的优化。

二、 其次，为什么要复盘

之前的文章中，我表述了一个观点，“产品经理天然的路线就是走向管理”。而作为走向管理的第一步，就是要会总结得失。每一个项目从开始到结束，过程中或多或少都会出现计划之外的突发状况。而复盘就是是绝佳的反思的机会，产品上的得与失，通过一条一条的罗列，不断深入思考，提升自己的总结能力。

产品经理核心的能力之一，就是总结能力，将收集到的需求建议、竞品优势等进行归纳整理，结合项目自身的差异点才能形成自己的需求思路。

三、 最后，怎么做复盘

前文已经说过，复盘就是对具体工作进行分解，分析问题点和如何改进，以下就任务分解之后的复盘点，进行阐述。

1 项目目标复盘

1.1 项目进度复盘

• 1.1.1 是否按照原计划交付时间交付？

• 1.1.2 原计划的需求点实现了多少？哪些需求点没有按计划实现？每一个需求点延后原因分别是什么？

• 1.1.3 哪些里程碑有延迟，延迟原因是什么？

1.2 项目结果复盘

• 1.2.1 项目中出现了哪些意外？为什么会出现这些意外？

• 1.2.2 用户对新增功能点的接受程度和项目规划中的是否一致？

2 需求阶段复盘

2.1 需求定义复盘：

• 2.1.1 是否提供完整的需求输出，包括：原型、MRD、PRD、UML等

• 2.1.2 设计师、交互师、开发人员分别对需求是否明确：如果出现需求不明确的情况，将会严重影响项目的进度和质量。

• 2.1.3 是否对典型用户和使用场景有清晰的描述？

2.2 需求变更复盘

• 2.2.1 需求变更次数：敏捷开发已经将需求变更的影响降到最低，但是较少的需求变更仍然是项目进展顺利的前提之一。

• 2.2.2 哪些需求变更影响了项目实际进度

• 2.2.3 每次变更的原因：领导干预？前期考虑欠缺？需求无法实现？分析每一次的变更原因，可以在后期项目中进行合理的避免。

• 2.2.4 每个项目成员是否都清晰的知道每一次的变更：只有每位项目成员清楚的了解每次需求变更，并做好充分的沟通，才能保证项目的进度和质量。

• 2.2.5 项目成员是否能接收需求变更：这就要求每次需求变更，都要和相关人员做好沟通。

3 设计阶段复盘

• 3.1 是否确定视觉设计的最终审核人？

• 3.2 UI设计产出是否符合统一标准？

• 3.3 设计工作是否影响开发工作的进度？影响原因是什么？

• 3.4 产品设计工作在什么时候，由谁来完成的？

4 开发阶段复盘

4.1 工期评估复盘

• 4.1.1 开发实施前，是否有充分的时间做工期预估：工期评估一方面是让项目成员能够对项目的整体进度有所准备，也是对项目需求进行详细梳理的过程。

• 4.1.2 工期预估与实际开发时间是否有差异，及差异原因分析

4.2 开发文档复盘

• 4.2.1 是否有提供开发文档？

• 4.2.2 开发文档是否符合规范

4.3 突发状况复盘

• 4.3.1 是否出现需求无法实现的状况？原因是什么？

• 4.3.2 是否出现团队成员变动情况？如何应对成员变动？后期如何避免？

• 4.3.3 是否出现功能模块与需求不符的情况？出现原因是什么？

4.4 Code Review复盘

• 4.4.1 是如何进行的：包括如何分工，如何复查等。

• 4.4.2 Code Review结果是什么？

• 4.4.3 是否严格执行了代码规范？对不规范的代码如何处理？

5 测试阶段复盘

5.1 测试计划复盘

• 5.1.1 是否有完整、准确的测试用例？

• 5.1.2 是否有一个测试计划？这样的计划是否有效？

• 5.1.3 团队是如何测试并跟踪产品开发效果的？

5.2 测试工具复盘

• 5.2.1 使用了哪些测试工具来帮助测试？是否可以持续使用？

• 5.2.2 测试的时间、人力和软件/硬件资源是否足够?

5.3 测试结果复盘

• 5.3.1 哪个功能模块产生的Bug最多，为什么？

• 5.3.2 哪些BUG出现回滚，原因是什么？

6 上线阶段复盘

6.1 验收复盘

• 6.1.1 是否进行了正式的上线验收？

• 6.1.2 在正式发布的过程中是否有出现状况？后续如何避免？

• 6.1.3 上线前是否和运营、文案进行充分的沟通？

• 6.1.4 是否检查了数据埋点，数据埋点是否满足运营要求？

6.2 上线后效果复盘

• 6.2.1 在上线之后是否出现重大bug? 为什么测试阶段没有发现？

• 6.2.2 产品上线后的问题反馈渠道是否流程？

• 6.2.3 产品上线后收集到哪些问题反馈？都是什么类型？如何改进？

每次的项目复盘，都是对自己的一次拷问和锤炼，迭代型产品每逢3个版本进行一次复盘，一般情况下，发版的节奏是一个月一个版本，因此可以按照3个月的节奏进行复盘。

最后，每次的复盘结果都要形成文字记录，这将是你成长路上的重要积累！

③ 产品经理如何判断一个新功能是否应该添加

1. 最小化产品（不要一开始就把功能做得尽善尽美，而是先把必不可少的元素做上去，受用户欢迎了再继续迭代优化）

2. 灵活的入口（尽量不要把功能的入口给固定死了，否则该功能不受欢迎后撤下的话，显得动静比较大，就像刚装上一只手然后又被砍掉一样，可以挑些可线上灵活配置的入口，比如说 banner 或运营位）

3. 灰度发布（可以选择特定比例或特定类型的用户展示新功能）

4. 功能开关（有些功能的入口考虑到用户的操作场景，不得不将入口固定的时候，可以给它设置开关，如果不受欢迎的话把开关关掉，就可以恢复到之前的设计）

5. 数据校验（发布前做好数据埋点，功能上线后将收集到的数据与自己的预期相比较，太糟糕的话分析原因是什么，是功能不行还是设计不行，如果是功能不行则砍掉功能，如果是设计不行则优化设计，再次迭代上线）

④ 产品经理如何有效的进行项目管理

1.制定目标——明确目标

这个“目标”可以是项目测试通过封包的日期，也可以是上线发布日期，但一定要整个团队达成一致，如果上线，可能需要负责市场的同事参与知晓。

2.制定计划——明确计划

根据第一点明确了目标，那么项目成员可以开始制定计划，也可以是产品经理制定计划，一般包含几个关键checkpoint：

需求文档产出时间节点

交互文档产出节点

视觉稿产出节点

依赖的外部接口提供节点

开发送测节点

功能测试完成节点

全回归测试完成节点

这七个checkpoint可以根据时间情况有所增减，有人会问，明确这个计划的作用是什么呢？

3.评估风险

那么在制定计划后，项目每个成员根据计划，来确定该做什么、怎么做、什么时候完成。在多人跨团队的项目里这一步尤其重要，可以说这一步走好了，后面项目进程会非常顺畅。

咱们随意的列举一下曾经踩过的坑：A项目启动时没有交互文档，而开发的ERD/测试的用例都依赖交互文档；

依赖的接口（其他部门）直接说暂无排期，或者是3-4周后提供，那搞毛；

开发送测时间太晚导致测试时间不足。每个成员进行计划评估后，项目可能亮起了黄灯，产品经理得做点什么吧？

4.协调资源/修改计划

根据项目紧急程度、上级重视程度，及时的协调各种资源，优化排期，修改计划吧。

这时候可能会把123再来一遍，问题会越来越少，过程会越来越透明，进度会可视可控，是不是感觉嗨的不行。

沟通

与人打交道，第一靠情商，第二靠技巧，都不行，那就只能靠姿色了~好了，咱们言归正传。

1.沟通技巧

为何需要掌握沟通技巧？当团队十几人，几十人的时候，可能你会碰到各种性格色彩的“同事”，所以得有备无患。

第一步：知己知彼，了解团队里所有人的性格和工作习惯。

第二步：以其人之道还治其人之身，与性格张扬思维活跃的设计打交道、与寡言少语专注技术的程序员打交道、与一丝不苟非常严谨的测试打交道、与不太配合的其他部门同事打交道，用对方对容易接受的沟通方式以求迅速达成一致，good job！

2.沟通效率

何为效率，就是减少不必要的沟（fei）通（hua）。How？

能面对面，就别打电话；能打电话，就别QQ/RTX/LYNC。文字沟通难免会有理解不同，导致挖坑；面对面简短的表述我的问题、我需要的支持、什么时间，并及时得到反馈。

永远别相信对方口头承诺的，Never！线下电话or当面沟通完，一定出一封邮件，阐述清楚并得到对方确认，邮件在有些时候真的挺有用的。

会议之痛肯定有人懂，会议时间尽量选择碎片化时间，比如9:30、13:30、5：00，这样的话就不会总觉得“奥，我待会有个会”，时刻处于被会议影响的工作状态。

会议中要避免问题大范围的展开讨论，可记下问题会后详谈；注意控制会议进展，当然偶尔闲聊，但是注意控制时长，尽量在计划时间内搞定。

执行力

这里说的执行力，可以理解为提升团队的执行力。

计划再好，沟通再好，执行力不行，都是浮云...至于方法，可以从以下几个方面着手：

1.日常工作中能够及时响应；

2.每件事都有一个节点，反馈进度；

3.高效的推动力，自己负责的事情能够推动解决并跟进；

4.产出物的质量要高，包含各种文档、送测质量、测试质量，这点很关键，以后单独细细道来~

5.保持进步，项目不会只有一个，可能是一个接一个项目，产品经历可以从0到1，进行有效的项目管理。

弘博创新产品经理精品课程

内容来源弘博创新管理咨询

希望我们能为更多的人带来有用的知识和信息

⑤ 如何做一个产品经理

了解产品。作为一名产品经理，对自己所管辖的产品有一定的了解是非常重要的，毕竟产品经理是贯穿整个产品制造以及销售的人，所以，自己要先了解产品，才能更好的针对产品来做后面的工作。2/6指导产品生产。在整个生产环节，可以适当的指导产品生产，与技术人员取得密切的联系与沟通，这样才能在产品生产的过程中肩负起责任，毕竟像技术活之类的交给技术人员就可以了，但是产品经历仍然可以针对其它方面提出建议额。3/6具有创新意识。一个产品想要在市场上取得一个好的销售成果，想要获得好的口碑，那么在制造这个产品的时候就可以适当的融入一些创新意识，并且还要在之后的生产中不断的创新，以便于更方便人们的生活。这也是做一个产品经理应该做的。4/6打造独具特色的产品买点，作为产品经理，不仅要在产品制造的过程中严格的监制，更要在销售的时候严格把关，要像产品的销售好，那么就必须把这个产品能拿出来的买点来进行更好的打造。5/6及时的调整策略，产品经理换句话说就相当于是一个舵手，在发现产品制造或者销售过程中出现的问题的时候，要勇敢果断一点，发现策略不多就要及时的调整。6/6和员工以及上级处理好关系。虽然说产品经理主要负责产品的制造生产和销售，但是仍然需要和手里面的员工以及上级处理好关系，这样才能更好的得到一些消息，以及使整个部门更加的和谐团结。

⑥ 互联网产品经理如何做产品的策划和评估

据统计，高达80%的项目没有经过市场调研和充分的市场评估便匆匆上马，所以在这一部分产品中，失败了不足为奇，成功的话，纯粹是靠运气。
下面提出几点简单的市场调研和互联网产品项目的评估方法：
1 产品商业市场分析
分析潜在受众对产品的依赖程度，以及该依赖程度能否达成产品的战略目标;这一步非常关键。是决定一个产品是否上马做的重要依据。这一步的实施，需要相关的调研手段配合。举个例子，有个朋友想做一个B2C的电子商务网站“买菜网”，这个网站主要希望针对北京最大的居民社区回龙观和天通苑地区的居民网上买菜。我建议他派出调查员，首先到该地区的5家大型超市门口对买菜者分时段做调查，调查只有2个很简单的问题：
① 您是否愿意在网上买菜，直接送到您家里去? 是 否
② 接受一次买菜配送服务，您愿意花的配送费为如果是5%，8%，10%请您填写
5%时 A 没问题; B 有些犹豫; 8%时 A 没问题 B 有些犹豫;10%时 A没问题 B 有些犹豫
通过这2项调查的基础数据得出一些比例，然后综合这2两个地区居民的数量就可以完全计算出整个市场的容量，以及可能的赢利和支出情况;以及随着业务量的增长，赢利和支出的增长比例，评估出网站未来是否能良性增长。只要采样比例合理科学，这些数据是完全可以计算出来的。
产品经理自己需要知道，任何想法和产品是可以通过多种调研方法结合数学模型计算的，同时要用这个理念去影响公司领导和决策者。最终达到的效果就是公司上马的项目尽管少，但成功率极高。
2 竞争分析
列出互联网上相同产品和相近产品的列表，进行相关指标分析(主要是产品能达成目标的决定性指标)，在这个列表中，需要标明每个产品的特点和优势(这个产品依然活着的理由)。坦率地讲，互联网发展到今天，你能够想到的点子，大部分人家已经想到并实施了，或者是和你的想法比较相近。但只要做好市场占有量及差异化分析，同样存在成功的可能。
所以说，互联网产品经理一定要具备相当高的市场调研能力，也必须具备良好的洞察力、分析力、策划力;既要懂得市场和用户，也需要懂得产品和内容，甚至还需要懂得公司的战略和运营;正如Google中国的产品经理赵羽可所说的，“我希望和我们的产品经理一起推出用户最喜欢的产品和服务，前提条件就是他必须深刻理解用户，知道他们想要什么，同时还要有一定的商业眼光”。
3 达成这个产品的战略目标，是否还有其它的手段和方式。
再举个例子，某IT网站设计开发了一个即时通讯产品，2个目标，第一希望达成该网站的经销商战略，也就是希望经销商通过这个专门的IM工具能够找到客户，和客户沟通，和媒体沟通。第二，满足该公司内部及时通讯需要。尽管这个产品目前还在实施之中，还不能给出是否能成功或者最终失败的结论。但我们分析这个产品，很容易发现要达成这2个战略，其实有更为恰当、更加低成本的产品形式。桌面版的IM工具天下已定，除了目前主流的产品外，很少有成功的其它产品，所以做为产品经理应该反过来思考，从而选择更加合适的产品形式来达成目标。比如，在经销商页面上开发基于web的沟通功能，就能够避免桌面软件安装升级的巨大使用障碍。4 技术评估
技术因素在互联网产品的成功与否中已经占据到了绝对重要的位置。产品经理必须懂得一些程序设计及软件架构的方法，这样才能判断出，哪些功能用什么技术实现能够达到预期效果。粗略统计，在所有好的值得实施的想法中，又有大约80%的项目死于技术原因，这些因素包括：技术选型出现重大失误，产品软件架构不合适，技术实现没有达到预先设计的效果等等。所以从这个角度而言，互联网产品经理的人选最好是做技术出生的，比如，Google的互联网产品经理多产品经理都是资深的工程师出。