#本文为人人都是产品经理《原创激励计划》出品。

在团队工作中，产品经理需要身兼多职、兼顾多方意见。而产品版本迭代管理往往需要牵扯项目的多方面。那么，当产品经理着手版本迭代管理工作时，应当如何协调团队工作、做好过程控制、进而凝聚团队力量？本文作者便结合其自身经验向我们做出了清晰展示。

自春节到现在，我陷入一种困境里：突然间，我好像成了“夹心饼干”？

事情是这样的，由于业务变动，最近我开始负责一个核心产品的版本迭代管理。我敞开心扉拥抱变化，但两个月下来，事情比我想象中得更棘手。

先交代下背景。

在我之前的工作经历里，我和前线的团队交涉比较多，销售、售前架构师、产品架构师、服务商、ISV，都相对比较熟稔。熟稔到什么地步呢，就是他们跟我说声hi，我都几乎能料到他下一句话想问什么、想要什么，我可以怎么推杯换盏地应对他们。和他们站在同一条船上久了，我深谙支持项目有多不易，我理解客户对产品的诉求有多急切，也愿意尽最大努力去争取产品研发的资源投入。

但是，一切开始不一样了。自打我接手产品研发工作，开始负责产品整体规划和版本迭代管理后，我多了一重身份。随着我深入了解产品的细节，了解看似简单实则不易的需求背后沉淀了这么多研发、测试的人力后，我不得不站出来为产品研发团队说说话了。

这也就导致，我清楚客户需求的合理性和迫切性，但我也在警惕产品研发资源的不合理占用。于项目团队而言，作为产品接口人的我开始谨慎承诺，小心防守；于研发团队而言，作为项目经理的我抱着一揽子需求回来，生怕我狮子大开口。

里外不是人了不是？我反思过，是不是该去学一学怎么端水？

把情绪放一放，我给自己一个版本的试炼机会，也趁此摸清楚了项目支持和产品管理的平衡之术。

我和其他团队的产品经理聊了下，有些同学一开始就是走产品策划路线，始终站在产研的角度，专心琢磨如何让产品做得更好；有些同学一直都是在客户现场，或是出差去现场的路上，他懂行懂客户，能根据客户需求拟制解决方案。

其中不乏有产品经理负责版本迭代管理，但总会遇到各种各样的问题：怎么去权衡各大项目反馈的需求优先级？怎么应对空降的需求带来的资源占用？怎么让前线团队放心、让研发团队齐心呢？

不少团队都倾向于将产品研发管理专门交给项目经理去负责，由项目经理协调产品、设计、研发、测试的资源，并跟进整体版本迭代的进展。这的确权责分明，产品做需求，开发写代码，各司其职，何乐而不为？

可事实上，版本管理的重点不在于由产品研发团队中的哪个角色来承担，关键在于如何去管理这个版本。既然团队内暂时没有这样的角色来支撑，那么我大可以利用自己的多重身份“夹带私货”，不是吗？

一、不仅是规划版本规划版本前先规划产品roadmap。

为什么前线项目组总是源源不断地投递需求——我要斩断不重要不紧急的客户需求。

为什么研发同学总是下意识拒绝需求——我要调动产研资源实现优先级最高的产品能力。

从客户需求到产品能力之间是有Gap的，我要搭桥造梁，就需要一个支撑。

那么，怎么规划产品的阶段性里程碑？

1. 从团队KPI入手今年团队的考核目标是什么，是产品收入？用户活跃度？标杆案例数？项目的复制情况？

2. 制定个人OKR基于团队的目标，落实到个人所负责的产品目标，去看在该目标下你要输出的关键结果是什么。

比如你们考核的是要在全国范围内树立至少2个国家级标杆项目，那么对应的这类型项目最关注的需求场景是什么；为了满足这样的需求场景，产品要实现哪些能力、配套提供哪些服务支持。

