演示原型和汇报的时候，都有哪些技巧？

关注并将「人人都是产品经理」设为星标

每天早 07 : 45 按时送达

因为汇报效果不够好，而导致产品创意被埋没无疑十分可惜。怎么通过产品的演示与回报，让好点子展现出预期的效果并更直观地体现其对用户的价值呢呢？这篇文章提出了几点注意事项，为提高汇报效果提供了帮助。一起来看看吧！

作者：厚厚

微信公众号：厚厚的语和文

题图来自Unsplash，基于CC0协议

全文共 4487 字，阅读需要 9 分钟

——————/ BEGIN /——————

汇报对于产品经理来讲是家常便饭，产品原型的演示与汇报是其中的重中之重，其汇报效果如何有时甚至决定了产品创意的生与死。

充分掌握其汇报技巧，不是为了给价值低或者方向错误的产品创意镀金使其熠熠生辉，而仅仅是为了让那些高价值的“金点子”创意发出它应有的光泽，不至于被尘埃埋没。

通常情况下，在产品原型汇报前，产品经理已经就创意与想法的整体思路进行过一轮口头上的汇报，并且得到了认可。但由于想法和落地之间有时可能会有不小的差距，有些看起来充满灵感与价值的想法在落地时可能会遇到很大的困难，比如落地效果比预想的效果大打折扣或者根本无法落地。

为了展现落地效果和更加直观地体现对用户带来的价值，一般在汇报完初步想法之后，产品经理会通过产品原型形式进行再次汇报。

这时的汇报主要呈现的是落地后的产品方案，去除了想法和落地之间的差距，体现出创意的主体思路和关键点。

同其他汇报形式一样，产品原型的汇报也有它本身的特点与技巧。

在产品原型汇报时不妨注意一下以下几点，可能会对汇报效果带来一些帮助：

关注企业背景差异

产品原型的汇报，在互联网公司和传统企业的目的和意义有所不同。

在互联网公司，身处良好的“产品思维”和“用户思维”环境和氛围中，通过白板和笔这种最简单的工具，就能够很好地对某个创意进行深入有效的沟通。

口头汇报时就能从想法讨论到落地，勾勒出产品方案，从而对创意的价值做出基本判断。

这时，产品原型的再次汇报，更多地是对上次口头汇报达成一致意见的产品方案的呈现和初步审阅，或许还有因双向连锁效应中的反向效应而带来的落地时的差异，即因细节问题导致的对上一层决策的重新评估。

而在传统企业，没有产品的概念，所处的是充满了“业务”和“技术”的语境，口头汇报常常是就想法讨论想法，可能会像头脑风暴一样将想法继续发散和延伸，也可能会像落地实施一样讨论技术可行性和技术架构。

通常讨论的范围会很广，但却缺乏对产品创意及产品方案的聚焦讨论及统一思考。

也就是说讨论完以后，留给产品经理的是一堆涉及到各个方面的散乱的信息，需要产品经理后续去花时间梳理思考，并形成落地的产品方案，最终通过产品原型的形式进行再次汇报，汇报的重点是对产品创意和产品方案进行全方位描述。

关注汇报对象背景

如同演讲关注听众是谁一样，产品原型的汇报自然也要关注汇报的对象，但这一点却是产品经理常常忽略掉的。

实际上，互联网公司和传统企业的汇报对象可能完全不同——都是向上一两个层级的领导汇报，但领导的背景却可能大不同。

在互联网公司，产品经理的领导基本上都是产品经理这个专业序列的人，高级及资深产品经理、产品总监等。这些领导都是一步步从产品的路上走过来的，与他们汇报更像是一次沟通讨论，呈现自己的创意与想法，寻求他们的指导与把关。

在汇报时，常常一语胜千言，不需要很多解释，一两句对方就能心领神会。对于汇报的内容、范围、呈现方式等，一般也不会做过多要求，能把问题清晰说明白就好。

在传统企业里，产品经理的领导并不都是产品专业出身。

实际上，传统企业产品经理的领导常常是技术序列背景。只有技术没有产品经理是互联网+浪潮之前传统企业的常态。

