邱岳的产品手记
邱岳
无码科技产品经理,公众号二爷鉴书作者
立即订阅
9923 人已学习
课程目录
已完结 48 讲
0/4登录后,你可以任选4讲全文学习。
开篇词 | 产品经理的世界没有对错
免费
01 | 验证码是个好设计吗?
02 | 产品经理工具指南
03 | 产品案例分析·Trigraphy的设计哲学
04 | 如何当好AI时代的产品经理?(学习篇)
05 | 如何当好AI时代的产品经理?(实践篇)
06 | 产品案例分析 · The Guardian的文本之美
07 | 关于需求变更(上):需求背后的需求
08 | 关于需求变更(下) : 化变更于无形
09 | 产品案例分析:Hopper的“人工智能”
10 | 产品被抄袭了,怎么办?
11 | 如何借鉴灵感?
12 | 产品案例分析:LabRdr的设计实验
13 | 无用却必要:产品规划(上)
14 | 留白与节奏:产品规划(下)
15 | 产品案例分析:Mimo与Learn Python的导学之趣
16 | 在内部产品中找到产品经理的价值
17 | 产品经理如何获得非权力性的影响力?
18 | 产品案例分析:WWF Together的情怀设计
19 | 产品经理如何与开发打交道(上):打破思维的边界
20 | 产品经理如何与开发打交道(下):合作与共赢
21 | 产品案例分析:Fabulous的精致养成
22 | 产品经理的图文基本功(上):产品文档
23 | 产品经理的图文基本功(下):产品图例
24 | 产品案例分析:PathSource的混乱与直观
25 | 产品世界的暗黑模式:操纵的诱惑
26 | 写好产品文档的诀窍
27 | 产品案例分析:Quartz&Hooked的对话式交互
28 | 产品分析的套路(上):谁是利益相关者?
29 | 产品分析的套路(中):解决什么问题?
30 | 产品案例分析:Primer的扑克牌交互
31 | 产品分析的套路(下):如何出解决方案?
32 | 从受众规模、需求频率和强度出发:排定需求优先级的方法(上)
33 | 产品案例分析:Arts & Culture 的架构之美
34 | 价值曲线分析:排定需求优先级的方法(下)
35 | 答疑时间:关于产品经理的12个问题
36 | 产品案例分析:解读知识星球
37 | 如何做好需求评审(上):需求评审不只是一次会议
38 | 如何做好需求评审(下):在评审中控住全场
39 | 产品案例分析:SeatGeek的订票设计
40 | 新年给产品经理的几碗鸡汤
41 | 产品经理的项目管理心得
42 | 产品案例分析:Unread的阅读体验
43 | “玩”的力量:从游戏设计中学习产品设计(上)
44 | “玩”的启示:从游戏设计中学习产品设计(下)
45 | 产品案例分析:Chartistic的“复杂”图表
尾声:你的快乐是哪一种
【第二季回归】二爷归来,再次扬帆起航
邱岳的产品手记
登录|注册

07 | 关于需求变更(上):需求背后的需求

邱岳 2017-12-05
“唯一不变的,就是变化本身。”——斯宾塞·约翰逊
每当行业中想要黑产品经理时,首个被砸下来的罪责一定是“需求变更”,仿佛需求变更是产品经理最要命的错误,我并不这么看。所谓需求变更其实很复杂,不能一概而论,今天我们就来聊聊它。

需求不会变更,变更的是实现

“需求变更”四个字有个不好的暗示,仿佛变更是来源于产品用户的需求变化。实则不然,从整个团队的角度看,需求变更多半其实是指“实现变更”。
用户的需求通常很稳定,变更是由于产品经理对用户需求的分析出现了偏差,或满足用户需求的手段发生了调整。
比如,产品经理说需要一匹更快的马,后来换成了要汽车。在这个过程中,用户的需求一直都是“更快到达目的地”,变更的是满足需求的方式。
就像“工程师用搜索技术实现了某个查询功能,后来发现索引建立有几秒钟延迟不能满足实时查询的场景需要,又改用查数据库”的道理差不多,需求没变,实现变了而已。
取消
完成
0/1000字
划线
笔记
复制
© 版权归极客邦科技所有,未经许可不得传播售卖。 页面已增加防盗追踪,如有侵权极客邦将依法追究其法律责任。
该试读文章来自付费专栏《邱岳的产品手记》,如需阅读全部文章,
请订阅文章所属专栏。
立即订阅
登录 后留言

