中台建设内容：中台的精细化运营 问题

中台建设内容：中台的精细化运营 问题⑥ 对自己，制定目标，倒逼自己关注自己的深层次需求，不虚度时光。⑤ 对团队，我开诚布公，收集大家对团队的期望，帮我补足我的管理水平；② 读书上，发现亚马逊的用户经营飞轮，将“按灯机制”作为了践行用户第一的核心举措；③ 培训中，公司产品小学小组，安排到线下体验真实走单，进一步激发每个人的同理心；④ 生活中，朋友圈发调查问卷，收集别人对我的意见反馈，促使我找到我的短板；

编辑导语：有的时候，明明我们做了很多，但为什么用户仍然不满意，究其原因是我们没有抓住用户的痛点，缺乏一个定位问题以及从问题到解决的驱动机制。那么，我们如何从用户的“问题”出发，找到那个正确的反向驱动机制，一起来看看吧。

一、引言

之前《以“用户之名”来锻造自己》一篇文章，我讲述了做产品如何关注用户，确切来讲，是如何关注用户遇到的问题。

文章中，讲了几个案例：

① 工作上，关注业务对中台意见，以及中台对内部的调研，发现核心矛盾，启动内建专项；

② 读书上，发现亚马逊的用户经营飞轮，将“按灯机制”作为了践行用户第一的核心举措；

③ 培训中，公司产品小学小组，安排到线下体验真实走单，进一步激发每个人的同理心；

④ 生活中，朋友圈发调查问卷，收集别人对我的意见反馈，促使我找到我的短板；

⑤ 对团队，我开诚布公，收集大家对团队的期望，帮我补足我的管理水平；

⑥ 对自己，制定目标，倒逼自己关注自己的深层次需求，不虚度时光。

以上这些案例，其实都是同一个内在逻辑。

即，从用户出发，以问题驱动来促使事情变得更好。

因为更多时候，大家做事能力是没问题的，但是恰恰缺少一个定位问题以及从问题到解决的驱动机制。

先定位到问题 ，我们才会去想解法，然后才可能去做，进而才会产生价值。

其实往宽的来说，把“问题”换成“需求”，方法论也是没问题的。

不过本文主要还是讲“问题”，并且是“潜在问题”。

“需求”是显性的，“大问题”也是显性的，很容易被人看得到，在管理上，不容易miss掉。

但是对“潜在问题”、“小问题”，更多时候不容易被重视，甚至可能会被人有意忽略掉。

这些隐藏的小问题，不重要么？不，我认为很重要。

一方面，小问题看起来好像危害小，但是长时间积累起来就会造成不小的效率和口碑折损；另一方面，有些小问题过去没有被解决，其实大概率是因为要彻底解决可能需要动底层投入成本大，或者是短期内看不到收益，亦或是解决问题需要放弃其他收益。所以就只能每次打补丁，case by case 解决问题表层。

如果业务增长非常迅猛，那资源大概率都会被投入到增量的事情内，以上的矛盾就会被暂时掩盖。但如果外部环境不好，业务放缓，公司就会要进入到精细化运营阶段。这时候，对这些小问题的挖掘和解决，就算是做未雨绸缪的事情了。

而现在整个互联网环境，我觉得就算到了这么一个阶段，需要修炼内功了。

二、问题反向驱动机制，本质是一种管理机制

过去在公司层面，有一个会议机制——VOC（用户之声 ）。

这个会议规格比较高，各个业务的最高负责人，以及公司的一些VP都会参与。

为什么会这么重视？

我觉得，大部分情况下，都是因为解决用户问题投入收益比不高，短期不见效，与业务所追求的增长目标相悖。

因此，就需要更高管理者站在长期利益角度，做决策，强push。

所以我觉得，要想解决这些“小问题”，就必须先要搭这么一套管理机制，否则很难有结果。

而洞察到这个逻辑后，我们也在上个双月okr，开启了中台的精细化运营，建立了“问题”反向驱动机制。

三、中台“问题”反向驱动机制介绍

以上这张，就是我们中台的反向驱动机制的架构图。

接下来，我按照3个步骤依次讲解下：

第一步：问题的定位

起初，我们需要先定义下整套机制要解决的问题分类。

根据过去积累的经验，我们基本确定了5种类型，并且结合每种问题构建了问题的信息源：

① 大需求项目过程中暴露的问题——信息源：大项目结束后的复盘分析

② 日常频繁改动小需求——信息源：日常小需求版本tapd管理

③ 线上溢出问题——信息源：线上问题online记录跟进

④ 产研日常被打断问题——信息源：运营定向收集记录产研被打断和咨询的case

⑤ 线上产品体验问题——信息源：组织产品定期对产品使用走查

以上这5部分信息源，都会安排有各自的负责人跟进，保证日常信息源的更新，也会对各自模块的信息做初步过滤。

第二步：问题的分析

有了以上的信息源之后，我们每两周组织一次反向机制沟通会议。

由整体项目负责人主持，各信息源模块负责人参与。

大家会上，会针对两周内所有增量信息，做逐一分析，并且按照问题的属性维度，再次将问题归类：

我们抽象出来了3种问题分类，分别是：

① 系统问题：可以去除人工化的（能力/知识/规则沉淀、配置化）、系统架构/设计不合理的；

② 机制问题：流程机制不完善的、分工协作边界不清晰的；

③ 人的问题：专业素质不够的、沟通协作不畅的、管理问题不足的。

PS：有时候问题会跨类，我们会合并为专项问题。

第三步：问题的解决

把问题筛选归类之后，并不意味着所有收集到的问题，都需要解决。

还需要根据问题出现的频率和影响程度，再做一次优先级过滤，才能形成AP，同时确定对应负责人和完成时间。

最后，需要在中台的产研周例会上，对AP的完成情况进行check，确保要解决的问题最终有结果。

以上就是对问题反向驱动机制的概要说明，具体内容不重要，核心是这个反向机制的内在逻辑。

马上6月底，算起来这套机制运转也有2个月了。过程中，驱动了近30个AP的产生，其中对系统问题的中台平台化建设起到了很大的推动作用。

接下来，这套机制，我们会固定下来，当做常规机制持续运行下去。

因为“问题”不是用户的需求，而是用户的痛点。

作者：减形简远，产品杂谈（life_pm）

本文由@减形简远 原创发布于人人都是产品经理，未经作者许可，禁止转载。

题图来自Unsplash，基于CC0协议。