01 翻译工程师？
要接近这个问题的真相，以我的浅见，首要的应该从什么是产品经理这个事情开始论起。关于产品经理的定义、职责或者是能力素质模型，相信大家已经见识了很多，但是我认为其实归根到底概括起来，产品经理的核心工作本质上就是“翻译”。
这个解释很骨感，但是我觉得最接近真相，我们可以认为用户之所以不能自己去和产品开发者（开发工程师或者设计师）沟通，是因为他们使用两套不同的“语言”。
每个人（或者群体）的语言都是源于本身的知识和经验，他所使用的“单词”以及“语法”是受限的，例如在我们众所周知的“更快的马车”和“汽车”的故事中，“马车”就是用户所使用的一个单词，在他的认知中“马车”代表了一切交通工具（或者至少是最快的一类交通工具），他用自己的语言描述了他需要的东西。
“更快的马车”的实际上就等同于“更快的交通工具”，马车和交通工具在这个语境下共享了一致的内涵。而这样一个内涵到了一个汽车发明者那边，又变成了“汽车”这样一种精密的工业机械（可能对于火车的发明者来说就又变成了“火车”）。
因而可以认为这期间用户需要的和工程师所开发的东西内涵是一致的，并非用户不知道自己想要的东西，只是大家各自运用了不同的“语言”进行了表达。
在过去的时代里这样一个翻译的工作随机的由产品开发流程中的任意一个角色负责，比如用户思路清晰可以直接表达自己的需求是“更快的移动到某一个目的地”，又或者工程师思路清晰可以理解到当用户说“更快的马车”的时候实际上这东西只要能更快的移动能载重就可以。
但是现代社会发展的一大特征就是分工不断细化，因而产品经理这个角色逐步从其他角色中剥离出来，成为了一个专门的岗位，这样用户就可以只关心自己需要的，而工程师就可以只关心自己要做的。
那么在一项翻译的工作中，我们需要关心是什么呢？最首要的，当然是需要我们学会双方的“语言”，而在B端和C端的需求分析中，一个重要的区别恰恰就是“语言”的区别。
02 “语言”的差异：数据or领域知识
如果是一款商业化的产品，不论是面向哪个市场，其实都是需要满足用户的共性需求，因而我们如果只去讨论一个用户的“语言”其实是没有意义的，核心是要找到一个用户群体内的“通用语言”，它可以被有规律的翻译为产品需求。
在C端产品经理的工作中，要获取一个用户群体的需求，传统的方法就是通过抽样调研、访谈或者一些心理学的分析方法，而近年来随着数据技术的发展，更加被依赖的是用户行为数据所表现出来的倾向。
可以认为在这样一个过程中，我们终于找到了一个全部C端用户的“通用语言”，那就是他们的行为。正所谓“口嫌体正直”，行为数据可以几乎完美的毫无掩饰的揭示一个C端用户真实的需要，同时这些行为数据基本都可以按照相似的规律进行解读，“翻译”成为一个产品的需求。
那么到了B端用户，他们有没有一个这样的“通用语言”呢？我们能否去采集每一个B端用户的操作行为作为依据来推断他们的真实需求呢？
我的答案是有这样的“通用语言”，但是相对于用户行为数据，我们其实有天然的更好选择。企业业务的各个环节，实际上大多数是存在其领域内的“通用语言”的，因为这些领域本身经过了长时间的发展和研究，有了自己的知识体系，比如工商管理、供应链管理、营销管理等等不同的专业领域，都有各自成熟的知识体系。这些知识体系就是这个领域天然的“通用语言”。
那么为什么我说专业知识体系是相较于用户行为数据更好的选择呢？
即便我们假设可以获取到这些数据（实际上B端用户不愿意共享自己的数据就已经是一个难点），用专业知识而非用户数据作为“翻译”企业用户需求的基础还有以下三个好处：
- 一个领域的专业知识，已经是该领域的专家做了大量的研究（当然包含了实践数据的研究）得出的成果，它已经涵盖了行为数据所能够带来的信息，并且来源更加丰富研究更加深入。
- 在C端产品中我们很少去解决用户不知道如何去做的问题，而主要解决如何做的更好的问题。但是B端产品的用户往往希望通过一个产品获得输入，一个专业的B端产品是可以帮助企业提升其对应领域的专业水平的，而这样的输入也几乎不可能是基于一个产品自身对用户数据的研究得出的。
- 对于产品经理本人来说，学习一块已经有成熟体系的知识，也是远比去学习用户行为数据中的规律要更加高效的。
因而我非常建议B端产品经理去学习一个领域的专业知识，作为自己业务理解的起点，而不是一开始就沉迷于分析用户行为的数据或者用户调研，后者可能也是有必要的，但是建议在你对这个领域已经有了一个框架性的了解的基础上再去进行。当然我也不是建议每个产品经理都成为业务专家，我们对专业知识的学习，重点是它的整体框架和关键概念，最终是为了能够便于理解企业的真实需求，更好完成我们的“翻译”工作。
但是在翻译工作中，实际上对语言本身的熟悉也不是唯一的要求，专业的翻译工作还需要针对翻译的内容背景做大量的功课，才能更加准确高效开展工作。相对应的，要做好需求的翻译，B端和C端的“叙事背景”也有着很大的不同。
03 “背景”的差异：具体的人or整体的组织
要探讨B端“叙事背景”与C端之间的差异，首先应该明确一个前提：企业（B）有自己的需求，并且这个需求可能不是来自企业内的任何一个具体的人（C）。
我相信前半句话可能很多人都觉得很容易接受，但是后半句可能令人难以接受。朴素的想法中，任何一个系统最终都是为人服务的，那么任何一个系统的需求应该归根结底都是一个个用户的需求。
其实这种想法并不能说是错的，甚至即便在B端的产品设计中，大部分情况下也是对的。但之所以大家会有这样的感受，是因为大多数情况下，企业中用户的需求，就一定程度上代表了企业的需求。
假设我们在设计一个人事运营相关的系统，一位人事运营专员毫无疑问是这一系统的主要用户，他的期望一定是越便捷越好，入转调离的操作步骤很少，人事数据一键生成图表，因为大量重复的低效率的paperwork是这类用户的一大痛点，当然企业也几乎有一模一样的期望。
但是我们仔细思考，对于企业来说，人事运营的操作便捷、流程简短，是不是为了让人事运营专员更舒服呢？显然企业不可能单纯为了让员工工作更容易去采购一个系统，这背后隐含的是企业希望在人事运营这个活动中降本增效。
操作便捷之后一方面一个专员可以处理更多的工作，另一方面降低了学习门槛也就等于降低了工作门槛，就可以使用更加便宜的人力，这就是降本的需求，操作流程减少了整个处理过程就更加迅速，避免时间差造成了一系列风险，这就是增效的需求。
可想而知当你真的达到了这两方面需求，那个希望你系统功能便捷好用的专员，可能面临的反而是失业或者降薪的风险。
这个例子明显体现出来，可能表面“语言”上，一位企业员工的需求和整个企业的需求是一致的，但是它们的内涵并非完全一致，甚至可能相反。因而在调研B端产品需求的时候，永远要记得具体的人可能为你贡献一些当前的情况的碎片化描述，但是串联这些描述的线条一定是企业本身的诉求。
那么再进一步，企业本身的诉求怎么去探求呢？除了掌握上一部分我们提到的专业领域的“通用语言”，还有一点理念是非常重要的，就是“企业的一切活动的终极目标都是收益的最大化”。
企业和个人不同的一点是它几乎不考虑什么情感价值、自我实现之类的需要，它被构造出来的唯一目的就是为了获取收益。
那么回归到一个B端产品上，其实企业本身的诉求，一定是一个服务于收益提高的诉求。比如在上面的例子中，核心在于减少人力成本，提高工作效率，降低潜在风险，这些最终可以服务于收益提高。
有时候B端的产品中会设计那种感觉任何一个使用者都会不爽的功能，比如严格的权限体系，同样的它也服务于让企业免于机密泄露的巨大风险，保护技术壁垒等诉求，还是令企业获得了潜在的收益，那么这些功能自然也是被市场需要的。
那么这里我建议大家可以学习“价值链分析法”这样一个方法论，用于理解企业在特定场景下的核心诉求到底是什么。这一方法论的核心观点认为企业的价值增加（可以理解为就是企业的收益提高）是由企业内部一系列的价值活动相互联系，最终形成一个价值链条而贡献出来的。价值活动分为三类：
- 直接创造价值的活动，即直接贡献了后续活动那个所需的东西
- 间接创造价值的活动，即降低了后续活动的成本
- 质量保证活动，即改善了或者保障了后续活动的质量
那么当我们试图了解一个业务场景的核心诉求，就可以关注这三个方面，引入这个产品是否会创造价值，比如一些BI系统，其实就是将原本无法分析的数据进行了分析和可视化。
是否会降低成本，比如上面举例的一些人事运营的系统，降低了成本；是否改善或者保障质量，比如一些流程自动化的系统，降低了出错的比例。当然这一方法论还有很多的具体分析方法，大家有兴趣可以自行了解学习。
04 总结
那么总结一下，其实我们其实谈到了B端和C端需求分析上面的两大差异，第一个是B端产品的“通用语言”是天然存在的，可以通过学习而非数据分析就可以获得的，第二个是B端产品服务于企业本身的诉求而非某个具体的人的诉求，企业本身的诉求又源自于企业希望提高自身收益的终极目标。
