共计 1638 个字符，预计需要花费 5 分钟才能阅读完成。
简评：越来越多人涌入产品经理这个岗位，但是面对不同的产品和客户群体，产品经理所需要的技能、知识和经验可能大相庭径。
近几年随着移动互联网的爆发性增长，几乎遍地都是产品经理了。华尔街日报 也曾报道称「产品经理」是新晋毕业生最青睐的岗位。拥有一定技术背景、良好的业务导向思维和优秀的运营经验加成，产品经理（Product Management）也能成为其他更高级职位角色的跳板。
然而，值得注意的是，现在大部分为外人所知的 PM 主要都偏向于 C 端（消费者业务），像大家熟知的 Facebook、Twitter、Uber 以及 Google 等。毕竟面向消费者的移动互联网大规模普及带来的岗位需求造就了 C 端 PM。
但是，C 端的 PM 经验几乎很难应用于企业软件。可能有些人不太理解，本文尝试阐述一下。
▎源之根本在于商业模式
消费者业务和企业业务的差异显而易见，因此它们对产品管理方面的要求也截然不同。
我们很容易能说出消费者业务的一些特征，诸如用户体验、广告盈利、App 内购等等。我们通过提升产品体验，运营市场策略以及各种增长模式来获取用户。当有了足够的用户之后，我们又会根据用户的喜好不断地迭代产品。
而在企业市场中，产品往往是活在规模订购的模式中。销售同事将这种大型复杂的企业软件产品售卖给小部分付费用户，在售卖的过程中，会进行各种资源预算分配的讨论。对于大多数公司来说，购买并开始使用一个新软件是非常庞大的工程，因此企业软件实际上是一种各方利益妥协的结果。
在企业市场中，一个主要客户就可以进行产品需求变更，这会扰乱原有计划和工期，但 B 端 PM 也不得不接受。毕竟交易非常重要，是盈利的直接来源。
不过具有讽刺意味的是，尽管 C 端工作中用户大于天，但实际上 B 端 PM 会更接近产品面向的客户。
对于 B 端 PM 意味着他们必须和销售、市场部门紧密合作，有时候还需要一起去见客户以帮助收集需求和交易。但 PM 毕竟不是销售，所以很多 PM 面临的挑战是如何能专注于长期的产品开发而不会因为销售需求而过分分心。
▎关于 MVP（最小可行性产品）
MVP 大家都懂，下面这个小漫画还挺直观的 ~
MVP（最小可行性产品）的思路在面向 C 端时好使，但面向 B 端时就行不通了，因为当一家公司要花几十上百万去购买你的产品时，不太可能是看中你的 MVP。
作为公司方，他们只想要解决他们现在面临的业务问题，销售必须向对方证明自己公司的产品能够解决这些问题。
所以企业软件通常都很专业，它需要深刻理解用户面临的业务问题，而这反过来又要求 B 端 PM 首先得理解用户的业务。
▎客户≠用户
另外，购买者和使用者未必是同一个人，这点也很重要！
甚至，还存在决策者角色：老板拍板，秘书下单，经理使用。
企业软件的购买通常涉及到大笔资金，这笔资金的使用一般来说可能需要高级副总裁授权，同时 VP 也要给更高一级的管理层或者董事会说明这项投资的理由。这就是为什么所有企业软件都都会打包成「解决方案」的原因之一了。
另外，真正的用户其实是业务部门，他们才是一线生产者。
所以客户和用户分离的这种形态，导致企业软件总是特别不「人性化」。管理员支付的是功能和商业价值，而非漂亮的用户界面。高管们的需求优先级是远高于下属的。
Lotus Notes 用户界面
Lotus Notes 是一个数据库产品，其上还绑定了一个电子邮件客户端。没人喜欢这个企业软件的用户体验，但是对于软件提供方 IBM 来说，这依然是一项价值 10 亿美元的业务。因为对于甲方高管来说，这个软件功能齐全，超低风险而且续约费用低。
最后推荐几个 B 端产品经理 ~
Adobe’s Ben Gaines and Joe Martin
Percolate’s Carmen Sutter
Constellate Data’s Matt LeMay
Salesforce’s Dan McCall
Demandware’s Vinod Kumar
HubSpot’s Jeremy Crane and Mike Champion
原文链接：
Product Management for the Enterprise
