写PPT，也需要向上管理。
向上管理的策略很简单，就是遵循《精益创业》中提到的MVP （最小化可实行产品，Minimum Viable Product）原则，意思是用最快、最简明的方式建立一个可用的PPT原型，通过这个最简单的原型来测试是否符合老板预期，并通过不断的快速迭代来修正PPT，最终适应老板需求。
简单来说，就是在做一个PPT的时候，不要一下子做一个自认「尽善尽美」的PPT，而是先花费最小的代价做一个「可用」的PPT原型，去验证这个PPT是否有价值、是否可行，再通过迭代来完善细节。
具体怎么做呢？
我们可以将写PPT的过程划分成四个阶段，然后让每个阶段遵循MVP原则。
阶段一：任务阶段主动出击
不同的老板有不同的风格，最怕的是那种安排任务的时候比较粗放，但对PPT最终质量要求又很高的老板，最苦逼是那种自以为听懂了老板PPT的要求，但最终汇报时发现跟老板的想法大相径庭的下属，这都是由巨大的信息不对称决定的。
解决信息不对称的唯一方法就是开始的时候就要不断沟通确认，能确认多少就确认多少，开始的时候这个“1”是非常重要的。
设想一个场景，老板突然让写一个企业级数据治理体系的材料，不同的人有不同的应对策略：
A：直接拍胸脯说好的，然后各种搜集资料，按照行业的最佳实践去写。
B：跟老板确认清楚写这个材料的背景和目的，比如知道了是XX咨询公司给老板提了建议，那么就应该先找到咨询公司问清楚情况，这样写PPT就容易聚焦到老板真正关注的事情上。
C：在了解了背景和目的后，尽可能的给出你的PPT内容初步建议，比如跟老板当场确认主要目录和内容，不要怕老板嫌烦，这个时候多引导老板说几句，其效率远好过于你线下自己去揣摩，要搞清楚你是为老板负责，老板自己说出来的当然是最准确的信息。
一般我们开始的时候只能做到B，做到C的很少，毕竟短时间内你是想不清楚的，也很难提出建议，如果你碰到的是那种事无巨细的老板，那只能说太幸运了。
阶段二：提供给老板目录框架
写PPT一般都会拟定目录框架，但我们一般把目录框架的拟定看成是整理自己思维的一个手段，并没有把它当成对外沟通所必需的，因此目录框架大多缺乏严谨性和完整性。
我们的一般思维是：反正这些框架目录以后还能调整，大致知道是啥意思就可以了，我要尽快进行实体内容的撰写，这是一种以自我为中心的写PPT方式。
现在我们要遵循MVP原则，把目录框架当成一个产品原型，你这个产品原型需要多人协同配合才能完成的，并且这个产品原型要尽快发给你的最终客户（即老板）确认可用性，写PPT要遵循相当的开放性，这是效率的保障，PPT写到极致，大多是团队协作的结果，跟做产品挺像。
PPT的产品原型包含三要素，第一是题目，第二是目录架构，第三是页面标题。我们可以基于多人协作的腾讯文档为例来说明，下面是PPT的产品原型示例：
把这个产品原型发给老板进行确认，老板微信上瞄一眼就知道这是不是他想要的东西，然后可以针对性的给出补充或修改意见，如果不是他需要的，全盘否定都没问题，至少我们不需要在这个方向上继续浪费时间。
如果能说服老板走到这一步，其实就成功了一半，你的产品原型经受住了考验。
阶段三：提供更详细的页面信息
目录框架只是确立了方向，但内容是否能获得认可，还需要把脑图进一步细化，即把每一页的主要内容描述出来，每一页的要素包括正式标题、帽段内容和分论点，如下图所示：
把这个脑图再次发给老板进行确认，如果没有太大的异议，就可以正式启动PPT的编写了，否则再回到阶段二，阶段三继续修改，在这个过程中，可以采取多人协作的方式同步进行。
阶段四：完成PPT的初稿
有了前面产品原型和文字基础，就好比建设好了高速公路，即使车再烂，也不会偏离航道，写PPT变成了完形填空，不再需要更多的技巧。
由于每一页的要点已经描述清楚，这个时候分布式协作也变得非常容易，效率远非个人能够比拟。
如果PPT页数过多，为了防止老板LOST，可以把脑图的目录框架在首页上放一下，这样有利于引导老板理解整个PPT的脉络。
当你拿着这个PPT去跟老板汇报时，一般不会推倒重来，更多是细节上的调整，比如表达有问题，论据不够充分等等，这个时候被老板指责，没什么好推卸的，就是实力问题。
摆正态度，认真录音，群策群力，不断的去完善你的PPT产品吧，当然这需要老板的支持和配合，如果老板不愿意改变，那也是没有办法的事情，但总得有人先站出来提出改善的建议。
