产品研发第一要关注的就是，是否扣准了市场的脉搏。产品对市场需求的契合性直接决定着产品价值的纯度。

除了相关人员对市场的个人把握能力，企业感知市场需求的触角机制建设才是重中之重。企业的市场部门的组织分工与合作方式、产品定义的流程体现了企业对市场的感知方式与角度，及把这种感知变现为产品定义的精度。分工就意味着赋予了相关部门各自独特的立场。立场是个有色眼镜，分工不同的相关市场部门戴着不同的有色眼镜去看市场，其所见所闻、所思所聚不可避免地被其立场所裹挟。

有些企业主要是研发部门决定产品的定义，则其产品的技术属性往往会得到较大的关注，而其对市场需求的契合性方面则容易出问题。有些企业的市场组织是渠道导向，产品主要由渠道部门来定义，则容易聚焦在渠道最前线的竞争场面中，市场需求会比较快速反馈回来，因而产品定义不会偏离市场需求太远，但是容易有短期倾向，且产品的个体精度不太被重视，产品的数量会猛增，不同渠道之间的产品整合也往往比较差。有些企业的主要是通过产品线来定义产品，产品规划会比较清晰，对产品个体会比较重视，也比较重视长线规划，但是往往会忽略产品短期的市场“格斗”能力，且对不同渠道、不同市场细分的差异性关注不够。

实事求是说，立场“短板”是客观的存在，要克服不同市场分工方式产生的不同“短板”问题，就不能仅仅依靠“单极”立场来定义产品，要建立“多极”性的跨部门联合决策机制。而建立实质性的跨部门联合决策机制，绝非出台一纸产品立项制度那么简单，背后不可避免还会有部门实力的较量。如果关键部门之间不能形成制衡，结果还是会是事实上的“单极”决策模式。比如，一个企业渠道部门过于强势，产品部门过于弱势，后者就很难实质性从不同的立场去平衡前者；反过来，如果产品部门过于强势，渠道部门过于弱势，同样难以取得实质性的平衡。

企业内部的市场需求管理可分为两个层次，第一个层次是较宏观的，面向产品集合（即组合）；第二个层次是较微观的，面向具体产品。

第一个层次的市场需求管理，一般是与公司整体战略是直接对接的，是对公司战略的展开和动态细化；也是围绕“所能”与“欲取”进行匹配的，其工作重心更多放在“欲取”方面。“欲取”必须建立在市场需求基础上，即了解市场、细分市场，在此基础上进行可行性分析与评估，最后形成“欲取”的产品组合，以及相配套的业务策略与计划。

看起来，这个过程的逻辑步骤并不很复杂，但要完成这项工作，卷入参与的部门会比较多，包括销售部门、营销部门、产品部门、研发部门、财务部门、公司级的产品决策组织，甚至生产与供应部门。如果没有结构化的工作分配，这种联合“作业”是很难取得实效并保持工作效率的。所以，常规的办法就是把全程工作模板化、交付化，沿着流程活动次序把每个角色的具体工作落实到“无歧义”的程度。这样一方面可以指导参与者的工作，另外一方面也明确了每个部门和角色的权责，保证分工后的工作成果能够无缝拼接为一体。如果不建立一套清晰的市场需求管理机制，只是依靠能够“话事”者的经验进行判断和决策，那么可靠性与周全性都很难保障。

第二个层次是面向具体产品的需求管理，有两个重点：首先它应该且必须在第一个层次输出的产品组合范畴之内；其次是要建立一个连贯的、紧密的产品需求管理链，或者说端到端的需求管理链。

理解端到端的需求管理链有如下几个要点：

第一，开发工作必须与来自市场和客户的需求敏感联动。

如果前端需求变了很多，而后端开发还是不受任何影响，自顾自地前行，那么就可以说二者没有建立敏感联动。

第二，不能轻筹划、重执行。

