创业公司老板总是干预我们的产品工作，怎么办？

本文作者将结合自身经验分享：创业公司的老板，为什么总是会干预我们的工作呢？以及常见的的老板干预手段，及解决对策。

前段时间特别的郁闷，准确说也不是第一次郁闷了，因为什么事情呢？——就是老板频繁的干预我的产品工作。我的老板是个特别有涵养的人，清华大学毕业的博士，又有海外生活的经历，为人也比较随和、低调。

但我就是特别反感他对我的工作进行干预，我认为既然你请我来了就得信任我，总是干预我的工作是几个意思？——为此我不惜进行了长期的斗争，期间也是各种争执、撕个不停，磨合了差不多半年的时间后，随着对彼此了解的加深，双方才开始愉快的合作起来。

现在反思一下，我发现我面临的情况还真不是个个案，因为太多的创业公司，老板总是以各种各样的名义对产品进行有意或无意的干预，很多产品经理对此也是苦不堪言。所以我觉得这里就有必要把这个问题拿出来单独分析和梳理一下，给其他小伙伴们也带来一些思考和借鉴。

一. 创业公司的老板，为什么总是会干预我们的工作呢？

我们先来分析一下为什么创业公司的老板总是喜欢干预我们的工作，我理解的原因有以下几点：

原因一：个人的管理风格

我大致将管理风格划分为两种：第一种是宏观型的管理方式，这种管理者大多对于结果比较看重，侧重于从宏观的角度对下属进行指导和把控，以结果为导向，而对于具体的做事方法、实现路径上较少的关注或参与；第二种是微观型的管理方式，这种管理者对于过程比较注重，喜欢经常性的参与到下属工作的细节中。

在我的认知里，通常第二种风格的管理者更喜欢干预产品的工作，不仅要求产品能够达到具体的目标，而且会对产品的各种体验和交互细节进行过多的干预。如果你的老板经常性的对你的产品实现细节问题进行了过多干预或者是提出了大量的建议，那么恭喜你，你很有可能遇到了“微观型管理方式”的老板。

原因二：对产品经理的不信任

社会心理学里面讲：人都有”自信错觉“，绝大多数人都会觉得自己比别人要聪明。我们的老板自然也不例外，尤其是很多创业公司的老板，认为公司是自己一手创办的、产品是自己亲眼看着壮大的，总会自我感觉良好，认为自己是很懂产品的。

这个时候自然就会对“外来”的产品经理有种打心底里的不信任，认为自己的骨肉自己看着才放心，交给产品经理这个“奶妈”总是多了几分顾虑。在这种情况下，老板不免以各种理由和方式对产品进行干预。

原因三：创业公司的焦虑感

这一条原因在很多时候可能是最主要的：创业公司的老板所承受的压力无疑是团队中最大的，员工被惹急了可以拍桌子走人，但老板就算是受了再大的委屈也不可能把公司原地解散。尤其是在创业团队中，老板对内要解决内部的种种冲突与矛盾，对外还面临着巨大的融资压力，常常是有了上顿没下顿，对外来充满了恐慌。

这给老板们幼小的心灵带来了巨大的焦虑感，而这种焦虑感通常会无形的转嫁到周围人身上，这时产品经理往往首当其冲。我们都知道产品的开发是需要时间和周期的、产品的发展也不可能是一直走直线上升的，而是会在不断的试错中迂回前进，所以当看到产品的数据短期之内没有明显的上涨，而公司的开销又在持续的增加时，老板们便会急的像热锅上的蚂蚁、不断的想了法子对产品工作进行干预，他们其实是想通过这种方式来转移自己的焦虑感。

原因四：对产品工作有误解

有时候美好的故事也会害死人，比如说互联网的江湖上就流传有乔布斯如何的对设计进行死磕、如何的对交互细节痴迷等大量传说故事。很多老板看到这些故事后，大脑一发热，认为自己仿佛是乔布斯再世：只要把那些细节问题扣好了、就成功了，妄图在每一个产品细节上与产品经理撕一番。