3. KANO模型这是东京理工大学教授狩野纪昭（Noriaki Kano）发明的对用户需求分类和优先排序的工具，需求分五类：基本型需求、期望型需求、兴奋型需求、无差异型需求、反向型需求。

① 基本型需求（必备型需求）

客户认为必须有，没有的话这个功能就不具有交付意义的需求。

针对这类需求，一旦你没满足客户，客户的满意度将一落千丈，你可能马上就要被踢出局。比如顾客买一个保温杯，它能正常装热水，顾客不会为此感到满意；但如果这杯子有裂缝，杯盖拧不紧，或是保温效果差，那么顾客对这个杯子的满意度就会明显下降，投诉接踵而至。

② 期望型需求

客户期望你可以实现的需求，一旦你实现了，客户满意度会显著提升，你提供的产品超出客户期望越多，客户就越满意。

但相应的，如果你拒绝满足客户需求或是表现不好的话，客户也会立马提出不满。比如客户期望贵司提供的问题响应机制可以更快捷、故障处理可以更高效，那么一旦你优化了问题处理流程，提高对客户的响应效率，客户就越满意。

③ 兴奋型需求（魅力型需求）

客户既不会过分期望，又不会明显不满的需求，即，有更好，没有也能接受。

比如早期海底捞向客户推出生日当天全体员工向顾客唱生日歌，这种服务的确会让顾客惊喜，但如果不提供这个服务，顾客也不会不满。这类需求通常能在某些时机打动客户，赢得客户决策人更多的关注。

④ 无差异型需求

这类需求对客户没有影响，有或没有都无所谓。

这种需求怎么会被人提出来呢，可能是客户对标了不同的产品，或是灵光乍现想到的，这样的需求在应对的时候需要甄别，不必过分投入在这类需求上。

⑤ 反向型需求

该需求会引起大部分人的强烈不满，你实现该需求反而会降低客户的满意度。

比如客户管理层提出一些强管理的需求，乍一听很合理，但深究下来，这需求对员工不友好。即便你短暂地满足了客户高层的需求，但长远来看一定会收到客户的投诉，毕竟客户采购软件并不仅限于在管理层使用，更多时候还是为了服务于全体员工。

针对这类需求，你且缓缓，先冷静旁观，做好充分的客户需求调研后，再决定是否要做。

根据上述三方面，在实际规划产品蓝图时，可以从以下两方面去考虑：

一方面根据团队OKR划定产品方向，圈定几个需要冲刺的功能模块，分月度、季度去迭代功能、做项目验证，再炮制到其他项目中落地；另一方面摆正心态，正视客户反馈的需求，全力以赴满足基本型需求，重视产品义务范畴内的事项，确保在市场竞争中不丢分。同时，尽力去满足客户的期望型需求，提供大多数客户关注的额外服务和产品，引导客户的决策链对本产品有更多的倾向性；最后才是争取实现客户的兴奋型需求，提高客户用户的粘性和复购率。你看，通过层层过滤，你会发现有不少客户需求其实没那么重要，它并不能为产品的销售有什么催化作用，甚至在占用产研资源后还讨不到一点好处。

二、不仅是管理版本前文提到如何在规划版本前规划好产品阶段性的里程碑，围绕里程碑去规划每个月的版本内容和版本节奏。

但实际上在管理版本中最大的问题不在于做哪些需求，而是什么需求要先做。每一位架构师都认为自己负责的客户提的需求最靠谱、最重要、最紧急，动辄就是“这是某位CTO提的”、“这个需求已经上升到我司的某位高管”之类的……通往产品发布的管道就这么宽，全堵在这段路上，谁也动不了，谁也不想让。

这时候除了根据KANO模型对需求做一层初步的分类之后，每个类目下依然存在不少需求，怎么排优先级？

向外看，竞争对手相比你的优势在哪？它推崇的关键控标点有什么？研究竞品并不可耻，市场就这么大，池子里的鱼就这么多，为了捕获更多的猎物，取长补短也是顺理成章的。

