16 | 在内部产品中找到产品经理的价值

Dec 26, 2017

16 | 在内部产品中找到产品经理的价值-极客时间



下载APP





关闭

讲堂部落提薪训练营云原生训练营架构实战营企业版极客商城兑换中心 App下载浏览器插件

渠道合作

推荐作者

16 | 在内部产品中找到产品经理的价值

2017-12-26 邱岳来自北京

《邱岳的产品手记》

课程介绍



讲述：邱岳

时长10:02大小4.60M



“心事浩茫连广宇，于无声处听惊雷。”
﻿
——鲁迅
当提到产品经理时，大部分人都会想到用户产品、商业产品或者平台产品。然而，有一类产品经理总是处在产品领域的阴影中，这就是内部产品的产品经理。
大部分的产品经理其实都不太愿意做内部产品，觉得这份工作受气还没有出头之日，而且也很难开口向亲戚朋友介绍自己的工作。
其实，做内部产品不但可以帮一个产品经理打下扎实的产品基本功，也能磨炼一个人的心性。我刚入行时，做的就是内部产品，并从中收获良多。
今天，我就来讲一讲做内部产品的方法和挑战，这些内容不但适合内部产品经理，对非内部产品的产品经理也会大有帮助。
什么是内部产品首先我们定义一下什么叫内部产品。内部产品通常是指自己公司内部员工使用的产品，比如 CRM、ERP、CMS、广告管理系统、法务合规、财务系统等。有的公司会选择采购其他公司的产品来用，但有的公司会开发自己的内部系统，这其中有的是基于开源框架的，有的是自己旱地拔葱，从零开始写的。这两种情况，通常都会有对应的产品经理来负责。
用户离你很近内部产品最显著的一个特点就是：产品经理和用户的距离很近——你甚至能看到你的需求方，他们通常坐在你工位附近。这也就意味着他们不再是你脑海中设计的用户模型，而是随时能冲到你位置上跟你争个面红耳赤的同事。
这直接导致你很难在产品设计中说不。所谓见面三分情，你经常看到你的用户，甚至跟他们一起吃午饭。这很容易让你融入他们的立场和喜怒，保持不住冷静和理性。
这个问题在我过去的工作中尤为显著，因为我媳妇就在我的直接需求部门工作，稍有不慎，麻烦就大了。我花了不少精力克服这样的问题，跟大家分享三条对我帮助很大的经验。
1 资源显性化第一个方法就是把仓库的门打开，将技术资源显性化。让业务部门清楚地了解到整个技术部门有多少人力，多少工作任务。我们当时的做法是会推算整个部门每个时间段的可用人力情况（比如每周 100 个人日），扣除一部分做日常 Bugfix 和重构之外（一般是 20%），剩下的和盘托出，让业务部门看到我们的人力情况和交付能力。
另外，我们会尽可能地跟业务部门去介绍系统的基础架构和实现原理。比如我们当时做订单系统，需求方认为更换订单标的很容易，改一个字段就好了，但对系统来说，这涉及一系列的上下文修改和流程的逆向处理。这种情况下，如果能从技术的层面解释清楚原委，就完全可以避免不必要的压力和对立。
2 项目流程化有的内部产品收集需求比较随意，用户可以随时向产品经理提要求，所以用户会泥沙俱下地提出一大堆想法，提出想法之后还会有期待。于是，我经常会看到产品经理被用户围着问，上次说的某某某功能怎么还没做完啊？
所以不论研发团队是否采用敏捷开发，都建议内部产品的需求收集与确认可以周期化。比如根据业务的节奏两周或者一个月一次（如果节奏很快每周一次也可以），大家拿出专门的时间来确定下一个阶段的交付计划。这样有仪式感的流程可以合理管理需求方的预期，让产品的进度更理性一些，避免失控。
3 用户研究的最佳试验场有人说内部产品不太重视用户体验，基本不配用研甚至交互设计师，所以内部产品的产品经理这方面能力都很弱。
对此，我倒不是这么认为。内部产品对交互和用研的要求或许确实不那么苛刻，也很少配有专职的交互设计或用户体验设计师，可对于产品经理来说，这其实提供了自己亲手做交互设计的空间。
在内部产品环境中，我们收集用户反馈的效率变得非常高，不用精心设计问卷，挑选投放渠道。你可以约好时间直接走到用户的工位上，坐着聊上三五分钟，问题没有设计好也没关系，随时可以返回去多问一句。
产品可用性研究成本也变得非常低廉，不需要单向玻璃，不需要送什么充值卡，直接坐到用户旁边看他的操作即可。
我曾经负责过服务部门的一套系统，当时的我可以直接拿着秒表坐到呼叫中心的同事身边，去找提效的关键节点。这是一种拳拳到肉的用户参与，不是通过一张问卷或者一封邮件隔靴搔痒。
不要成为功能经理——变被动为主动内部产品的产品经理容易遇到的另一个问题是缺乏主动性。刚才我们提到内部产品的需求通常会铺天盖地袭来。
在这样的情况下，产品经理稍有不慎就会处在一个消极应付的局面中，即便开足马力，需求列表也会越来越长。
在这个过程中，产品经理会逐渐开始放弃思考，只是把业务部门提来的需求转发给开发，变成一个传声筒。我们有时会将这样的产品经理称为“功能经理”，他所有的工作都是由功能驱动的，关注的只是特性和功能逻辑，而不再是产品层面的价值和取舍。
那么，怎样避免在内部产品中成为一个功能经理呢？我也在这里给你介绍几个方法。
1 跳过方案，寻找背后的动机和诉求在之前的文章中，我也提到过，产品经理要从用户的需求中，寻找背后的动机和真正的诉求。我也跟大家聊过“5 问法”——抓住一个问题不断追问为什么，找到需求背后的需求。在内部产品中，这一要求更加重要。
由于对系统的深入了解，内部产品的用户在提需求时通常都会直接提出“解决方案”。比如，像之前提到内部用户会提出“订单列表增加按时间排序的选项”这样的要求。甚至，我曾经还接到过类似“订单号字段增加至 128 位”这样具体的方案式需求。
这时产品经理一定要避免不假思索地将类似的需求直接交给工程师团队，你需要多追问几个为什么。比如订单号字段增加的需求，背后可能是整个订单号体系的变更，远不止改一个字段长度这么简单。作为产品经理一定要把这样的动机挖掘出来。
2 统一战线，成本收益一致内部产品线的产品经理经常会抱怨没有话语权，甚至不被业务部门尊重。这一点其实无可厚非，因为业务部门背负着刀刀见血的业务指标，而技术部门只是辅助。
这时候，需要将自己推到业务部门、甚至整个公司的立场上，从业务的角度而非工程的角度考虑公司的投入产出比。
将技术成本并入业务成本，同时把业务收益和内部产品技术团队的收益绑定，这样，产品团队才能跟业务团队绑定起来，产品的思维模式也从微观的产品技术团队上升到业务模块甚至公司层面。
这样的环境和状态，才能够变被动为主动，不再局限于成本中心的定位，扭转弱势地位。
除此之外，还有一个非常重要的提醒：想要与业务紧密绑定，内部产品的产品经理必须要深入了解业务。
如果是做财务系统的，要了解财务部门的职责、流程，甚至去了解一些会计师准则。如果是做 ERP，就要深入了解供应链相关知识。能与内部业务部门合作其实是个难得的机会，你可以向业务专家请教学习，丰富自己的见识。
我的第一份产品经理工作是做阿里巴巴内部的业务管理系统。借着这个机会，我了解到很多互联网企业商业产品的市场、销售和服务套路，这是一笔非常宝贵的财富，也是单纯做用户产品的产品经理很难得到的经验。
3 发挥强项，用技术帮助业务内部产品是个金矿，里面有大量的流程和业务数据，这些数据极具分析价值。业务部门或许会经常提一些数据分析的需求，但内部产品的产品经理应该同样了解，甚至比业务部门更加熟悉系统的数据结构以及这些数据的业务含义。
这时如果可以主动出击，经常分析数据，将简单的数据统计进化为数据洞察，就可以极大地丰富业务部门的视角。倘若再进一步，做出能够直接帮助业务部门做决策的数据产品，就可以进一步放大产品和技术的独特价值。
比如，对于支撑客户服务的内部系统，就可以在基础数据需求之外，提供更加完善的服务效率报表，甚至通过数据挖掘和建模做出服务量的预测，从而帮助服务部门根据业务的进展，弹性规划服务人员的储备。我还听说，很多客户服务支撑系统通过人工智能的方式，挖掘客服人员记录的服务小计或服务录音，利用数据统计去反推服务模式甚至产品的迭代发展。
总之，越是内部的产品经理，越应该努力往外走，通过自己的竞争优势（对产品、技术和业务流程的理解），去站到业务里面去成为一个攻击型选手，而非一个后勤补给选手。
总结最后，我们来回顾一下今天分享的内容。首先，我们提到了内部产品有自己的特点，也就带来了独特的挑战和机会。
用户太近带来的压力和混乱，我们可以用资源显性化和需求流程化来应对，并且把握好这种“近”的特点，去学习和尝试做用户研究。然后我分析了如何通过挖掘动机、绑定立场和利用技术力量推动业务来最大化内部产品经理的价值，避免内部产品经理沦为功能经理的窘境。
你有没有过负责内部产品的经历呢？内部产品设计的经历又是否给你带来了不一样的技能和优势？你不妨在留言中写下来，我们一起交流讨论。