我姑且不去深究关于乔布斯的相关传说的真假，但就实际的情况分析看，大多数都有虚构的嫌疑。因为以苹果的体量，那么多的产品线、那么多细节和体验、那么多个版本，别说一个乔布斯、一千个乔布斯都扣不过来。我个人认为乔布斯的伟大之处不是在于他多么注重细节，而是将一群世界科技领域的顶级天才聚集在了一起，向着同一个目标而努力。

所以很多老板会投入大量的时间和精力关注产品的交互设计和细节体验，而殊不知这些视觉设计和交互设计往往属于“界面层”，在用户体验要素里优先级是最低的。而每当老板向我提出设计、体验上的建议时，我都会不厌其烦的向其普及“交互体验要素的五个层次”这些基础的产品概念。——我不是说老板的建议都是错的，而是说这些东西应该由我们这些小孩子去负责，你一个大人，不应该把注意力放在这个上面。

上面分析了“老板为什么会干预我们的工作”，下面我就讲一讲应对的策略：“如何减少老板对我们工作的干预？”

二. 如何减少老板对我们工作的干预？

1. 定期撰写个人周报、汇报并反馈个人问题

我曾一度是非常反感写周报的，认为那些记流水账的东西是传统行业才玩的。但是后来我的领导建议我写周报，我也就咬着牙坚持了下来，但是这一写不要紧，我发现周报还真是一个很重要的沟通渠道，有着独特的意义。

平常的工作中，大家都比较忙，难以有深入交流和沟通的机会，而周报恰恰是一种很好的沟通方式，里面除了对上周的工作进行回顾外，我还会撰写一下：对行业竞争状况的看法、对业务发展状况的看法、对团队管理和建设的看法、对自我的反思等等，这里面不一定全都是好的，也有很多抱怨与牢骚……

每次我的周报发给老板后，老板也都会认真的阅读并对一些问题进行相应的反馈，通过这种方式让老板对我的工作有了更多的了解与认知，也就不断的减少了两个人的磨合与分歧。

这个方法小伙伴们不妨尝试一下，坚持认认真真的写三个月，你会发现和老板之间的很多隔阂都会逐渐消除。

2. 通过各种手段打造自己专业化的形象

前段时间看综艺节目，郭德纲在点评一个选手时说了一句话我特别认可：你的表演就业余水平而言已经很不错了，但你是靠这个吃饭的，就必须得再努力。这句话放在产品经理的工作中也是说得过去的，现在是“人人都是产品经理”的时代，随便一个人都可以说自己是产品经理，随便一个人都可以指着某一款产品说出几个交互或设计上的问题，但是他们毕竟还是业余的，而我们是专业的产品经理，我们就必须和他们之间拉开差距、要有着非常强的专业性。

所以，我们应当在公司利用一切的机会去普及产品相关的知识、分享产品相关的知识！——这不是为了炫耀或表演，而是通过不断的分享产品知识对周围人进行帮助和提升，同时这也会逼着我们自己不断的进行提升和学习！

就拿我自己说好了，每次开需求会议之前，我都会找机会普及几个与产品相关的知识，每次当我遇到好的产品文章时也都会分享到微信群或朋友圈，每次与大家开会讨论时，我也都会提前准备相关的行业资料和产品素材……通过这一系列的举措，来不断的打造自己的专业形象，形成别人对我们较为专业的认知。而当老板对我们的产品能力有了充分的信任之后，其实也就会逐渐减少对我们工作的干预。

3. 界定工作边界：讨论重大决策，而非产品细节

刚来公司时，每次和老板开会我都大发雷霆、气个半死，是因为每次在开会时，老板总是喜欢围绕着一些产品细节问题和我撕的死去活来，而对于一些重点的产品战略却轻描淡写的带过，让我感到有些本末倒置、舍本逐末。事后我反思发现，每次开会的时候，我自己也都有些失误——我总是会把一些细节性的问题拿出来讨论，而对于一些核心的问题没有留够充分的时间。

