编辑导读：为了管理企业和业务的需要，很多公司都会开发自己的内部系统，供员工使用。本文作者在做了一年的企业内部系统后，对竞争和博弈有了更深的理解，一起来文中看看吧。

时间过得很快，转眼做企业内部系统的产品已经一年。

在之前入职满半年的时候，收获了三点心得，自己也通过践行这些心得，让日常工作顺遂不少。

回顾一下：

一是大胆质疑预设流程。通过预设流程的改进，在合作层面，增加业务对我们做了什么，做的好不好对理解。

二是用影响代替顺从或者硬扛。耳濡目染的释放自己的影响圈。

三是拿结果，做闭环。把工作延伸到上线后，关注使用情况再次迭代，对做完对需求有跟踪意识和改进意识。

具体想了解的话，可以查看http://www.woshipm.com/it/5215779.html

回顾完过去，立足现在审视：在之前的基础上，又经历了半年的历练，自己对这项工作有新的看法了吗？

答案是：有的，有从更宏观的角度来思考了企业内部产品的立足，发现从竞争和博弈两个词出发，似乎可以找到一些最优解。以下就是我的思考。

一、为什么做企业内部产品比较难受？

在日常工作中，经常看到企业内部产品产生这样那样的怨念：

• 业务强势且指挥不当，对于需求做不做，优先级总有自己的看法
• 业务管辖的范围太宽，想要参与产品设计，甚至交互设计
• 需求做的时候催得急，上线后了没人指挥没人用也没人负责

久而久之，很容易丧失了对产品的“掌控感”，一身武功没地方使的憋屈打压着产品的积极性。

而做企业内部产品，也仿佛成了低人一等的辅助性存在。

那么为什么在内部产品身上会产生这么多憋屈呢？具体和两点有关。

首先是价值链中的话语权竞争。

如果把一个企业看成流水工业车间，业务方就是流水线上的工人和工头，而产品只是负责这个流水线的机器修理工，确保机器可以正常开动。

工人不上工，企业没饭吃，工头不上工，企业产出效率低，而机器的运行是正常现象，也不依赖于修理工活儿干得好不好。

在这个链条中，修理工的价值平时是很难被看见的，但只要机器停止运转影响到工人和工头，那责任也就大了，毕竟晚1分钟修好，就是晚一分钟的收入。

价值少但责任不少，就是内部产品的真实写照了。

从价值链的组成来说，业务从事的工作是能直接创造价值的基本增值活动，而产品是间接创造价值的辅助性增值活动。

正因为业务是属于创造价值的重要组成部分，所以腰杆更直，声音更大，更能理直气壮的要求别人来配合他。在这种理所当然的配合要求中，产品的难受就埋下了种子。

除了竞争，业务还擅长拉起一场零和博弈。

围绕公司更能出成绩的地方发力，无论是做主力还是打配合，一个成熟的职场人都不会抗拒。

但业务的要求配合，往往会演变成一场零和博弈——要么听你的，要么听我的，没有商量和共赢。

对于业务而言，往往跳过现场描述和细节场景，直接给到解决方案，甚至要指挥到交互细节，过程中大有不容置喙的霸气。

那这时产品的价值又如何体现呢？难道只能成为没有思想的的线框图生产机器吗？

确实在常规的工作流程中，产品是更偏辅助的职能，会用上支撑，助力这样的词汇来描述产品在业务上起到的作用，但这并不代表我们的价值只有画图和沟通这一亩三分地。

所以，零和博弈的相处方式并不适合真的想实现自我价值的产品。

二、以上问题，我们怎么破解呢？

首先，回到提升竞争优势的环节。

虽然业务天然有价值链的话语权，但往往提出需求有如下问题：

• 需求方向零散：提过来的需求五花八门，什么模块都有。拉通时间线一看，几乎无法对需求做归类。汇报的时候只有挨个叙述效果，零散的程度，让不了解执行细节的大老板们非常瞌睡。
• 需求描述不清晰：沟通的时候回答不了产品的灵魂5why，用语模糊，神色慌张，产品最后找到最直接的当事人发现可能想要的就不是这么回事儿。
• 需求价值点模糊：无法用指标衡量需求产生的价值点，或者说需求的价值建立在各种理想但现在不具备的条件上。

还有部分业务方，由于个人经验，思维的局限，往往提不出需求，勉强要提只能说一些表现层的感受：这个按钮位置不好，几个页面跳转麻烦，操作时间长了一点，总是围绕用户体验打转。

或者干脆把老板的随口一提当成圣旨，以老板提的次数多少作为做与不做，需求是否高优的判断标准，导致很多无效需求就这样被生产出来了。

