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 开始执行任务，提交后就去下一家门店继续巡检。等门店全部巡检完，再将每家门店存在的问题标注出来，提交并让店长完成整改。

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

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

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

三、总结

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

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

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

作者：空，公众号：小木盒产品记

本文作者 @空

版权声明

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