产品cv值是什么意思，什么是cvc产品

产品方案的需求评审，是所有产品经理在进入落地开发前必须经历的一个重要环节。需求评审的目的、意义、方法网上可以查阅到的资料很多，不再重复啰嗦了，今天我只想结合过往的项目案例，复盘总结一下自己的一些观点意见。

六个步骤

Step1 – 明确目标

明确这次需求评审的目标是什么，目标有三个层次：个人目标、产品线（或小组）目标、团队目标。说白了，就是能通过这次会议达到什么目的、解决什么问题，参会各方能否达成一致共识，便于后续的落地执行。举例如下：

1、个人目标：

我需要让开发、测试认真了解清楚需求，形成会议纪要，不要出现会上说的是A逻辑，实际提测时发现是B逻辑，减少扯皮的情况。

2、产品线目标：

我需要其它部门的人协调资源来配合。开发、测试能认同这次大版本迭代的产品方案，实现起来有技术可行性。

3、团队目标：

我策划的商业模式或产品创新，具备商业价值且有可落地的执行方案，能够为其它部门解决问题，或提升公司盈利等，得到公司管理层的一致认可，成功立项。

Step2 – 三个原则

1、不要强迫或说服，而是配合与共识

着重突出各方所获得的价值，实现共赢的局面。

别想着“告知、说服”别人你的想法，而是通过“抛观点、看数据、说结论”，再讨论，和各方达成共识的过程。出发点如果是“说服”，各方必然会找出自己经历的项目中比较极端或失败的案例来支撑自己观点，从而陷入长时间的辩论中。

2、不要在不同观点上过于纠结，浪费时间

一定要有结论，一定要有会议纪要，便于会后的分工、执行、跟踪、复盘。

“倾听、开放、包容”心态很重要，要抱着求同存异的观点来解决问题。在整个需求评审的过程中一定有大大小小的问题，不同的声音，对于彼此认可的地方确认完毕后快速带过，对于彼此不认可的地方不要纠结，如果讨论了10分钟以上仍然没有结论，就记下这个问题，先进行后面的内容，最后再掉回头来讨论之前有争议的问题。

3、一定要给所有人明确目标、结果

我经常会发现“新人”在开需求评审会的时候，一上来就讲交互流程，功能，这是大忌。就算全部是本项目组日常一起工作的小伙伴，但信息永远不可能做到实时同步，需求首先是汇总到产品经理，再进行需求分析，设定优先级，在不懂技术的小伙伴眼前只是一个小功能，但可能牵扯到的是整个数据结构发生的变化。然后就可能会出现开发工作量大扯皮的循环了。

一定要说清楚我们这个版本要“为什么做、怎么做、结果是什么”这三个方面，便于大家理解你为什么要这么做？做的好不好如何评价，快速达成共识。

Step3 – 评审前

1、按需求深度，明确和谁进行需求评审

如果是一个小功能迭代，比如“增加一个字段类型”，那么可能只需要技术、运营，二三个人就能快速搞定。如果是BUG，直接去找技术一个人也可以。

如果是一个中大型需求，比如“SKU推荐匹配机制优化”，那么涉及到的人就比较多，但是除了技术、业务关联方以外，UE / UI同学不能忽视。很多公司产品和设计经常是二个部门，经常会遇到“这个事情我不了解，能不能把需求再说一遍，便于我更好的把握设计风格”之类的问题。

特别注意的是，中大型项目一次需求评审基本是搞不定的。

2、保证文档物料齐全

可能涉及到的文档包括（不是每项都需要，根据需求评审的深度）：

（1）BRD & MRD、竞品分析、产品原型（低/中/高保真）等；

（2）《PRD产品需求说明》，产研层面，面向技术同学；

（3）《业务流程说明》，协作层面，面向销售、交付、客服、财务法务同学；

（4）《线上运营数据分析》，运营层面，北极星指标是否满足预期；

（5）《用户体验地图》、《行为路径分析》等主要用于增长迭代。

3、发起会议通知

务必保证业务关联方的核心负责人到场，个别干系人可私下再沟通。

核心要素：会议主题、时间、地点、形式（线上、线下）、主持人、会议流程。

4、提前到达会议室（重要）

建议提前10分钟左右到达会议室，连接投影、远程设备等，不要等到会议开始后才发现这个那个没法用，会对参会人员造成不好的体验。

5、提前小范围沟通（技巧）

不要默默的准备产品方案（闭门造车），产品设计的过程，也是一个业务沟通确认的过程，但也不是凡事都找别人先沟通。

举个例子：

在涉及到跨部门配合，多人协作需要时会特别重要。提前让对方知道你准备做什么事情，需要怎么样的配合，获得对方的认可及支持，会大大减少在评审会过程中被质疑和挑战的可能性，从而在一个快速、高效的过程中，达成大家的共识。

再说直白一点，假设有3个部门参与评审，其中2个直接关联的业务部门，如果事前和2个直接关联的部门确认好，那么评审会上需要沟通的是这3个部门的协同问题，而不是产品本身的设计问题，将会极大的提高评审会的通过效率。

Step4 – 评审中

1、明确会议背景及目标

按照Step1中制定的本次会议的目标，在正式进入方案评审之前，可以先说明本次评审的背景是什么，需要完成哪些事儿，希望达成的目的是什么，评审会分几个环节，每个环节大致的时间需要多久等等，让与会者对评审会有一定的心理预期。其实这部分工作可提前在邀请邮件中就体现出来，待正式开始需求评审之前，稍微提一下即可，那样则可以把更多的时间预留给后面的环节。