其实业务是没有办法替代产品的工作的，产品的思维能力，规划能力，设计能力，行业洞察等能力和技术是需要时光累积，历经高峰与低谷的沉淀，才能真正实现决策上的高胜率，方案上的高准确。

而只有到这个程度的产品，才能帮助企业信息化以扎实的，稳步的，较低的成本来发展。这样的理想情况，需要产品和业务，认可对方的价值，然后各司其职，有效配合才能实现。

而产品可以从两个方面入手，去解决价值链带来的话语权竞争问题。

一是规划主线，有节奏有重心地控制业务往前推移。

拉长时间来看，把握产品节奏比争论单个具体需求更有价值。

当产品主动把零散的需求归纳成线，逐步推进这条线的演化渐变，业务方才能够感受到：产品真的在做实事，而且是有规划有方法地在提升产品的价值，从而感受到产品角色的价值所在。

那具体怎么做呢？

从短时间来说，可以1月内定期完成一个“大事件”。

它可能是一个全新的模块，可能解决了一个新的业务场景遇到的问题，或者是服务于新的的角色。

具体举例：

• 服务于角色的业务管理APP
• 数据报表模块
• 某个新业务的线上化全流程

只要是和以往不同的、有新鲜的成分的、相对独立的、工作量不小的都可以纳入大事件的范畴。

立下大事件的输出计划，对于产研团队可以尽早规划手头的工作，在大事件之外，再来规划其他较为零散的需求。

对于产品和业务方，在沟通的时候可以清晰的看到成块的内容的产出，同时也可以把业务老板的注意力拉到大事件上，让对方的注意力有所聚焦。

根据我们之前的经验，1个60分钟的汇报会议，按单个需求去陈列说明上线情况和上线效果，至少有80%以上的时间老板都是沉默不语漠不关心的，仅有几个关键词的触动能打动老板多问两句。

而按照大事件为主去沟通和陈述，可以有效避免这种平均用力留不下印象的情况。

除了按月去进行规划，季度甚至年度中，也可以有一条主线来做串联。

主线可以清晰的瞄准一个数据目标。

例如：

• 支持100%的业务线上化
• 支持某个角色100%登陆激活，越活跃率达到80%。
• 支持90%的数据准确率

数据并不需要业务给出，而是产品可以为自己和身后的研发团队定下的一个志向。

那怎么定呢？

根据系统化所处的阶段可以有一个简单的区分。

业务在线了吗？如果还没有，首要是往业务跑通，支持更多业务闭环去做。

员工在线了吗？如果系统已经具备了业务闭环的能力，那么首要是帮助业务把员工使用率提起来。

通过日常观察得出，行政指令和管理手段并没有我们想象的那么有效。令出即随是不存在的，从管理强制但人人都规范性操作，还有很长的时间，这个过程中产品至少可以减少用户的负面体验，让系统推进更加顺滑。

数据在线了吗？员工开始正常使用系统，但并不代表产生的数据就会非常准确，中间还会有非常多的管理，调优，限制的工作要做，这也是产品可以提前预示预警，在产品方案上和业务管理方式上给出意见的地方。

其实有的时候业务没有那么专业，反而是产品可以向前一步，在经验不足的情况下获得更高级别权利的机会。同时，也因为了产品的向前一步，可以让业务后退一步，形成重新的动态平衡。

二是产品对自己的定位可以再拔高一些。

半年前，我画过这样一张图，去分析系统未来可以发力的方向。

后面发现自己格局还是太小了，因为这个时候我的想法，还是局限在把自己定义为业务支持方，想着我去服务于某些价值更大，或者使用更频繁的用户，去用系统改善或者服务他们现有的工作流，解决他们最困难或者最耗时的问题，这样就能为系统信息化带来更大的收效。

但如果格局打开，想象如果我不仅仅是支持方呢？

我能否利用技术的力量去做那些业务堆人力也很难做到的事情呢？

我是否可以做一些功能，作为企业创收的核心竞争力？

我是否可以做一些功能，只要使用就能为企业降本呢？

举个例子。个人从事的物流行业，某些场景下对于订单智能排线有着极度的依赖。这是在一定的数据量下，几乎是无法人力来完成的工作。那对自己来说，能不能先实现这块功能，然后拉着某个城市的业务去跑通，然后不停地向各个区域安利我们有具备的功能，可以服务于哪类客户。然后和业务通力合作，把这块收入真的做起来。

大家从事的职业有所不同，但是可以往科技改变商业的思路去靠。思考到底实现什么功能，才可以做到让企业因你而不同。

三、改变零和博弈的状态

首先要相信，你和业务一定是有着共同的关键目标的。

通过冲突模型，可以先来理解双方的替代选择，来确定强势和弱势。

对于业务方来说，大概率是可以压着产品按需实现需求的，毕竟一句“你们不懂业务”就可以压垮产品的1万句用户思维。而产品如果和业务方真的闹得很僵，走的人大概率是产品。