精选留言(64)

  • 池建强
    需求沟通确实需要技巧。上次我的研发和产品聊着聊着就急了。

    研发:我特么就不给你做这个需求
    产品:这个需求有用你为啥不给做

    我看着就要打起来,赶紧劝,能动手就别吵吵…

    后来沟通清楚了,其实需要很小的工作量就能完成这个有效的产品特征。

    把话说清楚,是产品经理的必备技能。但能说清楚的,不多
    2017-12-05
    34
  • Charles tong
    在做项目的过程中,在开需求评审会之前,我一般会先把自己的产品方案给技术看一下,简单评估下可行性,做一个简单的统一看法。
    再开需求评审会的时候,最大的目的是传达整个项目的目标,统一项目中的细节,然后根据会上各方的讨论结果再给需求内容做一些合理调整。最终发邮件确定方案。
    需求评审会更像是将产品经理对项目的看法和目标传达给项目参与者的过程,给团队成员统一目标。

    作者回复: 这也是个好办法 提高会议效率

    2017-12-05
    17
  • 宇宙全栈
    谢谢二爷的文章,知己知彼,百战百胜。 —— from 某程序员

    作者回复: 感谢宇宙全栈

    2017-12-05
    17
  • 刘祯
    需求真的是产品经理的拦路虎,想要越过它,必须有足够的能力与方法。今天学习了几点,总结下:

    一是 5 问法,这是破解需求的好办法。我们总说有一些伪需求,可能就是在前期并未做好充足的讨论与思考,碰到什么事情就一股脑地列入计划,不给自己留有一些缓冲余地,最后只能自己背锅。

    二是,通过不断提问,学会给自己充分的思考空间,闭门造车永远都是最低效的方式,要真正验证假设,而且一定要快。

    三是,我在现实工作中碰到的情况就是,需求评审这事其实大家没有放在心上,有些同事对业务并不熟悉,心态上还是以完成任务为主,对需求或是方案并未有足够的重视,简而言之,责任都是产品经理的。我一直在想,产品是靠团队的,一个人总有自己的局限。

    不知道二爷对此有何高见?如何将大家的心态转变成为真正做产品而不是做项目?
    2017-12-05
    13
  • Ryan Feng
    穿透用户诉求去找到更好的产品实现方式是好坏产品经理的分水岭

    作者回复: 也是基本功

    2017-12-06
    10
  • AthenaT🤘🏻
    打產品經理的時候,個別好心人沒能擠進去便轉而開始勸架了

    作者回复: 也可能在外头往里递砖头

    2017-12-05
    9
  • Atom
    前边分析用户提出需求那段,概括来说就是用户提出的需求往往都是他真实需求的解决办法。

    从(伪)心理学的角度看,我们所在的这个社会非常鄙视那种只会提问题而不提解决方案的人,因此我们习惯于在自己提出一个问题后自行思考解决方案。
    即使我们在面对一个新产品时是小白用户,但潜意识也不想承认这一点,不想让别人觉得自己是一个“没用”的人,因此在提需求的时候,往往会给设计产品的人提出一个解决需求的思路。

    作者回复: 所以产品经理得从这里面去看到真正的需求

    2017-12-05
    6
  • 陈颜俊
    关于5问,有一个说法我印象比较深刻,那就是永远别相信自己的Plan A,你一定可以想出更好的Plan B
    2018-01-09
    5
  • zzj
    留给产品做需求的时间,经常都是很赶的,花两三天或者一周就敲定一个可以做一两个月工期的版本,然后在实现的过程中,必然就伴随着变更了。

    作者回复: 唉,心痛

    2017-12-12
    5
  • Hand
    每天奔波在各种会议中的我,真的很想静静写文档,泪目

    作者回复: 实在不行就少睡点儿…

    2017-12-05
    5
  • 田小川
    现在的公司没有产品,通常都是需求直接丢给我(UI )去直接出效果图,但是又不交代清楚需求,也不留足够的时间给我去思考,感觉真的是特别蛋疼。有时候跟领导讨论需求的时候想问清楚真正的需求,以便有更好的方案去实现,领导很多时候又觉得我没必要知道那么多,按照他说的去做就行了,有点憋屈。

    作者回复: 别急,达到大家愿意跟你充分沟通之后,有些东西才能走通,循序渐进

    2018-01-07
    4
  • 时间之树
    其实,无论是需求分析出现偏差,还是需求方式进行变更,都体现了产品经理需求分析的能力。而在需求变更开始之后,考验的就是产品经理沟通和平衡能力。无论是过程中哪一环出现问题,都是产品经理的责任。虽然没有完美的产品经理,但是有不断完善自己的产品经理。
    2017-12-25
    3
  • 蔡文渊Eric
    前公司是一个硅谷团队,当时有一个重大产品需求美国的产品团队研究和讨论了一年多才开始研发。当时国内团队大部分同事都不理解为什么美国团队一直在讨论需求迟迟不肯开发,看看国内互联网团队一周一个新功能效率翻倍。事后回顾真的很佩服产品经理能hold住,一个重大产品需求应该多花时间研究和讨论才能确定,因为需要的开发资源也是翻倍的。
    2017-12-23
    3
  • Bonnie Mei
    感觉对不起开发。。
    2017-12-06
    3
  • 宅男丁
    评价更多集中在后面几点,也是二爷展开的较多的部分,可能是经历更多,大家也更容易形成共鸣和共识。
    想分享对第一点的理解。
    首先,需求是不变的,而且需求绝大多数情况终会被满足,产品解决的是其中效率和成本的问题,所以核心是找到需求,然后寻找或者建立工具去不断提高,工具可以是系统,可以是算法,也可以是人,很多情况是这几种的集合。
    其次,变更的是实现,或者通俗一点,就是解决方案在变。非常同意二爷的,变更在产品经理大脑里发生是影响最小的,但是会有产品进到追求最优解决方案的自我陷阱里,忽视了对效果的追求,更好的解决方案是对处理静态的世界是ok的,但是糙快猛更长期来看更有效果。
    产品的价值不是完成解决方案,而是持续满足需求。
    2017-12-05
    3
  • Quinn
    我居然少问了4个「为什么」。
    2017-12-05
    3
  • Shaoyao·琚
    二爷,没你这么办事儿的😂
    2017-12-05
    3
  • 十八
    感觉先确定上线时间。然后在各个岗位在反推安排自己的时间。是个非常糟糕的体验。
    2018-07-04
    2
  • 啊啊啊是我啊
    “二爷,没有你这么办事儿的。” 想知道这句话对二爷的心理影响是怎么样的。

    作者回复: 内疚了很长时间

    2017-12-18
    2
  • 菡萏如佳人
    如果产品经理能做到二爷说的50%,那就阿弥陀佛了…

    作者回复: 向着 100% 努力,能做到多少随缘了,佛系产品经理

    2017-12-08
    2
收起评论
64
返回
顶部