SaaS产品设计:从需求管理到架构搭建的方法和步骤
编辑导语:B端产品面对企业客户,获取的需求多又杂,产品经理要如何才能处理好需求,在复杂的业务中搭建好产品架构呢?本文就B端产品讲述了一套从需求管理到产品架构搭建的方法和步骤,一起来看看吧。
本篇文章就SaaS产品讲述一套从需求管理到产品架构搭建的方法和步骤,步骤包括:规模收集需求、发现业务规律、建立产品原则、需求分段分层、版本规则与搭建架构。
SaaS产品面对的是企业客户,需要帮助企业解决业务和管理问题,获取的需求非常多、杂、乱,产品经理常常手忙脚乱,各种分类依然无法处理好需求、管控好产品版本,难以在复杂业务中搭建产品架构。现在我们一起来解决这个问题。
一、需求管理的方法:分段分层圈图
相比C端需求的单点和单线特征,SaaS的需求更为复杂:更多角色反馈、更多业务场景诉求,听起来声音多、看起来需求杂,如果产品经理对需求归类不明就会导致功能开发过度或缺失。
SaaS产品需求复杂的重要原因是其服务对象不再是单个个体、消费者,而是一个行业、一个组织、一个业务。
因此,B端产品最基础逻辑是:满足业务链条的某种完整度需求。链条,是横向;完整度,是纵向。
横向,是业务链条,为需求分段,问的是:解决谁的问题或者什么场景的问题。
纵向,是业务深度,为需求分层;问的是:解决到什么程度。
横向与纵向圈定的需求范围,即是一个个版本。
分段分层圈图在应用中常有两类,一类基于用户群组细分,一类基于业务场景。用户群组类的分段分层圈图如下:
分段分层圈图可根据业务情况对用户群组或业务场景进行需求分段,如图用户细分了三类。每一段需求进行分层,根据用户/客户情况,以公约数衡定基础需求和差异需求,如{1.1,1.2,1.3}为基础需求, {1.4,1.5,1.6}为差异需求。
基于基础需求、差异需求与标准用户与个性用户的二维度划分四个区域:基础性需求、临界满足区、专业低频区、专业吸引区。
- 基础性需求:是必要需求,需求优先
- 临界满足区:是衡量当下阶段是否足够,是否是未来的要求
- 专业低频区:是个性用户的基础需求,衡量是否需要满足或标准功能已能满足
- 专业吸引区:代表需求低频,却拥有很强的吸引力或溢价能力
需求的管理,是给每一个需求打上标签、分层分段,形成一个个需求篓子,把需求分门别类地放入。理论上,所有的有效需求都应该在一个篓子里,如果没有,要么篓子不够,要么篓子不对。
二、从需求管理到版本规划的五个步骤
1. 收集需求池养分
那么,不同行业不同产品,如何共性设计需求圈层 ?
从需求管理到版本规划,有五步骤:收集需求池养分、发现业务规律、建立产品原则、需求分段分层、架构搭建。
借鉴《需求池和版本树,相生相持,铺垫产品成就参天大树》中的模型进行改造升级,如图:
收集需求,说起来容易,好像无非就是把所有需求汇总到表格里,其实不然。
重点是:有足够数量的需求。一定规模、相对全面的需求池,是有效发现业务规律的重要前提。
1)产品策划阶段
需要依靠策划人进行大量调研、访谈工作。笔者负责会展SaaS产品时,前期大量调研访谈整整用了三个月。节奏最好是:由广及细,由浅到深,由客户主导到对客户引导。
2)产品迭代阶段
团队要建立需求获取流程:销售同学从市场与潜客中反馈需求,运营同学从客户中反馈需求,产品同学从竞品与商业目标中反馈需求,建立强劲、持续的需求反馈流程。
特别强调,需求获取的必要方式是体验客户业务。只有参与,才有体验、感知具体的温度。
笔者认为,卓越产品工作至少有1/3的时间,在市场那、在客户那,在前线听见炮声、看见炮火。
2. 发现业务规律
需求是基础,从需求中发现业务规律。
业务规律是观察、分析、解决业务问题的根本点,是产品设计的出发点。
任何一个行业、细分领域,都可以从三个角度共同完成剖析和衡量:特征与属性、业务规律、发展趋势。
- 特征属性:一个行业、一个业务、一件事物,都具有表象特征和客观属性
- 业务规律:规律是行业、业务、事务内部因素之间或与外部因素之间形成的关系
- 发展趋势:基于要素关系、业务规律,形成阶段性的事务演变和发展趋势
思考业务性质,洞察业务规律、绘制业务趋势,是核心工作,也是基本功。示意图:
3. 建立产品原则
当拥有业务趋势的理解后,基于发展趋势和业务规律,开始规划产品的行动指南。
产品原则又不仅仅全部依据业务,产品本身拥有产品特点、技术特点,要考虑在内。结合业务特点与业务趋势、产品特点与产品趋势,综合考虑产品的重点是什么,依次排序。
举例子,对某人工智能产品需求梳理和分析,发现产品当前还属于MVP阶段(未完成0-1),未形成对目标客户的价值性和适用性,以此设定当前阶段产品原则。
- 核心价值原则:语义模型的价值性需要大幅提升、产品易用性需要大幅提升
- 核心客户原则:聚集当前核心客户,不增加产品线
- 最快提升原则:梳理资源,找出成本最低、提升最快(价值)、客户最紧急的功能
- 场景适配原则:学校阅卷与自主作业的场景流程须重构,优化运营部门工作内容
产品原则是基于理解业务规律的基础上,形成具体的行动纲要,表现出:完整、系统、多维、互补、顺序。能够指导产品行为,体现在:做什么、不做什么、如何做。
4. 需求分段分层
当真正了解业务规律和产品规律之后,做需求分段分层是一件有趣且并不困难的事情。
举例子,对某物流SaaS产品需求梳理和分析,发现产品存在两类问题(技术问题、产品问题)和一类业务发展诉求(业务规律),设定当前阶段产品原则,以此重新归纳需求、分段分层,如图:
- 技术支撑原则:主干能够支撑主干,主干能够生长支干(技术问题)
- 业务完整原则:围绕着业务场景,流程梳理、功能做完整(产品问题)
- 业务发展原则:客户业务有其规律性,重新规划版本(业务规律)
- 价值性原则: 功能的底层要求,具备价值性,聚集核心价值、重构价值链(产品问题)
把需求分段分层的标准与市场同学进行沟通确认,市场同学在与客户沟通时,能做到心里有底有数,提升了市场同学获取需求的效率。
大家可以自行设计自家产品需求的圈图。
5. 版本规划和架构搭建
通常,需求经过分段分层,基本完成了短期的一个个版本规划,比如版本1{(1.1,1.2,1.3…) 、版本2{3.1,3.2,3.3,3.4,3.5}等等。
版本精准规划,能够大幅提升产品开发质量与速度,减少重复成本与时间成本。
在业务规律与产品趋势的理解和判断下,可以规划长期产品目标、设定产品架构和阶段性版本。
产品架构,最好一开始就要有,然后持续迭代优化,不断修正调整。产品架构对老板而言,使之了解方向与投入资源;对市场与销售团队而言,是了解进度和能够满足客户什么;对研发团队而言,是精准开发、快速迭代的利器。
总结回顾,本篇对收集需求、发现业务规律、建立产品原则、需求分段分层、版本规则与搭建架构五步骤做了整体描述说明。事实上,每一步骤还有很多的内容讲解和案例说明,篇幅有限,后续章节介绍。
本文由 @李斌 原创发布于人人都是产品经理。未经许可,禁止转载
题图来自Unsplash,基于CC0协议
本文由 @李斌 原创发布于人人都是产品经理。未经许可,禁止转载。
题图来自Pexels,基于CC0协议。
该文观点仅代表作者本人,人人都是产品经理平台仅提供信息存储空间服务。
“一定规模、相对全面的需求池,是有效发现业务规律的重要前提。”这句话说得有道理
以前看了不下十次这类型的文章,但实操起来还是另外一回事啊……
后续有产品实操与拆解〜
任何一款互联网产品都应该有一个产品架构,有了这个强大而坚实的架构作为产品的基础,才能将产品需求一个一个填充进去,让产品丰富立体。
[强][抱拳]