对标产品总监，手把手教你编写《评审提纲》.docxVIP

对标产品总监，手把手教你编写《评审提纲》 使用过的招数，第二次，就更特么灵了！ 前天镜同学正在WC认真做着王者荣耀的竞品分析，这次使用典韦打野，峡谷游走正酣，草丛里突然蹦出个残血卤蛋，二话不说，对我一顿猛轰。把我吓得，还没来得及反应，他特么就挂了。 呵，不知道我典君有反刺伤甲么？ 正当我准备越塔去对面泡温泉时，领导打来电话：腿麻了没有，麻了的话，走两步，走出个虎虎生风，特么该你表演了，赶紧来开需求评审会！ 这特么不是逼我挂机么？ 一边是仨核桃俩枣又无比苦涩的工作，一边是至高无上的团队荣耀，哪个重要，我特么没有点AC数么？ 提上裤子我就冲进了会议室。 的确，需求评审会对产品经理来说太重要了，差不多就相当于反刺伤甲对典韦的重要程度。 好在，咱早就准备好了。 于是乎，我打开了PPT，屏幕上闪烁的几个大字，强劲有力，像是对卤蛋的无情嘲讽：《××××金融平台采购融资系统需求评审提纲》。 不得不承认，有时候肌肉比头脑管用！ 在我看来，这份提纲，就是典韦的宗师之力，就是凯哥的暗影战斧，就是产品经理的肱二头肌啊。 我参加过很多场婚礼，哦，不是，参加过很多场评审会，毫不客气的说，咱也是见过大场面的人，形形色色的产品，折叠起来看，大致可简单分为三种： 一是，上来就评审原型的，多见于缺乏社会毒打的新手产品。 二是，先讲下业务背景，展示清楚架构设计图、业务流程图，然后评审原型设计的中级优秀产品经理。 三是，准备的有个PPT评审方案，先从全局说明下本次评审会的流程和关键节点，用结构化思维阐述下关键主题，将需求设计历程统揽展示，然后再穿插着逐项评审产品成果，诸如，背景介绍、系统架构设计、业务流程、原型设计及需求说明文档等。 是的，镜同学就属于第三种，低调低调，弱水而已，不过谦山。 高渐离：该我上场表演了。 需求评审会是产品经理的主场，既然是会议，那肯定就得有主题，核心主题是什么呢？说白了就是需求传递。 需求评审的本质就是将需求设计向上下游进行传递，对业务、对技术、对测试、对运营等。 围绕这个核心主题，便需要从各个支线的产品成果去培训和讲解，如何有效的让后排的同学也听得到讲台上的声音，不会跑神或分散注意力，高效地理解需求，正是评审会的灵魂期望。 跟随镜哥的脚步，走完这七步，保证丑小鸭变漂亮的丑小鸭。 第一步，我们需要先整一个思考框架 这个框架重点是梳理评审会需要表演的节目，更多的是自己的思路和草稿，围绕着要评审的需求去整理，最好整理成思维导图，比较清晰明了，同时，也可以为接下要做的PPT提纲打下基础。 第二步，选择一个合适的PPT模板 PPT模板一定要骚气，哦不，一定要大气。 提醒两点，一是，界面风格一定要结合产品属性，比如，科技风或者工业风；二是，最好把公司logo加上去，显得走心和正规。 大哥，你是了解镜同学的，吃独食这事儿，我从来不干，我如果出手，趴桌子上（写方案）的，应该是我自己。 所以，镜同学亲自下海，一宿一宿的，精挑细选了个沉稳、大气、逼格满满的通用模板。 第三步，着手编写需求评审提纲，先梳理出目录 PPT提纲的目录就是评审会的主要议程，我一般会通过这四部分来分析，包括产品背景、业务流程、需求设计和讨论沟通。 梳理好之后，就可以按这四大块内容，展开评审会的具体议题。 第四步，详细介绍产品背景 产品背景就是针对你设计产品的项目背景、需求调研情况、可行性分析、业务现状等内容，讲清楚为什么做这个产品功能。 所以，我介绍产品背景时，一般分为项目背景、需求调研和业务现状。 1. 介绍项目背景时 交代下项目背景整体情况，主要从宏观层面说一下，显得高大上，但不要说太多，表述下和产品设计有价值的参考点，做好伏笔。 2. 介绍需求调研时 需求调研可以从调研概括入手，概括描述下需求调研的情况，包括调研的对象、调研目的及调研成果等。 然后用数据指标直观展示，用几个核心数据体现下调研情况，如，访谈用户数、平台规模、建设情况等。 最后结合产品和需求调研的融合，根据需求调研情况，结合产品功能的定位，描述下融合后的优势和挑战点。 3. 介绍业务现状时 将产品要服务的业务场景现状表述清楚，详细罗列下关键的业务情况，提取关键指标值，结合产品规划，有所侧重，将现状陈述清晰。 这里有一个小技巧，在讲述功能前，PPT用一页，简单的文字描述下，再加一个解释文字，不用花里胡哨，却给阅读人以想象的空间。 这就像是水墨画留白的妙处。 第五步，原有与现在的业务流程 接下来就是核心的业务流程，要讲清楚产品功能的主要业务逻辑，使用VISIO提前画好泳道流程图，把业务关系、业务规则及主要流程讲清楚。 只有先搞清楚了业务流程，让其他评审人员初步了解到大致的业务流程，有了感性的认识，接下来的原型评审才能更顺畅。 业务流程可以先从原有的流程入手，然后结合调整和融合的地方，因为很多产品是迭代，即便是新产品也