SaaS 产品经理:如何用“讲故事”的方式结合业务场景聊需求?

不知道作为 SaaS 产品经理,你有没有遇到过这些问题?

比如客户在使用系统的过程中,会提出各种需求,但实际上只是在向你传输解决方案。

再比如内部沟通时,如何向对方解释,你的思路虽然逻辑上成立,但实际业务场景下,客户并不是这样去做的。

前者是因为提炼对方表达后的关键信息,整合还原成真实的业务场景。而后者是因为在表达过程中,没有结合业务场景去描述需求。

而为了解决这类问题,SaaS 产品经理需要用场景描述的方式,给予对方强烈的代入感,便于双方基于业务去沟通。

接下来,我会结合工作中的一些思考与感悟,分享一个“讲故事”的方式,希望彼此能得心应手地聊需求。

一、回归业务场景,是做 SaaS 产品的起点

在讲故事之前,我们先来聊聊回归业务场景的重要性。

1. 首先是对外的沟通协调

产品经理如果想推进一个需求,需要和多个部门、多种角色频繁的交流,因此需要用一个双方易理解、贴近实际的沟通方式。

而基于业务场景的故事,就是通行于不同角色之间,解决产品问题的通行证。

这就好比梁宁老师说的,在腾讯内部如果想办成一件事,得不停地像念咒一样念用户体验。

本质是希望我们不要被个人的理解和视角所遮蔽,能站在对方的角度上提出解决方案。

2. 其次是对内的思考与分析

产品设计的过程是先发散后收敛,尤其是 SaaS 产品的设计,是基于整个业务链条进行设计。

因此在动手画原型、写文档之前,我们需要大量的调研、思考、分析,找出对方业务场景中的真实问题。

要知道,如果收集的信息不全,之前梳理的业务流程和原型,都会重新返工,费时费力。

3. 最后是整体产品的定义

业务脱离场景,即使逻辑上能成立,但终究不能称作产品,因为他不能解决问题。

SaaS 产品不同于C端产品,他们自己就是用户,甚至说可以通过想象力创造场景,达到引领用户需求目的。

比如通过摇一摇让彼此间陌生的人认识,进一步发生互动。虽然用户是有这种需求,但这种方式是被创造出来的,本身并不存在。

但 SaaS 产品的本质是解决企业的业务问题,而业务本身就已经存在,所以 SaaS 产品不能创造,只能还原。

到这里,你是否理解了业务场景的重要性,尤其是对 SaaS 产品来说。

接下来进入文章的主题,如何像讲故事一样描述场景

二、产品经理如何讲故事

这里介绍一种通用的场景描述方式,一是为了不遗漏关键信息,二是为了描述地更加丰满、立体,像故事一样。

如果用一句话来描述,那么就是:

产品经理,产品经理网站

接下来让我们逐步分析一下。

1. 场景描述七要素

(1)“谁”,某一个用户

指一个人或者说一种类型的群体。

对于 SaaS 产品来说,可以理解为业务流程的发起者。

(2)“环境”,在某一个特定的环境

这里的环境不仅是空间、材料等物理环境,也包括物质、时间等约束条件。

比如我们到点去食堂吃饭、放假去网吧开黑,不同的环境下会产生不同的动作,也会受到不同的限制。

(3)“时机”,出现某一个特定的时机

时机包括触发用户产生目标的事件影响用户行为的环境变化

比如在情人节跟女朋友逛街,突然看到有个小女孩在卖玫瑰,这时你会不会想买一束送给你女朋友呢?这主要受环境变化的影响。

接下来你跟你女朋友说了这个想法,她说“别浪费钱了,还不如去吃海底捞呢。”

此时,你会受到这句话的影响,思考晚上一起去吃点什么,这主要受到产生目标的影响。

(4)“目标”,带着某一个目标

也就是任务结束的停止条件。

当然,这个在生活中不会那么明显,因为我们做的事情会不断受到「环境」和「时机」的影响。

但在工作中,我们的目标(目的)都会很明确,比如我上午要对 10 个用户做用户访谈,那么这个目标完成后,这个任务也就结束了。

(5)“介质”,与某些介质

可能是另一个用户,也可能是一个事物。

比如我问你 234 × 298 等于多少?

你可能会拿起手边的计算器去算,也可能打开手机的计算器来算,告诉我答案是 69,723 。

特别说明在 SaaS 产品中,可以根据这个介质判断业务链中角色的相关方,从中找出受益方和受损方,避免丢失调研角色。

(6)“交互”,采取了一系列动作

简单、具体、为达成任务采取的方式。

比如点餐这个任务,通过手指点击(动作)点餐 pad(介质)完成操作。

(7)“任务”,通常是逐步进行的

目标是任务的总和,只有完成了多个任务,才能实现目标。

因此任务都是逐步进行,一个一个组合起来就是对应的流程图。

举个例子总结一下,先交代一下背景。

目前系统可下派周期方式为每日/每周/每月的周期性任务,默认从下个周期开始,比如今天是 3 月 18 号(周三),如果选择每日 16:00至18:00,那只能从 3 月 19 号的 16:00 至 18:00 开始。而选择每周周二,只能从 3 月 24 号(下周二)开始。

而现在的问题是,他们经常会紧急下派任务,让执行人完成并提交。

这里用上述七要素来描述:

小王是小组组长,每周需要按时下派任务,突然因为疫情,需要下派紧急的每日周期性任务,这时发现系统只能从第二天开始,所以只能再建一个普通任务,操作起来会非常麻烦。

2. 观察和验证你讲的故事

讲故事最容易出现的问题,就是借助自己的想象力,补全故事的细节。

这点对于 SaaS 产品经理来说,尤其需要警惕。

要知道, SaaS 产品的场景都是真实存在的,是需要在真实业务中去验证的,也就是在你描述完之后,别人是否有清晰的画面感。

如果对方觉得他实际工作中不是这么做的,那这个时候就需要警惕了,接下来需要进一步的跟进,去确定哪部分细节有问题。

举个例子:

小明是一名督导,上级安排他每周完成 10 家门店的巡检,当他到了某家门店后,打开 App 开始执行任务,提交后就去下一家门店继续巡检。等门店全部巡检完,再将每家门店存在的问题标注出来,提交并让店长完成整改。

这是我最初的理解,但后来才发现是我理解的有问题,实际上他们是边巡检边发起整改,提交后店长马上进行整改。

因为大多数情况,巡检多家门店不可能一天完成。

这就是我想当然地描述场景,造成业务理解上的偏差。

三、总结

因此在业务调研时如何能回归业务、梳理场景,最后以讲故事的方式与其他人沟通,这需要不断刻意的去训练。

这个过程,会不断培养提高我们对业务的理解。但这种理解是抽象的,而方法论只是一个拐杖,更重要的是我们在实践中加深自己的理解。

希望你我能都能借助这个拐杖,让这些方法论成为我们做事的习惯。

 

作者:空,公众号:小木盒产品记

本文作者 @空

版权声明

本文来自互联网用户投稿,文章观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如若转载,请注明出处。如若内容有涉嫌抄袭侵权/违法违规/事实不符,请点击 举报 进行投诉反馈!

相关文章

立即
投稿

微信公众账号

微信扫一扫加关注

返回
顶部