互联网
产品
第一步，按照你们创业的想法用最快的方法做出一个非常粗糙的原型，这个原型甚至只是一个没有功能的空壳（软件用户界面，或者纸板搭出来的硬件原型），让你们的团队自己用用看，把自己放在非常苛刻的客户的角度，看看是否会接受（不是界面本身，而是所表达的功能）？并用快速迭代来改进设计。比如Kickstarter上的一个基于Android很有名气的游戏平台OUYA，他们的游戏手柄，就是先用木头做的快速原型，在内部试用。目的是什么？在初期用尽可能小的代价，发现产品的不足，错误和不足发现的越晚，改正的代价就越昂贵。
第二步，找出具有创新意识愿意和你一起玩的几个非典型客户，做出一个只有简单的核心功能的原型请他们试用。能找到这种客户并不容易，可以有各种方式，比如许诺第一批产品出来以后免费赠送给他们。但首先这些客户一定是非典型的，极端客户。比如OUYA就会请一些游戏高手来试玩。比如下面这个OUYA的创始人，陪着一个游戏玩家一起玩游戏。这些客户是极其宝贵的，他们不仅会指出很多你没有考虑到的地方，帮你拓展思路，甚至会帮你打翻原有的设计！在这过程中你要注意观察这些极端客户的行为，不仅听他们说，还要琢磨他们为什么这么做。在这不基础上你可以发现很多新的需求，甚至产品的独到卖点，因为很多客户需求是客户自己都没有意识到的
第三步，根据上面的需求分析，再反馈回来，做新的改进，并进一步完善产品。也就是说重复第一步和第二步。直到非常确信这就是客户想要的东西，而且产品也可以做公众测试了。（可以想见你找到的极端用户陪你走这一程，他们是多么宝贵！）这时候基本功能就稳定了，但是还有很多bug，没有关系，因为你下一步要做的是寻找更多客户验证需求，而不是debug。
第四步，这时可以寻找更广泛的友好测试用户群体，通过观察和倾听，了解更多的需求。这时候大部分需求都是比较细微的，比如（那个颜色的遥控器我不喜欢）等等，若有重大的需求改变，就需要要做出取舍，因为这时候做改进已经非常昂贵了。提问的时候多问开放型的问题，why, what, where, which, how等等，而不要仅仅问：你喜欢吗？这样弱智的问题。
第五步，才是真正把产品做稳定，安排市场推广等等常规的流程。
一般一份PRD文档要包含以下这些内容：1、概述部分：简单介绍一下产品的背景，产品的价值或者愿景，产品的简单介绍，一些预估的风险点，干系人，名词解释等等；2、业务需求描述部分：定义好目标用户群体，业务流程图，业务架构图，脑图等等的介绍；3、功能需求描述部分：这部分才是用到上面所述方法的点，每个功能点都可以用那样的方式描述；4、非功能需求描述部分：与产品相关的一些辅助功能，性能要求、易用性要求等等；5、接口描述部分：与外部有相关接口的需要在这个部分描述；6、附录部分：培训信息、参考资料等，还可以有运营计划等等；完整的PRD文档中，最多的部分就是对功能需求的分解描述，AxureRP可以很好的支撑这个部分的全部内容，另外其实AxureRP也有流程图、UML图的功能，业务流程图、业务架构图等都可以在AxureRP里面实现出来。
1、远期沟通，充分沟通。在项目尚未立项的阶段就与参与人员尤其是研发人员沟通，让大家对于项目的意义、需求、目标有充分了解，这样大家心才能往一处使 2、充分评估与时间预留。对于项目的时间周期评估，需要建立在方法1的基础上，而且是对主体细节有充分了解，同时，对衔接出有buffer预留，避免意外情况 3、需求锁定与细节让步。需求提出后，在研发过程中需要处于锁定期，不得随意修改；而由于评估不完善造成的部分细节实现难度，在不影响大前提的条件下，产品人员要有优先级概念，对可让步的内容进行让步，并思考补救措施 4、全程的review。在产品demo基本完成后，不需要等到功能完整，产品人员就应该介入观察，不要把风险都堆积到上线前的验证。
每做一次项目计划变更，都会影响到日后的成本估算、活动顺序、行程日期、资源需求及风险控管的决策，因此甲乙双方的项目经理、IT经理都必须以整体的视野、统一的要求，对变更进行控制、确认与纪录。而需求变更的控制关键在于建立相应的控制组织、变更控制系统以及规范变更流程
充分做好前期的需求调研、系统培训等工作。深入企业一线，全面调查研究，最大程度地挖掘企业用户的潜在需求，发现可能要需求变更的地方，让企业用户尽快做出是否要进行需求变更。一般把需求变更或者新需求的确认最迟时间定在系统培训阶段。也就是说，在系统培训完成后、开始准备双线并行前，企业用户还可以提出需求变更的申请，但是，当系统开始双线运行时，就不允许用户再提出需求变更等类似的请求了，如编码的内容和规则、表单的数量和格式、数据流转和统计方式等，否则就要付出变更的代价。
建立变更控制组织系统。项目启动时，尽可能地与客户沟通，尽快建立正式的对变更进行控制的组织，通称变更控制委员会(CCB)，成员可包括双方高层(挂名)、甲乙双方的项目负责人、相关的需求负责人等，负责裁定接受变更内容、方法、步骤等。建立该系统的目的是统一管理需求变更和跟踪变更的状态，便于项目组测试人员、开发人员、系统分析员以及PM相互之间的沟通和交流。建立变更控制系统目的不是让用户不提出变更，而是让用户不轻易、随便的提出变更。
严格规范变更流程。一旦需求分析阶段结束，此后如果用户要求有新的需求加入即将交付的软件系统中，甲乙双方的项目组或变更控制委员会，要根据角色定义，确定变更流程，规定严格的变更控制流程，并控制新需求提出的频率。
对互联网产品而言，验收有三层含义： 产品功能用例化后，用例执行符合预期 与需求吻合，正向操作的用户体验良好 设计和前端UI符合评审的标准 第一层应该是测试人员应该重点关注的，，开发/产品本身就是测试，验收几乎等同于最后一次测试。但是无论是否有“测试工程师”这个岗位，产品需求的用例化都是十分必要的，即便通过了专门的测试，产品或领导在验收时，潜意识也是在执行相关的用例； 第二层说的是普遍意义上的验收，产品通过test平台测试，部署到了DEMO平台，由产品需求人员进行需求验收，当然，内部成员、相关领导都可以进行验收体验。对DEMO的验收，是“装成用户”后对产品的使用，通常是正向操作，同时除了逻辑和流程，验收人员会更加关注用户体验； 关于前端UI的验收，实际上是对“用户体验”的一部分标准化，而验收的内容应该与“设计评审”通过的内容相吻合。如果没有设计评审，那么标准就是公说公有理了。为了避免这种情况，需要在需求和设计评审前，界定清楚一些基本的准则和规范，的VI体系、符合W3C页面标准、符合XXX，最直观的还是所见即所得的“需求设计交互页面” 这个问题其实很好，好在专门提出了UI的验收。本质上是因为开发对UI或者对前端、兼容性等很容易忽略，因为这是个“简单但很花时间”的活儿，做起来没有成就感。当然，如果你们有一套自己的UI库或前端框架，那么能够规避很多前端上的扯皮，但如果没有，开发和前端至少需要50%的精力去搞页面。提前考虑标准、尽量使用框架、让代码公用并易于维护，这是前端和攻城师的硬功夫，否则就沉浸在无尽的BUG中，更不用说验收了。 至于谁负责？团队中的任意相关人都可以，前端、开发、产品、或者你们领导。总之，验收就是质量的最后把关，产品自己都看不过去，臭虫一堆，千万不要有任何侥幸心理让用户帮着验收。
做产品Roadmap规划的时候，要想清楚哪些需求是包括在MVP (Minimal Variable Product)的。也就是说第一版必须抓住目标用户的痛点和切实需求。在时间 金钱 资源有限的情况下，弄明白哪些功能点是必不可少的，对产品推出后成功是至关重要的。 如何弄明白这个问题？那就是从用户调研数据得来。没有经过用户验证过的产品原型一般来说都很难经得起推敲，因为这是在设计师（或者产品经理）的假设上完成的作品，而并不一定会获得用户的青睐和肯定。 当有了MVP（第一版）以后，就可以在市场的反馈结果上做下一步考虑，哪些地方是需要修改的，哪些功能点是需要补充的，哪些地方其实用户反响并不大可以移除的。把这些点做优先级排列，最重要和最紧急的放在下一个产品迭代周期的开发之首，再对新的产品原型做用户测试再做迭代。 A/B测试不是用来测试用户需求和主要功能点的，而是当产品有了一定的用户基数以后，团队对产品有了一些新的设计想法时，不能确定这个新设计是利大于弊还是弊大于利，于是对一些访问用户展示新的设计，同时对另一部分访问用户保留原有的设计，这样可以从用户转化率等其它目标变量来测试究竟哪一版的设计更改。