时间: 2021-07-30 11:28:08 人气: 5 评论: 0
本篇文章通过SaaS产品经理在工作中的思考与感悟，让人们了解如何以讲故事的方式与人沟通，从而更好地描述需求与接收需求，认识到回归业务场景的重要性。
不知道作为 SaaS 产品经理，你有没有遇到过这些问题？
比如客户在使用系统的过程中，**提出各种需求，但实际上只是在向你传输解决方案。
再比如内部沟通时，如何向对方解释，你的思路虽然逻辑上成立，但实际业务场景下，客户并不是这样去做的。
前者是因为提炼对方表达后的关键信息，整合还原成真实的业务场景。而后者是因为在表达过程中，没有结合业务场景去描述需求。
而为了解决这类问题，SaaS 产品经理需要用场景描述的方式，给予对方强烈的代入感，便于双方基于业务去沟通。
接下来，我**结合工作中的一些思考与感悟，分享一个“讲故事”的方式，希望彼此能得心应手地聊需求。
在讲故事之前，我们先来聊聊回归业务场景的重要性。
产品经理如果想推进一个需求，需要和多个部门、多种角色频繁的交流，因此需要用一个双方易理解、贴近实际的沟通方式。
而基于业务场景的故事，就是通行于不同角色之间，解决产品问题的通行证。
这就好比梁宁老师说的，在**内部如果想办成一件事，得不停地像念咒一样念用户体验。
本质是希望我们不要被个人的理解和视角所遮蔽，能站在对方的角度上提出解决方案。
产品设计的过程是先发散后收敛，尤其是 SaaS 产品的设计，是基于整个业务链条进行设计。
因此在动手画原型、写文档之前，我们需要大量的调研、思考、分析，找出对方业务场景中的真实问题。
要知道，如果收集的信息不全，之前梳理的业务流程和原型，都**重新返工，费时费力。
业务脱离场景，即使逻辑上能成立，但终究不能称作产品，因为他不能解决问题。
SaaS 产品不同于C端产品，他们自己就是用户，甚至说可以通过想象力创造场景，达到引领用户需求目的。
比如通过摇一摇让彼此间陌生的人认识，进一步发生互动。虽然用户是有这种需求，但这种方式是被创造出来的，本身并不存在。
但 SaaS 产品的本质是解决企业的业务问题，而业务本身就已经存在，所以 SaaS 产品不能创造，只能还原。
到这里，你是否理解了业务场景的重要性，尤其是对 SaaS 产品来说。
接下来进入文章的主题，如何像讲故事一样描述场景。
这里介绍一种通用的场景描述方式，一是为了不遗漏关键信息，二是为了描述地更加丰满、立体，像故事一样。
如果用一句话来描述，那么就是：
接下来让我们逐步分析一下。
（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 号（下周二）开始。
而现在的问题是，他们经常**紧急下派任务，让执行人完成并提交。
这里用上述七要素来描述：
小王是小组组长，每周需要按时下派任务，突然因为疫情，需要下派紧急的每日周期性任务，这时发现系统只能从第二天开始，所以只能再建一个普通任务，操作起来**非常麻烦。
讲故事最容易出现的问题，就是借助自己的想象力，补全故事的细节。
这点对于 SaaS 产品经理来说，尤其需要警惕。
要知道， SaaS 产品的场景都是真实存在的，是需要在真实业务中去验证的，也就是在你描述完之后，别人是否有清晰的画面感。
如果对方觉得他实际工作中不是这么做的，那这个时候就需要警惕了，接下来需要进一步的跟进，去确定哪部分细节有问题。
举个例子：
小明是一名督导，上级安排他每周完成 10 家门店的巡检，当他到了某家门店后，打开 App 开始执行任务，提交后就去下一家门店继续巡检。等门店全部巡检完，再将每家门店存在的问题标注出来，提交并让店长完成整改。
这是我最初的理解，但后来才发现是我理解的有问题，实际上他们是边巡检边发起整改，提交后店长马上进行整改。
因为大多数情况，巡检多家门店不可能一天完成。
这就是我想当然地描述场景，造成业务理解上的偏差。
因此在业务调研时如何能回归业务、梳理场景，最后以讲故事的方式与其他人沟通，这需要不断刻意的去训练。
这个过程，**不断培养提高我们对业务的理解。但这种理解是抽象的，而方法论只是一个拐杖，更重要的是我们在实践中加深自己的理解。
希望你我能都能借助这个拐杖，让这些方法论成为我们做事的习惯。
作者：空，公众号：小木盒产品记
本文由 @空 原创发布于人人都是产品经理，未经作者许可，禁止转载
题图来自 Unsplash，基于CC0协议
