产品建设流程探索（一）
1、做好准备工作：
了解产品的客户群体、竞争对手、产品团队（产品、研发、UI、测试、运营）的实力以及需要涉及的技术。从顾客、用户、竞争对手、分析师、产品团队、销售团队、市场及公司职员中收集他们能够发现的问题和可能的解决办法。
2、确定产品的目标：
确定你的产品目标是什么，解决什么问题，价值主张是什么（电梯理论）。一个清晰明了的价值主张能够让产品团队、管理人员、用户、试产人员都能明确的知道产品的意图是什么，从而更好的接受和建设优秀的产品。
3、确定用户原型、用户目标和用户任务：
用户原型：和尽量多的用户交流，与他们交流讨论、观察，对用户和客户进行分类，然后决定哪一类作为主要用户；然后尽量对这种用户特征进行详细描述（满足所有人是徒劳，最后往往没有人对你满意，所以尽量提出几个最重要和最流行的角色进行述；同样，如果你不去精确的定位你的目标用户，你就只会存在模糊的概念，你会发现理解你用户的反应非常困难。你要倾向于设想，让你能更像你的用户），以定义出“任务角色”，需要是典型、可行的、真实能够使用的。
用户目标：确定了我们的主要用户类型，我们就需要找出用户使用产品的目标：即用户使用产品想要干什么，解决这个根本问题是很困难也很有挑战性的，特别当你周围的人告诉你你已经解决了他们想要的。而最好的解决办法取决于是否你清晰的了解到底什么问题需要解决，每个用户模型可能有不同的目的，需要在用户原型涉及的方面中进行寻找。有可能将来某个功能解决的问题并不是主要用户需要达到的目标之一。
用户任务：用户为达到目标使用产品需要完成的任务。明确了用户原型与目标，就可以开始设计任务来实现用户的目标愿望，这是产品制作过程中的核心部分，也是创造力和创造力被激发的地方。
注：目标、任务并非具体的功能，功能是实现用户目标意愿所必须的，而很多功能往往都是低优先级甚至完全多余的。一个很讽刺的现象是：你用越少的功能你的产品感觉会更加强大，这是因为你的产品功能越少，你的用户就会发现并使用更多的功能，而用户成功的使用的功能越多，他们就会认为你的产品越强大。这是有些反直觉，我们在自己的行业中会愿意花费更多的时间去探索功能和容忍复杂性。
4、定义产品原则：
明确了用户任务之后，我们需要根据用户任务定义详细的需求和用户体验，同时还会面对许许多多的抉择，为产品标准作出最佳的选择是非常用必要的。
在大多数团队中每个成员都会有自己的“做好产品”的原则，但很少会有两个人的原则是一样的，这样的差异会导致不同的成员在面对相同或不同的选择时出现完全不同的结果，这将会是很糟糕的情况。因此尝试制作一系列整个团队的产品原则是非常有必要和有价值的事情，但这些原则需要具体到具体的项目、甚至项目的某一个阶段，它将在团队成员在项目中与到诸多问题做决定（选择）时进行指南。
5、产品原型和检验：
这是一个实现前面想法的阶段，通过创造力或创新力拿出成就的地方。但这里很多人容易翻一个错误：就是对产品的设计规范太有信心，因此一旦到测试阶段就发现自己想要的东西与拿到的东西差距太大，背离产品目标，但这个时候并不适合进行重大改变和调整。解决办法是进行大量的原型实验，如：
可行性测试：即产品是否可被开发，产品工程师和设计师都应该介入技术的可行性调查和探索可用的办法，就会发现有些办法是可行的，有些是行不通的，然后进行提前规避。
可用性测试：需要设计师和你一起提出产品功能，让它尽量满足不同的用户（主要用户），可用性测试经常能够找出产品功能或逻辑出现遗漏的地方，同时还能够验证你最初的需求是否合理的、必须的。可用性测试必须在产品的真实用户身上进行测试，没有人能够代替真实用户。
6、概念测试：
只是可用和可行是够的，更重的问题是：你的用户愿意为它付费吗？他们喜欢吗？你为他们提供了什么价值？对小部分功能较为单一、简单的产品而言，你的想法直接写在上或者通过描述就可以满足，但对于更多的时候：复杂的互动操作或是新的技术实现，为了预估产品是否达到了预期的目标，某种形式的原型是很有必要的。因为在实际中去检验产品非常重要，不然一旦实际产品研发开始，做出重大改变将会非常困难或者代价将会很大。
7、验证和质疑：
当你认为你已经弄清楚你的产品需要解决的问题，便可以进行验证和质疑假设。假设是很容的，但是不要把假设当做指引去进行，那会阻碍产品的成功（例：最开始人们进行假设太阳、月亮及其他行星都是围绕地球转的，并以此为指引在错误的方向上探索，最后当然不可能得的现代宇宙的真相，反而阻碍了人们获得现代宇宙的真相）。
8、 写：
最后你需要把这些写下来（PRD），用于在团队内进行沟通，要明白你会说很多事情，也不只是对一个人说，所以将必要的内容表述清楚并写下来是很有必要的。至于格式与内容形式其实都不是重点，重点是你需要尽可能严禁、无遗漏的表述你的要求，让团队成员能够轻松看懂、理解，且能够跟着项目进度进行更新。
PRD的四个组成部分：
1、产品用途：
指出目标，让团队成员知道他是干什么用的，目的是什么。尽可能的明确，基本包括以下内容：
A：哪些内容你要解决，不是解决方案；
B：谁是目标用户；
C：情景描述；
D：细节很多，但重要地方必须清晰；
2、产品功能特性：
产品需求文档最主要的就是需求，具体的需求取决于产品的领域、类型、目标……；但不论何种需求，你都需要清晰、严谨的陈述你的要求，而不是含糊不清。
A：描述每个功能的交互和使用案例都需要你非常清楚该功能的用户体验，还需要给工程师和设计师留下足够多的灵活发挥空间；
B：确定那些需求满足什么目的，否则一旦决定要削减某个功能就会非常困难，因此需求描述从要求——目的明确的说明将会使文档更加清晰，后续调整也会更加方便；
3、发布标准：
发布标准经常是不断变化的，不同的产品、不同的阶段都会有不同的发布标准。但PRD应该考虑到为每种标准定一个最低要求（如：性能、可测量性、可靠性、可用性、可控性）。
4、时间进度：
描述一个产品的需要的时间进度表，这是一个很难的事情，随便的定一个时间是没有用也没有意义的，需要描述环境、动机和预计目标，让整个团队都和你意义达到预计目标，最终共同完成一个成功的产品。
9、 优先级：
除了明确的要求，还需要给每一个要求定一个优先级排序，一般需要名产这个要求的重要程度：必须、重要、希望拥有。
A：必须：代表着产品基础架构和核心价值；
B：重要：不是必须，但在产品上线/销售时候尽量要满足这项要求；
C：希望：即使现在不能实现，但也需要作记录，在未来的版本迭代中有机会加进去；
可能这样还是不够的，还需要分更多的优先级，因为项目完成/上线的时间基本是确定的，并且为了配合销售或运营的工作同步进行经常还会被压缩时间，进而被迫削减功能，如果不进行优先级排序可能会导致最后客户使用事后关键功能没有完成。另外在开发过程中还经常遇到很多意料之外的问题需要解决，此时优先级排序将能够指引你优先解决关键问题，帮助在决策时作为平衡依据。而如果没有优先级的划分和排序，很多问题将无法被确定。
整个PRD是一个不断完善和思维提高的过程：清晰、严谨会造就成功的产品，模糊混乱会导致失败的产品；在激烈争论时有助于做出决策，且能够能住工程师理解和降低不必要的沟通成本。
10、测试完整性：
有一个PRD草稿后你需要测试他的完整性：
A：工程师是否能够清晰的了解并达到目标；
B：OA团队（测试/质量管理）是否有足够的信息来做出测试计划；
最后当相关人审核了PRD，确定产品各个方面都得到的说明之后，就可以按照PRD执行开发工作了。
11、管理产品：
在产品实施开发过程中，在完美的PRD也会有无数问题需要被解决，解决PRD中存在的问题，如果不存在就在PRD中写进去，而你的任务就是迅速解决问题并记录在PRD中，这样项目审查就会变得非常简单，因为任何一个部分都记录在册。PRD是一个“活文件”，跟踪记录产品开发整个过程，所有你认为有必要的内容都需要记录进去。
