在互联网产品开发中，普遍有很多非产研人员会认为做产品并不是一件多难的事情，所谓“人人都是产品经理”，每个人都能对还未落地的场景化需求说这么两句。
所以也经常流传着这样的调侃：这个需求很简单，怎么实现我不管，哪种语言你随便，不服可以找老板。
虽然是一句调侃，但是不难看出产品知与行之间的认知鸿沟。
在SaaS产品早期的SLG阶段（Sales Led Growth，销售驱动增长），大家卖软件靠的是销售力，当产品力相对较弱的时候，不可避免会被市场客户需求推着走，是克制还是放宽？是顺应还是推翻？是增加还是减少？
这些，都是产品经理和团队负责人应该思考的事情，为什么别人眼里看着很简单的需求，实现起来并不是那么容易？
我想，知易行难，问题之所以显眼的存在而不易解决，或许是思考维度的多元化没有打开。
如何打开这些维度呢？我和你分享一些我的思考和看法。
1
加法容易减法难
“做加法的想法几乎立刻就能在脑海中浮现出来，但做减法却需要更多的认知和努力”
你是否发现，市场和运营提出客户产品需求时，只要是合理的客户需求基本上都要去实现，因为你不满足客户的使用需求，产品在一线落地会遇到较大的阻力。
那么，在做需求加法的时候，产品是否可以多思考下，增加需求是否会影响原有产品架构的完整性，减少需求又是否真的劝退客户，或者有没有B计划来填补需求空缺。
2
专而精，好过大而全
集中精力专注在核心产品功能上，真正去解决客户场景问题，而不是大而全的覆盖，客户要的都有，但是都不好用，自然无法做成叫得响的拳头产品。
面面俱到不如深挖一点，好比现在的CRM系统，产品功能同质化竞争下，如何在差异化上做精做深，给客户心里打上属于自己产品的标签烙印。
3
对外顺应人性，向内克制人性
做减法是反人性的，不信你试试问下自己，谁不希望好处多多益善。只做顺应人性的事难以有成就，逆人性的事情才会有更多收获。
反馈在产品上，一味顺从客户需求做加法，尤其是SaaS产品，牵一发而动全身，最后肯定会拖累产品，在满足现有客户需求和满足未来客户需求上，辩证和克制也是必修技之一，既能顺应市场客户的使用需求，又能克制产品臃肿。
4
不用重来才叫快，能够积累才叫多
产品的反复推翻和重构具备极强的杀伤力，相信你肯定遇到过这样的场景，在产品MVP阶段，公司领导和产研团队好不容易内部论证推演做出了产品发展规划，但是在一线实施人员指导客户落地时发现事实和规划相背，这时候产品该坚持哪个方向？
很多公司的产品发展和最初的构想并不一致，这是事实。
没有一步到位的产品，尽快用MVP去验证市场，快速试错中暴露的很多细节和问题，都可以积累沉淀到下一次迭代。少即是多，慢即是快。
5
简单，简单，再简单
SaaS产品在前期客户体量还不足够大的时候，不要去思考太多高度灵活配置化的功能，一来是可供验证需求的客户样本有限，没有谁能确保一定会是这样的适用场景；二来是会让自己反复的做加法，因为你不得不在每个功能点上留有余地，以便后期开发。
让客户适应产品，还是让产品适应客户，没有标准答案，至少会是一个拉锯战，但产品最终要落实在客户层面实施，简单易用能带来更好的用户体验和更低的实施成本。
6
场景，场景，还是场景
闭门造车式的论证推演，自信满满的将产品推向市场，结果发现PMF不达预期（(Product Market Fit，产品和市场匹配度）。
很多我们认为用户应该关注的场景并没有发生，尤其是垂直型行业SaaS产品，为什么会这样？
因为客户场景并不是坐在办公室想出来的，去哪里？怎么想？应该在听到一线炮火的声音后再去做决定。试想一下你的产品，是否有70%以上的功能并不被用户经常使用。
最后的话
👉产品知易行难，缩短认知鸿沟，不妨打开以上维度
👉顺应客户需求，但也要克制需求，加法容易减法难
👉专而精好过大而全，找到自己杀手级的产品功能
👉回归场景，简单易用，产品要经得住前线考验
加与减，你今天做了吗？
END
作者：王钰
公众号：钰见SaaS
