1

产品经理向“用户”学习

 1 year ago
source link: https://www.woshipm.com/pmd/5799757.html
Go to the source link to view the article. You can view the picture content, updated content and better typesetting reading experience. If the link is broken, please click the button below to view the snapshot at that time.
neoserver,ios ssh client

产品经理向“用户”学习

2023-04-08
0 评论 2208 浏览 8 收藏 18 分钟
释放双眼,带上耳机,听听看~!
00:00
00:00

产品经理的四大学习方法中,有向客户学、向先进学、向书本学、向自己学,其中“向客户学”这件事,很多人有不同的看法。本文作者结合自己的经验,表达了对于“向客户学”这件事的看法,希望能给你带来一些启发。

pm3Dxw3A9KUL5bhhN9Hv.png

最近我经常在不同场合提到产品经理的四大学习方式:向客户学、向先进学、向书本学、向自己学(出自王戴明老师)。其中“向客户学”(包含客户、用户)这件事,很多人有不同的看法。

大多数人支持这个观点,并且能够在工作中或多或少接触用户,但在与用户的连接中也经常出现一些问题;还有一些人反对这个观点,觉得用户思维和产品思维差距很大,即便不接触用户,也能设计好产品。

其中的对错众说纷纭,今天我也结合自己的经验,表达对于这件事的看法。全文共分为三部分:

  1. 为什么一定要接触用户?
  2. 如何吸收用户反馈?
  3. 如果接触不到用户怎么办?

因为前些年我的工作,是为一些大客户做私有化产品,大客户再把这个产品提供给他们的用户(B端企业为主),所以我日常接触的更多以客户为主,而非实际用户。

业内常说,产品经理需要经常面对用户,否则容易“自嗨”,而我在刚转岗产品阶段,很难真正接触用户,也会经常陷入类似的误区。因此,首先聊一聊产品经理为什么一定要接触用户?

一、为什么一定要接触用户?

如果长期不接触用户会有哪些风险和问题呢?我归类了以下五个方面。

1. 难以转化“用户思维”

产品思维和用户思维,本就是两个不同的方式。我们日常工作,更多是采用产品思维将场景整合起来,形成可执行的业务功能。

而为什么要有这些功能?这些功能帮助用户解决了什么问题?用户会不会使用这些功能?诸如此类的问题,都需要我们通过用户思维来验证。

不了解用户,就很难知道他在实际业务中做什么,想什么,进而很难换位思考,用同理心来评估现有的业务。

2. 容易陷入“自嗨”模式

产品经理偶尔也会有一些突发奇想,或者是产品上的创新点、交互上的新方式,亦或是对于业务衍伸的新思考。但是这些创新点到底是不是用户想要的呢?

之前我就遇到过一次盲目自嗨,对于一个新想法干劲十足,但后续和用户沟通之后,发现实际上他们并没有这个诉求,一方面因为监管政策的不明朗,另一方面也是因为实际业务中很少遇到对应的困境。

在产品社区,也经常看到有人写一些产品经理自嗨的问题,所以这一点也很容易理解。

3. 中转的需求不一定准确

虽然有时产品经理无法接触到用户,但是其他岗位会有机会。比如销售、运营,或者向我们这种大客户定制模式下,客户也会接触到用户,所以这些岗位也会定期向产品团队反馈一些用户声音。

而这些用户声音经过他们的中转之后,很可能就“变味”了。无论是对方添加了自己的思考和诉求,还是对方没有真正了解清楚用户的诉求,最终产品团队拿到一个二手信息之后,对应的方案也会有很大的偏差。

我下定决心写这篇文章,就是因为前段时间拿到的二手需求和用户实际诉求差异很大。当时我们针对二手需求进行了两周的方案设计,在最后和用户开会介绍方案时,才发现他们的实际诉求并不在此。

4. 需求洞察的源头容易跑偏

很多产品经理在入行时,或者换了新的赛道,对于所从事的业务没有很多的实际经验,虽说其他三种学习方式(向书本学、向先进学、向自己学)也能够让自己熟知业务,但毕竟向“一线”人员学习,才能真正了解到很多业务盲区。

如果没有发现这些业务盲区,真正在进行需求洞察时则容易跑偏。比如用户想通过这个功能解决洗手的问题,你却在这里摆放了一箱矿泉水,虽说能够满足需求,但并不是一个好的方案。

