长文 | 如何从 0 到 1 搭建产品（下篇）

2017-09-18 10:34:00

距离上期发表已经差不多一周了，估摸着观众老爷也差不多能消化上篇的内容了，下面笔者将会奉上本文的下半篇。enjoy~

上期笔者讲述了在产品开发工作前期的准备工作，这个阶段的产出物已经有了UML用例图和简单的流程图，当然竞品分析报告还是得留档。如果高阶职级需求，MRD和BRD也在这个时候输出了，讲述产品潜力和价值，为你的产品争取更多资源。

而在这个阶段，该确定的需求已经确定了，没确定的需求被搁置，到最后估计就这么不了了之。是时候大干一场了。

少年，亮兵器吧！

3. 需求输出

3.1 业务流程

承接上文所讲的业务逻辑，这里复述一次。用户用例简述了参与业务的角色，以及发生这些业务的场景，接下来就要细化各个业务的流程了。关于流程图工具的话，win用Visio，mac用Omnigraffle，也可以用在线的Processon等等，什么用着顺手用什么，也有见过有的产品岗的同学用Axure之类的原型设计工具。

举个例子，还是滴滴打人。

以核心功能的流程展开。用户填写需求表单，表单内容包含目标的相关信息，比如常驻地址、身高体重、衣着相貌等，设定任务到期时间，并在提交表单后支付费用，订单生成后投放到订单池中，打手可看到订单池中的订单，并进行竞标，用户可查看打手的历史战绩和自我介绍。

关于费用，在早期可设置固定的活动价。但在产品运作了一段时间后，可把支付动作放到挑选竞标打手时，打手可以按照需求情况定期望价格，用户也可以挑选性价比高的打手，保障双方的利益。由于需求性质特殊，打手有可能无法顺利地执行任务，此时打手可以选择放弃任务，并说明原因，订单状态变更为关闭，用户可以选择重新发布此项任务。如果打手按时完成了任务，此时需要提交相关证明，用户在确认后，解冻资金打入打手账户，同时可以评价该打手。如果由于需求没有说明清楚，打手没有按照要求完成任务，则订单进入特殊流程，售后介入，调查实情，并调节纠纷。

其间发生的多种情况，都应当考虑到，早期实施MVP时部分发生特殊的问题，可以通过线下处理来解决，等到流程规范时可排期设计加入到产品功能当中。

在这之前的工作流程中，主要参与的人员有商务、运营、用研还有产品，在下述流程中，交互设计师、视觉设计师还有开发和测试都会加入。可能有的同学会觉得，这个时期技术人员加入会不会早了些，因为还没涉及实际的开发。但实际情况是技术人员加入后，可以协同进行一些业务功能上初步的思考，部分功能可能会因为开发难度较大，需要一些研究时间或者短时间内根本难以实现，这时候可以及早的驳回需求，避免在后续开发过程中补救，产品结构改动过大。

3.2 信息架构

一般来说，一个正常规模的产品，光靠一个页面是解决不了用户需求的，如果MVP版本的产品确实功能比较单一，也应该考虑日后迭代的功能增加，使得MVP可塑。这时候就需要梳理信息在整个产品中的分布。

那么，信息架构设计到底该怎么做？《用户体验要素》中，给出了信息架构分类的方法：自上而下或自下而上。

自上而下。从产品的战略目标出发，按照满足目标的功能出发，按照分析出的细化需求分级，一层一层地将每个模块拆解。本文讲述的工作流程比较适用这种方法实施的。这种思考方式有明显的优点，产品从整体到落地，都不会脱离最初的目标，而拘泥于细节。
自下而上。此类方法关注的是具体的功能点，使用此类方法将会需要小组头脑风暴来思考功能点，并整合归类，组建功能模块。产出的产品更加细腻，但可能会失去产品的根本目标，导致产品定位不准确，功能杂糅琐碎。

有一点要注意的是，在输出思维导图时要清晰干练，不要把所有功能点都罗列出来，不然就失去了思维导图的意义。下面这张图是在早期研究网易LOFTER时绘制的一张信息架构图，作为反面例子。如果一个产品的架构较大，可以按照功能板块逐个分析。

（在新标签页中打开，即可查看大图）