再后来和老板开会时，我进行了调整：把一些产品细节性的问题直接砍掉，而重点讨论产品的核心功能和需求问题。在当时的周报，我也写了一段很有意思的话，话的主题是“让小孩子去做小孩子的事情，大人做大人的事情”，暗示老板要明确自己的工作边界、不要越俎代庖的干预产品经理的工作。

以下是当时周报的原文，现在读来还是有点意思的：

“生活中我们有大人和小孩之分，小孩负责读书学习、考试，大人负责赚钱养家、承受各种社会压力，在一个家庭里面，如果父母工作都不错、收入也可以，就算是小孩子成绩差了一点，这个家庭整体也是幸福的，父母也会有足够的耐心去教导和培养小孩。相反，如果父母的工作都不尽人意、财务拮据，那么就算是小孩子成绩比较好，整个家庭也难以谈得上幸福，而且父母会将自己无法实现的想法强行加在小孩身上，给予小孩大量的压力，整个家庭都是灰蒙蒙的。

公司里也是这样，如果把管理层比作家长，各部门的员工就是小孩。家长负责融资战略、公司方向、团队管理、关系协调与人员辅导等，而小孩负责产品体验、交互设计、编写代码、测试推广等。现在我的感受是在公司里家长和小孩有时候会相互混淆了，家长有时候也开始干起了小孩的工作，而对于家长自身的本职工作有所忽略。坦白的讲，小孩子做的工作都是比较简单的，这些简单的工作就算做的再好也无法弥补战略上的错误和方向上的偏差。

我认为在小的事情上管理层可以尽可能的授权让小孩子去做，因为只要产品方向是对的，具体的功能和细节上，最差的也就是做了一些没用的设计和功能，是一个70分和80分的区别，但是一旦战略和方向错误，就是一个正80分和负80分的问题了。”

4. 做出成绩

以上说了那么多，其实还都是次要的，最核心的是什么呢？——就是“做出成绩”，刚接手产品的时候，用户的首单率是4%左右，后来通过多次改版，我把首单率直接提升到了12%。——通过具体做出的成绩，可以让老板意识到我们的能力和专业性，从而逐渐掌握对产品的控制力，减少老板对产品的干预。但这一项也是最难的。

上面分析完了原因和应对策略，下面就一些实际中可能出现的老板干预产品的情况，我也说说我的对策。

三. 常见的的老板干预手段，及解决对策

1. 老板质疑我们提出的产品需求时，该怎么办？

做产品的人都知道在讲话的时候要很警惕说几个字：“我认为、我觉得、我推测“，这些词都带有很强的主观臆断成分。——刚坐产品时，我也会经常这么干，总是会把个人的推测和假设当成结论。

这个时候我们提出的需求就不免会受到老板的质疑，回过头来看，会发现其实是我们自己问题，我们可能用了太多的主观臆断。

那么提需求时需要怎么做才会减少老板的质疑呢？我认为可以从以下几点入手：

（1）多用数据分析

刚做产品的时候，除了常规的数据之外，我不是很喜欢进行深度的数据分析和思考，这就导致我在开需求讨论会的时候总是被别人质疑，在有些问题上双方各执一词。而后来随着产品经验的增多，我越来越重视数据分析的作用。

现在我会强迫自己对数据进行阶段性的分析，对数据上模糊的地方进行进一步的拆解、搜集数据证据、验证假设、得出结论，拿着结论再提需求，老板和其他人的质疑声就少了很多。毕竟数据不会说假话（在大多数时候）！这里也安利一下当年我看的一本书《精益数据分析》，里面关于数据的论述还是非常精彩的。

（2）用户调研说话

用户调研并不是万能的，比如第一代iPhone发布之前，从来不会有人告诉乔布斯用户需要什么样的手机；又比如微信的摇一摇功能，也没有人告诉张小龙用户特别想要这个功能。而且用户调研的结论也并不一定反映实际的用户使用情况，比如对价格的调研，用户肯定是希望越低越好，但实际情况是就算再低、没有需求的用户仍旧不会付费。