究其原因,大多数情况都是在需求洞察阶段,对用户需求背后的痛点做到足够的了解。

5. 不易构建“用户旅程”

其实,一个完整的产品设计流程,应该从实际的“用户旅程”开始,先构建基本的用户旅程地图,再梳理这个旅程中的“用户麻烦地图”,然后考虑如何通过产品设计解决这些麻烦。

所以,如果无法有效接触用户,接触有效的用户,那么这个“用户旅程”便很难梳理出来。

虽然分了五类,但其实很多现象都是相通的。而且在接触用户的过程中,很多用户并不能准确的把实际诉求说出来,因为他们缺少产品思维,只是在向你描述事实,而这些事实又是支离破碎的,建立在很多前提条件之下。

前段时间我也和用户有过沟通,针对一个业务场景交流了很多次,最后才把整个场景串起来。

所以,需要我们善于提问,善于发现,善于梳理和串联,才能最终把真正的业务现状,用户痛点准确洞察出来。

二、如何吸收用户反馈?

即便能接触到用户,用户的反馈真的对我们有利吗?或者说应该如何筛选、利用用户的反馈呢?在收集反馈之后应该注意哪些,以免深陷“用户思维”。

下面我来整理收集到这些“用户声音”之后,需要注意的几个方面。

1. 用户说的不一定对

虽说我们要经常向用户学习,但是他们说的内容也不一定都正确,所以我们一定要拥有一颗随时分辨的大脑。

因为每个用户都带有强烈的主观思维,并且经受了很大的环境因素影响。比如同一个行业,不同公司的流程千差万别,当你访谈几个用户之后,会发现大家说的都不太一样。同样的业务有的公司说可以做,有的公司说不可以做,那我们听谁的?

比如用户吐槽说某个功能不好用,可能是因为他恰巧用不到,也可能是他不喜欢里面的交互或者排版,还有可能是他之前用过类似的功能,因为没有达到预期,或给他的工作带来了不必要的麻烦,进而否定了类似的功能。

所以说,吸收用户的反馈很重要,辨别用户的对错更重要。

2. 用户说的不一定容易标准化

即便用户说的对,业务上也确实存在这个问题,但是这个问题真的能够在产品层面予以解决吗?解决这个问题可能会影响其他用户,也可能这仅是这一小部分用户的诉求。当然有些用户的反馈也极具“特色”,可能几类用户的诉求都不相同。

所以,有些用户反馈不容易做到标准化。

那么,对于这类反馈我们怎样解决呢?有些可能会采用“曲线救国”的方式,通过其他功能结合起来解决,虽然麻烦,但毕竟解决了;有些大客户的特色化,我们可能会单独维护一个版本,或者为大客户增加标签,让具有此类标签的用户使用这些功能;也可能置之不理。

但归根结底,我们需要分辨用户的场景是否可以标准化,或者是否可以通过配置化的形式解决。否则系统的版本越多,特色化功能越多,从业务架构和系统拓展性、易用性上都将受到不小的影响(当然,钱多的时候例外哈~)。

3. “防范”专家型用户的建议

有时候,我们会遇到“专家型”用户,他们对业务非常了解,或者对互联网软件很了解。他们也会站在产品设计的角度来审视这些功能,经常能够提出一些直击要害的问题。

但是,专家型用户的建议依然要注意防范,原因就是因为他们太专业了,反而忽略了普通用户的思维方式和使用习惯。而我们的产品受众,更多的是这些普通用户。

比如我在调研一些软件时,操作习惯一定是跳跃的,目光也一定是多变的。之前我和家人聊一款软件哪里哪里不好用的时候,我爸说:我觉得这个非常好用啊!

所以,专家的建议,需要认真思考,并代入普通用户思维来评判到底要不要采纳。

4. 更要洞察无法触达的用户

之前在整理用户调查问卷时,我一直在思考一个问题。就像“幸存者偏差”一样,收集上来的反馈,都是那些愿意反馈的用户,希望产品能解决他们问题的用户,相对忠实一些的用户。

而有时我们需要知道没有被调查到的用户在想什么。

比如他们为什么不愿意使用;是哪些问题导致他们流失;他们有没有觉得哪款竞品更好?而这些问题的答案,我们几乎无法得到,只能通过有限的反馈和调查、分析来推演。

