本文根据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/
以上。