B端SaaS产品原则

编辑导语：B端产品设计并不是一个人的事情，往往是一个团队共同完成的。在整个团队中，会涉及到四个环节：需求环节、设计环节、研发环节和运营环节。在这些环节中，需要遵循一些原则，共同推动整个产品建设。

本文针对产品的需求环节、设计环节、研发环节和运营环节所提出的原则，需要整个产品建设参与方共同推动。

这些原则，是产品团队在学习以及实践中得来的，也学习参考了行业内领先toB平台产品团队的经验，总结这些原则，是为了让团队中的每一位伙伴，能够尽快的融入团队，大家能够形成相对一致、符合行业特性的产品观念，实现自我提升，并帮助公司产品更好的发展。

一、需求环节

需求管理能力是产品人员最重要的能力，需求的优先级决定了团队资源的投入方向。

1. 用户和场景是产品的基础

需求应主要来源于用户并用于满足具体使用场景。

产品需求来源可能有多种途径，比如市售后部门反馈、用户反馈、渠道反馈、产品内部沟通总结、竞品分析得来、上级领导提出、政策要求、运营部门反馈等等。

市场接受一个产品，一定是这个产品满足了市场需要，解决了企业的实际问题，我们应该更关注企业的真实反馈和所提需求，集中力量解决实际的场景需求问题。

产品人员需要对需求进行分析、甄别，每个需求，都尽可能由直接用户提出，拿到最真实的原始需求；对于中间转述得来的需求，夹杂了部分转述人的理解，可能存在需求失真的情况，不利于更好的给出产品方案。

对于非直接用户帮直接用户所提的需求，慎重处理，这些需求的提出方和使用方不一致，需求的合理性或可操作性，得不到保障，往往难以落地。

对于用户所提需求，一定要关注场景本身。用户并不是专业的产品人员，提出的一些需求更准确的说应该是要求，直接实现这些要求未必满足用户的实际目的，或者不是最好的操作办法，所以每个需求，都要清楚了解用户的真实意图，要实际解决什么问题。

如何搞清楚实际的场景，可以参考5W2H分析法。

附5W2H：

• Who：由谁来完成
• Where：在哪完成
• What：完成什么事情
• When：什么时间完成
• Why：为什么要完成
• How：怎么完成
• How much：涉及哪些费用

2. 优先满足多数人的高价值需求

开发产品功能，需要考虑投入产出比。产品人员在处理需求优先级的过程中，往往会受到各相关方的影响，比如有些需求提出人很着急，有些人需求提出或关注的人职位很高，会影响需求的优先级排期。

而需求优先级一旦确定，意味着团队资源将用于实现这些需求，需求优先级不合理，肯定会对产品的正常发展产生不利影响。

怎么合理安排需求优先级，需要一套相对科学的方法支撑，考虑需求实现的投入产出比。如何相对合理的评估，可以参考我此前总结的文章《产品需求应该如何管理》第五章节。

链接：http://www.woshipm.com/operate/4228746.html

从科学技术发展的规律来看，技术永远朝着人类需求多的地方去不断演化。

3. 具有持续性或重复性使用场景的需求才需要进入产品流程

如果说上一条原则是对需求管理的较高要求，这一条则是对需求管理的最低要求。我们工作中存在一些低频出现的场景，也要求产品化.

这实际上是对产研资源的一种浪费，这种低频的操作或一次性工作应通过尽量其他手段完成，在需要的频次上升或者重复操作次数提升时，再转为需要进入研发流程的需求。

二、设计环节

产品设计是产品人员的基本能力，优秀的产品设计可以增强产品的市场竞争力，提升用户体验和生产效率。

1. 产品设计应满足最小化场景闭环

产品设计不应过度求全，在资源有限的情况下，满足最小场景闭环即可。目前的产品迭代方式接近于敏捷开发，产品推向市场的特点是快速推出，快速验证，根据反馈快速优化。

如果一套功能设计过于庞大，会导致迭代周期延长，中间存在的问题只有在推向市场后，可能才被发现，再返工调整会浪费大量的工作量，可能会减缓产品的进步速度，降低产品市场竞争力。

产品设计不应削减必要的功能，强调最小场景闭环，是因为如果上线部分功能，导致用户最小单元操作无法完成，无法解决用户的问题，会降低用户的满意度。达不到产品迭代的作用和意义。

2. 优先满足操作效率需求

企业服务产品存在的主要价值，是能够帮助企业增加收入、降低成本。营销类平台侧重解决企业的增收诉求，管理类或其他工具类产品，侧重解决企业的降本诉求（降低成本包含多个维度，比如管理成本，运营成本，合规成本等等）。