但没有用户调研也是万万不能的，尤其是产品岗位工作久了之后，我发现自己离用户越来越远了，有点过于根据数据和个人经验做决断了，变成由产品经理来定义产品了——这是很危险的。意识到这一点后，我把用户调研进行了制度化：一方面是线上调研，在APP上给出了单独的调研问卷入口；另一方面是日常回访，安排单独的人每周花费一定的时间对用户进行回访。通过用户的调研与回访部分的验证了我的一些猜测与假设，也使得我在提需求时有更强的自信心。

归纳到一句话就是：用户调研不是万能的，但没有用户调研也是万万不能的。掌握了充分的用户反馈，在讨论需求时才会更加的理直气壮、有据可依。

（3）遵循行业惯例

在创业团队里，很多时候并没有充分的时间和资源给我们去做调研、做分析，我们面临的实际情况是必须在短期内快速的进行决断。这时就需要遵循行业的惯例，比如我做的是服务电商，在我调研了十几家电商的成熟产品后，发现“商品演示”的发展规律是：初期的小图展示、到后来的大图展示，再到现在的“视频+音频”。通过这些行业分析，可以得出结论：音视频的展示方式会更利于用户对商品的判别和了解。这些分析的过程与结论也可以成为我们提需求时的重要依据。

2. 老板总是提出一些无礼的需求时，该怎么办？

还有一种情况其实也挺常见的，就是老板总会突发奇想的YY一些需求出来，然后提给产品经理。那么这个时候我们到底该不该答应呢？可以分为几步走：

第一步：告知其需求过滤的方法

当接到一个需求的时候，可以通过简单的KANO模型进行区分一下，KANO模型将需求分为了基本需求、期望需求、兴奋需求。就我的经验来看，老板提的需求往往是兴奋性需求居多：这些需求做了可能会更好，但是不做也基本上没什么影响。

这个时候呢，我一般不会说：你这个需求不重要，我不做。而是会说：根据KANO模型，你这个需求属于兴奋性的需求，只对XXX类型的用户有影响，有了当然更好，但是在产品的当前阶段优先级并不高。（这样转变下说辞，是不是感觉高大上了很多？）

当然KANO模型只是需求过滤的方法之一，其他方面的衡量还要包括：需求的影响范围、需求的紧迫性、需求的实现难度等等。

第二步：询问对方需求的依据

很多时候我们接到一个需求，都是一个结果：比如我需要添加一个”邀请用户下单“的功能。这个时候我们必须要追问需求的依据是什么？

如果我们发现老板提的需求只是个人的主观判断，我们对此一定要谨慎，多问他几个为什么，然后再通过用户的简单调研或数据拆解对相关的需求进行初步的分析。

同样我们也要把这种思维传达给老板，告诉老板个人的主观判断往往是不可信的，提需求的时候也应该有基本的数据依据或调研依据。

第三步：MVP验证后再做结论

当然了，就算是上面说了那么多，对方毕竟是老板，就算是强制给我们安排一个需求，那也只能说是“政治任务”，而不能直接拒绝。所以，当老板坚持要做某个需求，而恰好我们又是强烈不认同的话，也可采用MVP验证的方式。

比如我的老板有段时间人工智能特别的感兴趣，总想要在产品上搞人工智能。但大家都知道，人工智能到现在为止，还只是一个噱头，概念大于实际的意义，目前尚未诞生一款人工智能方面的国民级产品。但耐不过老板多次强调，我又不得不做，于是我采用了一系列MVP方式来验证老板的需求，比如老板说要搞智能导购，我就先弄了一个人工的导购放在明显的位置，比如老板说要搞智能用户意见采集，我就先搞人工的回访——对这种做法，我美其名曰“没有人工就没有智能”。

等搞了一段时间发现人工的都没多少人用得到，更别说智能了，这时老板的兴趣点也转移了，这件事也就过去了。但若当时依老板的性子，我也傻兮兮的配合着大动干戈的去做，不仅没有好的结果，最后搞砸了，可能还是我背锅。

好了，以上就是我对“老板干预产品经理工作”这件事情上的一些分析与反思，希望给小伙伴们也带来一些帮助。