回顾Step2中第3点所说，不要直接进入产品方案的演示。（重要的事情说三遍！）这对进入下一步“说清楚需求的价值”，做什么，为什么做，有什么价值这些核心要点没有任何帮助！试问，前戏都没做好，直接开干，对方会爽吗？

2、说清楚需求的价值

和大家说清楚你这个需求的价值，从三个纬度切入：

（1）做什么：确认分层目标用户，及用户分别有哪些需求。

（2）为什么做：用户使用的具体场景，是否满足用户的诉求。

（3）有什么价值：帮用户和公司解决了什么问题。

2.1 做什么：确认分层目标用户，及用户分别有哪些需求

在需求分析时，首先要确认分层目标用户，及对应的用户分别有哪些需求，或者是某个需求涉及到了哪些用户，都是为了满足用户的需求，只有确认了产品的目标用户，才能根据实际需求设计产品方案。产品思维其实就是一个“场景”化的还原过程。

二种方法：

（1）定性的方式。常用的做法是用户访谈，通过和目标用户进行深入的沟通和交流，观察记录目标用户对于产品使用的意见。产品经理需要分析和洞察用户描述中，未被满足的痛点来挖掘用户的深层次需求。

（2）定量的方式。常用的做法是调查问卷。通过问卷的方式收集目标用户的需求。但是问卷的设计是一门学问，搞的不好浪费时间还得不到答案。

2.2 确认需求的使用场景

需要考虑用户使用的具体场景，根据使用场景设计产品方案能提升用户的使用体验，让用户在使用中感知到便捷。

案例：以“某B端后台业务操作”为例：

点击“身份验证”按钮后，采用了弹窗的交互形式。

这样设计带来的困境是，业务操作人员使用的电脑屏幕较小，分辨率较低，在窗口之间需要反复的进行“关闭，再次打开”的操作，所以造成了部分业务操作人员，会首先将身份验证窗口中的很多内容，复制到一个新页面中（相当于借助了一个记事本功能）。带来的问题是操作效率的降低和用户体验上的不舒适。

但是在产品设计的过程中，采用弹窗的形式本身并没有任何问题，但在用户实际使用的场景中就出现了痛点。而发现这一痛点采用的就是“定性”的方式，通过观察调查员的实际操作过程，发现了这一痛点。

2.3 需求能够解决用户的什么问题

判断一个需求是否有价值，最重要的一点就是看需求能够解决用户的什么问题。产品需要根据用户在实际生活、学习或者工作中遇到的问题来进行设计，帮助用户解决问题。

仍然以“某B端后台业务操作”界面为例，解决方案通过软件+硬件的方式实现。

（1）首先观察整体的页面排版布局，在高分辨率大屏幕（1920*1080以上）时，页面左右二端出现了大面积的留白区域（系统页面设计分辨率是1300），这是可以利用的显示区域，如下图所示，左侧操作区出现大面积留白：

（2）软件层面，使用“左右拆分视图”，左侧操作录入，右侧显示弹窗中的内容，方案设计之前，确认检查拆分视图的可显示区域，并做大致的宽度测算。

（3）硬件层面，为部分小屏幕员工，采购一台二手的1920*1080及以上分辨率的显示器，配合解决上述问题。以达到提升操作效率的目的。

3、掌控节奏，切勿争（si）论（B）

正确的坚持自己的想法很重要，当然前提是“正确的”坚持，经常会遇到的问题是 “我觉得用户不一定会喜欢的、我觉得这让用户怎么样……”，此时正确的姿势应该是把问题拆解，要么用严谨的逻辑或者数据说服对方，要么就是虚心请教，站在对方的角度去思考这个问题，不用马上回答，可以回复“这个问题我们再全面思考一下，如果有不明白的地方到时还需要请教你，待问题明确后也会同步信息给大家”。

插播一句：互联网行业，用数据结果做支撑，可以解决一切争（si）论（B）。

会议中可以预留FAQ答疑环节，在会议流程中也可以明确的标注出来。FAQ答疑看个人掌控能力，可以讲到哪有问题立马提出来并回答，也可以是先完整介绍某个功能模块后，再请与参会者统一提问并解答，以免中间被打断，导致效率打折。

在评审会的讨论中，产品经理要始终扮演问题解决者的角色，不是对抗，而是把握局面，不要让沟通陷入死胡同。

Step5 – 评审后

评审会后要做的事情大致以下几项：

（1）发送会议纪要，对会议中达成的共识做出总结，和大家同步以上信息；

（2）整理遗留问题，找相关同学沟通解决；

（3）完善方案，更新产品文档，上传至wiki、蓝湖等协同工具；

（4）更新后续工作计划，明确责任人及反馈时间。

Step6 – 定期复盘

产品经理需要通过不断提高自己的专业度，提升自己在团队的可信度。

每条产品线，应定期在迭代或项目验收后进行复盘总结，一方面是在微观层面上复盘产品设计中发现的问题，另一方面也要从宏观层面复盘在完整产研链路过程中遇到的问题（例如流程、协作、对接等问题），共同提升团队的整体产品专业能力。

产品经理有二类人群，一类是功能型产品，完成功能设计，解决某一项需求。

而另一类是业务型产品，真正的做到优化业务、赋能业务最终能驱动业务。

最后，失败不是成功之母，总结才是成功之母。哪怕每天提高0.1%，一年后就是一个全新的自己！

游戏试玩赚钱，添加客服微信：709425133  备注：游戏试玩！