台上一分钟台下十年功，一次成功的演示背后可能是自己十次的预演。本文是作者经过演示后的几点总结，分享给大家，希望能对你有所帮助。
B端的产品经理不仅要熟悉用户的业务、工作场景、调研用户的需求，对系统进行设计并跟进开发进度，系统的演示也是我们工作中必不可少的一个环节。
那么B端产品一次成功的演示有多重要？
如果是售前的演示可能会促成一个大合同的诞生，如果是定制项目开发过程中的演示可能会尽快的促进项目的验收，如果是运行维护过程中的演示可能会极大的促进甲乙双方的关系，有利于进一步的合作。
现在已经不是“酒香不怕巷子深”的年代了，等着客户自己发掘我们的优势，可能客户已经被我们的竞争对手抢走了，系统做的好但是没能成功的演示，我认为对我们来说是非常委屈的。
演示一般分为概括简介+主体演示+答疑解惑 三个部分组成，概括简介相当于一个目录大纲一样，让听众有一个大概的了解，脑子里有了框架后好方便我们在里面填内容。
主体演示就不用了多说了，就是我们系统实打实的能做到什么，答疑解惑当然就是回答自己没有讲清楚的内容或者回答咱们系统没有实现的需求。
经过我演示后的几点总结，分享给大家，希望能对你有所帮助，下面让Marvin和你一起详细聊聊吧！
预知参与人员
预知参加人员可以让我们有针对性的准备，不同角色对系统的功能的诉求不同，比如：高层管理者更多看到的是统计类的功能展示，中层人员和基层人员可能更多的是重功能。
为了让有效的时间内达到我们演示的目的，有侧重的演示效果可能会更好。
了解不同用户角色的诉求和痛点
不同的角色在工作中有什么样的痛点，我们的系统能帮他怎么解决这些问题，并以此还能提高他们的工作效率，最好就在演示开始就说这些问题，让用户能产生的同理心。有代入感后能引起听众的好奇心，使他们能听进去才是一个演示的开始。
B端的产品是重功能轻体验，业务才是B端产品的重中之重，对业务熟悉才能更好的做好项目，才能更好的演示，在真正的演示之前一定要自己先预演一遍甚至多遍。
介绍系统的模块
分别有哪些主要功能，让客户有一个大概的框架，并知道对应的解决了他们哪些问题，有了心理预期后接下来再讲系统是怎样实现这些功能满足他们的需求的，因为我们需要精炼我们的演示时间。
为了不让听众打断我们的演示，影响我们的演示计划和状态，最好在这个时候说一下如果有什么问题一会会有答疑环节，到时候会详细解答疑问。
介绍系统的详细功能
这部分可能会比较枯燥，但是因为有了之前的铺垫可能会好很多，注意把控情绪和节奏，没有什么特别好的办法。介绍系统功能时首先自己要对功能也业务都比较熟悉，并了解其中的工作原理等专业的知识。如果本身自己不是技术出身，有条件的话最好随行以为技术人员，便于解释专业上的问题。
竞品分析
分析本产品与市面上同类产品相比的优缺点，自己系统的优点肯定要大力宣扬，缺点其实也是一次展示自己的机会，一次什么机会？
增加预算的机会，哈哈哈，是什么原因导致的我们实现不了这个功能？
是缺少终端设备对信息的采集，还是设备老旧需要更新，还是确实是预算本身不支持这么大的开发人力成本？
总之让客户能感受到在现有的预算内，系统所能实现的效果已经物超所值，他们赚大了！同时在条件允许的情况下可以说说自身的不足和以后的迭代计划，为下一期的迭代提前做做铺垫。
时间的把控
有限的时间内能把系统演示讲的清楚，能让听众听明白才是真本事，每次演示在听众里可能有很多种角色，时间好不容易协调到一起，大家都挺忙的。这时候就凸显效率的重要性，思维清晰、有条理、注意演示的节奏显的尤为重要。
同时高效的演示能给用户带来系统功能齐全但是不复杂，操作简单的感受。在这里还要说一下，演示时最好自己也录音，一次次的回听，找出自己的不足，相信一次会比一次好。
答疑和解惑
精炼我们的演示，留出一定的时间给解惑答疑，首先做好心理准备，可以预知的问题提前准备一下，以积极开放的心态看待未知的问题。放心，总会有这样那样出乎意料的问题，耐心并以专业的视角解答问题。
这时候随行的技术人员也可以发挥其作用，对专业技术性的问题做出解答,尤其是对一些天马行空的需求，更要通过专业的视角让听众打消这个念头。
总结和跟进
除了自己本身的演示方法的总结还有当然就是客户新提需求的总结，最好在演示后能输出一个文档，再和客户一条一条的确认一下，进一步沟通和协商。还有要重点提的一点是不要闭门造车，没有有效高频的沟通自己公司忙活了半天，最后客户不满意自己还会感觉到挺委屈。
结束语
台上一分钟台下十年功，一次成功的演示背后可能是自己十次的预演，现在演示的从容不迫可能是自己以前磕磕绊绊在不断出丑中总结出来的。无论是什么样的文章什么样的方法论，不可能看过学过后就自己会做了。
就像是那句名言一样“听过很多道理，却依然过不好这一生”，所以有机会还是去实践吧，方法论可能只是一个方向，路还是得自己慢慢走。
