其实那会还在北京的时候，就曾经写了篇文章叫《正确的写产品需求文档（PRD）》后来被转载无数，现在想想那会还仅仅是停留在技能的熟练度一样，或者说通过这篇文章可以让大家掌握一种快速文档的套路。

    因为最近还是有很多新人问我要产品需求文档，他们很想看看一个典型的产品需求文档应该是什么样的，我直接拒绝了，我一般会说：“请多想想”。我是这么的理解：看文档本身其实是没有意义的，特别是产品需求文档，其实是需求的产物。作为产物就好比是你今天用一个手机，看手机的说明书一样，你知道了这个产品要做成为什么样子。为什么这么做，如何做？先做什么，后座什么，你还是不知道。

    所以从产品需求而言，文档本身没有个推导的过程。这也就回到一个问题上，很多产品经理新人本身是意识不到，如何做需求，如何写需求文档的差别的。在他们的潜意识里，反正公司是需要有产品需求文档这么一种载体来表达他们的想法，所以很自然而然的认为，学会了写需求文档，就掌握了如何做需求，处理需求一样。

    这样听起来有点绕口，但我表达的观点是：想与做的过程是分开的。一个是过程，一个是因为有这个过程的产物，很可能很多时候产物本身可能没有太多的意义。但从表象上来看，文档写的有没有逻辑感，有没有层次感，表述的文字是否清晰、清楚也是一种境界。

    很多时候我们写方案做PPT，很多人写出来的东西是完美不一样的。那PPT的宗旨是：简单、标题化、有视图、也不乏空洞。之所以举这个例子，其实是所以一样的情况。写产品需求文档本身其实更多的是：产品需求推导的过程。因为先有了推导的过程，然后再有了推导的结果。很顺利成章的，各位产品经理新入门的朋友，你是否也具有：“产品推导”的过程呢？

    产品推导的过程是：为什么要这么做，谁来做，做什么，怎么做，一步步怎么做，最后做成什么样。写需求文档的过程其实就是处理需求的过程，所以以上这几点有没有写想明白？很多公司要做一个产品，可能高层是想要一个东西，但在执行的过程中因为上下级之间认识、理解的不一样，所以在执行的过程中或多或少有所偏差。所以在这个过程中，回答上面几个本质的问题，是会纠正你做需求的思路，不会做弯路。

    产品经理这个群体是个很奇怪的群体，他们的主观性非常的强，喜欢把产品按自己的兴趣和喜好去做，所以得到一个结果本身不难。因为这个结果很可能是出于产品经理主观喜欢的结果，但如果从过程出发得到一个结果，这个时候大家相比一下过程和结果本身而言，对于结果的认识想必也会不太一样。

    结合今天说的主题：《如何媒体正确的看待：产品需求文档和产品需求》，产品需求文档可以是没有固定格式的，大家不要把产品需求文档想象的怎么样怎么样。写产品需求文档，是做产品经理的一个基本能力，写的逻辑感怎么、层次感怎么样，写的是否清晰和明白，是有一定差别的。但本质上不管是excel、word、rose、还是txt，其实都是次要的。

    宗旨：让给你需求拍板的人，知道你的逻辑是什么，让和你一起做的程序员很清晰的知道需求是什么，让给你一起测试的人员知道你的细节就可以了。以后也方便于版本升级，知道你一个版本、一个版本都加了哪些需求，改了哪些需求，删了哪些知道需求就可。 所以文档本身起到的东西就是这个，一个是告知，一个是存档。

    但产品需求是本质核心的东西，只有你想明白要做什么，怎么做，谁来做，一步步推导的过程是否合理、是否让自己信服，让别人信服，这才是最根本的。有了这个做保障产品需求在文档化的过程中，才会层次分明，结构清晰。所以当很多朋友一直在问我文档怎么写的时候，请大家好好的想一想：我应该在哪几个方面处理这个需求，需求的维度怎么切割？需求的优先级怎么切分？哪些是核心的，对整个产品起到重大关键的？哪些是锦上添花的？哪些是可有可无的？需求的主线是什么？……等等

    只有想明白了这些，才会轮到如何把产品需求，进行文档化的阶段。这个时间，我们再回顾头看看《正确的写产品需求文档（PRD）》，通过一些小的思维方式把写文档的技能组织起来，发现所有的一切都是那么顺利成章。最后也忠诚的建议大家：要想学会写需求文档，请先学会怎么样分析需求开始。生活也一样，从本质看起，这样我们感受到的会不一样。

建议继续学习：

1. 如何写产品需求文档（附PRD案例）    (阅读：4414)
2. 不懂技术的人不要对懂技术的人说这很容易实现    (阅读：4413)
3. 关于架构的一句话，还有一个实例    (阅读：3578)
4. 用Unix的设计思想来应对多变的需求    (阅读：3583)
5. 需求评审与讨论问题的基本方式    (阅读：2940)
6. 百度PM万维雅：需求把握和正确决策    (阅读：2695)
7. 如何准确看清用户需求？    (阅读：2557)
8. 用户的地图需求分析    (阅读：2385)
9. 姐要的视频广告    (阅读：2242)
10. 分析用户需求：在场景中寻找“痛点”    (阅读：2052)