提高效率是降低成本的有效办法，提高效率可以有多种方式，比如批量操作、缩短流程、自动处理等，产品设计过程中，应优先考虑这些能够提高效率的方式方法。

3. 功能基于现有场景进行抽象，不轻易增加新概念

企业运营往往需要多人协同，需要团队成员对某一场景有共同的理解和认知。

基于用户的现有场景进行抽象，尽可能保证线上的概念和线下基本一致。可以让用户不需要进行专业的培训学习，就可以理解系统的运作模式。这里的场景包括空间、流程、操作方式等，概念包括专业术语、行业名词、通用词语等。

任何一个新概念的产生，都需要人们去记忆和理解，在多人协同的情况下，一个简单名词也可能会产生理解的重大偏差。这都可能需要花费大量的精力去教育市场、培训用户。

三、研发环节

产品经理应同研发环节紧密配合，研发环节在实现需求的同时，兼顾产品的稳定和易用。必要的时候需要适当调整优先级和需求条目。

1. 技术实现应尽可能满足用户场景需求

这里强调满足用户的场景需求，而不是满足产品经理的需求，团队成员都有权利提出自己的合理化建议，在对用户操作场景了解清晰的情况下，给出最合适的解决方案。方案达成一致后，再进入研发环节。

技术实现应该尽可能满足用户场景需求，我们在实现需求的过程中，可能会因为实现的复杂度上升，工作量增加而调整方案，如果调整后的方案不能很好的满足用户的需求，则无需调整。

我们不能把实现功能作为目的，而是以满足用户场景需求作为第一准则，开发出一个用户不适用的功能，不会对用户和客户产生实际价值。

2. 稳定是产品建设的基石，稳定应始终居于主要地位

已有大量用户的线上产品稳定压到一切，新产品或用户量较少产品进度可适当加快。我们经常会面临各相关方催促需求上线的进度，期望提前上线，如果新功能上线影响原有系统稳定，则必须慎重评估，产品经理和技术团队识别风险后有必须拒绝上线此类需求。

稳定的优先级高于新功能的实现，这在企业服务行业是基本达成一致的认知。道理很简单，已经存在的功能，如果不能继续使用，会立刻影响所有的用户，导致正常的操作预期不能得到满足，严重的会影响企业的正常运营，直接产生经济损失。新功能是尚未实现的功能，用户对此并未形成依赖。

3. 产品中的提示应让用户能够看懂并知道下一步该怎么做

产品在设计和研发过程中，会产生各种各样的提示，很多提示是没有经过专业处理的，比如遇到一个异常，研发人员可能会直接抛出异常，或者按自己的理解给一个提示，而这个提示可能过于技术化，用户会看不懂。

系统提示非常重要，用户的每一次操作都会有预期的反馈，一旦预期没有得到满足，一定是出“问题”了，这种情况下需要用户明白发生了什么事情，为解决这个“问题”，很可能需要用户进一步做其他的操作。所以系统给出的提示，首先需要用户能够看明白，其次需要指导用户接下来该怎么做。

产品经理需要关注并参与各种提示的优化，为研发及其他环节的伙伴提供支持。好的产品提示胜过多次的产品培训。

四、运营环节

1. 尊重每一位客户，不轻易下线功能

用户使用了我们的功能，跟我们已经达成了协议，轻易下线功能，会导致用户原有操作习惯改变，甚至无法完成原有业务操作。给用户和客户带来的体验，是非常糟糕的。

如果必须要下线某项功能，产品经理请尽可能提前做好沟通工作，为客户提供可替代方案，把对客户造成的影响降到最低。

2. 在用户或客户需要的时候提醒

在产品运营的过程中，有的时候，给用户过多干扰，有时该提醒的忘记提醒，影响了客户的正常使用。我们应该避免打扰客户，需要提醒客户的时候，一定要提醒到位。

这些原则是我们做好B端产品的基础条件。

遵循了这些原则，不一定能够做好，而不遵循这些原则，往往会产生负面的效应。需要产品各个环节不停的去思考、琢磨，优化，才会让产品更好。

感谢：对于做B端产品的一些思考和借鉴，我们有团队内部伙伴的贡献，亦有行业领先平台的分享指导，在此很感谢大家的分享和付出，有赞产品设计白鸦团队分享的产品原则，给了我们很多的指导和借鉴意义，再次感谢。

本文由 @原始森林 原创发布于人人都是产品经理，未经许可，禁止转载

题图来自 Unsplash，基于 CC0 协议