轻视前端需求管理工作，势必形成“头小尾大”的局面，开发前期可能还看不出多大问题，到了开发后期，各种变更、例外层出不穷，把前面欠的会在后面连本带利偿还。事实上，在企业研发管理中，“头小尾大”是极为常见的一个状况，这就像一个人要出门去做一次“说走就走的自驾游”，临行前没有做什么准备工作，出了门就会逐步发现忘带了很多东西，于是要不断返回取东西、不断找超市买东西；也没有做路线规划，所以不断绕弯路。

第三，跨部门联合定义产品。

产品的属性是多维度、多层面的，涉及市场、软硬件开发、结构开发、包装设计、工程与制造、采购、质量、售后等多方面业务。为确保每一个属性都能接地气、可落实，就应该也必须卷入相关部门联合对产品定义，兼顾“应该怎样”与“能否怎样”。也就是说，通过跨部门联合作业和决策，对产品定义涉及各种属性在多部门之间达成共识，确保被定义的产品不但是满足市场需求的，还是能在生产上实现的。如果缺乏这种机制，则可视组织机构是不均衡的。部门之间不能形成必要的协同与制衡，最后偏颇于某个部门的立场，从而导致产品定义也是不均匀的，最终在某些方面出问题。比如，如果在产品定义时，最熟悉产品成本的供应链部门不能参与或没有话语权，那么产品成本就不在掌控之内了。

联合互动机制一旦真正建立起来，就会发现过往那些让各个部门烦扰的各种问题都“烟消云散”了，产品开发过程中的“意外”频出情况也会大大好转。多部门联合定义产品的过程，也必是一个多边博弈过程。要驾驭这种博弈，就需要清晰的规则。清晰的规则意味着清晰的分工，而分工要清晰，就必须沿着动态业务流进行场景式的细化设计，对每个活动进行清晰的界定，让不同角色不同活动的输出能够齿轮式耦合。细化工作一般会体现在分类化、模板化、标准化上。总之，要确保联合机制的有效性，就需要从驾驭博弈的视角进行机制的结构设计。

第四，需求管理是个连续的过程，并且其形态会随流程推进而不断变换。

需求与产品属性的对应关系并不是一步到位的，中间可能有多次相互衔接的形态的变换。从终端客户需求到市场需求，到产品需求，到设计需求，到制造需求、品质需求等，是一个有层次的推进过程，后者总是以前者为基础，中间有分析、有分解、有转换、有试错。除了负责形态传递与转换的当事人的专业能力，传递需求的流程管道也非常重要，它指导并规约需求在开发流程中的有效传递。所以，流程管道的建设也是重要的研发管理内容。

需求传递与变换路径长了，转换与推进过程就容易出错，失真概率也就加大了。前端客户与市场的需求到了后面，有些可能就会被忽略、被误解。以魅族、小米为代表的新兴手机品牌创新性地利用BBS论坛，让有活力的发烧友客户与开发人员可以进行直接的互动，这可以帮助开发人员直接获得来自原始客户的一手需求信息，大大促进了产品与市场对焦的精度和效。，我认为，这个做法具有广谱的可借鉴性。

第五，需求变更要“讲规矩”。

客户与市场的需求往往会在中途发生改变，这往往会破坏多部门工作之间的协同关系，因为他们都是以此需求输入而平行展开工作，需求传递路径具有一定的规范化。而需求变更会打破原有的规范，导致严重的疏漏和对接出错，不仅有些工作需要返工，导致效率降低，更造成了研发成本的巨大浪费。即使像魅族与小米采取的通过网络直接与终端客户互动的短路径需求管理方式，其公司内部也一定有规范的需求传递与变更路径，否则一定会出现混乱。

两个层次的市场/客户需求管理，都受一个核心观念的统领，就是视产品开发为一种投资行为。我记得看过一个故事，韦尔奇出任通用电气CEO伊始，向德鲁克征询有关企业成长的课题。德鲁克问了韦尔奇一个简单的问题：假设你是投资人，你会投资通用电气的哪些业务？这给了韦尔奇莫大的启示，于是杰克·韦尔奇做出了那个广为人知的决策：通用电气旗下的每块业务，都要在行业数一数二，否则就退出市场。德鲁克之问，不仅适用于评估和判断某个业务板块，同样适用于一个产品线、一个产品组合、一个具体的产品。