前不久支付宝首页改版了，令人欣喜的是“哇！支付宝”做得很不错，有机会要好好用用，写写感受，今天上班就写写支付宝登录页面上的验证码这个细节吧。
首先支付宝的验证码并不变态，仅仅是阿拉伯数字，容易识别，这个给用户的体验已经不错了（当然也会面临一个问题：容易被破解），经过这次改版，登录验证码的用户体验又得到了进一步的提升：首次登陆不需要输入验证码（根据cookie判断），输错密码时，才会提示输入验证码进行判断。
这个改进虽然不算是首创，但体验还是不错的。不过验证码还有另外一些问题，如果由用户看不清怎么办（虽然仅是数字）？支付宝的验证码又没有“刷新验证码”的功能，算是美中不足吧（或许是因为验证码太清晰了，没必要）。
Posted in 产品经理.
– March 10, 2010
昨晚第一次摸索到了弄开一次性牙膏的方法，也算学到了开启这类膏剂瓶的正确方法。都奔三的人了才学会打开膏剂瓶，是自己失败？还是产品使用说明有问题？
还是先来看看我是怎么打开一次性牙膏的吧：
下面是常见的一次性牙膏包装，以前我经常是把后面破肚（有点暴力倾向），可惜这次是塑料外壳，撕不开。想办法，宾馆找工具……
同学提醒，瓶盖有突起的刺尖，可以借力捅破牙膏嘴。恍然大悟~
第一次完美打开一次性牙膏。
过程就这么简单，但也产生了一个疑问，为什么我才知道开瓶的方法？首先是自己的探索精神还不够，其次瓶身说明还不够，或者不明显，对于一次性物品的使用，很多人并不会认真研究，顶多是看下瓶身的图案，所以产品的使用说明一定要简单明了，并且“显而易见”。
产品设计的最高原则是不需要额外的说明书，用户可以“即拿即用”，其次是拿到产品看下上面的图标/文字就可以使用自如，如下面的一次性牙膏设计：使用方法已经画在了瓶身上，用户很容易明白怎么使用。
末了，网站产品的设计也是如此，要让用户一看就明白是什么功能，怎么使用，提高易用性。
Posted in 产品经理.
– March 2, 2010
最近越发对产品经理这一职位感兴趣了，专门抽时间对产品经理的职责做了研究，今天算是第一步，整理一篇产品经理常用软件精选推介，希望能对将来的“产品经理”有所帮助。
流程用具visio
用例工具Rational-Rose
原型工具 axure RP
演示工具demo-builder
测试工具TestDirector
Microsoft Office Visio是微软公司出品的一款的软件，它有助于 IT 和商务专业人员轻松地可视化、分析和交流复杂信息。它能够将难以理解的复杂文本和表格转换为一目了然的 Visio 图表。该软件通过创建与数据相关的 Visio 图表（而不使用静态图片）来显示数据，这些图表易于刷新，并能够显著提高生产率。使用 Office Visio 2007 中的各种图表可了解、操作和共享企业内组织系统、资源和流程的有关信息。
Posted in 学习制作.
– February 23, 2010
国内互联网公司里，百度的产品一向为人称道。尤其是其搜索引擎的周边产品，比如百科、知道、贴吧等一系列产品。在不少资深互联网用户和专家眼中，这些产品应该是搜索引擎的标准配置。然而到底是什么让百度能够规划和设计出这么多优秀的产品，为什么他的竞争对手在这些领域根本无法与其匹敌？我们邀请百度的产品经理亲自为我们揭开谜底。
任何一个产品人员，要理清产品的分析和决策思路，首先要弄清楚什么是产品。产品的核心价值，是用户使用该产品的终极意义。例如军大衣和比基尼都是用来穿的，但是前者的核心价值是御寒，后者的核心价值是性感。手机虽然变化多端，但核心价值是语音沟通，所以如果通话音质不行的话，这个手机再炫再酷，也会被用户舍弃。
互联网产品也是同样道理。很多产品在外表看起来是一样的，但是如果深挖的话，用户为什么要用？最根本的好处是什么？答案是非常迥异的。例如一个是百度知道，另一个假设是在线购物网站的疑难问答平台，产品形式可以相似，但本质完全不同。前者的核心价值在于“让人们更便捷的获取信息，找到所求”，而后者则应该是一种高效的在线客服手段。这个本质差异就导致了很多要点和细节上的产品决策差异。
所以对一个产品进行分析之前，首要问题，便是弄清楚用户为什么要用这个产品，它带给用户最根本的好处是什么。
要解答这样一个问题，并不容易，很多失败的产品在一开始就没弄明白用户用它的理由，注定了后面的失败。在产品研发前，百度搜索引擎产品人员首先要解答这个问题。
百度产品决策原则
搜索引擎产品部门在招聘产品人员时，应聘人员尤其是对互联网充满热情的学生常常积极地抛出自己的各种想法，却没有仔细分析为什么做？该不该做？
外界也常常有人提出一些疑问，为什么百度不做这个产品？为什么百度不做那个产品？
在《李彦宏的百度世界》里，阐述过百度的产品决策原则：“无论百度推出什么产品，总是遵循三个原则：有需求、有优势、有收益。”
首先是需求导向。无论是客户需求还是用户需求，归根到底都是需求。先有需求，才再有动作。借用一个经典小故事，有两个卖鞋的人去岛屿上开拓市场，一个回来后跟老板说：“那里没有市场，根本没有人穿鞋。”另一个回来后跟老板说：“那里市场可大了，大家都还没有鞋。”这个问题如果放在产品决策上，应先问需求，先摸清楚对于这群用户来说，他们穿鞋的好处、不穿鞋的好处，再决定下一步。
其次，在有效满足需求方面，我们有无优势。用户体验是一个完整的过程，对于用户的终极需求的满足，才是真正有价值的。
“视频搜索”这个想法在搜索引擎产品部很早就有考虑和接触，但早期互联网资源非常有限，资源的下载是一个致命的瓶颈，搜索做得再好，对用户最终获取并观看这个视频并无多大的帮助，因此当时没有介入；到了后期，由于专业视频分享网站的兴起，用户视频体验得到了巨大的提升，且资源众多，从用户搜索关键词里很容易能发现大量视频搜索需求，百度在搜索方面的优势能为找视频的用户提供更多更好的便利，而网页搜索通用搜索解决方案并不能完全满足视频搜索的特殊需求，因此视频搜索诞生的时机到了。后续经过产品设计、产品研发，成为一款大量用户使用的搜索产品就是顺理成章的事情了。
最后是要符合百度使命，专注于搜索，增强公司的核心竞争力，才能保持旺盛的生命力，并且推动搜索领域更深远的发展。现在大家看到，百度网页搜索、MP3搜索、图片搜索、知道、贴吧、百科等每一款产品都拥有庞大的用户群，并互相关联、互相促进——这并不是偶然现象，也不是百度为了整合产品而做的整合，而是它们的诞生恰恰就是为了有效地满足用户需求的，它们本身构成了搜索引擎的整体架构，也是百度最核心的产品竞争优势。
产品的创新思路
为什么要创新？李彦宏说过，“创新的目的是为了更好地满足需求，不为创新而创新”。产品和技术部每天都在进行着创新的尝试，但新技术、新功能、新概念只是工具或手段，产品设计更关注“为什么创新”。
百度产品体系的重大创新是搜索社区，百度的贴吧、知道、百科、空间等，构建了一个完整的搜索社区体系，我们回顾一下当年贴吧上线时首页的那句话：互联网上的信息，和人脑中的信息相比，只是沧海一粟——百度过去几年的经验证明，类似贴吧这样的搜索社区模式，在将人们的隐性知识转化为显性知识，并借以提升搜索引擎的核心价值方面，是极其成功的。所以，贴吧是一个伟大的创新，相对全球而言更是独一无二的，而贴吧所代表的搜索社区的产品创新模式和不懈实践探索，更是百度对搜索领域做出的杰出创新贡献。
有些人认为横空出世的东西才是创新，只有推倒重来的东西才是创新，但是不要忽略一点，有些创新是“润物细无声”的，有些创新是细节的，但它们至关重要，同样推动着某一领域的进步。
比如在图片搜索领域，很多人都会觉得以图搜图、颜色筛选、人脸识别这些内容识别技术看起来很新颖，认为只有提供了这样的功能才是创新。在百度产品部的图片搜索组，早期几乎每一位新同事都对这些服务好奇，但经过了一段时间的用户行为分析和思考，才能理解使用筛选功能并不一定是有效解决用户问题的最好方法，应用各种用户需求识别技术、图片识别技术优化搜索结果排序，将用户更需要的图片直接排列在用户的眼前，这也是重要“润物细无声”创新。
对产品的正确决策
产品经理或产品设计师的责任就是保证产品的成功，从产品的决策到产品是否能符合预期地完成开发上线，当然最核心的是在前期需求，解答一个产品为什么做和做成什么样子。
产品人员在把握产品决策原则的基础上，要有敏锐的洞察力，要能作出正确的判断，还得具备两个必要条件。
第一，他自己就是产品的忠实用户。百度产品部门的每位同事，对互联网应用充满热情和兴趣，主动地成为相关产品领域最熟练的一线用户，带着真实的使用目的，能和用户站在一起，而不是带着审视检查的角度，后者往往当局者迷，不能洞悉真正的需求。比如贴吧的产品人员在学生时代不是骨灰级论坛潜水者就是知名论坛的风云人物；网页搜索的某位产品人员搜索引擎爱好者，进入百度前就热衷于发现各种搜索引擎妙用。
第二，他必须能站在大多数普通用户的角度去思考问题。百度产品部门不要求任何专业背景、技术背景，只要你能精确地把握和尊重普通用户的体验，在这一点上的要求近乎苛刻。你不能因为你懂得各种搜索技巧，就期望普通网民像你一样。当设计常用功能时，这样的思考是被拒绝的：“如果用户不明白，可以去看帮助文档”“这个问题用快捷键去解决”……而实际上面临的判断要难得多。
当然，搜索引擎作为信息获取的入口点，汇集千千万万网民的需求和使用习惯，百度的产品人员更能通过直接的数据来分析用户的行为，从他们比较集中的搜索请求中发现产品问题和产品诉求。这也是制胜的法宝之一。
有很多不明白互联网产品工作的人问：“怎么保证你的想法是客观的？”“怎么保证你需要的就是大众需要的？”面对这样的问题，很容易让人想到去做调研，调研的方法很容易让人想到是问卷调查。但实际上，产品设计和改进的很多方面是你没法通过直接问用户得到你想要的答案的，就像你没法通过直接询问用户的每一次搜索需要什么来指导搜索结果更准确。其实，用户实际的行动已经实实在在地告诉了产品人员，比他自己说得更多、更真。当互联网产品的用户群体达到一定规模，他们的行为数据具备统计意义时，会比纯粹的市场调研行为更加可靠和直接，那是非常珍贵的财富。
举个例子，我们通过用户行为的数据分析，发现网页搜索的用户行为与图片搜索的用户行为不一样：网页搜索的用户大多有特定目标，我们帮助这些用户快速地找到他想要的那条搜索结果以完成这次搜索，比如某某版本软件下载；而图片搜索很大比例的用户并无特定目标，他想欣赏一组图片搜索结果，比如某个旅游城市。这个时候，对每个图片搜索结果都要一一点击，打开新窗口不适应连续浏览体验，于是我们在搜索结果打开的模式上做了改进，这里面也有大量的数据分析，来决定什么样的模式对全体用户的总收益是最大的。
（转自：http://hi.baidu.com/zytsky/blog/item/2a3c4da3e65a6da6caefd023.html）
– January 3, 2010
做好产品需求文档的这十步，是经过长期的实践经验和反复验证而得到的。可能这里描述的不是很全面，但他已经足够让你做一个成功的产品需求文档。做好这几步花费的时间要以项目的大小、复杂程度、个体学识、基本技能熟练度而定。
第一步：做好准备工作
你要做的是一个让人无可争议的产品，为了做好他，你必须做好前期的准备工作。你需要去了解你的顾客、竞争对手、产品团队的实力和需要的技术。你需要从顾客、用户、竞争对手、分析师、产品团队、销售队伍、市场、公司职员等收集他们能发现的问题和可能的解决办法。这里有很多的工作需要你去完成,在“成功的产品背后”这篇文章中有详细的描述。
建立良好的交流也非常重要，它会影响着产品团队。如果你的准备工作做的够好，你也会变得越来越有信心和说服力。
第二步：确定产品的目的
任何一个好的产品都开始于一个需求。你必须清楚的了解这个需求，你的产品如何达到这个需求。
产品经理需要提出一个清晰、简明的价值主张，让它很容易被接受，要让产品团队、管理人员、用户、市场人员清楚的明白这个产品到底是什么意图。虽然这听起来很简单，但是也只有少数产品才有这样的价值主张。考虑“velevator pitch ”(电梯间演讲、电梯行销)测试。假设你在做电梯的时候遇到公司CEO，他问你产品的意图是什么，你能在电梯到达之前回答这个问题吗？如果不能，你就还有工作需要做。也许是你的说明没有针对性，他可能表现出来和其他产品做的没有什么明显区别；也许你提出的观点不能和你的用户产生共鸣；也许你解决的是一个非常规的问题，可能你想应用一种技术。这个价值主张可能需要满足公司的产品战略。注意你不需要阐述太多的细节，从某些方面来说，一个有价值的观点应当是越简越好。
产品需求需要确切的指出这个产品发布的目标，同样的这个目标也有优先之分。例如，你的目标可能是：1）易用，2）零售价不足$100，3）和前期产品很好的结合。然后你需要说明如何去测算。对于“易用”这类项目，你需要明确指出产品可用性达到某个水平。这是通常用目标用户来定义。可用性工程师能测算出你的产品对目标用户的可用性，也测算出可用性问题的严重程度，同样你可以说明没有重大的可用性问题。
这里的关键就是让每个人都知道产品成功的时候是什么样，还有给产品团队在设计和实施中遇到问题如何进行取舍的指导。
第三步：确定用户原型、用户目标和用户任务
现在你已经明白你想要解决什么问题，下接下来就要深入了解目标用户和顾客，在这步中，和你的PD（产品设计）紧密联系非常重要。
用户原型
在这个阶段，PM需要和很多用户交流，需要花费大量的时间去直接观察和讨论。现在我们需要对用户和顾客进行分类，然后决定那一类是我们的首要用户。
比如你正在做一个像eBay一样的互联网拍卖服务，你同时拥有买家和卖家，在这之中还有使用频率少的用户和经常使用的用户，不难想象还有个别特殊的用户，比如团体公司采购者。
PM（产品经理）和PD（产品设计）需要首先确定类型是最重要的，然后尽量对这个用户群的特征进行详细的描述，以便使用这个模型去指导产品的设计。这个模型通常称其为“人物角色”。 虽然是想像的，但是应该是典型的、可行的和真实的，让你能够使用。这个想法来自与一个能代表这类用户的本质的原型。
举个例子：
“里昂是一个超级卖家，46岁，男性，居住在Fresno，经营小型摩托车配件。虽然他开着一个小店，但是他的生意大部分来自Ebay,每个月平均有400多次交易。他出售的东西品种非常多，但是他最受欢迎的商品还是哈雷戴维森的负重袋。他自己拥有两个哈雷，还开着1993年的丰田皮卡。里昂已经结婚了还有两个小孩。
里昂买电脑仅仅是因为他需要使用Ebay,除了ebay和电子邮件很少再使用其他东西。里昂已经在Ebay上销售产品已经三年了，他学会了在ebay应该掌握的东西，他非常自豪的拥有超过5000的信用度。如果Ebay更改了网站，特别是销售的过程方面，对于他来说改变习惯、学习这些变更是非常困难的。 里昂已经形成了自己的习惯，星期一列出销售的商品，星期五拍卖结束，设法让在收到货款的几个小时内出货。”
但愿这样的描述能让你了解里昂和知道他是怎么来的。当我们考虑新功能时，我就要问问自己里昂会是什么发应，为了让他能顺利的使用这个功能我们需要做什么。
注意缩小范围，让他仅仅描绘必不可少的。满足所有人是徒劳的，通常最后没人会满意，所以尽量提出几个最重要的和最流行的角色描述是非常重要的。同样，如果你不去精确的定位你的目标用户，你就只会存在模糊的概念，你会发现理解你用户的反应非常困难。你要倾向于设想，让你能更像你的用户。
用户目标（用户意愿）
一旦我们确定并描绘了我们主要的用户类型，我们就需要找出用户在使用产品中的目标(想要干什么).这听起来很简单，但是解开根本问题是非常具有挑战性的，特别当你周围的人告诉你你已经解决了他们想要的。
从CEO、销售代表、工程师到客户，每个人都太兴奋而不能帮助你找到解决根本问题的办法，他们会告诉你在某个地方添加一个快捷按钮，或则添加一个功能仅仅是因为竞争对手有，或则是改变成他们喜欢的颜色。
最好的解决办法取决于清晰的了解到底什么问题需要解决，每个用户模型可能有不同的目的，需要在用户原型涉及的方面中进行寻找。有可能将来某个功能解决的问题并不是主要用户需要达到的目标之一。
用户任务（tasks，用户为达到目标使用产品而需要做的任务）
掌握了用户原型与他们的目标愿望，我们就开始着手设计任务来满足他们的目标意愿，这是产品制作进程中最核心的部分，也是创造力和创新力被激发的地方。
许多优秀的产品仅是用更好更新的办法解决一个已有的问题，有时候这种办法仅仅是应用一个种新技术，但是大部分是来自深刻的见解而使一种新方法的产生。例如TiVo（美国市场占有率第一的数字录像机）在电视节目录制的老问题上面想出一个全新的办法，让顾客更加容易地实现他们的目标并且建立了电子设备一个全新的类别。
注意我们虽然谈到了目标和任务但是还没有谈到具体的功能，这些功能都需要达到用户目标而必须的。你以后会发现许多功能都是低优先级或则是完全多余的。
以“必须功能”这个理由可以排除很多功能。讽刺的是，你用越少的功能，你的产品被发现得越来越强大。这是因为产品的功能越少，你的用户就会发现并使用更多的功能，成功的使用越来越多的功能他们就认为你的产品非常强大。这些理由都是违反我们直觉的，我们大多数人都不能和我们的用户一样，我们在自己的行业中愿意比用户花费更多的时间去探索功能和容忍复杂性。
第四步：定义产品原则
现在你需要开始把你的需求和用户体验定义成详细的要求。同时你仍然会面临着许多的决定和权衡，为你的产品标准作出最佳的决定是非常重要的。
在大多数的产品团队中，每个成员都有做好产品的原则，但很少有两个人有同样的想法，这些差异都会导致不可思议的结果。
尝试和制订一系列指导整个团队的产品原则是非常有价值的，这些原则需要具体到域名和项目。
用TiVo举例，在产品团队工作开始时，以下这些产品规范就被建立，并在团队里传达：
1.它是娱乐的
2.一个傻瓜式的电视
3.一个该死的视频设备
4.平滑柔顺的
5.没有模式和深层次
6.尊重观众的隐私权
7.像电视一样强大
这些规范很大的影响到产品的定义而且在很大程度上加大了难度，但是他们确实是成功产品的来源。比如易趣的口号就是：1、易于使用 2、安全 3、有趣
它将在该项目中，在面对众多问题而作出决定的时候进行指南.
第五步：产品原型和检验
这是一个拿出你想法的阶段，创造力和创新力拿出成就的地方.
很多人都容易犯一个常见的错误，他们对产品设计规范太有信心，结果一旦得到beta的测试他们就必须调整产品。但是肯定beta测试版并不是进行重大改变的时候，所以才会有许多首次发布的产品离目标太远。
对于许多产品来说，这个时候你可以用大量的原型做很多的实验。首先，下面的三个非常重要的测试你可能需要做
可行性测试
一个直接的问题就是产品是否可以开发，你的工程师和设计师应当介入技术的可行性调查和探索可用办法。有些办法是行不通的，但是有其他的办法可行是非常有希望的。
工程师会发现在产品的某个阶段不可能逾越，现在知道比以后知道要好。
可用性测试
产品设计师将要和你紧密工作共同提出产品功能，让它能适应不同的用户。可用性测试常常会找出遗漏的产品要求，同时确认产品最初的要求是否是必须的。在你拿出一个成功的用户体验之前需要多做一些测试工作。可用性的目的是在真正的用户身上测试，从产品目标用户得到质量反馈的测试是非常艺术和科学的。当然产品经理和产品设计将模仿使用，但是实际是没有人能取代真实的目标用户。
概念测试（Product Concept Testing）
光是可用和可行是不足的。真正的问题是你的用户想要购买吗—你的用户有多喜欢-你做的有什么价值。这测试可能与可用性测试联系在一起。
对于一部份小产品，您的想法写在纸就足够了，但是对于多数产品，为了预计产品是否达到目标，复杂用户互作用或新技术的使用、某种形式原型都是非常重要的。
原型也许是一个物理设备，或者它也许是软件产品的一个预览版本。关键是它需要足够现实，您能用原型在实际目标顾客身上测试，并且他们可以给您质量反馈。
以前做原型主要有两个障碍。第一是缺乏良好的原型工具，需要花费很多的时间制作原型；另一个是管理方不知道原型和真实产品的区别，在不可预计的情况下，按照最终产品来要求原型。
今天有优秀的原型设计工具可以让工程师或设计师快速的制作原型，可以有效的模拟未来的产品以达到必要的程度让实际用户进行测试。而且大多数管理者都知道模仿和实际的区别 — 就如同缩小比例的房子模型和真实的家一样。
在实际去做产品之前去检验你的产品是非常重要的。一旦实际的工程开始，作出重要的变动会变得非常困难，花费也会变得很高。
第六步：验证和质疑
当你认为你弄懂了你需要解决的问题，现在是时候开始验证和质疑假设。
假设甚至当作不知道是很容易的，但是切勿把不可知的结论当作指引，那会妨碍你获得成功。天文学最初定义是研究太阳和其他行星如何围绕自己转，本身的定义就是一个臆断，反而阻止人们获得真相。
第七步：写
当然你需要把这些都写下来，大多数的PRD都是word文档，但也有一些是帮助文档，PowerPoint，或则写在白纸上。当然用什么格式不是很重要，重要的是让团队成功能轻松的看懂，不会遗漏，还有就是PRD可以随着项目开发而更新。
记住对话是两个人之间的，但是PRD是要沟通整个小组。你也要记住获得产品的销售才是是重要的，所以不必担心要有什么漂亮的外观、PRD写的有多厚，只要它是可读的、可理解的、是需要的内容。
PRD文档主要有四个部份组成
产品用途
你的工作就是指出目标，团队需要知道他们的目的是什么，目标说明要尽可能的明确，请确保你的内容包括：
*那些问题你要解决，不是解决方案
*谁是目标用户
*细节很多，但是大图片必须清晰
*情景描述
多开展集思广益的会议和临时口头的讨论，从而更好的写出来，更会让团队深入了解。
产品功能特性
产品需求文档最主要的当然是需求。 具体的需求完全地将取决于您的领域，但是不管你是什么行业，您的产品团队将受益于陈述需求的清楚，毫不含糊的要求，而不是模糊的解决方案。
描述每个功能的互动设计和使用案例。您必须非常清楚每个功能和用户体验，还需要给工程团队留下足够多的灵活自主空间。
同样重要的是确定那些要求满足哪个目的。这里就需要提到“需求跟踪”，对于关键的产品这是一个重要的流程。每种产品规范可能受益于清楚确定那些要求满足哪个目的，如果某人决定削减要求，想要深入了解就会非常困难。 从要求到目的明确说明将会是文档更加清晰。
发布标准
发布标准经常是不断变化的，但是好的PRD应该考虑到为每种标准定一个最低要求。典型的如：性能，可测量性，可靠性，可用性，可控性。
时间进度
其中很困难的一个问题就是描述产品需要的时间进度表。随便列出一个时间是没用的，你需要描述环境、动机、预计目标。你需要整个团队都和你一样达到预计目标，最终完成一个成功的产品。
第八步 优先级
除了明确的要求，对每一个您的要求给予优先和排列秩序是很重要的。多数产品经理，如果他们给予优先级，一般都是表明要求是否是“必须有， “重要”或“希望拥有” (或其他一些分类系统)。分类是很重要的，不可掉以轻心。
产品经理对任何一个标记“必须拥有”都需要有高度的标准。如果还没有找到必须拥有的功能意味着产品还不应该产生。所以小心标注“必须拥有”，这些标注“必须拥有”的功能直接反应出产品的核心价值。
“重要”的分类也很重要，在产品销售前只要有机会就要满足这些功能。
“希望拥有”产品团队也应该注意到，即使大多数也都没有实现，在未来版本也适当的慢慢实现。
这些有时候是不够的，从1到n每一个分类优先排序都是很重要的。有几个原因：
首先，上市时间总是被关注，并且日程表经常下降，您说不定被迫使削减有些特点为了尽快进入市场。 你也不想产品团队先开发简单的功能而放松重要的功能，导致最后客户使用的关键功能还没完成。
其次，在产品设计和开发阶段，团队将会发现更多的问题产生并解决这些问题，所以很有可能有更多关键功能出现。优先顺序会可以帮助你如何平衡以容纳更多的功能。
这点就是说产品经理如何不给出优先级和重要等级，其他相关较少的因素也会跟着无法确定。
整个PRD是一个不断完善和思维提高的过程，明朗锐利就是可以成功的产品的，模糊就是失败的产品。在争论最激烈的时候也能容易做决定，并且帮助工程师做出计划。
第九步 测试完整性
现在你有一个PRD草稿，你需要测试它的完整性。工程师是否可以充分了解并达到目标？OA Team（质量管理团队）是否有足够的信息来做出测试计划，是否可以开始做案例？
当投资人或相关人审核了PRD，确定了各个需要说明的方面，所有的问题得到解决，现在你就可以按PRD进行产品开发。
第十步 管理产品
在产品实施期间，就算是最好PRD，也有不计其数的问题被解决。解决所有PRD中存在问题，如果不在PRD中就写进去。你的任务就是迅速解决问题并记录在PRD。
如果你做了你的工作并准备记录在PRD，项目审查就会变得非常简单，因为任何一个部份都历历在目。
记住PRD是一个“活”的文件，在要跟踪记录在产品开发期间的所有功能过程。最后你会发现很多额外的东西，如果你认为是必要的就在PRD中写进。
本文大体已经结束，全面的阐述一个PRD的产生和管理过程，感谢SVPG的分享。接下来有空闲时间我会整理上传一份互联网行业的产品需求文档模板在本页面，供大家下载。
– December 19, 2009