向内看，你不必把这份责任全部放在自己身上，建立版本评审委员会，邀请领导、产品和研发负责人、前线反馈需求的架构师，共同来评审这些需求的优先级。通过责任公摊和事务公开，形成一个集体公认的版本需求池。

在需求池初具雏形后，你要及时组织产品研发团队开版本启动会，宣导需求池里的所有需求，请产品和研发初步给出工作量的预估。一个版本迭代的周期就这么长的时间，对于比较复杂的需求，适时地拉长阵线去细化产品方案，才能确保不浪费研发的资源。

记住，排优先级时，不可只关注客户需求而忽视了去建设能满足更多客户的核心优势。

在明确版本需求和需求的优先级后，我们再来看下如何调动资源投入到版本迭代。

1. 资源投入情况项目经理：负责整体版本规划和需求管理，跟进版本迭代进程，对版本的整体发布负责；产品经理：负责产品需求的方案设计和评审，负责与设计、研发、测试协作开展需求的建设，对需求的实现情况负责；研发：负责产品需求的技术方案设计和实现，把控需求的研发进度；设计：完成需求UI设计和视觉设计，输出设计切图；测试：输出测试用例，把控需求的质量。这些角色在参与版本迭代时都有各自的期望，在不同的环节里都需要换位思考下。

比如研发，最怕产品方案没考虑完全就火急火燎地找上来要技术实现，前期方案的不周全大概率会引发后期需求的变更，这对研发而言就是资源的浪费。

那么站在研发的角度，产品经理对待需求就不能只是在讲一个简单的用户故事，客户需求和产品能力之间的gap有多大，取决于你如何去理解需求、如何去细化需求场景、如何打磨好你的产品。

相应的，在版本迭代的过程中，项目经理预留给产品经理思考方案的时间要充分，不能为了满足更多的需求而忽视了产品的细节。产品不可只看细节，也不可全然不顾细节。

不注重各个方面的细节，终究会连累到之前积累的口碑；当所有人都盯着你缺的那一筐土的时候，没有人会关心已经堆好的九仞土山。

2. 团队机制与过程控制既然是一个长期工程，那么何不如从一开始就下功夫定流程，定机制，把涉及到的角色的工作地图画出来？

前面提到，我给自己一个版本的时间窗，去印证这个团队机制的可行性。具体流程是什么样呢？

1）明确版本节奏

一个半月2个小版本1个大版本（ab为小版本，c为大版本），小版本内部测试体验，大版本对外正式发布。

2）规范迭代流程

① 建立版本评审委员会，从版本规划开始，做好向上汇报和对内同步，保证信息公开透明。没错，你是版本总体负责人，但你没必要把很多责任往自己身上揽，尤其涉及到需要上升决策的事情，分摊责任也同样是在分摊风险。

② 版本需求确定后，预留充分的时间给到产品经理调研需求、设计产品方案，并树立一个标杆性事件：开展版本启动会。由各产品经理大体宣讲需求，明确需求的研发负责人，全员投票评估需求的合理性和可行性。

③ 需求进一步得到产品和研发的评估后，产品和研发负责人各自组成feature team，启动对需求的实现之路，再配合设计、测试的资源，让需求在版本发布计划的时间窗内有序地推进，并适时地同步进展和风险，确保需求相关人对需求的理解是一致的。

3）加强过程控制

流程是有了，但流程里涉及到的环节比较多，需要抓住最关键的部分加强管控。

一个是需求评审环节，这决定了这个需求后续的实现路径，绝不能轻视。对于相对复杂且重要的需求，对于空降的高优先级需求，能不能插队也不是研发或产品或架构师说了算，都必须严格上升到版本评审委员会共同决议。

一个是研发排期环节，版本的发布时间窗是基本固定的，研发排期的评估除了根据需求的优先级、实现的工作量之外，还要根据发布计划的时间点看能赶上哪一个发布计划，以确保给客户承诺的交付时间是相对可靠的。

