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

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

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

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

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

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

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

    作者回复: 感谢宇宙全栈

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

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

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

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

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

    作者回复: 也是基本功

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

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

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

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

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

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

    作者回复: 唉,心痛

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

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

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

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

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

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

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

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

    
     2
我们在线,来聊聊吧