因此,我们一方面在接纳用户的声音,辨别用户的声音,更要想办法“扩大”用户的声音,去寻找那些我们无法触达的用户,去寻找那些占比更多、更普遍的用户声音。

记得在几年前,我们的产品刚开始设计,每当收到一个大客户的反馈之后,自上而下都非常兴奋,像打了鸡血一样尽量的吸收这些意见。现在回顾起来,反而缺少了以上提到的对用户反馈的“过滤”和“标准化”。

三、接触不到用户怎么办?

虽然说了这么多和用户对接的利弊,但仍然会有很多同行苦于无法接触到用户。最后,针对这个问题我来整理自己的建议:

如果在平时的工作中很难接触到用户,应该怎么办?

1. 主动沟通

职场上,解决大多数问题的第一要义便是主动沟通,通过向领导表达自己的想法和意愿,看看是否能够得到支持。如果你不主动,即便有机会,很多时候也轮不到自己。

沟通之后,即便短期内没有机会,这也是一个向上管理的方法,领导也可能会给你一些其他的建议,而这些建议,大多数也都是比较真诚和实用的。

2. 寻找推广、路演机会

一款产品在经历市场化的阶段,一定会有很多机会与客户、用户接触,之前我们的产品团队也协助过售前、运营等团队进行产品宣讲、客户路演、产品推介会之类的活动,其中不乏优质用户参与。

当出现这些机会时,无论是主动请缨,亦或是事后打听,都能得到很多用户声音和对接感受。

3. 协助客户调研

像我们这类大客户定制化模式,产品交付之后,客户也需要进行产品调研和推广,这时我们可以和甲方的业务负责人沟通,协助他们进行客户调研和产品推广,大多数客户都很很乐意产品团队帮忙(前提是要和自己的领导沟通好,因为很多时候这类推广是要另算费用的)。

4. 寻找关键人

有时即便不能直面用户,但是能找到一些业务上的关键人,也能够弥补很多信息差。

比如产品团队中的“老油条”、自己的工作导师、直属领导、客户方的业务负责人、运营同事、售前同事等。这些关键人即便没有在一线工作,但势必也和实际的用户有过很多对接,同时对产品所涉及的领域、场景有更深的认知。

其实,这一点依然是之前提到的四大学习方法中的“向先进学”,这里的先进即包含了先进的竞品,也包含了先进的前辈

5. 观察自己的领导

最后,我们可以更多的观察自己领导的成长轨迹。他的成长轨迹,也许是自己未来的发展方向。

我们可以通过观察领导如何学习业务知识,如何分辨用户反馈,如何规划产品方向,如何引导用户说出自己想要的答案。

其实,每个职场人的身边都不乏有经验的大佬,但是因为深陷其中,或者因为同事这层关系从中作梗,让我们无法客观的了解这些人的水平,也很难获取这些人的经验。

不过,这些问题,实际上都是“自我设限”。当自己真的拥有明确的目标,善于观察和分析,善于寻找破解的方法,这些问题也都能够逐一解决。

毕竟,产品经理没有不面对用户的,无论是直接还是间接,无非是主动或是被动。

四、写在最后

因为我只具备0-1和1-10的经验,真正在产品运营、用户调研、产品推广等层面缺少实际的工作经验。

以上内容均来自近几年的经验和思考,可能存在偏差和不足,希望各位有缘看到这里的朋友们可以结合自身的实际情况辩证性的吸收借鉴,如有不足之处,烦请指正,不胜感激。

产品经理的工作,是一个多元而复杂的综合任务,很多事都要考虑,很多事都要面对,并不是单纯的做设计、做规划。接触用户、了解用户才能为后期的合理性设计构建地基。

很多产品同行不愿意面对用户,要么是因为繁琐、要么是因为问题难以解决,当然也有可能是因为自己内心的恐惧与不自信。

可是无论出于什么原因,“向用户学习”的这一关,迟早要过,祝大家“过”得顺利!

专栏作家

不想延期,公众号:不想延期,人人都是产品经理专栏作家。半路转行的B端泛金融产品,坚持“以实践验证理论,以输出倒逼成长”的目标。点滴珍贵,重在积累

本文原创发布于人人都是产品经理,未经许可,禁止转载。

题图来自 Unsplash,基于CC0协议。

该文观点仅代表作者本人,人人都是产品经理平台仅提供信息存储空间服务。


About Joyk


Aggregate valuable and interesting links.
Joyk means Joy of geeK