3.3 交互设计

关于交互设计，在产品设计中从信息架构的布局开始，就包含了交互设计，比如在电商类目导航设计时，同类的或可相互搭配的商品会分为一类，这样分类更符合用户的预期。企业实际招聘时，会要求产品岗能力范围包含了改善用户体验并做出有效的交互设计。

产品设计早期，要保障产品基本的可用性。大致包含了一下几方面：

高效：帮助用户高效的完成没目标任务，减少流程中的步骤。
有效：用户需要完成的任务对于用户是有帮助的。
易用：减少认知和使用成本，使产品好用好记。
容错：允许用户犯错，并设计相对应的补救措施。

交互设计大师尼尔森层发布过「十大可用性原则」，比笔者分析的更具体，观众老爷可自行搜索查阅。相关书籍推荐《About Face4交互设计精髓》，该书讲解了多种产品形态的交互设计，涵盖范围非常广，几乎适用全场景，可作为工具书使用。

这个阶段最重要的就是产品需求文档的撰写和原型的设计，在敏捷开发中，大多数产品岗同学都会选择原型图+标注的形式来输出。但对于要和甲方或者老板的沟通的时候，可能会设计一个高保真原型，和产品需求文档分离开，无论哪种方式看具体工作情况来选择，最理想的状态还是文档和原型一起设计，如下图概览和客户端模块。工具用的Axure，关于工具类介绍，请移步笔者公众号另外一篇文章《产品汪的作战工具》。

4. 产品落地

4.1 项目管理

一般互联网公司的项目负责人会身兼数职，产品经理兼项目经理，技术负责人兼项目经理，或者干脆是老板。如果产品岗没有实权也应该把握项目进度的节奏，在前期产品规划中，考虑到项目实施的难度，量化项目进度，也就是大多数产品经理会说的“节奏感”。

首先会有一个明确的运营目标，要在一个阶段内达到什么样的一个指标，这点决定了产品早期的功能是有限的，早期项目盈利状况可预计但不可见，项目配备人员也有限，尤其是开发人员，要把握好产品迭代的节奏。

前文说道，在早期运营、商务、市场人员已经介入到项目需求分析中来在，这时候他们可能会提一些对于产品未来的运营方针，要求在早期版本的加入更多可盈利的功能需求，这可能会因为一些利益问题导致团队内部矛盾，下面团队协作和需求管理会讲到。还有一点要注意的是，关于项目延期，有些时候可能不是执行团队内部的问题，也可能是决策者规划的失误，所以不要乱扣锅子，扰了士气。

图片来自网络

4.2 团队协作

一个项目能否成功，和团队协作有着密切的关系。大家从五湖四海而来，为了一个目标奋斗，总归是斗志满满的。但身而为人，都是有缺陷的，不光是来自职业技能上的，还有性格这类相对隐性的属性。作为产品经理，应该好好了解团队成员的履历，擅长做什么，不擅长做什么，性格怎么样，这点很重要。

从工作流程上来讲，产品岗的工作处在开发、设计还有运营的上游，前期没有过多思考导致需求总是变更，而且是本可以避免的的需求变更，会消耗同事们的斗志，尤其是开发老哥们，半夜被叫起来改BUG本身就疲惫了，第二天来上班还被告知需求变更，之前的努力都白费了，这种心情观众老爷应该也会理解。运营为了完成KPI，可能会提出一些需求，比如一个复杂的社会化分享功能，导致产品定位模糊，这时候需要好好沟通，如果可行在版本迭代式加入验证想法，如果不可行，也不要当面回绝，可以和运营同事一起思考找出替代的方法。产品经理的同理心不光要用在产品受众身上，还要用在你同事身上。

世事洞明皆学问，人情练达即文章。这点，没法分享具体的经验。

不到万不得已，别怼。

4.3 需求管理

需求管理直接影响到项目的排期计划，多数执行型产品经理没有话语权，经常会被需求牵着走，导致自己工作很累，还经常背黑锅。这时候就要好好管理需求，这和前文团队协作也分不开，拿到需求的时候先分析，从以下几点思考：

