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

　　本篇文章通过SaaS产品经理在工作中的思考与感悟，让人们了解如何以讲故事的方式与人沟通，从而更好地描述需求与接收需求，认识到回归业务场景的重要性。
　　不知道作为SaaS产品经理，你有没有遇到过这些问题？
　　比如客户在使用系统的过程中，会提出各种需求，但实际上只是在向你传输解决方案。
　　再比如内部沟通时，如何向对方解释，你的思路虽然逻辑上成立，但实际业务场景下，客户并不是这样去做的。
　　前者是因为提炼对方表达后的关键信息，整合还原成真实的业务场景。而后者是因为在表达过程中，没有结合业务场景去描述需求。
　　而为了解决这类问题，SaaS产品经理需要用场景描述的方式，给予对方强烈的代入感，便于双方基于业务去沟通。
　　接下来，我会结合工作中的一些思考与感悟，分享一个“讲故事”的方式，希望彼此能得心应手地聊需求。
　　一、回归业务场景，是做SaaS产品的起点
　　在讲故事之前，我们先来聊聊回归业务场景的重要性。
　　1。首先是对外的沟通协调
　　产品经理如果想推进一个需求，需要和多个部门、多种角色频繁的交流，因此需要用一个双方易理解、贴近实际的沟通方式。
　　而基于业务场景的故事，就是通行于不同角色之间，解决产品问题的通行证。
　　这就好比梁宁老师说的，在腾讯内部如果想办成一件事，得不停地像念咒一样念用户体验。
　　本质是希望我们不要被个人的理解和视角所遮蔽，能站在对方的角度上提出解决方案。
　　2。其次是对内的思考与分析
　　产品设计的过程是先发散后收敛，尤其是SaaS产品的设计，是基于整个业务链条进行设计。
　　因此在动手画原型、写文档之前，我们需要大量的调研、思考、分析，找出对方业务场景中的真实问题。
　　要知道，如果收集的信息不全，之前梳理的业务流程和原型，都会重新返工，费时费力。
　　3。最后是整体产品的定义
　　业务脱离场景，即使逻辑上能成立，但终究不能称作产品，因为他不能解决问题。
　　SaaS产品不同于C端产品，他们自己就是用户，甚至说可以通过想象力创造场景，达到引领用户需求目的。
　　比如通过摇一摇让彼此间陌生的人认识，进一步发生互动。虽然用户是有这种需求，但这种方式是被创造出来的，本身并不存在。
　　但SaaS产品的本质是解决企业的业务问题，而业务本身就已经存在，所以SaaS产品不能创造，只能还原。
　　到这里，你是否理解了业务场景的重要性，尤其是对SaaS产品来说。
　　接下来进入文章的主题，如何像讲故事一样描述场景。
　　二、产品经理如何讲故事
　　这里介绍一种通用的场景描述方式，一是为了不遗漏关键信息，二是为了描述地更加丰满、立体，像故事一样。
　　如果用一句话来描述，那么就是：
　　接下来让我们逐步分析一下。
　　1。场景描述七要素
　　（1）“谁”，某一个用户
　　指一个人或者说一种类型的群体。
　　对于SaaS产品来说，可以理解为业务流程的发起者。
　　（2）“环境”，在某一个特定的环境
　　这里的环境不仅是空间、材料等物理环境，也包括物质、时间等约束条件。
　　比如我们到点去食堂吃饭、放假去网吧开黑，不同的环境下会产生不同的动作，也会受到不同的限制。
　　（3）“时机”，出现某一个特定的时机
　　时机包括触发用户产生目标的事件和影响用户行为的环境变化。
　　比如在情人节跟女朋友逛街，突然看到有个小女孩在卖玫瑰，这时你会不会想买一束送给你女朋友呢？这主要受环境变化的影响。
　　接下来你跟你女朋友说了这个想法，她说“别浪费钱了，还不如去吃海底捞呢。”
　　此时，你会受到这句话的影响，思考晚上一起去吃点什么，这主要受到产生目标的影响。
　　（4）“目标”，带着某一个目标
　　也就是任务结束的停止条件。
　　当然，这个在生活中不会那么明显，因为我们做的事情会不断受到环境和时机的影响。
　　但在工作中，我们的目标（目的）都会很明确，比如我上午要对10个用户做用户访谈，那么这个目标完成后，这个任务也就结束了。
　　（5）“介质”，与某些介质
　　可能是另一个用户，也可能是一个事物。
　　比如我问你234298等于多少？
　　你可能会拿起手边的计算器去算，也可能打开手机的计算器来算，告诉我答案是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开始执行任务，提交后就去下一家门店继续巡检。等门店全部巡检完，再将每家门店存在的问题标注出来，提交并让店长完成整改。
　　这是我最初的理解，但后来才发现是我理解的有问题，实际上他们是边巡检边发起整改，提交后店长马上进行整改。
　　因为大多数情况，巡检多家门店不可能一天完成。
　　这就是我想当然地描述场景，造成业务理解上的偏差。
　　三、总结
　　因此在业务调研时如何能回归业务、梳理场景，最后以讲故事的方式与其他人沟通，这需要不断刻意的去训练。
　　这个过程，会不断培养提高我们对业务的理解。但这种理解是抽象的，而方法论只是一个拐杖，更重要的是我们在实践中加深自己的理解。
　　希望你我能都能借助这个拐杖，让这些方法论成为我们做事的习惯。