当前位置:首页 > 网络营销 > 正文

一个会“说人话”的产品经理有多重要?

这里大家都是产品经理【起点学院】,BAT实战产品总监会一步步指导你学习产品和运营。

我经常听到有人讲理论几十分钟,却被告知“像人一样说话!” 窒息了。 以前这个场景多是“技术-产品”,现在更多的是“产品-运营”。 原因如下:

大多数技术都是通过产品来连接的,运营更多的是面对不同的产品逻辑思维。 产品思维是基于多个视角,结合产品逻辑、商业形态、商业前景等。运营是更多价值的焦点,包括某个活动、某个场景、一群人、需求等。产品经理嚣张这种情况在初创公司比较常见,也是因为相应的运营没有足够的经验。 具体视角的差异与逻辑思维的差异不同,例如:

喵:我想在国庆期间添加特殊标签,以增加用户活跃度。

Dog:专用标签有哪些形式? 有哪些应用场景? 预计每日活动量会增加多少? 时间点是什么? 您是否考虑过使用常规标签来满足您的需求? 那么为什么不一起优化普通标签呢?

喵:。 。 。说英语

往往就没有更多了!

这应该是每个产品经理都会遇到的问题,因为产品经理本身就被赋予了更多的使命,要更多地思考,更多地架构,充当运营和技术需求的润滑剂。 过滤需求、完整需求、规划需求!

产品经理如何讲人类语言?

我们先从产品迭代开始。 产品迭代涉及需求收集、需求分析、产品定型、需求评审、里程碑、测试验收、产品发布等,发现运营只在“需求收集”的第一步发挥作用,需求来源包括:用户、运营、产品、BOSS等。

早期的创业公司总是先从产品开始,发展到一定阶段之后再通过运营来驱动,所以每次迭代通常都是一个大的功能+小的用户需求和优化。

技术和测试完成后,我们通常会召开内部“产品发布会”,在大电视前展示迭代添加和优化的功能。 发布会总是顺利举行! ! !

产品上线后,PM开始了新一轮的需求收集,Meows也开始操作当前的产品功能(产品运营),但总是发现运营不了解产品的功能,会反复询问操作过程中出现的问题。 产品!

我当时很无奈,回应就是每次版本迭代更新《产品运营规则文档》。 我记得当时后台的文档有8000字长。 后来发现效果还是不好,所以干脆更新了需求文档(PRD)。 也复制到操作中。 之后我们开始邀请运营参与需求审核!

直到。 。 。

“你会说人类语言吗!”

什么是人类语言?

我自己也思考了很久,和BOSS沟通后,得出以下几点:

运营需要承担自己的责任。 产品不应该到处主导运营。 手术不应该被视为婴儿。 尽可能地,运营就是产品,产品就是运营。

我改变了和运营沟通的方式,进行了更多的交流。 我放弃了《产品操作规则说明文件》和PRD文件的“死人”沟通,尽量面对面。 在通信的基础上,我补充了功能。 更新描述(以最简单的方式说明该功能)。 喜欢:

XXX APP2.3版本更新内容:

经过进一步的沟通和比较,我们发现运营对这样的运营更容易接受和感兴趣。 另外,验收时邀请操作人员参与,也能增加操作人员对功能的兴趣和了解。

当操作需要时

这些是非运营提出的要求对他们的影响。 如果一个功能或者bug类是运营提出的,那么大场景就不一样了!

会有两种情况,区别在于操作的注意点:

A类:高度关注。 比如,如果你想配合某个活动或者场景提出的功能,喵甚至会热切地参与到测试和验收过程中,让你有足够的时间做好运营准备。

B类:主要收集Bug和优化意见。 说操作不注意也没有错。 主要原因是猫在提出各种问题后处于“弱记忆区”。 在遇到提出问题的对应场景之前,基本上不会再提出。

对于A类,赋予运营更多的参与感。 对于B类,我的应对措施是:产品问题记忆表

这是我在12.23收集的一些要求。 需求列表经过N次迭代后,字段被划分为以下维度:日期、提交者、类型、紧急程度、业务价值、描述、场景、可能原因、是否满足、计划、完成时间、问题、状态。

这些字段要根据每个公司的不同情况进行增减。 对于许多公司来说,这种表格是由请求者直接填写的,有些是卡片格式的,有些是通过电子邮件填写的。 方法没有限制。 请找到最合适的一个。 贵公司如何运作。

录制的步骤还没有结束。 最重要的是跟踪需求和反馈。 如果需求得到满足,你就是这个需求的项目经理。 您需要负责跟踪。 需求确定后,还需要通知猫接受并接受反馈(一个阶段后“需求满足度”可以提高)

如果不能满足要求的,需要向对方说明不满足的理由或者其他说明。

第三点、故事描述

故事描述原本是产品经理解释技术功能的一种方式。 由于思维方式不同,普通的产品描述技术可能无法理解他们,因此将他们带入场景中,从用户的角度发现问题并提出解决方案。 。

这也适用于产品 → 操作

对故事描述的接受度和理解力远远大于其他描述方式,所以PM需要成为一个“讲故事的人”。

以上三点其实就是个人在实际场景中遇到的问题的解决方案。 由于我是出差,描述可能不太到位,观点更多是针对小型或者创业型公司。 成熟的企业已经有标准化的流程和操作。 我们也有能力、有经验,所以不需要更多的担心,我们需要更多的灵活性。 我见过一些公司甚至放弃产品原型和PRD文档来进行敏捷开发。 除了团队之外,大部分都是产品经理带头的。 沟通。

不同公司的问题会以不同的方式被放大和缩小。 切勿简单套用其他团队的沟通方法。

从人类的角度来看,这并没有那么神秘! 这是关于人、情感和理性的。 PM除了是一名优秀的产品设计师和负责人之外,还是整个企业组织的连接者和驱动者。 因为你是整个组织的中心,所以有更多的开放和降低。

请记住,PM 无处不在!

本文最初由@青团社-强子(微信GXQ22222)发表在《人人都是产品经理》上。 未经许可禁止转载。

0
收藏0

最新文章

随机文章

取消
扫码支持支付码