互联网渗透后，不少传统企业招聘了产品经理但却没有建立产品团队、产品部门，因此产品经理的汇报对象就变成了原来的技术领导。

与技术背景的领导汇报，则要麻烦的多，常常需要更多的解释，在需求阶段也会过多地讨论到技术实现及技术方案等方面的话题。

除此以外，因为没有相关背景及对产品经理的工作方式方法不了解，常常还会对产品经理的输出物、汇报内容及方式有更多、更细节的要求。

汇报开始前交待背景信息

很多产品经理在产品原型汇报时会忽略背景信息的交待，但其实交待背景信息是非常关键的。

如果你有讲了半天之后听众才感叹“原来是这样！”的经历，就会对它的重要性深有体会。

背景信息是主要内容的铺垫和认知基石，能让人了解事情的来龙去脉，解开听众心中首要且暗含的“这是要干啥事”的疑惑。

不交待背景信息而直接切入主要内容，会给听众一种生硬且茫然的感觉，后面听到的所有内容其实都是在不断寻求心中那个“这是个什么事情，为什么要做这个事情”问题的答案。

当听众的大脑因为某个问题而高速运转或者已经被它完全占满时，扑面而来的信息纵然再精彩也无法再有效填充进去。几句话的事儿，看似小问题，实则却影响全局。

我们在汇报前，千万别忘了交待背景信息这件极其重要的小事。

描述产品框架

人们接受一个新事物需要一个过程，而汇报常常需要听众在极短的时间内完成这个过程。

让听众以最快速度接受一个新事物最好的策略之一，就是帮助他们搭建好关于这个新事物的知识框架，在知识框架下再去接收更深入的信息要容易多。

在产品原型正式汇报前需要花费较多时间把产品思路描述清楚，让领导们对所要讲的内容形成一个整体的认知框架。这是非常关键的，否则继续往下讲只会让领导们云里雾里，越听越迷惑。

最常见的结局是领导们在某个点突然喊停，然后开始一点一点通过提问的方式回溯，直到他们对所要讲的内容建立起知识框架。

不少产品经理对此有过惨痛的经验教训，精心准备的产品原型从头开始讲起，结果仅十几分钟之后就被领导喊停，然后就是一系列提问，提问的问题基本上都是关于思路框架方面的内容，汇报者常常这才意识到领导们对整个框架还没有建立起概念。

可能你之前口头汇报时说过思路框架了，觉得没有必要再说，但实际上很有可能领导们已经没有什么印象了。

作为领导，他们常常是非常忙碌的，每天面对的事情纷繁复杂，你的工作中心可能只有两三件事儿，而领导们常常重点关注的事情都好几件，还别说各种突发的事情以及来自上层领导的各种新指示。

互联网公司的领导因为有产品专业背景，如果你没有描述产品框架，他们在大多数情况下也能自行快速脑补。

但在传统企业里，因为领导常常是技术背景，并不能通过脑补来弥补这个信息。

除非你确信领导们对思路框架已经完全了解了，否则思路框架再怎么讲都不为过，特别是在讲一个全新的产品创意时。既然如此，产品经理应该在一开始就把这个问题解决掉。

为了达到好的效果，产品经理在产品原型的第一页可以画一张体现整体产品思路的框架图或流程图，起到引领全局认知的作用，实践证明这种方法非常有效。

“讲解速度=理解速度”

已有事物在大脑中已被整理并存储，当被讨论时可以立即调出。而大脑对于新生事物需要有一个整理加工的过程，速度要慢的多。

产品经理在汇报产品原型时含有大量新内容，讲解的速度也要慢下来，留给听众一定的整理思考时间，让讲解速度=理解速度是最佳状态。

那么大概是什么样的速度呢？

参照自己或许会有很好的感受。

回想一下你自己在整理这些信息时花费了多长时间，在某个具体的点上又费了多少工夫，那么在讲整理好的内容进行讲解时大概需要多少时间或许心里就会有个数了。

产品原型汇报时发生讲解速度过慢的问题很少见，常常是因为讲解速度过快导致效果不佳。

