涂料客户定制化需求多怎么处理
发布网友
发布时间：2023-05-19 05:38
共1个回答
热心网友
时间：2024-08-23 20:44

BeeArt
重塑数字化产品管理新模式
来自专栏数字化产品设计社区
（文章作者：产品经理 钱冰沁）
自从孵化 BeeArt 以来，常常收到各种各样的用户反馈与客户需求，它们在需求分析看板中有着专属的一列，不完全统计多达上百个。只是对于一款 B端产品而言，这样多的个性化需求是非常头疼的一个问题。面对这类需求，到底该如何处理？这里面有多少是真需求，是核心需求，哪些又只是边缘性需求，哪些应该被通用，哪些属于个性化，又有多少其实是伪需求呢？
作为一名 B端的产品经理，你该如何面对它们呢？在此我有一些个人经验想分享给大家，我是如何思考这些客户需求？又是如何合理处理它们？
01. 客户需求可以分为哪些？
a. 个性化功能
我希望在我的团队空间中，左上角 BeeArt Logo 可以替换成自己的品牌 Logo
当接到这个需求后，我了解到这个团队需要举办一次线上工作坊大会，参会者会使用 BeeArt 作为交流工具，因此希望自己大会的 Logo 可以更多的对参会者露出。对他们来说，左上角的 BeeArt Logo 会混淆主办方的品牌。因此他们提出可以更换主 Logo 的需求。
那么这个需求属于个性化需求吗？我相信不少产品经理也接到过企业客户提出换 Logo 与换肤的需求，这似乎是一个可以被通用的常规需求。在判断这个问题时，我从以下几方面思考：
这个需求之前是否有其他许多客户提出过？
提出此需求的客户是否是产品的主要目标客户群体？
在翻阅了之前的需求池与反馈记录中发现，没有除此之外的任何客户提出过该需求，当客户在使用一款 SaaS 软件时，心里便会默认左上角为软件品牌 Logo，这对使用者似乎并不造成混淆。而此团队举办线上工作坊今年也只有这一次，并非一个高频通用场景。坦白说，在之后的产品销售时也不会将此客户当做核心目标客户。
因此，依照当下即可判断，这就是一个个性化功能！
b. 定制类功能
定制是 B 端产品始终绕不开的话题，SaaS 产品的噩梦。我粗粗的会分为以下 3种情况：
产品的角色权限分类需要匹配我们的组织架构
1. 对于 大型客户，因为本身规模大、业务结构复杂、流程固定，因此他们所需要的解决方案都带有极强的专属风格，很多需求只能依靠定制才能完美匹配；
提供更多的教程指引，再来几个小游戏模板
2. 对于 中小客户，由于他们业务还没有标准化，流程也不一定成熟，因此很多规范的通用需求对于他们使用门槛较高，需要很多开箱即用的定制需求；
白板内字号从14跳到18，差别过大，字号选项增加 16号；
3. 一些 偏视觉类 的定制需求，由于每个客户甚至个人的视觉偏好差异较大，字体字号，颜色边距，每个人可能都不一样。
其实定制类的需求往往也是一种个性化需求，由于客户 A 所定制的功能，很可能其他客户都不需要。因此面对较为完整的具有时间节点的定制需求，我会考虑通过付费的项目制进行推进。
随着 B 端产品逐年演进成熟，目标客户群体中高端大型客户占比越高，所需要应对的定制化需求也就越多。产品面临的架构臃肿，功能冗余的风险也就越高。这也是很多 SaaS 产品坚持只走 SaaS 路线的原因。
c. 私有化部署功能
私有化部署就是将本有公有云上的代码部署在客户的私有云或本地机房中，本质上它已和公有云上的 SaaS 产品不再是一套。
对接企业 SSO 登录
一般需求私有化部署的客户大致分为：
对于自身数据安全有严格要求的
需要对接企业已有系统的
需要二次开发自己的专属功能的
拥有自主服务器和开发人员，希望自己维护演进的
由于私有化部署需要团队消耗更多的时间，人力与成本。因此，一般只有资金充沛的中大型客户才会需要私有化部署。最大的风险即为当客户在私有化部署之后又叠加了定制化功能，对于后续升级与维护将是难上加难。也就意味着这类客户将由产品的升级订阅转为了项目制运维。
02. 评估价值与可行性
一个成熟的产品经理在面对这些客户需求的时候，并不应该一味的满足同意，应该站在需求的价值、投入产出比、可行性等角度进行综合分析。
a. 价值评估
1. 是否具有 被通用的潜力有些需求可能是某个业务领先的客户提的，从当前来看，极有可能是一个个性化需求。但是从长远角度来看，这个需求可能会成长为一个通用化的需求，随着整体客户群的周期进入发展期后，这类需求将会逐渐通用化。
2. 能否为单体客户提供足够大的价值某个单个需求，可以为客户带来巨大价值，为客户赚取巨大收益、或是缩减成本。
3. 能否为产品带来品牌效应这个需求对于产品本身来说有没有商业价值，但可以与客户发生链接，最终达到客户帮产品做宣传与背书、帮我们转介绍更多的客户等。
b. 投入产出比
有些需求可能只是修改一下前端页面的 UI，那么这种改动就比较小，投入产出也就比较小，虽然价值不大，但是成本也很低，可以视紧急程度而决定。现有 BeeArt 中则是每个迭代都会安排固定的时间进行 UI 优化，既能满足客户需求，又不占用过多资源。
c. 可行性
在前文所分类的 3种客户需求中，私有化部署的需求往往是难度最大的。
1. 不同的硬件配置、不同的硬件架构、不同的操作系统、不同的网络情况等，不同的安装、架构、运维都要与之兼容；
2. 每次的版本功能更新，都需要在各个客户处私有化部署一次，工作量重复了好几倍；
3. 私有化服务产生的 bug 会带有特殊性，和 SaaS 中的同一种 bug 并不一定是因为相同原因产生的，增加了定位难度，同时修复后要单独再发布更新，大大增加了问题的响应时间；
4. 不同私有化的部署的产品版本可能存在多个，迭代功能需要考虑不同版本的兼容和影响，成本巨大；
因此，如果你是一个创业小团队，在产品还未成熟的早期，私有化部署会对产品迭代演进造成很大的阻力，更建议成熟后在做打算。
03. 如何正确的处理客户需求？
1. 对于小功能型需求、页面 UI 类型需求等个性化需求，如果客户重要度较高、需求轻量度较小、且对业务流程基本无影响，可以考虑直接进入产品路线图进行排期优化，或是择机通过收费的形式进行定制。
2. 如果该个性化需求实现成本很高，且对现有业务流程影响很大，需要进行大量改造的，我建议再三慎重思考，尤其在产品孵化早期，接这样的定制化需求会对产品本身的迭代带来巨大的影响。因为这不仅是一次性研发，在未来的每次迭代，你都要额外考虑一套可能差异巨大的业务流程的兼容，从产品、开发、测试每个角度来说工作量都会大增，甚至会严重影响 SaaS 产品自身的发展。
3. 除非这个客户真的是不能丢弃的客户，做完这些定制化需求，客户能给你带来巨大的价值，那么也只能硬着头皮接了。接了需求后，一定要合理的分配 SaaS 和定制化的资源分配，不要本末倒置，长期把资源都投入到了定制化、私有部署中。这也是很多 B端 SaaS 产品还没做起来就已经潜入一堆浆糊、瞻前顾后、和无休止的客户扯皮中的原因。
作为一名产品经理，接需求往往最容易。难得是如何在纷乱的需求噪音中坚持本心，不被眼前的利益动摇，拒绝掉那些与产品形态和商业模式不符合的需求。
