1 战略规划：
作为一些产品的负责人，钥匙从没有参与战略方向的制定，仅有幸以旁听的形式进行过极少的战略讨论，这些讨论会与其说是战略讨论会，不如说是公司领导极力说服大家朝某个战略方向走，也就是战略思想灌输。看过很多同行朋友的说法，似乎对于产品经理来说这是一个普遍现象，也不难理解，一个产品要有大的投入，做与不做甚至做成什么样都是老板非常关心的问题，因此产品经理在战略制定的时候能起到的作用很小。
不过战略规划也是需要总结和分析的，虽说互联网行业瞬息万变、时不我待、快马加鞭、紧赶慢赶~~~ 但是要开拓一个新产品还是需要完成这个产品的简单分析和战略的描述。
2 前期分析：
产品的前期分析不分高低贵贱都要做，大到一个完整意义上的产品，小到一个新功能，前期的分析都是非常关键。这个前期分析首先是要了解这个产品，以及产品相关服务的生态系统（ecosystem），一个产品经理在这个阶段所要做的就是了解整个领域的情况，竞争对手，用户，甚至需要关注一下国家政策。其次在这个阶段需要给产品一个定位，要回答的问题诸如“用户是谁？”，“满足用户的什么需要？”，“我们应该提供哪些功能（内容）满足他们？”等等，当然了，这些问题在这个阶段我们只需要一个定性的分析就可以了。
3 用户研究：
用户研究包含的范围很广，《赢在用户》这本书有经典的描述，从前期的用户访谈到可用性测试直到上线后产品运营时对数据的分析，都属于用户研究的范畴，这里仅仅讨论产品开发前期的用户研究。在前期首先要对整个业界这个方向产品的情况做调研，收集情报，这期间有很多方法，土一点的比如从CNNIC、IResearch等处寻找调研结论直接Copy，好一点的选取目标用户进行访谈、发放问卷、寻找专家进行访谈等等。
钥匙想说的是，想要做好一个用户研究需要花费的精力很多，尤其是在一个没有专门用户研究人员的互联网公司里，能给你这么多时间与资源来做这件事实在是一个奢侈的想法，不过在有限的投入下获得最大的成果是决定产品经理能力高低的体现，所以也没什么可怨天尤人的。在这个阶段需要搞清楚一些问题，比如“我们的用户到底是谁？”“他们有什么样的需求？”“如何才能有效的实现他们的需求？”。
4 概念设计：
概念设计是一个产品的灵魂体现，这部分的实现产品经理可以要求UED与你一同完成，不过很多公司可能没有专门的UED做这件事，所以只能自己撸起袖子干的。简单的把概念设计分为三个阶段：
第一个阶段：需求概念。概念设计的开始往往伴随着头脑风暴会，选出一些靠谱的功能（内容）的设计，然后由产品经理给出一个功能范围定义，最好能附上部分核心功能的交互流程。这时最好开一个会议，会议内容就是找上老大们敲定下来我们的功能范围，这点非常重要，一定要有记录，否则会出现项目进行中老大跳出来要改方向的事故（当然，有记录老大也可能会跳出来，但是如果这样你能争取到对应的自由度）。
第二个阶段：概念原型。此时就要体现产品经理资源整合的能力了，最理想的状态是拉来一个人帮你完成一个高保真的功能原型，钥匙见过比较牛的是找一个Flash牛人，做一个纯粹的Flash实现的高保真原型，那叫一个真！往往伴随着高保真原型的出现，会重复上面说到的用户研究，但不论怎样这东西最终的目的是给公司老大们汇报，让老大们看看这东西原来就长这个样子，同时也让老大们用一用，敲定产品的一些具体实现。如果上第一阶段是设计产品的骨架，那么这一阶段就是给骨架上添点肉了。
第三个阶段：完成MRD（市场需求文档）。这个阶段主要是总结一下上两个阶段东西，拼凑成一个完整意义上的MRD，这里就是考验产品经理画饼的功力了，以文档和原型的方式告诉公司领导层你要做的这个东西是什么样子，为什么做成这个样子，能解决用户的什么问题，这样做了再市场竞争对手间有什么优势，未来有什么样的发展预期，当然，最最重要的是你通过这个阶段的汇报，能为你争取到多少资源。
5 需求确定：
这部分内容应该是业内大部分的产品经理都在做的事情，有了上面的积累一个产品的样子已经在产品经理的脑袋里鲜活的出现了，产品经理所要做的就是撰写一系列的文档将这个鲜活的影像记录下来，所谓PRD和UI详细设计就是这个阶段的产出物。此时你的产品已经放在了纸面上，你要把他小心的交给项目经理了，再由项目经理分解你的需求写成一个FSD（功能详细说明文档）这个文档是给开发人员看的，他们可以拿到这样的文档直接开始开发。
需要注意的是，很多互联网公司往往没有项目经理，或者有也是在管理开发团队无数个项目的项目进度的监管员。钥匙的经验是要么会有一个架构师来分解你的需求，要么直接拿你的需求给开发，伴随着开发不断的骚扰和自由发挥把项目完成。
钥匙遇到的一般是有一个项目进度监管员，且无人帮你分解需求的情况，这种情况只能是产品将PRD写的尽量的细致，除此之外，还要在脑海里有一个非常完整，非常细节的情境，在开发针对你PRD中某部分有疑问的时候清清楚楚的告诉他这里应该是什么样子的。
6 项目预算：
这部分暂时不涉及财务问题，仅仅从项目管理的角度看，我们需要由一个WBS（工作分解结构），一个甘特图，一个资源直方图，这是最少的配置，可以清晰的显示出你的项目进度与所需资源的关系。这项目管理方面内容理论较多，在这里不做赘述。
7 实施开发：
开发的过程比较考验你前面的工作，基本上你在甘特图上应该有不止2个的检查点，到时检查项目的进度是否符合预期，如果出现了问题也要想办法保证进度。如何保证呢？基本上有加班和砍功能两种办法，砍功能这点是开发痛快，产品痛苦的事情，而加班正好相反。不论你最终选择了什么方法，最最核心的就是记住你这个产品所服务的用户是谁？他们是不是用不到你想砍掉的功能。
8 产品上线：
我所经历的产品上线都是悄悄的上线，并没有大张旗鼓的做市场活动，我想这是大部分互联网产品上线的情况吧。悄悄上线是好处多多的，由于互联网产品逻辑复杂，流程多样，所以在没有大量的用户使用并做几次迭代改进前，很难说会存在哪些问题。在这方面钥匙有一次惨痛的教训，记得有一次钥匙负责的一个产品上线，上线成功的信在公司内部研发中心群发，信里感谢了一堆的同事，搞的特别煽情，结果是大家感兴趣的上网一看，哇塞！随便点点就发现一堆的BUG，群情激奋的同事们立马用发信表达自己的不满，看到那些两位数的关于产品BUG的信，钥匙当时我只有一个愿望，就是切腹自杀~
这个惨痛的经验让我明白了，谁都不能为你的产品负责，即便有强大的测试团队告诉你你的产品OK，完全达到上线的指标，也要自己在上线前狠狠的测试一下，毕竟没有那个测试人员比你还了解产品&用户。
9 产品运营：
以前有位老大曾经说过，互联网产品是一个萝卜一个坑，一个新产品开起来了，一个人砸下去就一直在这个坑里挖了，挖的深了还得多拉几个人下水，如果想再开一个新产品只能找另一个人来挖坑。这句话可以体现大多数互联网产品的情况，也说明了产品运营的重要性，在整个产品生命周期里绝大多数的时间都是在做运营。
说到做运营钥匙感慨良多，各种类型的互联网产品之间的运营方式千差万别，而且每种产品的运营都有很多技巧在里面。比如新闻类产品，Sohu的首页新闻是每五分钟观察一下点击数据，点击差的就往下撤，同时运营人员也以点击量为考核目标；再比如论坛类产品，运营的工作主要是和人打交道，论坛的斑竹、分类的管理员、总管理员，层层的组织都要有运营老大建立，建立完毕了还需要自己在里面用马甲发帖，顶贴直到找到一些不错的意见领袖，形成一个良好的讨论氛围，论坛类产品的考核目标是UV和PV/UV双重指标；再再比如钥匙做过最多的搜索引擎的运营，不停的订指标，写规范，做评估，最后推动开发改进，搜索类产品的指标就不单是PV、UV这么简单了，各种性能都有自己的指标，根据产品所处阶段衡量指标不同。
总而言之，运营才是一个产品能否成为优秀产品的核心！
OK！记录了一遍我所理解的新产品开发流程的流水账，这个流水账其实是一个比较理想的东西，在实际操作过程中经常会剪掉其中某几块的内容，PRD可能在压根没有做用户调研的情况下写出来，项目预算也可能根本不用做，所以请大家仅作参考之用，不要太深究其中的细节。
作为一些产品的负责人，钥匙从没有参与战略方向的制定，仅有幸以旁听的形式进行过极少的战略讨论，这些讨论会与其说是战略讨论会，不如说是公司领导极力说服大家朝某个战略方向走，也就是战略思想灌输。看过很多同行朋友的说法，似乎对于产品经理来说这是一个普遍现象，也不难理解，一个产品要有大的投入，做与不做甚至做成什么样都是老板非常关心的问题，因此产品经理在战略制定的时候能起到的作用很小。
不过战略规划也是需要总结和分析的，虽说互联网行业瞬息万变、时不我待、快马加鞭、紧赶慢赶~~~ 但是要开拓一个新产品还是需要完成这个产品的简单分析和战略的描述。
2 前期分析：
产品的前期分析不分高低贵贱都要做，大到一个完整意义上的产品，小到一个新功能，前期的分析都是非常关键。这个前期分析首先是要了解这个产品，以及产品相关服务的生态系统（ecosystem），一个产品经理在这个阶段所要做的就是了解整个领域的情况，竞争对手，用户，甚至需要关注一下国家政策。其次在这个阶段需要给产品一个定位，要回答的问题诸如“用户是谁？”，“满足用户的什么需要？”，“我们应该提供哪些功能（内容）满足他们？”等等，当然了，这些问题在这个阶段我们只需要一个定性的分析就可以了。
3 用户研究：
用户研究包含的范围很广，《赢在用户》这本书有经典的描述，从前期的用户访谈到可用性测试直到上线后产品运营时对数据的分析，都属于用户研究的范畴，这里仅仅讨论产品开发前期的用户研究。在前期首先要对整个业界这个方向产品的情况做调研，收集情报，这期间有很多方法，土一点的比如从CNNIC、IResearch等处寻找调研结论直接Copy，好一点的选取目标用户进行访谈、发放问卷、寻找专家进行访谈等等。
钥匙想说的是，想要做好一个用户研究需要花费的精力很多，尤其是在一个没有专门用户研究人员的互联网公司里，能给你这么多时间与资源来做这件事实在是一个奢侈的想法，不过在有限的投入下获得最大的成果是决定产品经理能力高低的体现，所以也没什么可怨天尤人的。在这个阶段需要搞清楚一些问题，比如“我们的用户到底是谁？”“他们有什么样的需求？”“如何才能有效的实现他们的需求？”。
4 概念设计：
概念设计是一个产品的灵魂体现，这部分的实现产品经理可以要求UED与你一同完成，不过很多公司可能没有专门的UED做这件事，所以只能自己撸起袖子干的。简单的把概念设计分为三个阶段：
第一个阶段：需求概念。概念设计的开始往往伴随着头脑风暴会，选出一些靠谱的功能（内容）的设计，然后由产品经理给出一个功能范围定义，最好能附上部分核心功能的交互流程。这时最好开一个会议，会议内容就是找上老大们敲定下来我们的功能范围，这点非常重要，一定要有记录，否则会出现项目进行中老大跳出来要改方向的事故（当然，有记录老大也可能会跳出来，但是如果这样你能争取到对应的自由度）。
第二个阶段：概念原型。此时就要体现产品经理资源整合的能力了，最理想的状态是拉来一个人帮你完成一个高保真的功能原型，钥匙见过比较牛的是找一个Flash牛人，做一个纯粹的Flash实现的高保真原型，那叫一个真！往往伴随着高保真原型的出现，会重复上面说到的用户研究，但不论怎样这东西最终的目的是给公司老大们汇报，让老大们看看这东西原来就长这个样子，同时也让老大们用一用，敲定产品的一些具体实现。如果上第一阶段是设计产品的骨架，那么这一阶段就是给骨架上添点肉了。
第三个阶段：完成MRD（市场需求文档）。这个阶段主要是总结一下上两个阶段东西，拼凑成一个完整意义上的MRD，这里就是考验产品经理画饼的功力了，以文档和原型的方式告诉公司领导层你要做的这个东西是什么样子，为什么做成这个样子，能解决用户的什么问题，这样做了再市场竞争对手间有什么优势，未来有什么样的发展预期，当然，最最重要的是你通过这个阶段的汇报，能为你争取到多少资源。
5 需求确定：
这部分内容应该是业内大部分的产品经理都在做的事情，有了上面的积累一个产品的样子已经在产品经理的脑袋里鲜活的出现了，产品经理所要做的就是撰写一系列的文档将这个鲜活的影像记录下来，所谓PRD和UI详细设计就是这个阶段的产出物。此时你的产品已经放在了纸面上，你要把他小心的交给项目经理了，再由项目经理分解你的需求写成一个FSD（功能详细说明文档）这个文档是给开发人员看的，他们可以拿到这样的文档直接开始开发。
需要注意的是，很多互联网公司往往没有项目经理，或者有也是在管理开发团队无数个项目的项目进度的监管员。钥匙的经验是要么会有一个架构师来分解你的需求，要么直接拿你的需求给开发，伴随着开发不断的骚扰和自由发挥把项目完成。
钥匙遇到的一般是有一个项目进度监管员，且无人帮你分解需求的情况，这种情况只能是产品将PRD写的尽量的细致，除此之外，还要在脑海里有一个非常完整，非常细节的情境，在开发针对你PRD中某部分有疑问的时候清清楚楚的告诉他这里应该是什么样子的。
6 项目预算：
这部分暂时不涉及财务问题，仅仅从项目管理的角度看，我们需要由一个WBS（工作分解结构），一个甘特图，一个资源直方图，这是最少的配置，可以清晰的显示出你的项目进度与所需资源的关系。这项目管理方面内容理论较多，在这里不做赘述。
7 实施开发：
开发的过程比较考验你前面的工作，基本上你在甘特图上应该有不止2个的检查点，到时检查项目的进度是否符合预期，如果出现了问题也要想办法保证进度。如何保证呢？基本上有加班和砍功能两种办法，砍功能这点是开发痛快，产品痛苦的事情，而加班正好相反。不论你最终选择了什么方法，最最核心的就是记住你这个产品所服务的用户是谁？他们是不是用不到你想砍掉的功能。
8 产品上线：
我所经历的产品上线都是悄悄的上线，并没有大张旗鼓的做市场活动，我想这是大部分互联网产品上线的情况吧。悄悄上线是好处多多的，由于互联网产品逻辑复杂，流程多样，所以在没有大量的用户使用并做几次迭代改进前，很难说会存在哪些问题。在这方面钥匙有一次惨痛的教训，记得有一次钥匙负责的一个产品上线，上线成功的信在公司内部研发中心群发，信里感谢了一堆的同事，搞的特别煽情，结果是大家感兴趣的上网一看，哇塞！随便点点就发现一堆的BUG，群情激奋的同事们立马用发信表达自己的不满，看到那些两位数的关于产品BUG的信，钥匙当时我只有一个愿望，就是切腹自杀~
这个惨痛的经验让我明白了，谁都不能为你的产品负责，即便有强大的测试团队告诉你你的产品OK，完全达到上线的指标，也要自己在上线前狠狠的测试一下，毕竟没有那个测试人员比你还了解产品&用户。
9 产品运营：
以前有位老大曾经说过，互联网产品是一个萝卜一个坑，一个新产品开起来了，一个人砸下去就一直在这个坑里挖了，挖的深了还得多拉几个人下水，如果想再开一个新产品只能找另一个人来挖坑。这句话可以体现大多数互联网产品的情况，也说明了产品运营的重要性，在整个产品生命周期里绝大多数的时间都是在做运营。
说到做运营钥匙感慨良多，各种类型的互联网产品之间的运营方式千差万别，而且每种产品的运营都有很多技巧在里面。比如新闻类产品，Sohu的首页新闻是每五分钟观察一下点击数据，点击差的就往下撤，同时运营人员也以点击量为考核目标；再比如论坛类产品，运营的工作主要是和人打交道，论坛的斑竹、分类的管理员、总管理员，层层的组织都要有运营老大建立，建立完毕了还需要自己在里面用马甲发帖，顶贴直到找到一些不错的意见领袖，形成一个良好的讨论氛围，论坛类产品的考核目标是UV和PV/UV双重指标；再再比如钥匙做过最多的搜索引擎的运营，不停的订指标，写规范，做评估，最后推动开发改进，搜索类产品的指标就不单是PV、UV这么简单了，各种性能都有自己的指标，根据产品所处阶段衡量指标不同。
总而言之，运营才是一个产品能否成为优秀产品的核心！
OK！记录了一遍我所理解的新产品开发流程的流水账，这个流水账其实是一个比较理想的东西，在实际操作过程中经常会剪掉其中某几块的内容，PRD可能在压根没有做用户调研的情况下写出来，项目预算也可能根本不用做，所以请大家仅作参考之用，不要太深究其中的细节。
温馨提示：答案为网友推荐，仅供参考
第1个回答 推荐于2016-06-16
先绑定手机再注册账号：
优点：防止恶意注册，刷帐号，减小服务器负担，用户质量提高。
缺点：部分用户对使用手机号反感，或因隐私问题不愿意注册，流失一部分用户。
建议：互联网产品成熟后使用。
先注册账号再绑定手机：
优点：注册方便，可以吸引更多用户。
缺点：可能会引起大量恶意注册、灌水、刷帐号等。
建议：互联网产品初期使用，后期过渡为必须绑定。
第2个回答 2012-03-22
先绑定再注册：优点：可以直接用手机号作为注册用户名，数据库简化，注册方便；缺点：用户担心信息泄露。
先注册在绑定：优点：用户直接使用注册账号登陆，而手机号只是作为注册信息中的一个部分，能减少信息泄露风险。缺点：数据库增加。
从用户使用的角度看，建议先注册在绑定，而且最好是自由绑定，不能强制绑定。追问
先注册在绑定：优点：用户直接使用注册账号登陆，而手机号只是作为注册信息中的一个部分，能减少信息泄露风险。缺点：数据库增加。
从用户使用的角度看，建议先注册在绑定，而且最好是自由绑定，不能强制绑定。追问
可是很显然，上面的两个流程。绑定手机是必须的步骤。我想问A方案是注册过程中会出现什么情况会使注册失败？
追答A方案注册需要用户输入收到的验证码，如果手机网络信号出问题等的，无法收到验证码，肯定注册就失败嘛
追问按你这么说。B方案也一样要失败的啊。因为肯定要经过验证才能注册成功的
追答最好是先注册成功以后再与手机绑定验证，要不然都没人注册，本来注册就是很烦人的，你还要验证，如果注册的开始或者过程中就要求验证，没人会注册，你的这两个方案都是失败的方案。你去看看人家做的好的，比如网易邮箱，都是先注册成功以后，询问用户的意愿来进行手机绑定的。哪有一来就要求验证的，这种方案一般都是失败的。
相似回答