由于在自我认同和话语权等方面的劣势，内部产品领域一直是互联网行业从业人员不太愿意触及的领域。本文作者总结了一些自己做内部系统的经验，希望能给你带来一些帮助。
内部产品领域一直是互联网行业从业人员不太愿意触及的领域。作者自毕业进入职场以来，机缘巧合下独立承担了公司内知识管理与培训线业务的各类产品工作，一年半的时间在内部产品的大坑内，从挣扎求生到游刃有余，从茫然失措到获得肯定，希望将自己这段项目经历中的所思所想记录下来，为大家提供一些借鉴。
首先，在自我认同上，内部系统是有着天然劣势的。C端产品天然会有着用户量与产品知名度带来的成就感；B端产品在最终企业订单里能感知到自身给公司带来的收益价值；内部系统的产品经理只能在虚无的满意度上寻求自我认同。甚至关于内部系统是不是产品这个问题都很微妙，常见的互联网产品，由于边际成本几乎为0，在各个行业里翻江倒海。
内部系统往往与特定业务耦合过深，对于同一业务的不同团队诉求都很难低成本支持，用户侧甚至对系统存在毫无感知，只是在业务流程中间接享受着系统支持。这样的系统让人感觉到只能叫做业务工具，并不能真正意义上叫做产品。在无限的业务需求单里，内部系统产品经理很容易自我怀疑与消沉。
其次，在话语权上，内部系统的产品经理往往显得很没有主动权。要清楚地了解到内部产品的用户群体，包括着内部员工、业务团队与管理层，在管理层面前产品经理自然是毫无话语权的。
在业务团队面前，由于内部系统最终指向于业务支持，因此业务团队出于业务理解与直觉，往往“以始为终”地指导你进行产品设计，对于产品经理而言，过分顺从似乎变成了传话筒，失去了工作主导型；过分抗拒又似乎偏离了系统最终服务对象，因此在这种两难中如何抢回产品设计主导权是一个考验点。
在我的实际工作里，产品经理话语权丢失，是我曾经遇到的非常大的问题：
内部系统的产品经理，非常容易成为需求落地的协调工作承担者，而不是产品设计的主导者。内部产品经理有时候没有挑选需求的权力，甚至经常因为插入的紧急需求，被迫限定上线日期，再倒排工期投入资源。
一旦长期陷入这样的情况，产品经理角色的自我价值会被最大程度削弱，成为一个只会抽鞭子的监工，一个需求传话筒。这会非常影响个人心态和团队对产品角色的认同。
最后，内部系统想要衡量自身工作收益是有难度的，系统收益与业务收益很难解耦衡量，对于到底是业务团队优秀还是产品设计优秀的问题上，内部系统的产品经理很容易没有底气。内部产品无法自身发挥价值，再好的系统设计必须让业务团队去使用，承载业务开展才能显现出系统存在的意义，因此产品收益仿佛变成了业务收益的施舍与附赠；
与此同时，如果系统出了问题影响到业务，这个责任却是非常明晰地属于产研团队的过错。收益是隐性的，责任却是显性的，内部系统的产品经理需要在这样“憋屈”的环境中推进工作。
想要解决以上所说的问题，有非常多需要做的，比如：如何与业务团队形成良好的沟通关系，如何管理好管理侧的预期，如何疏导好团队内同学的心态……
但要真的做好这些工作，需要有一个“抓手”，那就是系统本身需要标准化转型。当一个定制系统转型成为一个标准化产品的时候，你的工作就不再是“接单式”支持下一个业务项目，而是沿着自身规划的产品路线推进。
不可避免地，你还是需要跟业务团队去确认你的规划与方案，但是你们不再是对齐“下一个业务项目，我们系统的支持方案”，而是对齐”针对未来较长的一段时间，业务的发展诉求，产品侧提供推进路线”，这样你回旋空间将会极大提高。
对于系统的标准化转型，产品研发团队是天然存在动力的，因为这意味着你们的工作从业务下游变成业务上游，你们可以主动地、自由地去做自己的产品。但是对于业务侧和管理侧而言，这是需要一定程度的理由去说服他们投入资源，耐心等待变化的。
对于业务侧，最大的动力来自于业务变化诉求，业务团队对业务本身成果负责，因此在你的方案里，你需要向他们说明标准化的产品对业务的助益。
在我的实际工作里，业务侧动力来自于三点：
而管理侧诉求，则是在支持好业务本身的同时，最大程度的降本增效（这是内部工具/系统/产品永恒不变的命题），帮领导算好这笔账会是你争取到资源的最大依仗。另外，对于有商业化野心的领导，内部业务系统转型为SAAS化产品，对外提供服务是一个非常美妙的故事，而这一切的源头就是先让一个系统成为标准的、可复制的产品服务。
相对而言，在初始立项环节用户侧的挑战和阻力是最小的：内部系统往往是隐在业务之后的服务。但是需要有清楚认知，当搭建了一个标准化平台服务之后，你将会需要多应付来自用户侧的压力。
当决定推动内部系统转型为标准化产品后，对于产品经理角色的能力要求也会发生变化：
无论是内部系统还是标准化产品，业务团队本身是基本盘，失去了业务的承载，无论是系统还是产品都会失去意义。因此想要做好系统转型，首先是要深刻全局的理解业务。
值得说明的时候，有时候某一个业务团队/角色的视角都是相对局限的，作为产品方，你需要最大程度了解到每个类型的业务团队，每个不同的角色，每个存在环节的实际情况与诉求。
这里面既包括强势的业务团队，也包括存在感不强但是可能广泛存在的业务团队；既包括显性的业务角色（业务执行者，业务负责人），也包括相对隐形，但是产品标准化后会突出的角色群体（目标用户，关联业务团队）。拿到的信息越多，对于后续产品设计与上线存在的阻力也就越少。
我经常的思考路径是这样的：
当产品经理可以理顺一个完整的业务SOP，并且能够涵盖了各类角色、各种系统能力的时候，自然能够明确标准化后的产品所要涵盖的范围、解决的问题、标准化的逻辑……这些信息是进行产品设计的立足点。
标准化产品最大的优势是具备极好的可配置性与可拓展性，能够对未知的业务发展诉求，提供稳固的产品底座。而对于框架的设计，能够尽量了解市面上已经完成SAAS的竞品是非常有效的方法。
找出具有代表性的产品，梳理每一个产品的模块框架设计，试图理解设计共同点与不同点，再结合自身的产品诉求去调整，对于新人来说是比较切实可行的工作路径。
我在实际工作中，最为成功的是基于系统的权限结构与数据结构，设计了新的业务团队管理模式，该模式实现了多业务团队相互独立又相关联的业务诉求，同时又稳固承接了后续源源不断入驻的业务团队。
值得一提的是，当我发现后续入驻的业务团队开始借助产品设计去优化内部的管理模式的时候，我会感觉到标准化产品的影响力已经渗透到业务团队内部，并在实践层面得到了极大的认可。
在转型期间，过去的业务团队会不由自主给出定制化的产品需求。定制化是一个能够让产品角色在当下阶段偷懒，但是未来踩坑的事情，对于这一点产品角色需要清醒的坚持好底线。
在多次通过标准路径解决业务诉求后，业务团队也会感受到产品支持模式的变化，如果标准化产品框架足够稳健，支持过程足够高效，业务团队感受到变化是积极的，双方沟通的成本将会越来越小。因此一个良好的产品设计，也是后续减少沟通成本的必要筹码。
正如本文的第一部分所说，再好的产品设计必须让业务团队去使用，承载业务开展才能显现出实际收益。并且对于转型后的标准化产品而言：
因此必要的运营工作是不可缺少的，有时候内部系统支持团队并没有这样的运营角色，因此在转型后运营工作就承担在产品角色身上。
在实际工作中，我对于运营工作主要基于几点开展：
1）指引文档与视频
当产品面向对象不再是固定团队的时候，产品设计足够的易用性和完备的指引文档是帮助新增用户快速上手的最低成本方式。
2）分批次宣传培训
3）形成稳定长期沟通渠道
转型成标准化产品后，面向业务侧与用户侧需要建立起稳定的沟通渠道，对版本的更新迭代及时推广宣传，用户反馈有长期的获取途径。让用户与业务看到产品的稳健向前迭代。
4）借力外部力量
公司层面要求整合同类业务数据，作为已经上线并且存在相当影响力的产品产品成为了数据的收口点，业务团队自然主动入驻。
个人视野有限，只能以自身工作经验出发，来分享一些自己关于企业内部系统转型的思考。
未来如果有同领域的朋友有新的想法，希望能够多多交流。
本文由 @Ted.Z 原创发布于人人都是产品经理，未经许可，禁止转载。
题图来自 Unsplash，基于 CC0 协议。
该文观点仅代表作者本人，人人都是产品经理平台仅提供信息存储空间服务。
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。