复盘一款产品从到的全过程

　　从一个想法到最终看到一个产品＂长＂出来，需要产品经理有过硬的基本功和良好的商业感觉，同时也要有强大的协作领导能力，使团队形成统一的合力才可能最终实现。
　　从0到1做一个产品，从来都是让人激动，很多PM一直都很期待自己能够真正主导一个完成的产品。
　　回顾这些年的工作经验，我在不同的领域经历过多个不同规模、不同性质的产品，见证过一个产品仅仅从一个脑海里的＂想法＂最终演变为一个大型的产品，有幸主导过大型的平台型产品的全过程，当然也未能幸免的承接过失败的黑锅。
　　这个过程，有过欢乐，也有过很多不愉快的往事，好在我心依旧，并不曾丢失＂追求卓越的初心＂和＂改变世界的幻想＂。
　　我相信对生活的热爱，终究给我们带来最美好的世界。
　　作为一个产品人，也许这一份热爱，才是始终推动我们努力的根本。我试图复盘我所主导的一个2B产品，尽可能的复原当初的故事，在点滴中重温旧日的梦想。
　　这个系列，我准备了很长的时间，也多次起笔又中途放弃，断断续续的拉锯，也许最终成型的文字，仍然充满了矛盾和混乱，只愿怀胎十月，能让它呱呱落地。
　　我将尽可能的解密推动产品落地的全过程，包括产品的定义，设计和开发，以及由此引发的系列问题，更包括在此过程中我所学到的宝贵经验和深刻教训。
　　01万事开头难，如何启动一个新产品？
　　回顾曾经所有经历的项目，成功的，或者失败的，都各自有它的缘由。但很多项目是从一开始就出现了差错，所以在整个复盘的过程，我把＂定产品义＂放在了最前面，比如如何定义一个产品经理的角色，如何定义用户的角色，这也是正式启动一个新产品的第一步。
　　这些问题，包括直接用户的业务需求，也包括付费决策者的业务问题，当然也包括所在组织的商业目标。
　　＂产品定义＂的工作，在产品的实践过程中，决定了这款产品所能企及的高度，也对后续的整个迭代过程带来了重大的影响，甚至最终决定产品的成败。
　　这一部分，我准备了7个篇幅的内容，详细的复盘整个2B产品的前期准备工作。
　　1. 2B产品的核心需求到底是什么？
　　我们都知道，任何一个产品，都是为了解决用户的问题。
　　2B的产品与2C的产品，在对用户的理解上是完全不同，它想要解决的问题就不再是简单的＂使用者＂的问题，而是使用者和决策者背后的＂组织的问题＂。
　　这是一种完全不同的视角，它带来的显著特征就是它的体验不是单一的使用体验，而是由此带来的对整个企业业务的影响，才是其核心体验——效率和效益才是企业的核心诉求。
　　对任何企业来说，首要需要解决的始终企业自身的＂绩效＂问题，而不是＂一线员工＂的工作＂舒适度＂问题，或者说这些问题的优先级实际上是靠后的。
　　这个是最被忽视的问题，特别是2B的产品，很多时候都只关注到所谓的＂使用体验＂，而没有真正却解决付费的＂决策体验＂，这个问题才是2B产品最底层的逻辑，但却并没有真正被重视。
　　2. 为什么做了大量的调研工作，还是做不好产品？
　　任何产品在启动之时，都需要考虑诸如市场环境，竞争状况，商业模式等重要问题，都需要经过缜密的论证才能得出真正具备可行性的产品目标，调研，成为了必须完成的工作。
　　但真实的情况是，我们极端的依赖数据分析和市场调研，但却又经常在调研中迷失。
　　曾两度出任英国首相的本杰明·迪斯雷利有句名言：
　　＂世界上有三种谎言：谎言、该死的谎言，还有统计数据。＂
　　针对新产品的调研都在做，但也经常失效。我们要知道的是，如果仅仅通过调研就可以把产品做好的话，那也实在太简单了。
　　单纯的调研往往是做不出好产品来的，因为数据常常只是用来支撑自己立场的依据，而不是反映真实情况，更没有通过数据分析找到宏观的趋势变化。
　　偏见，让我们远离真相。
　　3. 频繁爆发的产品质量事故到底是因为什么
　　传说中的张瑞敏怒砸砸冰箱的故事，至今仍然被人称颂。实际上，我们常能见到各式各样的产品质量事故，特别是硬件类的产品。
　　我们不禁要问，究竟是什么使得产品的开发工作陷入一种四处救火的状态？为什么整个团队看上去非常的忙碌，但做出来的产品始终差强人意，甚至还经常性的出现各种严重的产品质量问题？
　　我曾经经历过类似的局面，N条产品线并行在开发，国内和海外的订单都在交付，开始的时候一片欣欣向荣，结果大跌眼镜，迟迟无法正式量产一款合格的产品。这对整个团队打击非常巨大，就像一条无人掌舵的船，随波逐流，团队的每个人都笼罩在一片阴影中，不知道什么时候这艘船就可能彻底沉没。
　　救火，不断的处于救火状态，终将磨灭团队的信心和创造力。
　　4. 为什么产品经理活成了＂原型仔＂
　　PM这个角色从诞生到火热，尽管经历了这么多年的发展，但有一件事情是从未真正改变过的，那就是PM并没有真正匹配的权威和决策能力。
　　产品开发的任何一个过程都有的一个槽点，就是谁也使唤不动的尴尬。
　　很多时候，产品经理都只是被授权＂负责推动＂一个项目，所谓的＂用户需求＂事实上已经被老板们所圈定，要做的事情只不过是在一定的时期内，利用有效的资源把原型画出来，写好一份文档，组织一个会议，能够把这一项工作任务能够顺利的推动下去。
　　这也是为什么很多时候PM们被诟病或者自嘲为＂原型仔＂的起因，因为他们对开发的过程和成果，以及后续诸多环节往往难以发挥真正的影响力。
　　真正的产品经理，始终伴随产品的成长和壮大，们既是产品的设计者，也是产品的管理者，推动项目的落地仅仅是他们的一项基本职责。
　　他们能够赋予产品更多的价值，赋予团队更高的灵性和活力，让产品定位深入每个成员与用户的内心，使产品的设计、运营、推广都完全符合产品本身的定位。
　　一个好的产品，往往从一个好的PM开始。
　　5. 产品经理的挑战，以及如何打造有创造力的团队
　　产品经理作为一个＂特色＂的角色，既不会写代码，也不会切图片，他们的成功都来自于整个团队的努力。所以，打造一支富有创造力的团队，是产品经理的高阶能力之一。
　　产品经理需要在产品开发的过程中应对诸多的挑战，要有饱满的热情，带领产品成功的使命，还要有一定的担当，能够用于承担产品开发过程中的黑锅和责任，更要有足够的耐心和智慧去化解产品开发过程中的各种礁石。
　　找人和管人，是PM成长的必经之路，作为真正意义上的产品负责人，引导团队成员的多元化发展是必要的思考方向。
　　不但要保证团队能够应对各种不同的实战需求，又要充分考虑到个人的存在价值和差异化成长。只有这样，团队能够健康成长，产品才能持续良好的运转。
　　6. 新产品开发必须要遵守的基本原则
　　一个产品能否成功，取决于很多因素，在产品设计中的很多做法并没有标准的对错之分。所谓＂事在人为＂，同样的事情不同的人去做，结果可能完全不同。
　　做产品久了就会明白，很多时候真正左右产品方向的是所在组织环境，因为文化会带来完全不同的产品价值观——产品原则。
　　产品价值观决定了产品的商业模式，明确了产品的边界，体现公司对产品质量的追求，深刻影响着产品的设计和运营策略。
　　＂能力＂让我们把事情做对，而＂价值观＂让我们选择做对的事情。我们很难去左右企业大环境的影响力，但在产品的边界建设方面值得付出更多的努力。
　　7. ＂仪式感＂，是产品能否成功的重要因素
　　生活需要一种仪式感，产品的成功也需要不断营造的仪式感。因为各种因素的冲突引发的进度、质量问题，很多时候其实都能够被规避，但却因为团队、组织的傲慢和偏见，让这一现象此起彼伏，从未中断过。
　　所以，大型的产品，如何能够画好一张饼让整个团队了解这个产品的背景和远期规划，如何争取到恰当的支持、配合和资源帮助产品走向成功，这非常考验PM们纵向、横向管理的能力。
　　凡事预则立，不预则废。
　　启动会议是对项目前期工作的一个总结，更是对下一步工作展开的指南。但它终究只是一个形式，不要忽略它，也不要对它抱有太高的期望。
　　没有正式的启动会，可能这个项目不会得到重视，但召开了启动会也不见得就可以确保顺利完成，它只是告诉所有人，项目开始了，需要怎么配合、做什么事情、达到什么目标。
　　对于新产品开发而言，做好这些都只是前菜。
　　到这里，我相信你已经为准备打造一个伟大的产品，做好了足够的准备，拉起了一支富有战斗力的队伍了，建立了与之相匹配的产品文化和规范，更明确了相应的职责和管理机制，是时候出发了。
　　02体验来源于设计，如何规划产品的未来？
　　定义一个产品的过程，有些时候也会由此定义一个团队的＂文化＂，基本上决定了我们行动的方向和我们行动的方式方法，能在产品正式启动之初能够明确一些基本的规范，一定是一大幸事。
　　接下去的一个阶段，更多的是能体现产品经理的＂直接＂专业技能，请注意＂直接＂这个词汇的含义，因为产品文化、产品原则这些事情绝多数都超乎一线产品经理们的氛围。
　　但设计一个＂好用的产品＂——满足用户期望的产品是我们能够为之努力的事情，是作为产品经理最能自豪的一个过程。
　　这是一个＂产品的设计＂过程，包括定义产品的架构，梳理清晰的产品流程，设计产品的完整体验，这是一个专业技能的呈现过程。
　　这个过程，需要我们投入特别多的心血，还有对未来的规划和畅想。也因此，在这个过程我也用了7篇文章来阐释如何＂操刀＂完成整个产品的设计。
　　8. 架构能力，是产品经理渐进的核心能力
　　产品经理的终极目标，就是去架构公司的业务，解决从市场机会到商业变现的过程，这需要很好的商业意识、业务洞察、战略规划和架构能力来相互配合。
　　这种能力需要在实践中逐步积累学习，我们应当从产品的信息架构，递进到产品的业务架构，更多的去思考信息架构、产品架构和未来业务架构的关系，抽象一些发展产品架构能力方面的因素，不断的进步。
　　形象一些来说，业务架构是心脏，产品架构是骨架，信息架构是肌理脉络，最外面呈现的UI，只能算是皮肤了。
　　信息架构、产品架构与业务架构的关系，可以认为是一种递进的思考方式。作为产品经理，持续对用户、业务和商业模式的深刻洞察，特别从商业层面去梳理业务架构，是产品经理的高阶能力。
　　9. 基于用户洞察设计产品的业务架构
　　我们常常在市场研究上投入了大量的精力，但却在设计产品、服务和商业模式上忽略来自用户的观点。
　　在产品设计过程中，如何才能避免这个错误，如何才能真正深入的理解用户对价格、环境、日常事务的关心和愿望，以及用户的目的和想法如何影响产品的具体设计过程。
　　在这个过程，还存在一个巨大的挑战就是，到底该听取那些用户和忽略那些用户的意见。
　　每一个细分的用户群体，都有该群体的独有特征，他们对环境的理解，以及由此带来的行为和愿望都会存在巨大的差异。对创新性的产品而言，忽略对现有用户的关注，紧盯新的和未满足的细分群体，可能是更有利于产品的创新，从而带来更快速的增长。
　　10. 设计产品架构的基本方法
　　产品架构是团队基于某一独特市场和用户痛点的统一沟通语言，也是在产品迭代过程中的业务边界。
　　其根本目的就是为了梳理产品思路，从整体上把握产品的发展方向，把控产品的功能重点（卖点），它决定了产品必须要实现的功能，可以说产品的架构决定了产品的发展路径。
　　同时，为了满足我们所设定的＂架构＂构想，还必须配备相关的产品研发和市场运营资源以及具体的落地计划，包括技术选型和技术路径，市场营销规划等一系列的策略和措施。
　　我们可以想象一栋楼的地基问题所带来的影响，对任何产品而言，一旦架构定错，轻则楼盖不高，重则根本改不起楼。
　　架构，是一个偏向宏观的事情，但与＂房屋＂的案例不同的是，产品的架构不只是＂结果＂，而是一种迭代的过程。它会随着业务的发展而不断优化和调整，对一款产品来说，不存在一种始终静态的架构模式。
　　11. 2B产品的用户角色问题
　　＂当用户使用某个产品的时候，他们是为了完成某个特定的工作（到达某种结果）＂，这是一句产品名言。
　　在设计产品时，真正值得高度关注的是用户的目标、产品的使用场景以及用户与产品的关键交互阶段，而不仅仅是把焦点集中在用户的任务是什么以及如何完成任务。
　　不管各种新奇的理论如何，我们首先做的第一件事情始终都是在围绕用户展开，通过实地的业务模拟，考察和分析推演，结合具体的业务流程和工作流程，拆分各个＂群体＂，为真实的用户服务。
　　12. 平台型产品的用户权限管理与RBAC模型
　　系统的权限管理，简单的说就是针对不同身份的用户设置不同级别的访问、请求和处理数据的范围级别。通过一种巧妙的设计，约束不同身份的用户在系统上的操作路径和操作权限，考虑的是企业的数据安全问题。
　　对2B的产品而言，必须充分考虑到业务的复杂性和扩展性，使得产品的业务管理和控制权限能够随着业务和组织架构的发展而快速部署。需要特别注意的是，不同的业务形态、不同的管理机制，都会给权限系统的设计带来重要影响。
　　产品设计经常都是一种博弈权衡，所有优秀的产品，都基于对业务、规则的深刻理解。越早进行系统性考虑，成本越低，效果也越好。
　　13. 如何通过优化业务流程提高产品体验
　　很多产品经理谈到＂业务流程图＂时，都只是机械的照搬现有的机制，从线下、纸上的东西倒转腾挪到线上，系统上而已。
　　这一类的产品经理，很少能够从业务场景的角度运用合理的设计来优化业务过程，更无法通过提升产品的整体体验来提升业务效率。甚至很多流程图就像蜘蛛网般的缠绕，不能够符合基本的规范。
　　这不得不说是一种遗憾，但很多人没有意识到，也从来没有真正去思考过。
　　对任何用户/客户来说，把业务产品化（信息化）的过程，实质上就是对流程的再造和优化，而不是简单的把线下流程的线上化。
　　产品经理在这个过程需要充分发挥这个岗位的特性和能力，肩负起优化业务的使命，通过钻研业务流程图的关键事件，分析为什么要这么做，有没有更好的解决方案，从而对现有不合理的业务流程进行重组优化，进而制定优化方案，改进现有流程。
　　03人月神话，如何管理产品开发过程？
　　从一个想法到最终看到一个产品＂长＂出来，需要产品经理有过硬的基本功和良好的商业感觉，同时也要有强大的协作领导能力，使团队形成统一的合力才可能最终实现。
　　这个过程不是三千米的竞赛，更像是一万里的长征。
　　对产品经理而言，如何利用好现有的资源，快速拉起队伍，快速的试错，并且快乐的推动整个进程从来都是很大的挑战。
　　这个话题可能难有确切的答案，不同的组织都会有不同的风格。
　　在整个复盘的第三部分，我定义为＂产品的管理＂阶段，我用3个篇幅剖析了一个产品在开发迭代过程中将要遇到的问题和挑战，以及一些可以改善的措施。
　　14. 产品经理如何规划产品roadmap
　　产品路径这个词听起来似乎很容易，最终输出的也无非就是一张图，但这种图的作用和绘制的难度，可能跟你想象中的有一些不太一样。
　　我们都认为自己在采用最佳实践，行走在正确的路径上。但实际上，很多团队包括我亲历的很多团队，都处于不断开发功能不断发布新版本，但就是没有好产品的无限循环中。
　　回顾这些年我经历的项目，我总结起来造成这种情况的原因就出在＂产品路线图＂上——我们没有能够让自己走在一个正确的方向上。
　　制定产品发展路径图的本质，就是为了指导我们的行动如何才能达成计划的目的。往大了说，也就是组织的业务愿景（好的产品愿景应该告诉人们你的产品如何服务社会），它通过具体的成果检验我们的工作。
　　一个有效的产品路径，一定是按照一定的时间框架，从业务和技术两个维度建立互相促进匹配关系，根据组织的投入和收益水平，以及市场的发展状况分阶段的演进。产品路径图不但反应我们所要完成的工作，也显示所需要投入的资源和研发周期。
　　15. 产品开发过程中的关键流程管理
　　对产品开发过程的管理，是对整个过程＂完成了什么，如何完成的，结果如何成功，是好还是坏＂的系统性描述，整个领域有很多的理论体系帮助我们优化和改善我们的工作，但软件开发在某种程度上存在一些重大的挑战，从而使其变得与众不同。
　　产品经理在面对不同的产品，不同的组织下，需要充分考虑到环境的特殊性，过程管理的方法随之千差万别，在有些时候还存在大量的偶发性事件，你需要时刻准备适应由于未知和不确定的原因所带来的额外工作。
　　不同的组织，甚至有完全不同的产品成功的定义标准，是按时并在预算内完成算是成功吗？未必如此。或许是客户满意度？
　　对你个人而言，如何把手上的项目达成目标，确保这个项目给企业带来的效益比花费多，就是一种成功。
　　16. 盘点软件开发过程中的典型性问题
　　＂需求传递到开发后，只有等产品出来那天才知道是魔鬼还是天使＂。
　　产品研发被当作一个黑箱子的情况，在日常工作屡见不鲜，很多时候，我们似乎早已习惯于依赖惯性和自觉的来完成产品的开发，认为只要按照＂客户＂提出的要求编写代码即可，最终得出的产品却是完全脱离市场，整个团队也是不断的在深坑中挣扎。
　　特别是还有一些企业，很习惯于把销售机会当作产品机会，认为产品只是技术部分的事情，习惯于以牺牲质量为代价追赶进度。
　　作为一个＂富有创造性＂的工作，软件产品的开发过程相比于其他项目过程都有它的特殊性，研发管理的思想和体系也随着研发实践逐步发展起来。从上世纪80年代的＂门径管理＂，到NPD，以及后面的IPD模式都得到了广泛的应用，大大的提高了企业的研发水平和研发能力。
　　我们完全由机会建立更好完善的机制和流程，来提供产品的成功率。
　　想要真正建立起更为科学高效的产品开发过程，首先第一条就是建立新产品开发是一项投资行为的文化。要从投资的角度看待新产品的开发，强调用投资的理念（投资收益的角度）和方法来经验管理新产品的开发，只做有价值的产品，在进入开发团队之前就对市场机会进行过滤。
　　以＂销售机会＂为主导的环境下，研发部门最终都会沦为完全的成本部门，研发投入变成了庞大的费用开支。整个团队势必变成以控制在费用为第一的原则，而不是站在投资收益的角度看待问题。事实上，任何企业的成长都是靠投资保障的扩张策略，而不是靠压缩费用的收敛策略。
　　04 尾声，才刚刚开始
　　真正从零开始做一款产品，远比我们想象中要复杂，而且越大型的产品，其复杂程度就会更高，涉及到的各方的关系和利益平衡，当然也更需要考虑用户价值和商业价值的平衡。
　　也许我们已经掌握了很多系统的方法论，也能够应用各种优秀的工具辅助我们的工作。但尽管如此，作为产品经理的我们依然难以避免在现实工作中遇到何种各样的情形。
　　但一个真正的产品经理，最思考的是如何基于＂未来战略＂层面去规划一个产品，也就是广泛意义上的从一个想法到一个模型，从一纸草稿到发布上线，从一个用户到第一笔收入的全过程。
　　这个工作贯穿一个产品从无到有，再到发展壮大的整个生命周期。
　　如果你正在此间，希望你我共勉。我希望我能在这个复盘的过程中，再次学习，也期待与你的交流和对话。
　　这个系列，也许有些长，但希望能对你有所启发。我准备通过17篇文章，解密推动产品落地的全过程，包括产品的定义和设计、开发过程的管理，以及由此引发的系列问题，更包括在此过程中我所学到的宝贵经验和深刻教训。