B端SaaS产品原则

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

true

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

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

一、需求环节

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

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

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

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

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

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

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

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

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

附5W2H:

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

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

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

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

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

链接:https://www.woshipm.com/operate/4228746.html

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

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

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

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

二、设计环节

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

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

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

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

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

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

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

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

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

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

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

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

三、研发环节

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

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

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

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

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

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

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

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

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

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

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

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

四、运营环节

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

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

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

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

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

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

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

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

 

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

题图来自 Unsplash,基于 CC0 协议

给TA买糖
共{{data.count}}人
人已赞赏
Saas产品设计

SaaS 102 | 做 SaaS 产品应该如何做决策?

2021-8-11 0:00:00

Saas产品设计

SaaS产品之路——需求篇

2021-8-26 0:00:00

0 条回复 A文章作者 M管理员
    暂无讨论,说说你的看法吧
个人中心
购物车
优惠劵
今日签到
有新私信 私信列表
搜索