在我面试几百个产品经理的经历中，我发现很多产品新人都在学习一些质量不高的教程。这些教程通常用前大半截的篇幅来介绍一些形而上的理论，真的到了实操阶段却草草收尾，只教你一些表面的东西，例如流程图长什么样、动态面板怎么画，很少去讨论在真正的工作中，一个PRD到底是怎样诞生的。所以我想做一些教程给你们看，让你们能够真正掌握实操的过程。

但在我整理过去作品的这段时间里，我发现很少作品可以写成图文教程，因为我采用的都是面向对象的设计 *** ，每个模块都是静态的，模块之间是互相成就的，不存在一个“线性的流程”。用几小时视频加上我的嘴炮旁白是可以做到的，但是用图文的形式就很难表达清楚。

每当这种时候我都很希望能掌握电影《降临》中外星人传授给地球人的表意文字。一个水墨状的圆弧上，每一个突触都代表一个事物，突触之间的位置关系代表了它们在这个故事里的角色。这个故事没有开头和结尾，你可以用一万个声音去叙述这个故事，而故事本身却并不复杂，因为时间的一维方向性在这里被打破，只有角色，和角色之间的所有的关系。

不过这个系统是个例外，它是我上家公司政务SAAS系统中的一个小功能，叫做简易表单系统。顾名思义，它比较简易，因此它有机会写成图文教程。

写这篇教程之前，我花了半天的时间来整理它的提纲，然后花了一天半的时间从以前的文档里慢慢找到配图并PS。从提纲来看，虽然没有介绍到全部的思路，但是我在叙事结构上做了一些取舍，让你可以更轻松地跟着我的思路走下去，所以现在我们进入正题。

注：本文在第3章之前都是抽象逻辑探索，你可能会觉得枯燥而跳过。但是当你看完后面的原型章节之后，你会发现，你还是得返回来重看一遍。

立项和整理需求

我不会人五人六地告诉你我是怎么调研市场和研究竞品的，因为这个项目不存在。在实际的互联网公司工作中，很多痛点是痛到不行的，但是很多时候大家对痛苦的忍受程度、愚钝程度也是超过你想象的，越大型、人均头发数量越少的公司越是这样。

这种时候，产品经理也很容易因为压力而随波逐流，但你的使命就是去做指路人。只要把你的方案表述出来，告诉别人怎么你是怎么解决老板和大家的痛苦的，你就可以立项。调研报告和各种炫彩的ppt不是必须的，它们通常是因为你的策划案不够漂亮，或者大家还不够相信你。没有什么ppt能比一个漂亮的落地计划直接甩在大家脸上更有说服力。

上图是某个银行给我们的Excel表，他们想把这套表格搬到线上来，图里只是其中一个合作银行的一部分的表格。而且，我们当时在做的也不光是银行的线上表单，刚好还有某个地区 *** 的科创局也需要上线一个系统，让企业用在线表单填写信息上传上去。

当你看到这样的可怕的表格，不是上图这一份，而是十几份，你会怎样做？

“让我们直接一页一页画成原型，然后交给程序员一个字段一个字段开发吧！”——在我看到我的产品经理莫名其妙地加班、程序员也在莫名其妙地加班之前，他们就是这样做的。我现在截图给你看，你会觉得这样很愚蠢，然而当你身临其境的时候，每天被老板分配的任务压到喘不过气的时候，你真的会很容易失去跳出来说皇帝没穿衣服的勇气。

显然你要去 *** 一个通用的表单系统，这个表单系统能照顾到这些不同的数据填写需求，让程序员开发出来，然后撒手不管，丢给客户或者运营去配置具体的数据。

很多产品经理不知道去分辨老板哪些指令是专业的，哪些是业余的，自己甘心做一个“需求翻译器”，还纳闷为什么自己的需求不被人好好执行。其实你的方案能让大家少加班，还能让大家出品更好，你的威信就在不断建立，大家就会把你当做指挥官。

当遇到客户或者老板丢给你十几张Excel表的时候，你首先要看这些表格是不是规范的。如果是一张大宽表，所有的数据都被整理得井井有条的，那就不需要去梳理它，可以直接走下一步。但是如果你遇到的是我这样的，不同的几个机构给的不同的表格，而你想把它们都做成一个表单系统，那你就需要先去好好梳理这些数据了。