1704232126
人人都是产品经理2.0:写给泛产品经理 5.1 从问题到解决方案
1704232127
1704232128
前两章提出并筛选了产品概念,采集了需求,研究了用户,随着信息收集得越来越多,对各种“用户需求场景”也理解得越来越透彻。这一章要开始琢磨解决方案了。
1704232129
1704232130
几年前读马斯洛的《动机与人格》时,发现有一章专门在谈论“问题”与“方法(解决方案)”这两个词。书中最难理解的地方,也许就在于“问题中心(Problem Centering)”与“方法中心(Means Centering)”这两个概念,这需要我们一起来理解和思考。
1704232131
1704232132
下面列出了产品经理们工作中常见的一些疑问:
1704232133
1704232134
a)PRD怎么写,给我个模板吧?
1704232135
1704232136
b)写PRD是什么目的,给谁看,要对方了解什么?
1704232137
1704232138
c)最优的团队组织结构应该怎样?
1704232139
1704232140
d)我们的团队做现在这个产品,需要哪些能力,谁有这样的能力?
1704232141
1704232142
e)我们应该用什么流程?
1704232143
1704232144
f)现在的流程会出什么问题?如果出问题怎么解决?
1704232145
1704232146
进一步分析可知,上面的问题可分为两类:a、c、e问,是典型的方法中心,而b、d、f问,是典型的问题中心。二者的区分可以概括为:方法是手段,问题是目的。而新手产品经理常犯的错误,就是过于重视方法,或过于忽视问题。
1704232147
1704232148
问题中心是“手里拿着钉子,看什么都是锤子”,更多思考“问题”相关的事情。如果你对任何问题的解决方案都能信手拈来, 已达到“手里无锤,飞花落叶皆可为锤”的产品高手境界,那么的确可以只关注问题本身。方法中心是“手里拿着锤子,看什么都是钉子”,更多思考“解决方案”相关的事情。如果你真的打造出“雷神之锤”,可以用来解决任何问题,那你的产品需求解决能力确实也可以天下无敌。
1704232149
1704232150
从“问题中心”的思路出发,只要能搞定问题,用什么方法就不再是最重要的事情。比如,旺旺对话框里的计算器,调用的是Windows的自带功能,从技术角度来看这一解决方案非常简陋,但的确能实实在在地满足买家、卖家沟通时讨价还价的现实需求,可以视为“问题中心”的成功典范。
1704232151
1704232152
从“方法中心”的思路出发,方法本身就是核心追求,至于这个方法究竟能解决哪些问题,可以暂不考虑。比如有些业内顶尖的公司,早在5年前就成立了研究人工智能的实验室,当时只是基于对未来趋势的预判,并不知道研究成果能用在哪里,但大家心里清楚,等数据量积累足够多、计算能力足够强、算法足够厉害之后,总能找到应用场景。
1704232153
1704232154
长久以来,国内的教育导向都是强调方法而忽视问题。而从事产品经理这个工作,可以让我们渐渐学会在两者之间找到平衡,正好对传统教育的负面影响起到一定的纠偏作用。比如前两章对应于产品经理的工作,就是分析问题。在一个团队中,技术人员的思维侧重方法中心,业务人员的思维侧重问题中心,而产品人员则要融合这两种思维——需要先“问题中心”,尽快找到“用户需求”,回答Why和What;然后“方法中心”,最终设计出“产品功能”来回答How。
1704232155
1704232156
本章仔细聊一聊从问题到解决方案的转化过程。
1704232157
1704232158
1704232159
1704232160
1704232162
人人都是产品经理2.0:写给泛产品经理 5.2 Y模型的基本概念
1704232163
1704232164
产品经理们工作中经常说的“需求分析”一词,就是指从问题到方法(解决方案)的转化,或者说从用户需求到产品功能的转化。我的总结非常简单,就是一个大写的字母Y,我把它叫作“Y模型”,如图5-1所示。先看看Y模型中的一些概念,如果看过前面的章节,对这些术语应该并不陌生。
1704232165
1704232166
1704232167
1704232168
1704232169
图5-1 Y模型的基本概念
1704232170
1704232171
“1”是用户需求场景,经常简单说成用户需求。这是起点,是表象,是需求的第一种深度——观点和行为。
1704232172
1704232173
“2”是用户需求背后的目标和动机,是需求的第二种深度,产品经理在思考用户目标时也要综合考虑公司、产品的目标。
1704232174
[
上一页 ]
[ :1.704232125e+09 ]
[
下一页 ]