很多人好奇，我们平时用的比如微信APP，简书这些产品都是怎么从一个想法到最后做出来让我们知道和使用的。今天就和大家粗略的说说一款产品的诞生记。我总结了下，大致有6个步骤。
第一，一个点子或灵感
国内互联网行业发展的如此迅速，从2000年的百度，QQ和四大门户，到2010年的电商，团购，移动硬件，再到近两年的滴滴，直播。不断产生的创新领域新产品如雨后春笋般纷纷诞生，前仆后继。如今你能叫得上名字的产品都是从无数“尸体”上爬出来的。QQ因为赚钱无门路差点被卖掉，京东因为非典走上了电商的快车道，这些无数具有前瞻性的的想法和决策是引导着一款产品从无名走向世界的初始。
某一天，你突然灵光闪现，不管这个点子会为你赚很多钱，或者会给你带来很多用户，或者你觉得大家一定会为你的这个idea拍手称赞，会喜欢的不得了。都可以认为这是一个很不错的想法，但是，事实真的会如你想象的那么美好吗?这就需要进入下个环节， 验证你的想法。
环节主要参与人员：一般为公司老板，产品经理等。
第二，验证你的想法
俗话说的好，“上梁不正下梁歪”，这句话同样适用在互联网产品上。产品方向就是这个上梁。
想象很美好，现实很骨感。一个在你认为很赞的点子，可能对于其他人根本丝毫不感兴趣。难道你就这么一厢情愿的认为全世界都会为你的这个点子买单？答案自然是否定的。所以你要做的一件很重要的事情就是“接触用户，论证想法”。
通俗点来说，你找一些这个想法潜在的使用者聊天，看看他们对这个想法持什么态度。如果高票通过，大家都迫不及待的等着你的产品出来一睹真容，说明你已向成功迈近了一大步。如果大家都表现出无所谓啊，或者抵触感很强，或者压根就没有和你共鸣，你就要多想想了，是不是自己的个人想法不代表所有人，在交流过程中你说不定能够挖出一些和你这个类似的其它想法。有时候一些小小的偏差，就会导致满盘皆输，要知道产品的方向，军令如山倒，一开工就没有回头箭了，即使能调整， 那付出的代价也是比在的调研阶段要大很多的。
如今成群结队的创业者走上这条“破釜沉舟”的不归路。以用户为中心的思维已经被人说的烂掉了，但是仍然有人只是拿它当作一句口号，做起事来还是我行我素。然鹅，很多公司产品的话语权并不是那么高，在面对老板强硬的态度，大多数人选择的是妥协，明明知道这个需求是个伪需求但仍然要执行落地。这点无奈，我相信很多产品同学应该感统深受。
如何破这个局？核心就是如何说服老板。
是时候体现出产品的专业度了。通过专业的竞品调研（现有线上其他产品的发展数据），用户调研（潜在使用者的反馈），模式上的行不通（如果有逻辑错误的情况下）等等，输出专业的调查报告，侧面的告诉老板，我们还是想想其他路子吧。再好一些的产品，甚至通过自己的调研找到了一条其他的路子（建立于你充分理解老板需要走哪个战略方向，战略层），并梳理成文档呈现老板，这样是最有说服力的（不要光否定，有时候拿出更好的解决方案才是最有力的说服）。
小注一下1：用户调研是门系统的功课，里面不仅涉及需求调研，还有核心产品的原型稿和迭代稿，不断的在初期兵马未行的情况下完成产品在初期范围层和结构层的确定。（Q2中有一本推荐的《用户体验的要素》，里面对各个层级做了具体阐述，感兴趣的可以详细做下了解。）
小注一下2：除了用户，还要多多让诸如客服、市场、运营、商务、销售等多岗位人员提前参与进来，他们的出现会起到锦上添花的效果（千万不要被带偏而动摇根基）。
环节主要参与人员：产品经理，交互设计，视觉设计等。
第三，研发阶段
好了，假设以上环节你都已经完成了，下面即将进入实际开发阶段。
产品团队输出一套经过确认的全家桶。内含一份《交互原型稿》（可迭代），一份《产品需求说明文档》（PRD，可迭代），一份《功能开发清单列表》。研发人员通过这些文档，就能够很清晰的了解产品的从宏观到细节。根据产品需求的实际功能开发评估量，由技术经理进行多人分模块并行开发。视觉设计根据产品原型和背景需求，发挥出自身的专业度，选择和产品气质相吻合的设计风格和控件。确认后交付前端（含Web/H5/Android/iOS）进行前端界面的代码编辑。后端（服务器端）根据需求开始准备数据库，相关接口的和前端交互的准备工作。这里面涉及到的四五个工种之间的并行开发，也是一门学问（效率，会议，沟通，跨部门等等），这里就不展开说了，后面有机会单独回答。
开发完成，进入测试阶段。
一般根据需求，会设定多个测试环境。第一道关，开发单元自测。每个模块的开发在完成自己部分的功能后，需要自行跑一边，看看流程是否能跑通啊，是否能够正常工作啊，是否符合前端界面设计的标准啊；第二道关，产品验收。所有模块都开发完毕了，产品就需要连起来当作一个已上线的产品标准去验收一遍（这个alpha版本，通常会让你丑的哭，难用的让你抓狂）；第三道关，测试团队验收。一般还要分三个环境：第一个内网环境（问题实在太多，方面开发频繁修改调试），第二个封测环境（该环境和线上环境保持一致，尽可能提前发现线上的潜在问题），第三个灰度环境（小范围发布在几台服务器上，如果有错误能够尽早回滚，影响面不太大），第四个生产环境（对所有用户发布，正式对外，这时候一般出现的问题就会很小了）。另外，测试团队在研发期间也会根据需求列出一份详尽的测试清单（专业点叫测试用例），把可能遇到问题的测试点，全部走一遍。确保以最小的风险上线。
对了，再说下版本更新。对于客户端产品来说，版本发布是否需要更新，要看需求是否对客户端的框架部分进行了改动。一些客户端产品有强制更新和非强制更新一说。具体要看改动的客户端功能新老版本是否兼容。（单一个更新，这里面也有文章，比如哪些地方要用客户端写，哪些要用H5写，版本如何控制，版本编号如何确定命名等等，后面再说吧。）
OK，至此，一款产品已经可以让所有用户下载使用啦。
环节主要参与人员：产品经理，交互设计，视觉设计，Web/H5研发工程师，Android/iOS研发工程师，服务端研发工程师，测试工程师等等。
后面还有三点，详见下一篇吧。
最后，如下链接可以引导你去看产品问答的其他内容：
