外包公司一般情况是这样的，客户负责写产品需求文档1.0版，然后产品经理负责补全。产品经理有可能是老板，有可能是一个销售。这都不是最主要的。最主要的是要把需求文档补充完整。
这里面有一个问题，很多公司的人忙来忙去，不愿意写那么详尽的文档，把写文档的时间拿出来和程序员沟通一下，效果反而更好。但是这种公司，必须具备一些条件，其中一个很重要的条件是基本的 UI 部件没有固定的标准（在大公司，按钮、配色都有相应的设计准则），那么很有可能出现产品的功能和功能之间不协调的问题。尤其是当一个成员辞职后，整个产品组需要花很长时间来填补这个空缺。
理论是死的，人是活的。不论是写详实的文档还是写粗略的文档，需求文档都应该包含一下内容：
1、要解决什么问题。解决好几个问题的话，优先级要排列出来。
2、论证用户的痛点，是否存在。
3、写清楚这个产品上线之后的正作用和反作用。比方说，有些金融公司的风控系统做的太智能了，可能就被竞争对手利用了。或者说其中一个功能上去了，导致大家都不用其他功能了。
4、要讲清楚用户使用场景，尤其要弄清楚限制条件，限制条件包括主观和客观，用户自身有条件限制，客观情况限制了用户。
5、解决方案不能有歧义。这一条大部分是写给自己公司内部看的，确保内部不会有误会，不会有分歧。内部开会讨论解决方案的时候，大家能形成思想统一。