分享给需要的人，Ta购买本课程，你将得18元

生成海报并分享

赞 16

提建议

15 | 产品案例分析：Mimo与Learn Python的导学之趣

17 | 产品经理如何获得非权力性的影响力？

 写留言

精选留言(22)

听天由己
2017-12-26
我今天才了解内部产品这个词。目前公司拥有较为完备的后台管理系统，从场馆管理到俱乐部管理，从 PC 到移动端，以前是按照金融体系的后台打造的，所以在业务改造上花了不少心思，可并不稳定，因而要进行产品整合是一件很困难的事情。今天我感触最深的就是，用技术帮助业务，将数据变为洞察。平时我们的运营同事更多地是通过 Excel 的方式来收集每周的业务情况，还要对每周的表现进行对比。特别是一些运营需求与新功能，限于开发资源，我们只能首先满足基础要求，后续进展基本上就无人跟进了。他们每周要花一定精力去分析、去总结，几个月来都是如此。我明白习惯是很难改变的，但是我们要有自我提升和主动的意识。对内部产品的迭代同样需要大家共同监督与完善，我这就去好好想想内部产品可以有哪些改造空间。感谢二爷。
展开
共 1 条评论
15
Julian
2017-12-27
深有感触，资源显性和周期性的提需求太重要了！不仅是内部产品，用户产品也适用。以往运营部门经常时不时过来说一句我有个idea，有个需求…而且是不同人隔三差五就上来提下，需求管理混乱，同时资源有限，没法满足需求，自然让运营同事觉得我们在有意怠慢（后来和业务部门讨论，整改出了一套流程 1. 明确告知，现在研发的人力如何，java有多少，php多少，前端多少，人力就那么多。至少让业务部门的心里预期能降低，真的不是需求今天提过来，后天就能上线的。 2.明确需求出口人和对接人，运营人员的需求内部先讨论出优先级，再统一由出口人输出给产品，产品再评估需求，和具体的需求方确认。这也是一种化被动接收为主动吧。
展开
作者回复: 对，而且一看你这么正儿八经，需求方提需求也会严肃很多
14
逃之玉諑
2017-12-27
对于一个没有技术团队的公司，要如何做好一个内部产品经理呢？开发团队是外包的和他们沟通很困难
作者回复: 这个最难了，可能要靠流程和文档了。当然，最好还是能跟他们做好利益绑定
5
辣酱
2017-12-28
邱老师，这几期录音声音都挺清楚的，保持，之前有几期声音挺小的.
作者回复: 哈哈哈哈，好嘞，我以后声大点儿
4
Jerry
2017-12-27
对于内部产品我是这么理解的，内部产品就相当于toB产品。只是用户只有自己公司一家。把它当成toB的产品去操作，考虑。
作者回复: 也是个思路～
4
zero
2018-01-09
内部产品没有产品经理，作为交互设计师担起了产品的角色。但作为第三方部门，事情推行困难，内部也不是很支持，各种心累呀😭
作者回复: 先想办法建立信任和影响力，然后事情可能会容易一点
2
Paualf
2019-11-06
跟着产品经理做了一个内部的广告检测平台，同时和游戏数据相结合，过程中向产品经理请教了很多广告行业的问题，学到了很多东西，以前也觉得做内部系统学不到东西，后来发现不是学不到东西，是自己想不想学到东西
作者回复: 「发现不是学不到东西，是自己想不想学到东西」//赞👍👍👍
1
小朱0707
2018-02-12
我现在负责的系统就是是内部产品，由于属于后台，前面要对接多个业务系统，后面要对接财务系统，业务系统中还有外包系统，尤其心累。现在的精力全耗费在沟通了解各个业务系统的逻辑中。做了不到半年，感触如下： 1.作为后端系统，明确自己想要的字段，清晰定义，因为每个业务系统的命名可能不一致。 2.作为财务的前端系统，知其所以然非常重要，不然很容易传给错误信息. 3.搞定业务方非常非常重要，运营看到的需求是非常表面的，最根本的需求还是业务。五问方法用起来！看完真的感触很深，谢谢二爷
展开
1
刘剑
2017-12-28
内部产品的产品经理 1.需要把成果能量化，从而从数据上让领导和同事感受到你的价值 2.内部产品经理还需要化繁为简，明白每一个阶段解决哪些核心问题 3.非常认同内部产品对业务熟悉度要非常高 4.内部产品经理具有数据分析能力那么很快就能结束这个岗位转而到一个更高（更有价值）的岗位上去请问邱老师夫妻在同一个公司利大于弊还是弊大于利？为什么？
展开
作者回复: 我觉得对我来说是利大于弊，有共同语言，还可以一起上下班
1
Charles tong
2017-12-26
对内产品和对外产品如果由同一批技术来做，就会凸显一个矛盾：技术总是用做前台产品的精简化思维来看待后台产品在功能上的必要的繁复。这矛盾应该算是组织架构导致的问题，所以有必要在对内和对外的产品上区分出不同的技术团队开开发。这样有助于统一团队对待产品的态度，统一的态度也就决定了产品推动的顺利。我现在做内容审核系统，碰到的最大问题也就是上述的问题，每天在对技术同学的说服和说服不得中耗费精力，其实感觉还挺浪费精力的。当然这个问题也绝不是态度这一个因素导致的，决定态度的是团队的KPI设置，以及公司的战略方向。公司战略是很难撼动的，同时在组织架构也无法改变的时候，合理的团队KPI设置却能够从根本上解决很多矛盾。我也继续在这条推动团队设置合理KPI的螳臂当车的道路上行进，直至阵亡。但也可能这一切的行动都没有意义。
展开
1
时间之树
2017-12-26
感觉公司对内部产品的用户体验没有对外部产品的用户体验重视度高。离用户越近，产品反而越不好用。也可能这只是我们公司的特例。
1
BetterFeeling
2017-12-26
对于内部产品，用户就在自己身边，可以非常方便观察用户的使用情况，努力改进产品可以增加同事的使用体验和效率，一个微小的优化可能会大幅度提高同事工作时的幸福度。所以，应该珍惜每一个做产品的机会，精进自己。
1
马辉
2021-04-12
产品可用性研究成本也变得非常低廉。确实是，如果做的产品离用户近，得到的反馈路径就大大减少了，如果是面对开放形用户，只能一直傻等用户反馈，突然间明白，为什么很多应用都想方设法的去收集用户的反馈。
悟空来 | Arthur...
2020-06-18
学习到了：计划把我们的系统分为商机系统，crm，业务系统
个人学习
2019-04-22
我们压根就不叫产品经理，信息管理专员，好听点可能会叫信息管理工程师。
旺旺
2019-04-18
绝对不能沦为功能经理，要做主动出击型的产品经理。 1、用户太近，容易带来压力和混乱，我们需做好“资源显性化”和“需求流程化”来应对；其实，一个小团队，太过灵活时，也会容易出现类似压力和混乱，需要做好内部流程化管理。 2、把握好用户近的特点，去学习和尝试做用户研究。 3、挖掘动机、绑定立场、利用技术推动业务最大化。
展开
Moran
2019-02-22
内部产品这个定义也是今天才知道，我一直把这类的产品统一归纳为B端产品，网上很多产品资源都是面向C端的，真正针对B端的产品信息不多（文章、教程等）
卢嘉敏
2018-12-19
功能性产品经理是一个野路子出身的必经历程吧
heha37
2018-10-27
从内向外
javaadu
2018-08-19
资源显性项目流程化理解业务，主动往外走，站到更高层面

