时间: 2021-07-30 11:25:34 人气: 11 评论: 0
在职场上,随着产品的迭代,增长速度的变化,难免**暴露出一些问题。那么,产品经理在面对这些事情的时候应该怎么处理呢?

手上有个开源的 CRM 系统,服务于公司销售团队。这个销售团队是公司的现金牛业务,略强势,业务老板也说,我们说要什么,你们产品做就好了。于是销售提什么需求就做什么功能,平时合作还算顺畅,也做了不少符合业务团队目标的工具。
一段时间下,由于业务跑的非常快,业务增长速度也很快,大家都相安无事。然而从去年开始,业务增长速度慢下来,问题就逐步的暴露出来。于是在年末汇报,业务方老板吐槽说 CRM 系统不好用,不是围绕「业务」做产品,影响业务效率。
被批评了自然不爽,我可是非常配合业务团队做的功能啊。不被业务方认可算了,还被业务方老板吐槽,不是业务前进的助力工具,作为产品经理,委屈的不行。
冷静下来,仔细回顾了这一年的产出之后,还真的也只是做了一些修修补补的工作,都是些毫无存在感的事情,用时下流行的名称就是「工具人」。
怎么办?
要转化做事的思路了,不做「听话」的产品经理,要做可感知的创新。
要做有价值的事情,就要做到「懂业务」。
我们在做业务需求的同时,开始深入的对产品进行分析,梳理业务流程和使用场景,也对行业内大量竞品进行调研。最后整理出一份符合公司业务发展 CRM 结构图。

灰色表示已经完成,白色表示没有,绿色表示即将要做的事情
拿着这个规划,找业务方老板汇报,并尝试了解老板的想法。
原来老板其实也挺郁闷,想通过CRM 系统了解下当下业务情况,以及目前销售团队状况,没有合适的报表查看,只能手动配置一个巨麻烦的报表,还要下载下来自己分析,虽然有销售总监的每周汇报,但还是缺少灵活性。
老板对我们这个计划认可,也希望我们和销售总监、以及一线销售聊聊,听听他们的想法。接下来,我们又找销售总监、一线销售聊,看看他们最关注的是什么。一翻沟通之后,得到以下反馈。
需求反馈:
老板:要能看到销售的业绩情况,以及团队关键的业务指标情况,用来辅助我决策一些销售策略。
销售总监:希望能提升销售签单效率和回款率,并且能及时发现异常。
一线销售:我想知道哪些客户能快速签单。
搜集到客户需求后,我们开始做进入第二步:需求分析。
那现在我们就把收集过来的业务需求,转化为产品需求。

把业务转化为产品需求,接下来,就开始分析,如何「如何围绕业务」做产品。
我们优先考虑了业务老板使用场景和需求,设计了一个「业务 DashBoard」,让他一眼就能看到,他希望得到信息,大致可以分为:
(1)业务管理模块
可以快速的了解当前业绩进度,以及销售的能力排行。
(2)客户管理模块
能让管理者,了解业绩完成情况之外,清楚销售跟进客户的情况。

这个 Dashboard 虽然过程很复杂,但逻辑清晰明了,产品设计过程就略过了。上线之后我们也没有设置权限,业务团队登录系统后,先**看到这个页面。
上线一周后,我们对数据进行了梳理,发现“回款”有了明显提升,由于非常清楚的展示到页面,销售不需要非常麻烦的到处查找,哪些客户需要催到款,原来一周内**有 200+的未到款合同,减少到 100 以内,效果非常明显。
小Tips:为什么要先考虑做老板需求?当然是决策者对业务的影响大啊。当有多角色需求出现冲突时,优先考虑决策者的需求。
Dashboard 上线后,也暴露业务的欠缺点。
客户管理:
销售管理:
拿到这些数据,我们再次进行业务汇报,并和销售总监进行探讨,规划了 DashBoard 2.0,帮助销售总监方便的查看团队情况。
客户管理方面:
销售管理:

2.0 版本上线后,由于有了客户资源自动流转机制,销售的工作积极性有了明显提升,体现在跟进记录有了明显提升,销售业绩也有小幅的上涨。
我相信不少产品经理也**遇到类似事,闷头为一线使用者做功能,而一线更关注于自己手头的活能不能完成,就算你做到极致,也是刚刚满足业务需求。而 CRM 系统的搭建,不仅仅是系统建设问题,更是业务体系设计问题。
如果不把业务体系搭建好,你做的东西一线员工用的再好,也不**增加业务效率的明显提升,反而老板觉得你整天修修补补,不是围绕“业务”做事情。
如果发现你的产品功能上线后,使用效果未尽人意,那不妨试试影响一线使用者的老板,至上而下是个不错的办法。
司马特小队,公众号:司马特小分队,人人都是产品经理专栏作家。8年+互联网资深产品经验,多年B端产品管理经验。具有多个从0到1的大型B端产品的孵化、重构、迭代经验;主要教授产业互联网产品相关的硬核知识点。
本文原创发布于人人都是产品经理,未经许可,禁止转载
题图来自Unsplash,基于CC0协议。