时间: 2021-07-30 11:39:43 人气: 7 评论: 0
一般说来，在产品发布前，产品经理给相关负责人们进行产品demo是一个必不可少的环节，千万不要小看了这一环节，这可能与你的产品成败有着直接联系。
无论是to B的产品，还是to C的产品，一般在产品发布前，产品经理都需要给作为主要项目干系人的boss们进行产品demo，虽说不是正式发布，但还是不要小看这一环节，往往产品的成败及后续发展就蕴藏在这一次简单的demo中了。所以今天想在这里简要的给大家介绍一下产品demo的注意事项。
很多时候，老板们都是急于看到成果的，他们其实并不愿意在你即将上线，或者正式上线之后，在来关注产品的情况；而站在产品经理的立场上，则希望产品越完善越好，希望把时间尽可能的后延。这里简而言之，就需要产品经理或者项目经理，需要根据产品的实际进展情况和公司的具体要求，来进行判断时间节点。
需要保证演示的版本稳定，千万不要出现产品这边演示，研发那边更新版本的情况，顺便说一句，对于版本更新的频率和时间，应该在项目跟进过程中约定清楚，不要随意变更。产品经理在演示前也要亲自走一遍流程，确认版本的稳定程度。
准备好必要的文档，一般包含以下几方面内容：
① 当前进度；
② 如果是迭代产品的话，要写清楚，此次变更包含哪些内容；
③ 当前系统还存在什么主要问题没有修改（防止在demo过程中出现明显问题，事先说明总好过被领导质问）。
准备好演示环境，确认好网络、投影、视频**议等设备是否能够正常使用，屏幕的分辨率等等是否适合当前环境。
最后需要说明的是，产品在演示过程中，需要对于产品的缺陷和问题了如指掌，这样才能避免过多的采坑，影响演示效果。
如果演示需要准备数据或者其他资料的话，另外，包括演示账号也请提前做好准备。
演示前，对于产品的UI样式也可以进行适当的调整，确保不出现太大的问题。
首先要保证逻辑清晰，能够完整的演示产品的主要流程，在日常演示产品的过程中，经常出现刚刚演示一点儿，领导就开始针对问题发表意见，以至于演示断断续续，不能连贯，或者干脆由于领导的时间问题，没能完成整个演示。针对这些情况，可以在演示前，事先声明，先演示完主要流程，在谈细节、感受，过程中如果多次被打断演示，也可以适当的提醒领导。
产品人员在演示时，需要有人帮助进行**议纪要，以便记录反馈信息，当然、适当场合中，录音等等也可以。
针对功能和使用流程的展示，要有所侧重，详略得当，毕竟boss们时间宝贵，不能都用来了解用户管理或者帮助等非核心功能。
对于领导曾经建议或者要求的功能，如果在此版本中，没有体现，在领导提及时，要能够给出合理的解释。是此版本没有，还是功能没有完成，还是需求本身存在不合理之处。
对于某些产品，交互过程比较复杂，用时比较久的情况下，应该提前准备好不同状态的任务进行演示，例如在一个机器学习的训练平台中，我们可以演示“模型创建”的过程，模型训练的过程，发布的过程，但是我们不能用一个模型串联下来整个流程，也许这个模型训练可能需要半个小时，或者更久的时间，所以我们就可以事先准备好各种状态的模型，直接演示即可。
还有一点就是注重细节，还拿“模型创建”举个“栗子”，在演示过程中，可能**输入任务名称、描述等等，最好在事前准备好名称和描述的文案，不要随便用“测试”、“111111”等等代替，尽量营造真实的使用场景。
举个例子：
如果产品的逻辑或者流程，过于复杂，可以事先准备一个常用问题的小文档，以便针对各种常碰到的问题进行预案。
即便是万事俱备，也极有可能在演示过程中出现各种问题，沉着应对便是，很多时候不用遮遮掩掩，实事求是反而效果更好。如果在演示过程中，领导针对当前的产品表达了不满，也要沉着应对，有礼有节，针对提出的问题做出必要的解释，产品如此设计的原因？适用的场景？以及局限性。
另外一点值得注意的是，不要在演示中急于应承boss们的各种需求，除非你已经完全确定项目的进度来得及，技术上没有难度，逻辑上不存在其他衍生问题等等，最好的回复方式便是，我理解您的意思了，我们**后**针对这个需求进行分析和确认。
演示完成后，第一要务是针对**上收集到的反馈进行评估。
针对以上情况都要有明确的处理方式和反馈意见。待讨论清楚后，可以以邮件的方式进行备案和回复。
针对本次需要整改的内容，进行排期，确认项目的进展情况是否允许做出整改。
其实上面整理的这篇小文，某种程度上说，也不局限于我开篇设置的场景，包含给客户演示，给投资人演示等等，也都需要在事前做好充足的准备，只有这样，才能在演示过程中更加从容应对，达到最理想的效果。
本文由 @燕然未勒 原创发布于人人都是产品经理。未经许可，禁止转载。
题图来自 Unsplash ，基于 CC0 协议。