速度过快，常常是因为产品经理对汇报内容了然于胸，再加上产品经理练就的清晰流畅的思路，很容易一讲起来速度就快起来了，等到讲完了回头发现领导们一堆疑问，还得翻回到前面一个一个地对问题进行解答，基本上相当于把之前讲的内容再重新说一遍，最终相当于讲了两遍！

在互联网公司，产品经理面向的是经验更加丰富的专业人士，他们对于产品方面的理解和思考能力都很高，速度可以稍微快些。

而在传统企业，产品经理面向的是没有产品背景的非专业人士，他们的思维方式与思考的内容都与产品经理有很大的不同。

面向他们汇报时，我们要特别注意讲解速度这一点。

无论面向对象有无专业背景，我们都要注意的是：讲解时要留意听众的反应，让讲解速度=理解速度，确保听众理解了再继续往下走。

产品经理常常会高估领导们的信息接收能力，实际上领导们也并非天赋异禀，也需要时间来吸收与思考。控制速度，让领导们跟上你的思路，是取得良好汇报效果的关键所在。

加重和重复关键点

在整篇的汇报过程中，一定会有一些关键点需要让听众重点关注。那么可以采取什么样的措施来达到这个目的呢？加重、重复是简单且有效的策略。

关键点，就隐藏在整篇汇报的内容中。如果我们不对这些内容做特别的处理，那么它就同其他内容一样，很容易被听众同等对待而导致忽略掉。

有些思考能力强、经验丰富的听众，能够自行挑选出关键点。但作为汇报者来讲，明确指出其中的关键点是我们的责任，不能把这个义务转嫁给听众，除非你想隐瞒它，况且依靠听众自身明显不靠谱。

加重的语气，很容易让听众感受到不同，注意到变化，引起其注意，从而关注到那些关键点。

而重复，是为了加深听众的记忆。

让我们记住一个事物的最好办法就是不断地重复再重复；同时，重复，也会引起听众的注意和思考。

为什么总是重复这个地方？

这个疑问将带领听众去弄懂它，听众在这个过程中也会把关键点理解消化掉。

点出隐藏的底层逻辑

产品创意的好与坏，不仅仅体现在表层页面上呈现出来的可见元素和由此引起的直觉体验，其背后的底层逻辑往往更为关键。

万变不离其宗，底层逻辑是产品运行的机制和规则，是产品功能生长发芽的土壤，决定了产品生态是走向繁荣还是走向凋零。充分体现着产品经理创意与想法的产品原型，作为汇报主要素材时有其优势与劣势：

• 最大的优势是形象直观、可体验；

• 最大的劣势是想法思路和底层逻辑隐藏于页面之间，不容易看出。

因此，产品经理在进行产品原型汇报时，需要点出隐藏在背后的底层逻辑，就其中的内在规律和事物本质进行阐述，并且应该就这些内容进行深入探讨。必要时，也可以通过流程图的辅助进行说明。

如果说产品原型的页面是“养眼且感性的”，那么底层逻辑则是“理性的烧脑”。

推演出一套好的底层逻辑，使在产品上的各类用户都能够感受到自己的需求被满足，拥有合适的义务与权利，产品才能长期健康地发展下去。

损害任何一方的利益，产品都难以为继。

全篇回顾和总结

讲述完全部内容之后，再对所讲内容进行一个全篇的回顾和总结是十分必要的，特别是内容比较多、讲述时间比较长的情景下，听众对于前面所讲的内容可能都已经忘得差不多了。

最后的回顾和总结能让产品经理带着大家再勾勒一下所讲内容的框架，在最后的时刻给听众的脑海里留下一个总体的框架图。

细节常常很多，听众很难一一记住，但只要听众最后能把这个框架图记住，当他在回想的时候就能唤起一些与之相关的细节。

这就是最后做一个全篇回顾和总结的最大意义。

希望以上几点能为你的产品方案汇报提供帮助，希望我们每个人都能很好地把自己闪闪发亮的创意与想法表达出来。

—————— / END / ——————

产品经理培训｜产品运营培训｜企业内训服务

请在公众号后台回复「培训」了解更多

▼ 喜欢请分享&收藏，满意点个赞，最后点「在看」 ▼