本文中，笔者将结合自己参与产品重构以及做SaaS产品的实践，与大家分享一些关于产品功能设计的思考，希望对你有所启发。
在上篇文章《关于「产品架构设计」，我的实践思考》中，讲述了当时我们是如何做的架构设计。
但在实际工作中，我们更多的还是做功能设计。
如果说架构是骨，那么功能就是其中一块块的肌肉，而字段属于连接整体的经络，最后这个系统会像人一样运作起来。
在产品基础完善期（即生命周期的萌芽期）， SaaS 产品为了满足核心场景的需求，会不断的增加功能，满足对方的业务诉求。
如何高效完成 SaaS 产品的功能设计，这是我作为产品新人的主要工作，因此需要不断的积累经验，提高产品方案的质量。
接下来，我会与你分享关于 SaaS 产品功能设计的一些思路，希望对你有用。
01 这个问题，需要通过功能来解决吗？
我刚入行时，当面对一个业务问题的时候，首先想到的是我该用一个怎样的功能来解决它，流程是什么样的，以及原型该怎么画。
而实际上我提出的解决方案不仅解决不了本质问题，同时因为方案被无数次打回来，导致对自信心的打击很大，甚至那时候觉得自己不适合做产品。
那么，问题到底出在哪了？
经过这段的时间的沉淀，我发现之前自己「解决问题」的思路不对。
在分析问题时，应该「先定义，再发散，后收敛」。
而不是重复做「收敛」的动作，那样只会跟无头苍蝇一样乱撞。
因此我总结了一下，当面对一个问题时，应该先明确以下这几个点。
1. 确定问题与现状
最常见的方式就是提问，我们需要通过合理和高效的提问，围绕着问题去收集相关信息。
作为产品经理要时刻谨记一句话，对方说的往往只是解决方案，而非问题和现状。
意识到这一点，通常我会问这么几个问题搞清现状。
（1）你们遇到了什么困难？
要知道，当你用「困难」作为提问关键词时，对方的表达就不再是「我要怎么样」，而是会说「现在是怎样」。
因此以这个问题作为开头，对方会下意识回顾事情发生的始末，回答过程中也会连带出很多相关信息。
产品经理需要做的，就是基于对业务的理解，对流程、角色、利益关系等关键信息保持敏感，完成信息的初步采集。
（2）在系统上如何操作？
我们的目的，肯定是希望产品能够为对方提供完善的服务。
所以通过「问」和「看」对方在系统上的操作，不仅能确定问题在系统层面的不足，还能发现其他的一些操作问题。
（3）目前是如何解决的？
最常见的情况，就是系统还没有做相关的解决方案，也就是这部分业务问题在系统上是缺失的。
那么我们就需要做相关的业务调研，从功能的层面去解决这个问题。
2. 最简解决方案
我们都说做产品要做 MVP（最小可行性），其实做功能也是一样。
我们要以最简单的方式来解决对方的问题，方便日后的拓展，或是重做。
这里要切记「最简」不代表「缺失」，业务闭环是做 SaaS 产品基本逻辑。
（1）已有功能的优化
有的时候不是我们没有这个功能，而是这个功能对方不知道，或者是说用不起来。
作为产品经理，需要对当前系统已有功能非常的了解。
那么面对这种情况，可以选择先做系统层面的讲解，然后再去考虑如何优化。
（2）视觉或交互上的调整
这里的核心理念，还是用最小成本去解决对方的问题。
比如组织架构的树状展示方式，单击是选中，双击是折叠 / 收起操作，这就能解决他们查看对应层级人员的视觉干扰问题。
（3）利用通用功能（增删改查）来解决
这些功能既通用，认知成本又低，作为基础的解决方案正合适。
比如客户存在任务执行一半，要求不必再做的问题，我们需要先考虑「删除」这个功能能否解决问题，而不是上来就做一个「任务停用」的功能。
如果上面这些问题你都搞清楚、弄明白了，那么接下来就会进入到功能设计的阶段。
02 设计功能，满足客户的个性化需求
对于 SaaS 产品来说，客户的需求存在多样化，因此在设计功能时一定会考虑「可配置」。
这么做的目的，一是希望前端页面简洁高效、内容清晰，且能够满足不同客户的业务需求。二是对于后端的功能配置，能够做到归类清晰、不杂乱。
那么我们该如何去做呢？
首先我们需要判断，业务流程与现有方案差别的大小。
如果差别大，我们需要从系统层面来配置，比如线下教育行业的上课流程存在两种。
那么对于少数企业的情况，可以考虑在面对这些用户时，将系统逻辑后台写死。
但如果业务流程与现有方案差别小，那仅从功能层面进行配置即可，这种就很常见了。
然后就进入到具体的功能设计流程，主要分为 3 个步骤。
1. 找到对应模块
如果说每个模块是解决「一类业务问题」，那么每个功能就要对应解决「单个业务问题」。
例如我之前做的一家少儿编程机构的管理后台，主模块分为市场管理、销售管理、教师管理、教务管理等。
那么对于线索回海这个业务问题，肯定要在销售管理模块下做功能设计。
2. 判断是否做成可配置
先用一套四象限法则，介绍一套判断的方式。
上图来自网络
先说一下第二象限，对于 SaaS 产品来说，如果我们选择要满足企业的个性化需求，尤其是他们占比还比较小，那我们要重点考虑「商业价值」。
如果对方希望你能帮他解决，但不愿意付钱，那么就要提高警惕了，这个业务问题对企业来说不价值没那么大。
再说一下第四象限， 这里重点要从 SaaS 产品公司的 ROI（投入产出比）来分析，不能为了满足客户而忽略公司的生存。
最后就是第一象限和第四象限，这其实比较好理解，这里就不做过多赘述。
3. 设计它的默认设置项
这里需要产品经理能够从大量客户的个性化场景中，找到最核心的场景，并以此为依据将该选项作为功能的默认配置。
这样做的本质，是希望减少误操的可能性。
写在最后
当然，任何事物都存在两面性，实际中也不要将所有功能都作为「可配置」。
一来这样会降低系统的易用性。
要知道，客户要的不是你的可配置，而是能高效、简洁的完成自己的工作内容，而每个配置项意味着对方需要多一步思考。
过多的配置项不仅造成页面的不简洁，同时也会增加流程的步骤。
二来会带来极高的开发成本。
如果配置项中的另一种选择没有客户使用，这无疑也是在浪费开发资源。
而这个问题的起因，又回来到了产品经理对业务的理解能力不足，需要加强业务调研的能力。
以上就是我对 SaaS 产品功能的设计的理解，接下来就是希望你我在实践中，不断的理解与调整。
愿你我一起加油，共同成长~
作者：空；公众号：小木盒产品记
本文由 @空 原创发布于人人都是产品经理。未经许可，禁止转载
题图来自Unsplash，基于CC0协议。
