善学者,假人之长以补其短

(本文根据GeneDock产品总监何荣惠在知乎的回答整理而成,转载请保留转载信息和原文作者及链接。)




本文根据GeneDock产品总监何荣惠在知乎的回答整理而成。原问题:to B 的产品经理和 to C 的产品经理有什么差别? to B 的产品经理的价值如何体现?

回答如下:

原阿里云飞天平台初创员工、日志服务产品经理,在阿里云历经开发、测试、项目经理、产品经理,现在与一群志同道合的伙伴在为生命计算,负责GeneDock产品工作。


没有做过To C的产品经理,前同事有几个离职后创业做To C产品的,在各自的领域做得有声有色,有时候会一起聊天,我觉得To B和To C在需求分析、产品设计、UI设计的方法论上并没有什么太大区别。这两类产品面向的群体都是人,可能B面向的更多是专业人士,C更多的面向普通人,然而所有的产品都不是脱离人的需求臆想出来的。

“从产品设计上来说,抽象才能使得各类不同场景、复杂场景用简单的模型来满足。”

最初,我们开始做某个产品的时候,往往是已经嗅到了市场中、行业中有这样的需求。在第一版产品出来及产品后期迭代的整个生命周期中,我们会从用户那里听到需求反馈,这个时候需要挖掘用户真实的诉求是什么,去理解用户场景并抽象。在程序员的世界里,有种不好的coding style叫面条代码,在产品经理这里,如果用户说什么你就做什么,我把他称为面条产品。从产品设计上来说,抽象才能使得各类不同场景、复杂场景用简单的模型来满足。


从我之前的工作和现在的工作来说说To B产品经理日常做的事情。


正如上段说的,当我们开始立项一个新产品的时候,前期已经做了足够的调研来预估未来这个行业的市场规模和需求。


最初我们会有个产品Demo,接着,找到第一个天使客户、第两个客户、第三个…当有十几个客户时,你会发现Demo不work了,总有这样那样的坑,需要人肉去填,而且即使同一类型的客户,场景也并不是完全一样的。这时候,你需要坐下来,去分析并抽象用户场景,定义产品模型,写PRD,找架构师和研发讨论,这样的产品模型下,现有的架构是否能够满足,是否需要重构,如果重构是否有尽量不影响用户的过渡方案,过渡方案是什么。


首先,大家要在产品模型定义上达成一致,接下来,产品才开始定义接口。接口定义细节很多,例如,这个接口的请求是什么样的,有没有参数,参数的类型如何定义,返回结果是什么,是什么格式,各类错误信息的定义,然后继续写PRD。GeneDock最近刚对外开放了部分API,有兴趣的同学可以去官网看一下。


以上都完成后,可以基于API进行SDK、命令行工具、Web的开发,来满足不同用户的需求(此处应有PRD)。例如我们有些用户偏好用图形化工具来上传下载数据、在Web上进行生信流程开发和运行;也有一些用户在实验阶段用本地工具调试,当生产稳定后,希望直接调用API来自动化生产;还有的用户偏好用命令行工具来写脚本。

“ To B的产品同样会去关注用户交互设计带给用户的影响 ”

一分钟变小白,在不同的用户场景下并不是相同的。例如,如果你的用户是程序员,接口易用性设计的好,那就够了;如果你的用户是科研人员或者医生,那么页面交互设计的友好性则是重要的。


To B的产品同样会去关注用户交互设计带给用户的影响,例如,可以去记录用户在Web上使用产品的行为,来思考为什么用户在这个操作上卡壳了,没有再往下操作,怎么改进来使操作流畅。To B的产品同样关注UV、PV、转化率,只是统计方式与To C不一样。

“产品经理怎么与团队建立信任和信服感?”

我曾在知乎看到过一个问题:“产品经理怎么与团队建立信任和信服感?”我的理解是,首先保证自己在这个领域认识是不断提高的,平时有时间可以多看书,类型不限,能跟不同的人聊天;其次,在与研发沟通的过程中,你不知道的东西一定要问清楚,只有在了解细节的情况下才能做出正确的判断;第三,产品的闭环尽量自己想清楚,如果你总是让别人帮你善后,那就没有然后了;最后,跟志同道合的人做志同道合的事,把合适的人放在合适的位置上 :-)。


在我的认知范围里,产品经理并没有To B,To C之分,只有好坏之分。朋友圈里不少低调资深优秀产品经理,To B和To C的两个阶段同样优秀。(说实话,回答这个问题感觉有点班门弄斧呢^_^)。


GeneDock产品研发团队的小伙伴们是群很有意思的人,两个创始人曝光率较高,就不说了。生信团队的负责人,为了来创业博士不读了(说起来好多辍学的名人呢^_^)。还有学医的小伙伴,有医人的,还有医动物的,近期又入职了几个主业码农、副业说相声的小朋友。好吧,我其实主要是来招产品经理的,也欢迎各位投其他岗位。诚挚邀请:https://www.genedock.com/joinus/


以上。


(本文转自知乎,[点击可查看原文]