编辑导读：产物代价莫非只是各个产物部分本身的事情吗？各个业务部分该如何共同晋升产物代价？文章依次对打造产物代价的三个段位展开了梳理说明，对这两个问题举办了阐明接头，与各人分享。

三十功名尘与土八千里路云和月

莫苟且白了少年初空悲切

——宋·岳武穆

一、初段程度：仅靠产物部分输生产物代价独木难支

对SaaS公司来说，产物、营销、处事是三项需要兼备的本领，产物代价正是其间的要害链条。但在产物代价打造、输出的事情上，大部门公司只能做到这个水平：

描写一下详细状况：

产物、研发部分每个版本开拓什么成果，根基上靠本身拍脑壳。

销售部分本身整理产物代价，做PPT等销售东西。

销售代表和C *** （客户乐成司理）碰着客户提Bug、提需求，就丢给产物司理，让他们本身做取舍。

每次发新版，产物司理就给所有部分做同样培训，把每个新成果都操纵演示一遍…

这样程度的组织，产物版本即便更新很快也往往会抓不住市场脉络、产物代价包装做不到位，每次产物培训都让销售听得一头雾水，市场竞争中产物优势也不明明……

二、中段程度：在各部分间通报产物代价而非成果

初段协作水准的企业会发明：给销售代表做全成果讲授接收度很低（其实他们在对客户的销售进程中也不需要给客户演示那么细的成果）、给市场部只讲成果又远远不足；销售代表直接向产物司理（甚至是研发工程师）反馈客户发明的Bug，往往心很急却说不清楚、操纵上也复现不出来，无端打乱了产物司理和工程师的日常事情节拍，影响后者事情效率。

因此，我认为以下这些行动是错误的（见X处）：

而那些产物代价协作能到达中段水准的企业会这样协作：

这里有两个流程：

A、新版本代价输出及培训流程（浅绿色）：

①筹备发新版前，产物司理与客户乐成、市场部一起探讨应用场景和产物代价描写，由市场部进级销售东西、客户乐成部完善利用场景和客户利用的案例。

②由市场部对销售团队做基于产物代价和应用场景的新版本培训，并不需要做完整的操纵演示（产物越巨大越不需要），而应该环绕几个焦点客户应用场景，向销售代表通报产物代价而非成果。

而客户乐成内部的培训，除了代价通报，仍需要保存成果及操纵的部门。因为她们是需要帮客户办理操纵问题的。

B、Bug及客户需求通报流程（浅赤色）：

①销售代表不再直接向产研部分发送非紧张bug、设计缺陷及客户需求，而是发给客户乐成部下的热线 *** ；

②热线 *** 会做好“Bug复现”、设计缺陷确认及需求整理事情（后两者亦大概由C *** 认真），确认有效后再转给产研部分。这里需要有IT系统支持，Bug等会关联客户，让销售代表、 *** 和C *** 可以相识处处理惩罚进度，利便主动向客户反馈。

个中Bug按照是否阻碍主事情流程（Blocking）和影响客户范畴分3~5级，差异级此外处理惩罚时限及流程有所差异。

紧张Bug处理惩罚（一般占比很小）因为有严格的处理惩罚时限要求，仍然由销售代表、 *** 直接与研发工程师（/产物司理）举办相同。

三、高段程度：各部分合力打造代价产物

以上两个流程将使得产物代价的通报程度获得很大晋升，但这还不敷以影响到产物自己的演进。高段位的公司还可以或许做到 —— 各个部分配合为晋升产物代价而高效协作。我也画了一张图：

高效的产物代价打造包罗以下流程：

销售部分将客户对产物代价的需求反馈给市场部，而把产物成果方面的信息反馈给客户乐成部；

客户乐成部将成果改进、新成果的需求反馈给产物司理，这些信息来自上面销售部分的反馈，也来自于处事进程中；

客户乐成部在处事进程中会发明“乐成客户”，须养成习惯（作为OKR /KPI要求或做好其他鼓励）按期将乐成利用案例输出给市场部；

市场部汇总销售部分、客户乐成部的信息，基于计谋做市场、客户群体阐明，输出方针市场画像、基于方针客户画像的要害场景提供应产物部分。

产物司理、市场部按期交换产物设计的思路和焦点逻辑，并一起与CEO、销售VP、客户乐成VP探讨，以确定下一个版本的主要新特性。

可以看到，这个流程的焦点部分是市场部（假如售前支持岗亭，也会包袱个中一部门事情）。