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