写需求其实并非是在谈需求。
需求活动主要不是编写需求文档，相反，它专注于理解业务问题，并为之提供解决方案。
怎么样才算理解了业务问题呢？
1.即你做的是哪个行业的产品，就对这个行业的商业模式、产业链、竞争状态等要有所了解。而只有深入了解了业务本身，才有助于发现使用场景，并为之提供解决方案，让用户用得爽。

2. 如果我们必须构建产品，那么它必须为拥有它的人提供最理想的价值。
除非产品提供了利益，否则拥有产品者不会付钱作为产品开发者或设计者，要深谙一点：即我们关注最终结果的拥有者，只是间接地关注用户。但是在免费时代，很多公司并不靠产品本身盈利，所以不能孤立地看这个上图中的曲线，应当将整个产品生态搭建起来，看看哪个环节是赢利点。

很多大公司，平台级的产品均是不盈利的，通过专心打磨产品获取千万级的用户，然后通过其他方式进行盈利，例如在线 、增值服务或电商。

3. 你必须知道要求是什么，才能构建正确的产品。

要理解产品打算为用户完成什么，以怎样的方式完成，就必须理解拥有者的业务工作。产品经理得到需求，描述产品的功能（做什么）以及产品的属性（做到什么程度）。

不幸地是，交流的无奈导致需求并非总是被恰如其分地理解了。

4. 构建一个产品和解决一个业务问题之间，存在巨大的差别。前者不一定实现后者。

这一点是对第一点的补充。做一个产品就是为了解决一个业务问题，因此开发工作必须从问题开始，而不是从解决方案开 始。

5. 需求不一定要写下来，但是构建者必须知道它们。

需求文档是为了更好的沟通想法，一份高效准确的需求文档能够让开发人员和设计人员非常明确需求是什么，从而实现它。但很多时候，口头沟通更方便、直接，特别是一些细节的确认，往往需要口头表达。

但值得注意的是，口头沟通需求效率虽然高，但是不是所有需求都能用这种方式来沟通。编写需求是为了让利益相关者和产品经理彻底地理解需求，也有利于追踪文档。

6. 客户不一定能给你正确答案，有时候他也不知道要什么。

利益相关者在描述一个需求时是由困难的，交流的无奈是存在的。所以产品经理应该把握业务的复杂性和规模。

有时候，产品经理应该如实记录下客户的要求；有时候，应该从解决方案中导出需求，有时候必须提出创新，得到更好的解决方案。

7. 需求不是偶然得到的，要通过某种有序的过程得到。

做产品就像拍电影，要先有一个剧本，确保剧情有序地发生。
任务的次序、重点和应用程度需要采用该过程的人或团队来决定，参与这个过程的人必须能看到为什么不同的任务是重要的、哪些任务对项目最重要。但优先级是可以调整的，过程中要灵活变通。

8. 怎么迭代都行，只要理解了业务的需求。

敏捷迭代越来越成为新宠，取代着原始的瀑布流开发方法。但是冷静的头脑在开发之前已经将需求过程吸收到开发的生命周期中了。

聪明的办法不是废除需求，而是从一个不同的方向接近需求。真正值得关注的是，既要发现需求，又不必编写无用的、不成熟的文档。

9. 所有的方法和工具都无法弥补糟糕的想法和糟糕的手艺。
这一点是对第 7 点和第 8 点的补充。

有序的过程并不能替代思考。需求收集、验证、编写文档的过程并不是一种流程，而是由提交的产物驱动的。

要记住，自动化的工具只是辅助手段，产品经理最重要的工具就是：脑袋、眼睛和耳朵。

10. 要想成功地实现需求，需求就必须可度量、可测试。

需求可以主要分为以下三类：

功能需求：产品支持其拥有者的业务时必须做的事情。
非功能需求：产品要再拥有者的环境中取得成功，必须将功能完成得多好的量化描述。
限制条件：全局性的需求。
例如，产品有一个需求是 “应该对新用户有吸引力”：
建立可测量的指标即：注册时间少于 2 分钟、数据项（例如姓名、邮件地址等）犹豫时间不超过 5 秒。
可以很肯定地说，如果你不能为需求找到测量指标，那么它就不是需求，只是一种无根据的想法。

11. 作为产品经理，你终将改变用户思考这个问题的方式。
产品经理的部分工作就是帮助人们尽早理解和质疑他们的需求，这样他们就可以帮助你发现它们真正的需求。

当产品经理开始理解需求时，尤其是在需求来自于不同利益相关者时，就开始建立起一套抽象概念，通过展示业务过程的模型渐渐参透工作的本质，得到清晰、可测量的需求，并把这些反馈给利益相关者。
在做这些事情的时候，产品经理就在渐渐改进（改变）他们对业务的看法。