在这种天然的强弱关系下，可以从核心诉求入手，去驳斥业务的合理性，以及给自己找论据支撑。

首先可以从以下方面驳斥：

需求和关键目标的相关性：这个需求真的能实现关键目标吗？它们之间是怎么样起到作用的？如果要起到这些作用，业务要做的一些准备工作或者先决条件有没有具备？

需求对关键目标起的作用的大小：这个需求对于业务向上的动力真的可以起到那么高的作用吗？值得放到高优吗？有没有其他的业务认为重要但不紧急的，工作量很大的活儿也可以拿来先规划着？业务的近期，中期，远期规划如何，同时间内外部竞争和环境又会有什么样的发展，需要产品做什么样的准备？

设计方案对关键目标的影响：这样设计操作流程真的会影响关键目标吗？按钮放哪里，界面怎么排布会影响目标达成吗？同时也需要请业务放心，产品的设计一定不是空穴来风，是基于未来需求演化进行的框架设计。

其次产品也可以给自己找外援。

• 用后果做外援：列出业务方案可能产生的最严重问题和后果，如果业务没法解决这个问题，他就不太会再去坚持了。
• 用竞品做外援：同类产品的状态做外援。竞品做了的不一定适合我们，但也有比较大的参考价值，而没做的可能就要谨慎对待了。
• 用用户做外援：找产品使用者的观点来支持。
• 用数据做外援：找之前的相关或者类似的案例，来证明自己是对的。

另外要做到以上的点，核心要点是——比业务还要懂业务。

用我自己现身说法。有一块历史悠久但支持收入体量大的业务系统，主要处于维护状态，很少去做改动，也没人了解里面的背景和逻辑，但是由于业务量大，仍然会不时的有需求过来，所以决定还是有必要去深入了解下这部分的内容。

那我怎么做的呢？

首先我请资深的业务接口人从头到尾讲了一遍系统的前世今生，形成了初步的文档。

同时欢迎业务丢需求过来，不管做还是不做，我都会顺着需求的场景去了解现有的功能模块，也增加对于五花八门的业务形态的了解。

与此同时，也抽空几次去现场观察学习，实地看到大家的现场流转和系统使用是怎么对接的，当中又有什么问题。

通过这一系列的操作，我成为了业务心中的贴心小能手。直到现在，业务在这部分有了新的问题，不管是技术问题甚至业务问题，都会找到我询问解决方法，我真的成为了这个板块的专家，也自然在这个板块有了核心的话语权。

四、妥协后的选择

当然要说的是，有的时候环境并没有那么理想，哪怕做出了所有的努力，也会不得已按照业务规划的来走。

那么此时可以做的是什么呢？

放下情绪，正视最后的结果。

当时争论的过程一定是有意义的，虽然不能达成想要的效果，也可以奔着理解对方在想什么做努力。

和业务一起复盘。

当时争论的焦点，可以一一记录和保留。在功能上线后，拉着业务去复盘和对照。证明谁对谁错不是本质需求，重要的是双方可以在真实的结果面前，一起回顾为什么这个决定对了这个决定错了，背后的思考方式是什么，渐渐摸索出大家都能认可的思考方式，让业务更靠近产品思维，让产品也更能理解业务思维，也为大家的信任埋下基础。

五、总结

个人视野有限，只能以工作覆盖到的场景，也就是企业内部系统作为引子，来聊聊自己的思考。

但竞争和博弈的思路，应该不仅仅适用于企业内部产品这一环境，只要有资源的争夺，涉及多方合作的各种形式，都可以往这两个关键词上去延伸。

最后再回顾一下文章最后中给出的三点建议。

1）转化思路和行为，扭转自己的价值链地位

规划主线，有节奏有重心地控制业务往前推移。短期可以用“大事件”法则，中长期可以串联主线。拔高定位，直接避开在当前价值链的争锋，自己以企业最关心的指标为目标，以内部孵化的思路去新开辟一条价值链。

2）通过塑造专业力量在博弈中取得进展和认同

具体的冲突中，可以使用驳斥对方的观点，以及寻找自己观点支撑的办法来进行有理有据的沟通。日常的积累中，要努力做到比业务还要懂业务。

3）非理想情况下可以做的

放下情绪，正视最后的结果。

一起复盘。

做心中有光的产品，正能量的产品，你就会在不顺中先反省自己，改变自己，从自己出发去寻找出路。

这是我从前后两位领导身上学到的道理，也和你共勉。

作者：假装是运营，微信公众号：SaaS学姐

本文由 @假装是运营 原创发布于人人都是产品经理。未经许可，禁止转载

题图来自Unsplash，基于CC0协议