今天就来探讨下如何从项目经理的角度出发，将这些环节形成闭环，更好的为产品精益求精服务。

　　对于需求—数据—改进的闭环，可分解为以下三点：

产品功能交互设计之初，明确方向，设定指标（KPI）

产品开发过程做好埋点，确认数据来源，获取数据

分析数据，并反馈到产品功能交互设计

　　下面，分别展开每一点在项目中我们应该如何去做。此处只是从项目经理的角度出发，讲讲我们在项目开展中可以关注的环节，对于数据驱动创新等更专业的内容建议大家阅读《精益数据分析》。

　　功能设计之初，制定指标

　　产品的孵化和各功能模块的设计在最初的时候都有一个初衷，去解决用户的痛点。从产品初衷到产品形态，j2直播，如何去衡量我们做的每一个功能用户是买账的。在最初始阶段，我们就需要设定指标来衡量，而其中数据指标是最为量化和直观的。但在这个过程中，不能仅仅就提出数据指标，更要明确定义每个指标的具体意义以及计算方式。

　　举个例子，比如想用每日活跃用户的数量来衡量app的受欢迎程度。初一看觉得这样的指标很合理，但其实是不够的，因为没有对活跃用户做一个定义，不同的定义会极大的影响我们的判断。所以我们必须做到精确定义，排除可能造成干扰的其他因素。

　　每个指标的背后，都应该为产品的方向和目标服务。比如一个即时通讯的工具，那么用户之间的消息量、好友数也许是我们衡量这个产品健康度的指标，因为这两个指标和我们的核心功能切合。

　　通常来说，在产品设计之初，产品经理和策划就应该根据自己对产品的思考整理出核心指标。核心指标也并不是不变的，在产品MVP验证探索阶段，也许产品的方向都可能发生变化，此时核心指标也会发生相应的转变。

　　在定义好核心的指标之后，我们应该针对这样的指标让整个团队达成共识。这样的方式可以采取多次的头脑风暴，以及讨论会。在这样的过程中，其实大家可以更加深入的去挖掘。参与人员包含运营市场产品设计以及开发测试，只有大家共同理解目标，在每个工作环节才能集中精力为这样的目标去努力奋斗。同时这样的一个过程也建立大家对产品的一种主人翁意识。

　　铺平数据来源之路

　　对于数据指标达成一致意见之后，那又如何常规的获取数据呢？

　　在产品研发过程中，对于数据获取的途径一并考虑，则可以节约很多后期跑取数据的繁复过程。比如数据埋点的接入，核心KPI系统的搭建。都是用来呈现常规数据的手段，随用随查，而无需再让开发人员去跑取。

　　在我们日常产品中，通常数据的来源有三处，一个是服务器数据库数据，二是日志数据，三是埋点后收集的数据。服务器的数据和日志的数据相对来说比较精准，但很难做用户使用路径的分析。而埋点数据，由于受第三方数据分析系统的上传策略限制，在精确性上存在一定的折损，通常用来做用户路径的分析，数据对比，以及日常观测。

　　对于埋点，会涉及到埋点事件，以及埋点事件的属性和标签，结合数据分析平台。产品策划同样需要在产品设计过程中，j2直播，理清楚埋点的需求，提交给开发。而埋点的需求通常会结合分析用户行为、各维度数据呈现的要求。同样埋点需求文档也是需要在产品迭代中不断的维护更新。因此，也建议大家将埋点需求文档和需求管理结合起来。在整体的开发流程中，关注埋点需求的落实和验证。

　　所谓工欲善其事必先利其器，想让数据驱动，那么这些工作的完备开展会极大的帮助大家的日常工作。

　　数据指标带来的反馈

　　有了数据，我们又应该如何去对待数据从而带来正向的反馈呢？

　　对于团队

　　数据指标应该定期的反馈给团队，做到数据信息透明。这个有很多的方式，比如例行的数据周报发送，数据平台的权限开放。另外，也需要培养和调动大家对数据的敏感性。我们以前一直在谈如何提高成员的ownership感，而我认为，让大家更透明的了解自己正在为之奋斗的产品的状况则是非常重要的一点。核心数据指标较为健康，整体向上的趋势，对团队来说无疑是最好的激励。而当数据下滑或者出现异常，也便于整个团队提高危机感，从而共同审视当前的工作，是否可以为了数据上扬而做些力所能及的事情。

　　对于产品运营