写需求其实并非是在谈需求。
需求活动主要不是编写需求文档，相反，它专注于理解业务问题，并为之提供解决方案。
怎么样才算理解了业务问题呢？
1.即你做的是哪个行业的产品，就对这个行业的商业模式、产业链、竞争状态等要有所了解。而只有深入了解了业务本身，才有助于发现使用场景，并为之提供解决方案，让用户用得爽。

2. 如果我们必须构建产品，那么它必须为拥有它的人提供最理想的价值。
除非产品提供了利益，否则拥有产品者不会付钱作为产品开发者或设计者，要深谙一点：即我们关注最终结果的拥有者，只是间接地关注用户。但是在免费时代，很多公司并不靠产品本身盈利，所以不能孤立地看这个上图中的曲线，应当将整个产品生态搭建起来，看看哪个环节是赢利点。

很多大公司，平台级的产品均是不盈利的，通过专心打磨产品获取千万级的用户，然后通过其他方式进行盈利，例如在线 、增值服务或电商。

3. 你必须知道要求是什么，才能构建正确的产品。

要理解产品打算为用户完成什么，以怎样的方式完成，就必须理解拥有者的业务工作。产品经理得到需求，描述产品的功能（做什么）以及产品的属性（做到什么程度）。

不幸地是，交流的无奈导致需求并非总是被恰如其分地理解了。

4. 构建一个产品和解决一个业务问题之间，存在巨大的差别。前者不一定实现后者。

这一点是对第一点的补充。做一个产品就是为了解决一个业务问题，因此开发工作必须从问题开始，而不是从解决方案开 始。

5. 需求不一定要写下来，但是构建者必须知道它们。

需求文档是为了更好的沟通想法，一份高效准确的需求文档能够让开发人员和设计人员非常明确需求是什么，从而实现它。但很多时候，口头沟通更方便、直接，特别是一些细节的确认，往往需要口头表达。

但值得注意的是，口头沟通需求效率虽然高，但是不是所有需求都能用这种方式来沟通。编写需求是为了让利益相关者和产品经理彻底地理解需求，也有利于追踪文档。

6. 客户不一定能给你正确答案，有时候他也不知道要什么。

利益相关者在描述一个需求时是由困难的，交流的无奈是存在的。所以产品经理应该把握业务的复杂性和规模。

有时候，产品经理应该如实记录下客户的要求；有时候，应该从解决方案中导出需求，有时候必须提出创新，得到更好的解决方案。

7. 需求不是偶然得到的，要通过某种有序的过程得到。

做产品就像拍电影，要先有一个剧本，确保剧情有序地发生。
任务的次序、重点和应用程度需要采用该过程的人或团队来决定，参与这个过程的人必须能看到为什么不同的任务是重要的、哪些任务对项目最重要。但优先级是可以调整的，过程中要灵活变通。

8. 怎么迭代都行，只要理解了业务的需求。

敏捷迭代越来越成为新宠，取代着原始的瀑布流开发方法。但是冷静的头脑在开发之前已经将需求过程吸收到开发的生命周期中了。

聪明的办法不是废除需求，而是从一个不同的方向接近需求。真正值得关注的是，既要发现需求，又不必编写无用的、不成熟的文档。

9. 所有的方法和工具都无法弥补糟糕的想法和糟糕的手艺。
这一点是对第 7 点和第 8 点的补充。

有序的过程并不能替代思考。需求收集、验证、编写文档的过程并不是一种流程，而是由提交的产物驱动的。

要记住，自动化的工具只是辅助手段，产品经理最重要的工具就是：脑袋、眼睛和耳朵。

10. 要想成功地实现需求，需求就必须可度量、可测试。

需求可以主要分为以下三类：

功能需求：产品支持其拥有者的业务时必须做的事情。
非功能需求：产品要再拥有者的环境中取得成功，必须将功能完成得多好的量化描述。
限制条件：全局性的需求。
例如，产品有一个需求是 “应该对新用户有吸引力”：
建立可测量的指标即：注册时间少于 2 分钟、数据项（例如姓名、邮件地址等）犹豫时间不超过 5 秒。
可以很肯定地说，如果你不能为需求找到测量指标，那么它就不是需求，只是一种无根据的想法。

11. 作为产品经理，你终将改变用户思考这个问题的方式。
产品经理的部分工作就是帮助人们尽早理解和质疑他们的需求，这样他们就可以帮助你发现它们真正的需求。

当产品经理开始理解需求时，尤其是在需求来自于不同利益相关者时，就开始建立起一套抽象概念，通过展示业务过程的模型渐渐参透工作的本质，得到清晰、可测量的需求，并把这些反馈给利益相关者。
在做这些事情的时候，产品经理就在渐渐改进（改变）他们对业务的看法。