什么是产品思维?
创新区别于领袖和跟随者的唯一标志是思维的不同。
—— Steve Jobs
当我们谈到产品思维的时候,我们会想到什么?是以用户为中心的理念,强调数据驱动或团队协作,还是要求具备逻辑和创新的思考方式或者项目管理能力?
人脑的思维是科学界一直在探索的方向,思维尚没有明确的定义,互联网产品思维也是一样,缺乏概念上的洞察。在许多书籍和文章中,产品思维被认为包括:“对用户需求的深刻理解、快速迭代的能力、对数据的敏感度以及对市场趋势的适应能力。”
而对于产品经理这个角色来说,“产品经理需要结合战略性、用户导向、分析、创新、技术理解、沟通、项目管理、领导力和适应性等多方面的思维方式。”
按照这些观点来看,似乎产品经理 像是一个全能角色,但全面也意味着缺乏重点,总不能说产品思维就是全部,产品经理就是先知吧?
或者我们换一种问法,在产品思维中,什么是最重要的?
产品思维,可以被理解为一种深入挖掘问题本质并重新组织生产力的策略。对于互联网产品来说,产品思维的核心在用户中心性、创新和适应新技术、战略和前瞻、解构和抽象思维、明确焦点这五个方面。
这五个方面共同构成了一个强大的产品思维框架,它强调用户中心、创新、战略性、解构能力和简洁性。产品经理通过运用这些原则,可以设计出既满足当前需求又能适应未来变化的成功产品。
用户中心性
用户为什么“不存在”?
产品设计避不开的话题总是用户。大到商业计划书,小到几句话的需求,产品经理总会被问到:你的用户在哪里?用户需要什么?你的产品能满足用户需求吗?用户愿意为你的产品付费吗?... 无论技术如何发展,用户需求始终是产品设计和发展的核心。理解并满足用户的需求、痛点和期望是产品成功的关键。
但理想很丰满,现实很骨感。现在大部分互联网产品经理都充当大厂螺丝钉的角色,情况大概是上级说什么我就做什么。用户需求也有用研部门进行搜集整合,或是由市场团队或销售团队(例如企服 Saas)直接对接。对于坐在电脑面前,盯着原型图和 产品文档的产品经理们来说,用户好像 “不存在” ?
我很早之前就意识到了这个问题。在恶补产品经理相关知识的时候,书中总会提到 “用户” 这个词。那个时候对用户不甚理解,也不在乎。原型和需求都搞不定呢,还担心用户干嘛??没错,我当时就是这样想的 /汗颜..
我从未见过 “活着” 的用户。每当上级让我去搜集用户观点的时候,我会去翻不同产品的评论,看他们想要什么,讨厌什么,然后记录,形成需求。用户对我来说更像是一则评论,一条数据。我可以在数据看板知道用户在干什么,点击了哪些按钮,浏览了哪些页面,匆匆下一个结论并形成需求。
那么,有哪些方式能够帮助我们快速找到用户呢?
寻找用户,发现需求
- 从场景中寻找用户
找到用户,首先要成为用户。
假如团队正在做一款健身 App,身为产品经理的你要如何找到用户?一个比较简单的方法是 “成为用户”。假设我现在是一名健身小白,我有很强的意愿要开始锻炼。我会到哪里去寻求帮助,是选择线上还是线下咨询?
如果选择在线上咨询,我可能会在哔哩哔哩或者小红书寻找攻略,因为我认为锻炼很难在短时间内出成绩,需要长期坚持,看一些真正有益的内容;如果选择在线下咨询,我会在公司或家附近寻找提供有低价体验课程的健身房,并让专业的健身教练指导我进行训练。
那么,一个用户最终可能会在这些渠道中留下痕迹,我们可以从这些应用中寻找用户,了解用户需要什么。
- 发现用户需求
在刷完健身视频后,我都会下意识地浏览评论区。在其中出现最多的就是:
- 我身高xxcm,体重xxkg,尝试过锻炼,但肚子上脂肪很难减,应该如何瘦下来?
- 我体脂xx%,跟练了许多视频,但最终没有效果,有没有科学的减脂方法?
- 练胸的话,一般推荐几组?如果力竭的话,是继续维持RM,还是做递减组呢?
- 刚开始锻炼,需不需要喝蛋白粉呀?增肌粉和肌酸每天应该吃多少呢?
- 锻炼3年,目前对身材很满意,但想要突破平台期,应该怎么做?
有没有发现这类用户提问的特点?他们通常处在不同的场景,有着不同的需求。例如增肌,减脂,饮食等等。我们在收集评论之后,就可以进行解构和抽象。
比方说,从上面提到的诸多 问题中可以解构(拆解)出许多关键字,例如:
完成拆解之后,接下来要做的是进行抽象。通过抽象,我们就能组合起用户需求。例如将身高、体重、体脂率归入人体基础指标,将锻炼组数、力竭、RM、递减组,归入锻炼细节。以此类推,我们还能抽象出锻炼时长、锻炼目的等模块。
这样一看,平台上关于健身锻炼的问题,其实就可以归纳为基础信息、锻炼计划和健身饮食三个方面。用户的逻辑也比较容易理解,即用户会提供一些基础信息,需要有人帮忙制定锻炼和饮食计划。当然,这里还有非常多的模块,例如健身工具、锻炼激励等,都可以通过解构和抽象的方式来匹配用户的实际需求。
以上,大部分的用户和需求,都可以通过 “让自己成为用户” 这个方法去发现。在《启示录》等许多产品书籍中,还提到了用户访谈,产品测试参与等许多方法,这里暂不展开。关于用户行为数据分析的部分,在如何做好埋点设计中我会进行讲述。这些方法都能帮助我们更好地了解用户。
创新和适应新技术
新技术对于社会的改变是迅猛的,但人对于新技术的反应却很容易滞后。
你还记得支付宝是在哪年推出的吗?或者说你有没有突然感叹,发现移动支付好像无处不在了?作为产品经理,不仅需要紧跟当前技术,还需要预见未来技术的发展,利用新技术解决用户问题。
技术改变了什么?
让我们把时间往前推,回到互联网还没有诞生之前,那个时候,我们获取信息(主要是书籍)的方式有两种:
- 通过邮局预定或者购买
- 在线下书店、报摊购买
对书籍出版感兴趣的小伙伴可以听听这期播客:👉 E22 孟岩对话读库老六:大多数人选择成为大多数人
如果将这种预定或购买书籍的形式理解为信息的流转过程,可想而知,数据的传输速度是相当慢的,动辄需要 1~2 个月。
当互联网出现之后,互联网技术提升了二进制数据的传输速度。传输协议和传输工具的出现,几乎颠覆了我们对于信息的获取方式。
直至现在,我们还能持续发现新的应用场景来进一步放大这种传输能力的价值。例如现在很常见的云服务、云储存以及云游戏(云原神,启动!)。在现在 5G 移动通信技术的普及下,仍还有许多场景值得探索。例如远程医疗、智能驾驶、智慧城市等。
再举个例子。以往你需要去到线下菜市场或者超市,对比不同商店的价格、选择蔬菜,这个过程可能需要耗费 1~2 个小时,最终才能买好一日三餐所需要的食材。现在将传统线下对比选购的形式转换成线上浏览、比价下单、外卖到家的方式,大大节约了买菜的时间,同时生鲜的价格和质量还能得到保障。
抓住技术出现的时刻
当闪电打下来的时候,你最好在场。
——查尔斯·艾里斯
回想一下上面我提到的问题,你是什么时候意识到这些新技术的出现?还是等到这些技术改变环境之后你才发出感叹呢?
之所以要提到这个问题,是因为新技术的诞生只出现在 极少数的时刻。例如今年爆火的 ChatGPT,有不少开发者在第一时间开发了微信公众号和小程序的应用,获得了可观的流量和收入。我想说的是,当机会来临时,产品经理需要奔跑在潮流前沿,不断思考新技术的使用场景,以及它是否能够解决传统难题,解放生产力。
例如我在 ChatGPT 走红以后,就根据现有知识写了一份PPT,还搭建了一个知识库。付费体验 GPT-4 之后,将问答功能结合到了上一家的产品设计当中。
技术的发展是一个长期的过程,我们并不知道技术革命会在什么时候发生。就好像 AI 技术在上世纪 50 年代便已经提出,但普通用户认识到 AI 技术的力量也只是近期的事情。这要求产品经理要紧盯所在领域的技术变革,抓住机会,确保 “雷能劈到你”。
列举其他一些我印象深刻的新技术应用:
- 电子书:网络资源加上阅读器(例如微信读书)能够实现零成本阅读
- ChatGPT:几乎影响了所有需要文字编辑的行业,不同程度地实现了降本增效
- 共享单车:解决了最后一公里的出行难题,让出行更加环保
- 链家:真房源的理念颠覆了当时黑中介和假房源频出的租房市场
- iPhone:Apple 率先推出的触摸式交互,变革了人机交互的底层逻辑,提高了交互效率
战略性思维
我,一名普通产品经理,在工作中几乎不被要求具备战略性思维。这些事情似乎高屋建瓴,应该是高管或者老板们该考虑的问题。但是战略性思维为什么成为了产品经理最需要的宏观思维?这在于:
未来才是决定产品能否存活的关键。战略性思维关乎如何理解未来市场的变化,如何预测未来的需求。
产品经理有一项必备能力,叫做数据分析。许多公司都重视数据分析,认为数据分析能够带来所有问题的答案。但是数据分析的结果只能反映过去发生了什么,过去做的事情带来了哪些结果,而并不能预测未来。如同证券交易中的技术分析,数据分析是面向过去的解释,而不能改变未来。
除了回顾和改进,产品经理更重要的能力在于预测。设想未来市场的变化,容量有多大,是否有机会等等。对于自己所负责产品或功能,也能通过战略性思维理解产品背后的业务和市场。
对于预测,我举一个极端的例子:
在车机领域,中控台产品经理被要求需要面向 4 年(48 个月)后的用户需求进行设计,因为一个车型从立项到量产,往往需要 4~5 年的时间。
如果车机仅面向当下进行设计,等到新车上市之后只能等待淘汰。面向未来开发已然是车企的共识。例如早期的宝马的 iDrive、福特的 Sync 以及奥迪的 MMI 系统,这些车机系统在初期都遭受了许多非议,但很少是因为系统过于陈旧 而带来的批评。
知道战略性思维的重要性后,下一个问题就是如何培养战略性思维。我认为有两个简单的方法是产品经理能够快速上手的:
1、理解业务和市场环境
深入了解你所在行业的市场趋势、竞争格局、客户需求以及技术变革。这可以通过阅读行业报告、关注竞品和竞争对手来实现。举例来说,我从事的券商软件领域就需要知道以下几个方面:
- 竞品有哪些,它们占据了多少市场份额?相对于竞品,我们的产品市场情况如何?
- 龙头产品做了(可能)导致成功的设计,落后的产品做了什么(可能)导致失败的设计?
- 竞品的功能主要有哪些?哪些做得很优秀,哪些是用户喜欢的,哪些是我们没有的?
- 产品采用的技术架构是什么?他们是否采用了敏捷方法,产品迭代更新速度是否迅速?
2、尝试从高层次看问题
尝试从一个更高的视角来看待日常工作。这意味着不仅仅关注产品的具体功能,而是要理解这些功能如何帮助公司实现其更广泛的目标。
在前公司任职的时候,突然有一天老板开始关注金条业务,并准备开展相关的业务。前公司从事的业务虽然和贵金属相关,但在后期逐渐朝期货转向,为什么在那一刻突然做金条(一般等价物)业务呢,我百思不得其解。是期货业务做不下去了吗?
思考:
- 1、为什么做业务转型?是原先的期货业务无法继续开展了吗?
- 2、公司从来没做过 online and offline 的业务,开发团队能支持吗?
- 3、业务需要耗费大量人力和资金,预期收支似乎没法平衡
如果仅从 ROI 或者当前业务的拓展方向去考虑,可能你也会得出和我类似的结论,无法理解老板们的决定 。但后来从宏观的视角去看这次调整,就比较容易发现做这次转型的原因:
以上列举的原因可能有所偏颇,仅作为示例。我想要强调的就是多从宏观视角去看问题。即便针对业务列举的宏观原因看起来有点不靠谱,或者觉得离当前公司和业务太远了都没有关系。尝试用 “设想 - 验证” 的方式去解构业务会很有帮助。
PS:一开始我觉得上面这些理由完全构不成业务转型的理由,现在只能说老板们眼光毒辣...
重构思维
如果你解构希腊,最终你会看到一棵橄榄树、一株葡萄藤和一艘船留下。正是有了这些,你才能重建。
——奥德赛·埃利蒂斯(Odysseas Elytis)
在对复杂事物进行解构、抽象和重组的过程会直接它的本质,将其分解为便于理解的状态。这意味着我们能够以创新的方式重组它们。解构是为了更好的构建。
如何进行解构和重组?
解构、抽象和重组,这种思维其实一直出现在我们身边。例如在高中,写作文的流程通常由审题、分析构思、重新描述组成。我们对作文题目的 “审题” 就是一种解构,将命题人的意图转化为格式完整的文章,则是抽象和重组的过程。
培养这种思维,要求产品经理需要保持好奇心和优化意识,观察生活中的许多现象,思考这些现象背后的原因,进而去拆解对象,删除无用低效的环节,重新组成成有效的新对象。比方说,运营部门提出了一个活动海报设计的需求,设计部门进行设计,但是一直被运营部门打回,最终耗费了大量时间才完成了海报设计。
这里面可能存在沟通的问题,但更多地还是需求不明确带来的反复修改。我们利用解构、抽象和重组的思维简单地进行拆解,问题就能轻易解决。
可能一开始并没有很多机会去拆解工作上的业务,但是可以通过解构、抽象、重组自己的日常生活、学习和工作进行练习。
1、解构、抽象和重组生活
2、解构、抽象和重组工作流程
重构的重要性
强调重构(解构、抽象和重组)思维,其实更是在强调产品思维的重要性。
开始这个小节之前,先来看这三个场景:
- 用户想要将微信通讯录按联系频率联系,产品经理二话不说开始提需求。
- 家里的小孩子半夜哭闹想要吃饼干,爸妈拿了面包给宝宝吃后,小孩子安然睡去。
- 中学生自行归纳出一份 “秒解公式” ,结果考试中很少有题目能符合公式的要求。
第一个场景,我相信很多产品经理都遇到过。我们采取的方式也很简单粗暴,用户提什么,我们做什么。产品经理在接收需求的时候,会图懒,用户说什么就做什么,思考需求的必要性似乎格外没有意义。A 需求不做,还有 BCDEFG 等着你。这种思维比较危险,这暗示你抛弃了思考,选择了执行。但对产品来说最重要的事情不是执行,不是画原型、写流程、找方法,而是去定义好那个问题,基于问题背景再去思考。
为什么要有产品经理?为什么开发不直接跟业务部门对接?一个很重要的原因就是产品经理会在中间发现各种各样伪装成需求的解决方案、伪装成需求的提案、伪装成需求的要求。重构思维很重要,最主要的原因这关乎是产品经理的职能所在。
产品经理需要找到需求背后的人和问题,甄别、洞察之后,再去考虑找解决方案。这强调产品经理需要有解构对象的能力,而不是说我有一把锤子,满世界找钉子。
第二个场景关乎解构对象后进行的抽象。
正常情况下,作为宝爸(产品经理), 家里的小孩子半夜哭闹,想要吃饼干,我首先会下意识地翻箱倒柜找出饼干给孩子吃。但在这里首先需要思考一个问题,“想要吃饼干” 这件事是解决方案还是用户需求呢?答案是前者。饼干是用户提供的解决方案,而真实的用户需求是 “宝宝饿了”。宝爸在这个时候只需要喂宝宝能够填饱肚子的食物,而不是掉进在家里找饼干的陷阱。
用户提出一个诉求时,你不能简单地满足诉求,或者简单的把诉求稍微修饰一下就转发给开发。产品经理的第一职业素养就是不能把业务部门发来的需求直接转发给开发。当用户喊着想要饼干时,多问问自己为什么,为什么半夜要饼干?是不是饿了?一定要饼干吗,其他食物是否也能满足?
第三个例子和重组相关,这个例子我会在下文进行详细的说明和示例。重组的前提是抽象,只有抽象做的好,产品设计才不会重复进行变更。
善于解构、抽象和重组的思维是成为合格产品经理的第一步。