硅谷产品总监教你如何构建产品开发流程

用户痛点分析

产品开发流程中,最重要的是要理解 用户痛点。

今年春季,Intercom(一体化客户沟通系统) 刚刚完成了 1.25 亿的 D 轮融资(谷歌风投也全面加入),在 5 年内实现了年经常性营收(ARR)5000 万美元。可以说,在 这7 年的时间里,Intercom 一直在不断取得进展,而这其中有一个非常关键的原因:Intercom团队会深刻理解每个项目要解决的问题。
你可能会觉得这句话是废话,因为每个产品经理都是这样想的啊。但是,很多产品经理也只是这样想,到具体执行的时候,他们已经离这个关键点越来越远了。接下来我要分享的就是 Intercom 的产品副总监 Paul 的经验总结,希望能给大家一些启发。

大多数产品的开发过程

下图展示的是一个非常标准的产品开发流程:

这个过程产品经理们应该非常熟悉,就是“瀑布”开发的常用流程。当然,如果你的产品团队比这种瀑布式开发更“敏捷”一些的话,过程可能是这样的:

备注:图中的循环也可能是“设计-开发-测试”的循环

接下来,让我们一起来思考一个问题:

假设在项目里一共有100个单位的可用时间。团队里所有人(产品,运营,设计师,分析师,工程师…)都投入工作,你会如何安排?

在工作中,大多数的产品开发团队初期是这样规划的:花一点点时间决定问题的优先级,界定问题(痛点),然后用更多的时间去设计解决方案,接下来,把大部分时间放在「把东西做出来」上。

立即登录阅读全文
登录或注册即可解锁全站内容,即表示你理解并同意 服务协议 与 隐私政策

实际操作的时候,这种规划常常变成这样:

发现没有,时间基本都放到开发上了,根本没时间排优先级,明确问题,和初期的想法背道而驰。

为什么会这样?

当一个资历很高的重要人物(比如老板,大家都懂的~)突然想到一个新点子,并且想尽快实现时,团队的工作方式就会走偏——研究用户真正痛点、明确问题这一步被无限挤压。

这个重要人物的想法可能是拍脑袋“拍”出来的:坐车的时候,洗澡的时候……一旦这个想法在他心中成型了,他会觉得一刻都不能浪费,得马上去设计,马上把东西做出来!

最糟糕的情况是,一旦你的产品路线图充斥着这些“拍脑袋”的想法,产品就会变的东打一枪西打一耙,功能毫无内在联系。

曾经,Paul 在做谷歌做某个项目的时候常遇到这种“拍脑袋”的想法,而且他发现大多数被这类想法绑架的项目都是失败的。当然,这并不是对谷歌的全盘否定。

很多初创公司会失败也是因为这些“拍脑袋”的想法。这类团队的很多员工表示这就是他们的工作方式。他们会把用户研究,用户访谈这些挂在嘴上,实际工作时并不会执行。

在 Facebook 工作时,他看到的很多项目是这样的:

这比在 Google 时好一些,不过从图中你可以看出来,“开发”依然占着绝对的比重。但是,在 Intercom,他们绝对不会这么做。

Intercom 的做法

在开始设计、开发之前,他们就花费了大概 40%的时间。可以说,他们「沉迷」于确定问题优先级和明确要解决的问题。Paul 会不停地「拷问」大家的灵魂:你真的,深刻的,理解了眼前这个问题吗?同时,在 Intercom,他们也非常鼓励产品经理去公开分享、讨论要定义的问题。

为什么要这样做呢?

因为「先理解好问题、痛点,才能有好的解决方案」。

然而,大多数软件开发团队都会直接跳过问题定义的部分。

在实际操作中,Intercom 建立了几个团队来确保做好前期定义问题的阶段。

  1. 客户支持团队(他们会标记与客户的每次对话,以便 PM 进行审核);
  2. 销售团队和营销团队(根据反馈建立产品/市场矩阵);
  3. 研究团队(Intercom 从一开始就投入巨资在这个团队上);
  4. 分析团队(Intercom 现在非常重视,也在加大投入)。

在测试阶段,他们会意识到「原来还没有将这个问题 / 痛点 研究透彻」,所以又会重新对问题进行界定。

说到这里,你会发现一个问题,如果大家都认同「先有理解好问题、痛点,才能有好的解决方案」这句话,为什么许多公司和团队还是会跳过界定问题这个部分呢?Paul 认为有三个重要原因:

1. 首先,理解问题本身就是一件非常难的事情。它需要你和一定数量的用户疯狂交谈,一遍又一遍,进行“巧妙”的信息挖掘;它需要你走出自己的脑袋,进入用户的脑袋,尽可能地“感同身受”。

深入了解他们的实际需求(真正的痛点)。人们经常以他们想要的解决方案形式描述他们所遇到的问题。平庸的产品团队会停在这里,不再深挖,就去做了。然而,用户的真正痛点还在他们的思想中埋藏了几层。好的产品团队则会继续前进,不断问为什么。

2. 在这个过程中你要做的工作听起来不潮也不酷。一份用户研究报告,一个新的 UI 模型,一个新的原型,你觉得哪个「酷」?很多位高权重者都喜欢看到「又新又能用」的东西,他们没时间读那些报告。在现代的互联网环境下,深度阅读和反思来获得深刻的知识并不令人兴奋,也不那么重要。

3. 前期任务(排优先级,界定问题)的工作量在产品上很难得到体现。比如你花了很长时间去研究、界定问题,希望能把产品做好,但上级领导却觉得你花了这么长时间才做出这么点东西。他们并不重视你花了多少精力研究,他们只注重最终的产量。

所以说,前期的问题界定是一项艰苦的工作,它被贴上了「无聊又不酷」的标签,从产出量来看又很难证明这部分工作的价值。

然而,对Paul 而言,这是他们做的最重要的事情之一,也是他们项目成功的最重要的因素之一。在动手去做之前,先搞清楚要解决的是什么问题,如此,才能帮助你避免做出「漂亮的废品」。

最后,希望大家都试着去改变对时间的分配,把更多的时间放到“界定问题”上。把问题界定清楚以后,你会发现,接下来的设计、开发都会变得很顺利,最终用户也会喜欢你的产品,因为你懂得他们的需求。

点个赞鼓励一下作者吧~
点赞
收藏
请用微信扫码分享哦~
分享
加入社群
创新战略交流群创新战略交流群
扫码进群
扫码加我拉你入群
TOC业务增长群TOC业务增长群
扫码进群
扫码加我拉你入群
TOB业务增长群TOB业务增长群
扫码进群
扫码加我拉你入群~

勿删,用于自定义目录加锚点,隐藏即可

相关文章推荐

One thought on “硅谷产品总监教你如何构建产品开发流程

发表回复

点赞
收藏
请用微信扫码分享哦~
分享
关闭按钮
欢迎来到Runwise即能创新社区!
登录装饰图,三个人围坐在电脑前,对某个灵感进行沟通和讨论
已有账号?