一个是产品体验环节，不少团队在前期需求设计上严防死守，可一旦步入研发阶段，产品经理除了间或响应研发的问题咨询外，对需求本身的实现过程和实现结果是有点轻视的。

这里需要尤其重视需求研发完成后的产品体验环节，产品经理必须完整地按测试用例走查一遍功能，确保最终的功能与最初需求的设计是契合的。若有偏差，是否要变更或追加需求，则同样需要引入版本评审委员会（与该需求相关的人员）一起来评估。

三、不仅是一颗糖产品如期发布了，这时候我对前线的架构师是否就有了交代？不够。

回想下，架构师对产品的能力是清晰的吗？他们提的客户需求为什么在不少产品研发同学看来不太合理呢？归根结底是因为项目支持和产品建设脱节了。

两拨人，一拨人忙着做项目，一拨人忙着做需求，各自作战，各自为政。

你可能会说，产品做出来不就是为了更好地在项目里售卖和交付吗？没错，但在实际运作的过程中确实存在这样的问题。于是你会发现，前线团队对产品一知半解，产研团队对项目一穷二白。

这是常态，但可以被改变。

回过头来看整个版本迭代流程，你会发现有很多环节完全可以借助前线架构师的力量。

在版本规划初期，项目经理可以请架构师给出有力的项目背景佐证需求的合理性；在需求调研时，产品经理与架构师的深入访谈，可以更充分地了解需求场景和目标，如有必要也可以跟架构师一起拜访客户；在需求研发完成转产品体验时，产品经理邀请架构师一起体验功能，确保功能的效果与架构师的预期一致；在产品发布后，产品经理可以请架构师一同编制功能故事，描述功能的操作路径、实现效果和价值，以便客户更好地使用功能。整个过程里，前线架构师与产研团队有了更多的互动和融合，这是我们给到架构师的一颗糖，它不仅提升了架构师对产品的理解力，也加深了产研团队对客户的认识。

同样的，产品发布后交付给到客户后，这时候我对产研团队是否就有了交代？不够。

很多时候一个新版本从规划到发布，一个多月过去了。这一个月期间，客户也许还在追着要这个能力，也许早已不在意这个需求。但是产研资源也确确实实地投入进来了，他们需要一颗糖，可能不够甜，但总比交付出去下落不明要好得多。

因此我们会要求，前线实施团队交付新版本给客户后，需要主动了解客户的使用情况：有没有用？用得怎么样？有全面推广起来吗？还有其他反馈吗？这些都要定期追踪，了解客户不同层级的用户对新版本发布的新功能的想法，正向反馈负向反馈都好，都要有个交代。

通过这样的交代，一个更加完备的产品故事应运而生，产品经理有更多的实践素材去佐证功能的价值，架构师有更充分的底稿去应对客户的挑战。

四、小结我相信不少成熟的团队必定有自己一套完善的版本管理方法，对于客户需求和产品能力的转化也是运筹帷幄，对此我要恭喜你。的确，同一个问题会有很多解题的思路，我从这次的事件中也想通一个道理，那就是如何去克制把问题简单化处理的冲动，避免陷入对观点做取舍的二元偏误里。

在对外和前线团队的持续沟通中，我清楚了项目的百种不易；在对内和研发团队的共同作战中，我理解了产品的所思所想。如何去平衡项目和产品，让项目驱动产品的提升，让产品更好地服务于项目，让原本若即若离的两拨人汇聚成一股更强劲的力量，这是我从中体会最深的。

我想，捋完一遍思路后，我大概不需要去学怎么成为端水大师了。

#专栏作家#健壮的大姐姐，微信公众号：健壮的大姐姐（ID: is_strong），人人都是产品经理专栏作家。腾讯高级产品经理，专注于To B服务项目管理和行业分析，欢迎各路好汉一起探讨。

本文为人人都是产品经理《原创激励计划》出品，未经许可，禁止转载。

题图来自 Unsplash，基于 CC0 协议