用户体验：在产品早期，这类需求基本会被无视，只保障基本的可用性。
技术难度：现阶段技术支持直接影响一个需求能否做。
商业价值：对于C端产品而言，这点会和用户需求冲突，典型的问题就是广告。
ROI：即投入产出比，需要估计项目投入成本以及能带来的价值

然后更具这几点来排列需求优先级，需求评估说到底就是价值评估。有很多突发的情况就是，老板一拍脑袋想出了一个好点子，这种时候，私下里找老板沟通，问清该需求的来源，如果老板执意要做，那就按照老板的想法来吧。(逃

需求管理需要纳入需求池，一些被搁置的需求如果不做好记录，可能会被遗忘。下面图表为业内比较通用的需求池模板：

在主动采集需求的时候，做好需求来源的记录，分析具体情况，深挖背后的需求。在被动接收需求的时候也尽量让需求提出者描述需求，可能需求提出者在填写表格的时候思考清楚了这个需求有没有存在的必要，这个方法能节约产品经理分析垃圾需求的时间。

4.4 用例测试

把测试环节单独拿出来讲，是因为产品经理在写产品需求文档的时候可能考虑不到很多细节，或者一些特殊场景，一般思考的是单元用例，而集成测试时会发生很多突发问题，比如一些删除操作引发的关联变动。

测试人员作为专业挑毛病的人则会思考的更缜密，技术出身的测试人员逻辑思维也要强于一般产品经理。早发现，早治疗，趁着产品开没进入开发环节，赶紧补充细节需求。比如，一般运营后台或者B端产品，会有系统使用者权限管理，日常使用中总会出现各种情况，总有一些是产品经理遗漏的。这时候就要泡杯咖啡，虚心请教下测试同学。下列图片例举了部分特殊情况，没有提供解决方案。

经过了一轮轮的任务对接，改完了一堆bug，也美化产品UI，验收了产品，终于到发布产品这令人激动的时刻了。但在正式发布前，还有准备工作要做。

5. 发布上线

5.1 灰度发布

灰度发布常用于验证产品是否符合用户心理预期，观察市场对产品的接受程度，只向少部分目标用户发布产品，并根据反馈在短时间内做出快速调整，游戏行业的公测就是典型的灰度发布，是一种常规化的流程。有些时候部分不能确定的功能会选择在这个时候做AB测试，甚至是ABCDE的测试。一些空白市场的创业者常使用这种方式，用MVP低调地验证商业可行性。

还有一点就是，产品在开发环境和测试环境经过了多轮测试，也不可能保证产品完全没有BUG。灰度发布在某种意义上，是用线上环境做测试。

5.2 使用说明

B端产品在产品上线前需要需要对商务、销售、运营和客服进行集中培训，光靠ppt讲解和产品演示还不够，需要撰写用户使用说明书，不光是内部人员要了解，还要让目标用户理解产品的操作。一些面向农业等目标用户受教育水平低的SaaS产品，则会在产品设计时最大化产品的易用性，使得用户能够快速上手产品。

而对于C端产品，撰写的用户说明手册则不会是面向用户的，需要用户查看使用说明书来使用的C端产品基本就可以宣判死刑了。如果产品一些功能是创新的，史无前例或者有一定的使用成本，一般都会选择加入引导流程，来引导用户使用。移动端产品则可以在开屏页加入新特性说明或者功能说明。

图片来自网络

5.3 运营策略

互利网发展了数年，产品运营的方法论层出不穷，AARRR模型的运营方法论在业内比较受认同，这里着重介绍。

AARRR模型为获取（Acquisition）、激活（Activation）、留存（Retention）、收入（Revenue）、传播（Referral）的首字母缩写。引用某度词条对该模型的解释

获取用户（Acquisition）
运营一款移动应用的第一步，毫无疑问是获取用户，也就是大家通常所说的推广。如果没有用户，就谈不上运营。
提高活跃度（Activation）
很多用户可能是通过终端预置（刷机）、广告等不同的渠道进入应用的，这些用户是被动地进入应用的。如何把他们转化为活跃用户，是运营者面临的第一个问题。
当然，这里面一个重要的因素是推广渠道的质量。差的推广渠道带来的是大量的一次性用户，也就是那种启动一次，但是再也不会使用的那种用户。严格意义上说，这种不能算是真正的用户。好的推广渠道往往是有针对性地圈定了目标人群，他们带来的用户和应用设计时设定的目标人群有很大吻合度，这样的用户通常比较容易成为活跃用户。另外，挑选推广渠道的时候一定要先分析自己应用的特性（例如是否小众应用）以及目标人群。对别人来说是个好的推广渠道，对你却不一定合适。
另一个重要的因素是产品本身是否能在最初使用的几十秒钟内抓住用户。再有内涵的应用，如果给人的第一印象不好，也会“相亲”失败，成为“嫁不出去的老大难”。
此外，还有些应用会通过体验良好的新手教程来吸引新用户，这在游戏行业尤其突出。
提高留存率（Retention）
有些应用在解决了活跃度的问题以后，又发现了另一个问题：“用户来得快、走得也快”。有时候我们也说是这款应用没有用户粘性。
我们都知道，通常保留一个老客户的成本要远远低于获取一个新客户的成本。所以狗熊掰玉米（拿一个、丢一个）的情况是应用运营的大忌。但是很多应用确实并不清楚用户是在什么时间流失的，于是一方面他们不断地开拓新用户，另一方面又不断地有大量用户流失。
解决这个问题首先需要通过日留存率、周留存率、月留存率等指标监控应用的用户流失情况，并采取相应的手段在用户流失之前，激励这些用户继续使用应用。
留存率跟应用的类型也有很大关系。通常来说，工具类应用的首月留存率可能普遍比游戏类的首月流存率要高。
获取收入（Revenue）
获取收入其实是应用运营最核心的一块。极少有人开发一款应用只是纯粹出于兴趣，绝大多数开发者最关心的就是收入。即使是免费应用，也应该有其盈利的模式。
收入有很多种来源，主要的有三种：付费应用、应用内付费、以及广告。付费应用在国内的接受程度很低，包括Google Play Store在中国也只推免费应用。在国内，广告是大部分开发者的收入来源，而应用内付费目前在游戏行业应用比较多。
无论是以上哪一种，收入都直接或间接来自用户。所以，前面所提的提高活跃度、提高留存率，对获取收入来说，是必需的基础。用户基数大了，收入才有可能上量。
自传播（Refer）
以前的运营模型到第四个层次就结束了，但是社交网络的兴起，使得运营增加了一个方面，就是基于社交网络的病毒式传播，这已经成为获取用户的一个新途径。这个方式的成本很低，而且效果有可能非常好；唯一的前提是产品自身要足够好，有很好的口碑。
从自传播到再次获取新用户，应用运营形成了一个螺旋式上升的轨道。而那些优秀的应用就很好地利用了这个轨道，不断扩大自己的用户群体。
通过上述这个AARRR模型，我们看到获取用户（推广）只是整个应用运营中的第一步，好戏都还在后头。如果只看推广，不重视运管中的其它几个层次，任由用户自生自灭，那么应用的前景必定是暗淡的。

不同产品每个环节需要做的工作差别很大，本文主要讲述产品岗工作流，关于运营相关工作不详细展开。

6. 反馈分析

6.1 用户反馈

用户反馈是采集用户需求的重要来源，一般直面用户的是运营和客服，这类二手需求在解读时需要考虑具体情况，这时候上文提及的需求采集表就发挥了大作用，然鹅日常工作中，运营和客服都不愿意写这么繁复的表格，每天需要解决这么多用户的各种问题已经很心累，还要加上额外的需求采集的工作，可能会造成情绪问题，如果发生这种情况，可以适当的调整信息采集的内容格式。作为产品设计者，产品经理应不定期的轮岗到用户运营或客服，如果公司业务是做B端产品的，那应该和BD去拜访客户，了解最真实的需求，这种一手的需求会给产品经理培养同理心带来很大的帮助，也防止在需求转述的过程中造成偏差，影响产品设计。

对于运营策略，笔者没有做过具体的运营执行，没有建设性意义的建议帮助各位观众老爷，搭建运营支撑系统的数据分析模块可以参照几款大厂的数据统计系统，Google Analytics、Mixpanel、腾讯分析、百度统计、GrowingIO等。笔者会在后续文章中详细描述如何在数据BI系统中减少开发成本，提高运营参与度。