描述2024年To B大模型应用的落地实践及思考

1. 背景

2023年新年伊始，ChatGPT一夜之间家喻户晓，市场闻风而动，各家模型百花齐放，百家争鸣，各家AI产品竞相发布，各类AI场景争相涌出，媒体铺天盖地的报道，一时间好不热闹，各类场合各色朋友，言必谈大模型。仿佛错过大模型，就是错过了泼天的富贵。既兴奋又焦虑，兴奋的是所谓人类奇点的来临，焦虑的是，大模型会不会一夜之间改变我们在众多领域的认知，大模型所信奉的大力出奇迹是否会作用在To B领域：

a. 会不会改变当下的To B商业模式、商业周期以及商业逻辑？

b. 当下的To B产品市场规律、方法、策略、财务模型是否还适用？

c. 在当下经济大环境下，B端客户如何看待AI？

机缘巧合，带着一系列好奇和疑问，有幸进入一家互联网公司做To B领域的大模型应用。这里只讲述从2024年3月中旬至11月底的实践过程和观察结果，并对比当下的To B商业模式，各位见仁见智。

2. 经历

a. 市场

2024年元月，该公司大模型战略正式发布，短短一两个月内，有近千家企业找上门，无论是进一步了解交流，还是方案咨询寻求合作，然而，截至2024年11月底，从市场到线索（MTL），再从线索到现金（LTC），最终的转化率几乎为0。

b. 产品

年初规划推出的一系列面向企业服务的大模型应用，在经历了上半年磕磕绊绊的项目历练和市场筛选后，最终只保留了两个产品，仍处于早期客户的挖掘阶段。

c. 项目

有价值的项目商机仍然来自公司的老客户，上半年被认为最有可能成单的三个项目：

1）A项目，客户需求蔓延，同时竞争对手介入提供了更多承诺，最终放弃；

2）B项目，上半年投入大量研发资源完成了项目一期，客户在拟订合同中增加了多项排他条款，禁止将产品输出给同行业其他客户，但截至11月末，仍未完成项目合同签署；

3）C项目，上半年提供了产品Demo，但一直未能了解客户的真实需求，下半年驻场调研，结果发现，客户现状远未达到产品所设想的目标场景，需要预投入大量的资源完成前期准备工作，举步维艰；

d. 业务

年初被梦幻开局冲破了头，定下了1个亿的业务目标，截至11月底，完成额只有小百万。落差之大，不得不令人反思。

3. 反思

反思一：对于市场风口的判断

对于战略发布会后的这近千家主动联系的企业，将其按照市场线索及商机管理分类，呈多个“二八法则”的分布：

a. 观望学习者居多，约占 80%

b. 有意向，需进一步挖掘需求的占 20%

c. 有明确需求，可立项、可共研共创的占 20%*20%

d. 满足上述条件，公司产品和技术可以满足需求的占 20%*20%*20%

e. 满足上述条件，公司商务跟得上，项目没被友商拿走的占 20%*20%*20%*20%

总结下来，就是看热闹的多，愿意掏钱的少。大部分只是想学习和了解，少数带着问题场景要寻找技术可行性，真正愿意花钱尝试解决问题的并不多，有明确场景需求的仍然来各行业的头部企业，而且是对数智化转型要求较高、走得较前的行业企业，他们有一定的战略视野、业务洞察以及技术前瞻力，愿意尝试早期新鲜事物，这类企业本身就屈指可数，又加之项目预算、技术可行性、方案匹配度、商务关系、市场竞争等因素，最终，在一系列“二八法则”的连续作用之下，从MTL到LTC转化率为0也在情理之中。网红式的带货方式，并不适合今天的To B市场。

这些听起来这都是马后炮，其实，Gartner技术成熟度曲线很早就总结了这个特点，也给市场大众提过醒，虽然一遍又一遍再强调，但面临上千家企业找上门的泼天富贵，不冲动不上头恐怕很难。任何技术的市场化，尤其是To B落地，都会经历几个时期，大模型的市场化并没有一飞冲天，它依然没能逃出Gartner技术成熟度曲线的一般规律。2024年从年初到年底，恰巧经历了萌芽期、膨胀期到泡沫期这个过山车。

反思二：To B业务元年目标的设定

基于年初对火爆的市场风口判断，公司年初定下的业务目标是年收入1个亿，当年实现盈亏平衡，在经历了上半年几个项目的艰难落地实践之后，7月份将业务目标下调为年收入3000万，10月份再次把目标下调到500万。

常年做To B产品的都清楚，一个软件产品从构想开始到年收入过亿，通常要7年时间，还要以方向正确、赶上风口、同时自己不犯错为前提，这是由To B业务的漫长商业周期决定的。因此，To B业务前两年的目标设定，通常以产品需求验证以及商业模式验证为主，业务收入通常只做参考，从第三年开始才会正式将业务收入以及业务盈亏平衡等财务指标作为关键业务目标。

To B业务元年，能摸清自己的技术能力，找到匹配的行业客户和场景需求，明确目标市场和产品需求，作出产品原型，完成产品需求验证和商业模式验证，算是取得重大成功了，因为80%的B端产品连业务元年的验证也难以完成。

业务目标不合理，业务拓展就会变形，以收入作为当下业务元年的目标，必然会导致饥不择食，忽视客观规律，忽略策略层面的分析和判断，尤其在客户场景需求挖掘、目标市场和产品定义还不清晰这个阶段。

反思三：To B早期产品市场策略的选择

a. 早期市场客群的选择及产品需求的甄别

产品的需求，是由产品所在领域的发展趋势决定的，领域中只有少数头部客户具备这种前瞻性，大量的客户只是行业的跟随者，因此，对于一个创新产品而言，在市场中选择早期赞助者客户完成产品市场验证极为重要。

不是所有的市场客户都是你的客户，同时，在市场的不同发展阶段，对目标客户群体的选择也不尽相同，尤其在早期市场阶段，不恰当的客户会对产品的关键策略带来误导，有些误导甚至是致命的。以收入作为当下的业务目标，必然会忽略对早期赞助者客户的慎重选择，带来的后果就是：不仅无法对产品需求作出有效的验证，甚至还会陷入到客户需求的沼泽和泥潭中无法自拔，更无法借助市场的保龄球道效应快速形成行业优势。

上半年的三个客户，并不都符合早期赞助者客户的画像要求，包括下半年产品市场化过程中，也没有将重点放在对早期赞助者客户有针对性的挖掘上，仍然试图用通用的市场手段广撒网，不仅浪费了有限的市场销售资源，也没有完成有效的产品市场验证。

b. 资源管理策略

无论外部市场如何天花乱坠，在产品早期阶段，都要合理控制资源投入，小型开发团队完成产品原型，尽快找客户做验证，再快速更新迭代，直到跨越鸿沟后，再加大市场和营销资源的投入。即使现在的硅谷投资，也要看到业务验证结果再判断项目是否值得投资，产品技术是否成熟？能满足哪些业务场景需求？带来哪些差异化价值？

如果在产品定义不清晰、市场验证没完成的情况下就贸然大规模市场化发布，投入大量市场及销售资源去找客户找商机，必然引发B端信任的消耗，以及对公司资源的严重浪费。因此，早期市场阶段，一定要重视资源的投入规模，以及不同资源的导入顺序和导入时机。

反思四：To B大模型应用落地，谁会成为主力军？

现阶段，虽然一众大模型厂商冲在前面，积极帮B端客户探索落地场景，但难以短期之内接过企业数智化的接力棒，原因如下：

a. B端场景需求及领域知识的壁垒（B端业务场景需求理解以及领域知识积累是个长期的过程）

B端客户这么多年对于行业、场景以及业务的沉淀和积累，历经20年才走完了信息化阶段，大模型厂商需要投入和花费大量的时间和资源完成领域知识的学习、理解、转化和实践这个过程，短期内难以突破B端领域知识的壁垒和障碍，即使从外部挖人挖团队，试图从组织层面快速补齐，但也很难在短期产生业务效果，因为现在组织内部的领导和团队不懂，依然难以对业务作出合理的分析和判断，因此，这个问题就演变为：组织内部要完成B端业务场景需求和领域知识的认知共识，然而，这种共识的形成是一个漫长的过程；

b. B端客户既有信息化业务的壁垒（B端业务从信息化到数智化的重构是个长期的过程）

B端客户通过多年的信息化承载了大部分的企业业务，不可能完全舍弃现有信息化底座另起炉灶搞数智化。从AI能力到业务场景，大量依赖定制化，同时，对于完整的客户需求，由于缺少传统产品所积累的功能打底，仅靠AI提供的部分功能或者AI产品原型难以实现完整的功能覆盖，需要大量的功能补齐，而这个过程又难免重复造轮子。因此，企业的数智化需要以当前的信息化为基础，在业务的某些点上，逐步将AI的能力引入进来，实现对当前信息化业务的AI升级改造。

最了解和熟悉B端客户场景和需求，最理解和掌握B端领域知识的还是做信息化的这批人，当前大量的信息化业务仍然掌握在他们中，比如企业自己的开发部门，外部的ISV开发商，以及传统B端产品厂商，他们需要逐步建立AI认知、掌握AI这门新质生产力，依托大模型厂商的AI能力支撑，一步一步对现有信息化业务进行解构以及AI重构，这又是一个长期而漫长的过程。

大模型厂商可以通过与传统供应链合作将AI能力输出，但难以绕过传统供应链另辟蹊径，除了某些低成本可以完成AI重构的简单业务场景，或者有某些新的业务场景和机会出现，业务的信息化和数智化可以一步到位。

c. B端传统生态和供应链的壁垒（B端新旧生态关系的重构是个长期的过程）

但大模型厂商做2B业务需要迎接的另一个挑战来自传统生态和供应链，从信息化到数智化必然会对现有的生态和供应链进行重构，然而生态和供应链并不是一天形成的，形成今天的格局有着错综复杂的历史原因，供应链和客户、供应链与供应链、客户与客户之间有着千丝万缕的联系，各种信任与利益关系需要在数智化过程中逐渐被重构，对大模型厂商而言，这又是长期且漫长的过程。

核心的核心，还是如何解决大模型能力与B端业务需求之间的鸿沟问题。

反思五：大模型B端落地场景

对B端业务场景和需求的理解几乎是目前所有大模型厂商的硬伤，同时，大模型在技术上还需要克服各类幻觉问题，通用大模型在垂直领域又欠缺专业性，因此，早期的大模型应用场景主要集中于企业的非核心业务，对精准性、实时性、重要性要求不高的场景，如企业知识库、员工培训、文案编写等，或者一些离线非实时辅助性场景，如数据分析、数据洞察等。对于复杂化业务场景，尤其针对精准业务逻辑和精准业务数据要求极高的实时交易类型或实时生产类型的核心业务，在很长时间内，难以交给大模型来自动化决策和执行，一方面在于技术层面，AI需要不断突破和扩展其能力边界，另一方面在于合规层面，仍面临错综复杂的问题和挑战。

4、感悟

a. 2B产品只有持久战，没有速胜论

b. 我非常赞同这家公司老板所说的一句话：“企业最大的成本是一把手决策失误的成本”。人总是不断重复错误，我们重复前人犯过的错误，你重复我犯过的错误，并习惯将别人的错误归咎于其个体原因，并没意识到错误背后隐藏的客观规律性。认识规律、尊重规律、按规律做事，对To B来讲尤为重要，建立To B认知的内部共识，对于一个To B组织而言尤为重要。然而不幸的是，组织内部共识的建立过程，是一个又一个不断重复的错误累积而成的。

c. 我们仍然相信，技术的变革一定会带来商业模式的变革，AI有朝一日一定会颠覆当下高成本低效率的To B商业模式，但这件事不会发生在今天，甚至未来多年也难以改变。To B业务没有大力出奇迹，只有日拱一卒。

最后，推荐一篇文章《2025年每一家企业，值得做一次从“N到1”的战略》。

2024，又是收获满满的一年。

阅读原文

跳转微信打开

“忘不了的人和事，才是真生命”

写在2022年最后一天

2022年是急剧变化的一年。

相信即将过去的2022年是打破多数人认知的一年，林林总总、大千世界中发生的每件事都在洗刷我们对这个世界的理解和认知。无常是常，变化才是这个世界的根本规律；不破不立，没有斗转星移、日月交替和四季轮回，怎会看到气象万千？你可能惊讶于这个世界变化的太快，自己难以跟得上，也可能惊讶于这个世界变得更复杂，自己无法理解，无论如何，这或许就是明天起床后我们的新常态，又或许，明天的世界会变得更快，更复杂。

依然清楚地记得15年前入职TrendMicro时老板的一句话：For change, I must change first.

2022年是深度思考的一年。

今年难得有大把的时间用于总结过去、学习新知识、展望未来。

今年终于把《演化的高级威胁治理》系列6篇文章全部更新发布了，够安全行业慢慢做上5年；同时发布了《大安全体系框架》，提出了传统网络安全和新型数字安全的分水岭，以及数字化安全原生的挑战；最后把过往多年的产品管理的心得整理成《产品管理方法论》供大家参考借鉴；除了发表的内容，还完成了几个未来领域的体系规划，有的和安全行业相关，有的和数字化转型相关，同时提交了几个专利，等待未来在不远处一步步到来；

今年最大的收获是认识了很多非安全行业的人，尤其是活跃在数字化转型最前沿的一部分有愿景、有预见、有洞察的思考者和行动者，他们带我跳出固有的行业和思维，打开了另外一个崭新世界的大门；迈进新的大门，不仅要补充新的领域知识，同时还要进一步夯实底层认知的逻辑体系，让自己走得更稳更远；

2023年是满怀希望的一年。

“忘不了的人和事，才是真生命”，感谢2022一起见过的人！

没来得及见的人，让我们2023再见。

阅读原文

跳转微信打开

如何打破产品战略规划的神秘感和主观色彩，让其有据可依，让大家都能理解？同时，在数字化转型之下，传统的产品研发管理模式是否还能适配，需要如何转型？这是本文所阐述的两方面重要内容。

如何打破产品战略规划的神秘感和主观色彩，让其有据可依，让大家都能理解？同时，在数字化转型之下，传统的产品研发管理模式是否还能适配，需要如何转型？这是本文所阐述的两方面重要内容，篇幅较长，请耐心阅读。

【第四篇：规划的逻辑】

白日    周丹

谈起产品战略规划，很多人认为这是拍脑袋的事，或者认为这是艺术家的活。写这篇的目的是让产品战略规划这件事更科学、更严谨、更有逻辑，让更多人看得懂，理解得了。

1. 战略的核心

要支撑战略决策和承接战略落地，就要先理解战略。谈起战略，大多数人认为是神圣不可及的事，尤其被某些咨询公司冠以“高度、视野、格局”等词汇之后，战略更被认为是“肉食者谋之”高高在上的事，然而，抛却华丽和神秘的外衣，战略的核心就是讲清楚两件事：“干什么事”和“怎么赚钱”，翻译成战略词汇，就是“业务闭环”和“商业闭环”，且这两件事各有三个灵魂拷问。对于业务闭环来说，需要回答三个问题：做什么？不做什么？为什么是我做（why me）？对于商业闭环来说，需要回答另外三个问题：干这事怎么赚钱？我赚哪部分钱？为什么是我赚钱（why me）？

图 8 战略的核心

这六个问题当中，这里只强调一个“不做什么”。无论做企业还是做产品，一定要有边界意识，知道自己擅长做什么，不擅长做什么，擅长的地方就努力做精，不擅长的地方就通过生态对接，然而，国内大多数企业很难守住自己的业务边界，认为这也能做那也能行，于是造成市场上大量重复且低劣的轮子。上篇提到的产品生态策略，其最大阻碍通常来自于研发部门的两句话：“这个我们也能做，那个我们也有”。不信你可以问问研发。

2. 需求究竟从何而来

当企业把上述六个问题想清楚弄明白之后，就到了怎么做的阶段，分解到产品战略规划，就是要依据战略长期方向明确相应的产品方向性需求（或称产品体系需求），进而根据产品方向性需求设计产品总体规划（或称产品体系规划）。那么，产品方向性需求究竟从何而来呢？

a. 对于这个问题，大部分人的第一答案是需求来自客户和市场。然而，长期靠客户和市场指导产品需求的通常是项目型企业，因为此类企业的业务模式就是客户说什么就做什么，客户要什么就满足什么，只要客户给钱就行，所谓的产品就成了一个个定制化项目；诚然，市场头部具备前瞻视野的客户可以提供大量有价值的前瞻性需求，但对于企业而言，并不清楚这些需求的本质以及背后原因和发展脉络，只是被动的响应这些需求，把这些需求做出来而已，企业和产品只知其然，不知其所以然，长而久之，项目型企业就逐渐沦为客户的人力外包团队；

b. 有人认为需求来自竞争对手。别人做了什么产品，产品发布了哪些功能，自己就跟着做，但长此以往，就会丧失产品的创新本质以及差异化的能力，最终导致产品同质化严重，最后不得不在低价中搏杀；

c. 还有人认为需求来自行业研究报告或者行业标准。行研报告通常是对行业现状的总结和发展趋势的预测，能写在行研报告中的，一定是已经有人在做的，并且做成的事情，对于产品跟随者而言有一定的参考价值，但能否超越早期对手，取决于对行业最前瞻方向和需求的理解认知；行业标准是业内多家企业所达成的交集和共识，事实上是所有行业产品必须满足的最小需求集合，因此行业标准只代表了产品的最低合规需求。

事实上，上述这些需求都是产品的表象性需求，那么，产品的核心需求究竟从何而来？如何才能挖掘到产品的核心需求呢？这里就引出了一个关键话题：规划的逻辑。

3. 规划的逻辑

总体规划通常分两步走。第一步是定义“演化的过程”：明确演化方向、划分发展阶段、标识属性特征，推导演化结果，即“预见未来（Foresee the Future）”；第二步是基于“预见”的结果，定义“体系的架构”：分析内部属性、分解外部特征、构建模型框架，设计体系架构，即“定义未来（Define the Future）”。

图 9 演化的过程

总体规划中最具挑战的其实就是定义“演化的过程”，大家一定会问，如何完成“演化过程”的推导和实现“预见未来”的能力？答案是“大胆假设、小心求证”，这个过程不仅需要感性思维的想象力，更需要理性思维的逻辑，大胆假设的想象力因人而异，不可言传，但小心求证的逻辑还是可以用模型解释清楚的，其核心思想是矛盾论：事物是由矛盾构成的，矛盾是事物发展变化的根本原因，可以通过分析事物的矛盾要素，推导事物的演化方向和演化结果。这里把从一个事物从节点A到节点B的演化逻辑抽象为如下三个过程：

图 10 演化的逻辑

a. 抽象

将一个事物在节点A的各种现象的关键特征进行抽象（不是总结、也不是归纳），还原其本质；

b. 演绎

基于事物的本质，对事物在节点A进行矛盾分析，找到其内部矛盾和外部矛盾，以及主要矛盾和次要矛盾。所谓内部矛盾和外部矛盾，就是影响事物发展的内部因素和外部因素，所谓主要矛盾和次要矛盾，对应的是各类因素的重要性和优先级；

矛盾是推动事物发展的根本动力，主要矛盾居于支配地位、对事物的发展过程起决定作用，因此，进一步对内外部主次因素进行分析和推导，可推演出事物接下来的发展方向和发展结果，由此可得到事物的下一个发展节点，即节点B；

c. 分形

较之节点A，节点B的内外矛盾和主次矛盾又发生了新的变化，围绕这些新的矛盾要素，一定会呈现众多全新的具体场景和表象（现象），节点B的内部要素及其各类外部场景和表象，一起构成了事物在节点B（未来的某个阶段）的内部属性和外部特征；

时时有矛盾，事事有矛盾，矛盾在事物发展变化过程中不仅会互相转化，还会不断发生变化，因此，要时刻关注各种矛盾要素自身的发展和变化，不断评估事物演化的过程和结果。重复上述过程，不仅可以完成事物从0到N的完整演化过程的推导，又可以完成各阶段假设结果的求证，此为总体规划的第一步，即“预见未来”，规划的前瞻性正体现于此。

总体规划的第二步，基于“预见”的结果，定义“体系的架构”：分析内部属性，是指根据内因找出事物的内部逻辑构成，以及各构成之间的相互关系；分解外部特征，是指根据外因找出事物的各种外部表象和对应场景，以及各种表象和场景之间的映射关系；构建模型框架，是指根据内部关系抽象出内在逻辑模型，根据外部表象抽象出外在呈现框架；设计体系架构，是指根据内在逻辑模型和外在呈现框架重构出完整的体系架构，即“定义未来”。

产品总体规划，也是依据上述过程，先通过演化过程的推导，得到演化结果，再以演化结果为目标对象，完成产品体系架构。回到本章节的核心问题，需求究竟从何而来，看到这里也就不言而喻了，产品的需求核心来自事物预期的发展规律以及演化结果，正确的产品需求来自对事物演化发展的正确判断，市场和客户的需求只是事物发展到一定阶段的必然产物，是最终验证规划预判和产品需求的方式。好的产品一定是引领市场和客户需求的，它会在不远的未来“等待”客户需求一步步到来，“等待”市场时机逐渐成熟。

4. 进入市场的时机和方式

好的规划不仅能正确判断未来领域的发展方向和发展结果，还能正确判断未来市场的启动时机，所以说，好的方向是规划成功的一半，好的时机是规划成功的另一半。做产品的目的是为了满足市场需求，如果市场需求始终没有到来，或者市场需求高点已过，一定要好好反省规划的市场时机是否恰当。过往有非常多优秀的企业，萌生过很多有前瞻性的规划和想法，但由于误判市场时机，过早或过晚进入市场导致规划失效、产品失败、战略失败的案例比比皆是。在这里，我们依照市场生命周期，根据企业进入市场的时机，将企业划分成四种类型：

图 11 企业进入市场的时机

a. 引领者

顾名思义，企业早于市场看到了新的领域机会，它引发创造了新的市场需求，是市场需求的引领者，是新兴市场的开拓者，同时也是早期市场和早期客户的教育者，属于上述引领客户需求一步步到来，开创市场并引领市场逐渐走向成熟的先驱；

b. 洞察者

在早期市场阶段，一定会有对市场较为敏锐的企业洞察到来自新兴市场的机会，并选择快速跟进，一起推动市场从早期阶段发展到主流阶段，属于对市场发展持有洞见的早期玩家；他们捕获市场机会的方式可能来自早期市场的客户，也可能来自第三方研究机构对新兴市场的分析报告等等；洞察者也许很早也预判了同样的领域方向，只是不确定市场到来的时机，不想第一个吃螃蟹，然而一旦市场出现声音，他们就会伺机而动；

c. 跟随者

一旦市场呈现爆发趋势，跟风的企业就会越来越多，他们或抱着分杯羹的心态进来参与，或基于竞争策略被迫选择跟随，或看到市场逐渐企稳向好，市场技术日趋成熟，此时进入市场风险较小，林林总总，最终，众多跟随者共同助力快速将市场推向龙卷风暴和主街；同样，在这批跟随者当中，仍然不缺少对领域有前瞻看法的企业，他们愿意先观察着这个市场的变化以及赛道中各个赛手的表现，待上述时机成熟再以生态、投资、并购赛手等方式进入市场；

d. 滞后者

出于各种原因，总会有市场判断和市场响应较为迟缓的企业，此类企业或缺少远见、或缺少资源，或出现严重市场误判，最终丧失了市场时机，如果市场在自身业务边界之内，同时又符合战略目标，丧失机会就意味着自杀，市场竞争犹如逆水行舟不进则退，业务踏空可能面临整体被淘汰的风险；

找准市场的方向和时机很重要，进入市场的方式也同样重要。企业或者选择躬身入局，从产品研发一步步做起，或者选择生态引入或OEM引入，还可以选择战略投资的方式介入市场，有甚者还会选择收购并购赛道上的选手进入市场，等等不同方式。每个企业对于市场机会（Opportunity）的判断、进入市场时机（Timing）的判断以及进入市场方式（Way）的选择都不一样，取决于企业的战略方向、商业模式、风险偏好、经营策略、竞争态势、企业规模、发展阶段、资源配比、财务状况、企业文化、技术路线等等一系列因素。引领者未必能笑到最后，也可能成为先烈，洞见者未必不能将引领者取而代之，跟随者未必不能赚的盆满钵满。无论怎样，企业首先要具备规划未来领域发展方向的前瞻能力，其次再根据自身情况选择进入市场的时机和方式。

由于篇幅有限，上述理论在这里不便通过案例和实践展开，看起来会觉得烧脑和干涩。的确，规划过程集合了一个人或一个团队的抽象思维、逻辑思维以及体系思维等综合能力，同时，还需要大量认知和经验的支撑。

【第五篇：研发的架构】

白日    周丹

开篇讲过，产品研发管理的职责是依据产品体系规划的要求对每个相关产品进行详细规划，明确每个产品的具体需求并给出产品详细设计，最后根据产品详细设计研发出所需要的产品，解决产品“怎么做”的问题，其核心是对接能力和需求；传统产品研发管理所涉及的项目管理、需求管理以及团队管理大家都非常熟悉了，这里不多赘述，今天在数字化转型之下，传统的产品研发管理模式是否还能适配？需要如何转型？这是本篇所探讨的内容。

1. 研发管理的挑战

传统研发管理过程中广泛存在三大挑战：一是来自组织的挑战“混淆研究、开发和定制”，二是来自业务的挑战“需求响应”，三是来自人的挑战“代码艺术家”。

a. 混淆研究、开发和定制

我们一直在讲的“研发”，事实上包括“研究”、“开发”和“定制”三件事。先说“研究”和“开发”，“研究”关注的是领域方向创新以及核心技术公关，“开发”关注的是产品工程化，虽同属研发体系，但侧重点不同，价值提供也不同，然而大多数企业只重视“开发”和“定制”，忽略或者混淆了“研究”，没有研究，企业找不到领域的发展方向，产品会缺少创新动力，失去核心技术支撑，最终会被市场所遗弃；再说“开发”和“定制”，大多数企业认为开发就是按照用户的需求完成定制，项目型企业这样理解没有问题，产品型企业这样理解就会有问题，核心问题在于无法区分哪些是领域需求，哪些是场景需求，哪些和技术有关，哪些和业务有关。因此，如何对研究、开发和定制进行区分和定位，如何划分组织和团队职责，如何在方向、价值和目标上协同一致，这是研发管理需要解决的第一件事；

b. 需求响应

造成需求变更的原因有很多，比如原始需求不清晰，需求本身发生了变化，不断有新的需求提出，需求传递过程中出现信息偏差等等，软件行业响应需求的方式主要依靠软件工程，无论是瀑布模型、快速原型、极限编程、还是敏捷开发等等，其核心都是为了保证做出来的产品符合需求要求。传统方式下，大量的需求需要依靠文档的方式记录、保存、更新和传递，项目团队需要花费大量的时间和精力确保需求理解的准确性、完整性和一致性，然而，无论用哪种软件工程模式，最终产品和原始需求之间总会存在或多或少的差异。数字化转型之下，需求产生和需求变更的频次会呈级数增长，用户业务要具备敏捷性，具备随需而变的能力，传统软件开发和交付方式是否具备快速且准确对接用户需求变化的能力，这是研发管理需要解决的第二件事：如何快速准确响应需求？

c. 代码艺术家

做过研发管理的人都知道，每个研发团队中都会有一两个叫“张三”的关键人，只要张三在，出现重大问题就能搞得定，项目就有保证，老板就放心，一旦张三不在，项目马上就塌，老板就心慌。“张三”是让研发管理者又惊又喜且又难以拿捏的一类人，通常称之为“代码艺术家”。代码艺术家在技术领域有很深的造诣，是各类技术的带头人，也是项目的中流砥柱，但是项目的成功如果取决于代码艺术家的个人技巧和能力，而不是依靠架构和体系力量的保障，那么代码艺术家就会成为项目中的重大风险，这样的项目通常不会长久，这样研发的产品也会举步维艰。因此，研发管理需要解决的第三件事：如何使用代码艺术家？

事实上，上述个三方面挑战并不是今天高科技企业才遇到的，传统工业化时期就遇到过同样挑战，并且工业化时期的成熟工厂模式已经给出了解决方案。大家是否留意，国内大多数开发都是面向成品的开发方式，也就是说，需求描述的成品是什么样子，研发就按照什么样子进行开发；而国外大多是面向工厂的开发方式，也就是先造机床、先建产线，再把零件和流程打造好，最后完成面向成品的装配，同样的机床、同样的产线，今天生产汽车、明天生产坦克，这种方式在早期投入的成本比较大，但是工厂一旦完成，其生产效率和对接各类需求的能力会极大提升，早期手工作坊和现代化工厂的差距可以说明一切。工厂不仅是将能力和需求对接制造产品的地方，同时也是将创新和工程、技术和业务、系统和人进行解耦的一种架构方式，这种模式同样值得研发管理学习和借鉴。

2. 研发的架构

综上，研发管理可以通过以下三方面的架构调整，实现创新和工程、技术和业务、系统和人的解耦，用系统和科学的方式解决上述三方面挑战：

图 12 研发的架构

a. 组织架构：将创新和工程解耦

从组织上，有人要研究设计何种工厂、机床、流程、零件以及如何设计，有人要建造厂房、机床和产线，还有人要生产零件，调整流水线，最后还要有人完成组装，因此，从组织架构视角，一个研发组织可以划分成核心研究、生产开发以及定制集成三个部分。

核心研究偏向领域细分研究以及核心技术公关，是创新型组织（Innovative Group），关注的是创新能力，最终关系到企业的领先性和竞争优势，而生产开发和定制集成偏向技术工程化（Technology Engineering）和业务工程化（Business Engineering），是工程化组织（Engineering Group），关注的是生产力、质量、成本、效率和交付能力等，虽然前者会给后者提供能力支撑，但二者的目标、过程和产出截然不同，因此，研发管理需要从组织架构上对创新和工程进行解耦，把研究和开发、定制划分开。

图 13 研发的组织架构

b. 工程架构：将技术和业务解耦

工厂的生产开发部门需要考虑如何构建机床和产线作为生产的基础平台，再根据定制集成的需求快速生产相关零件、调整相关流程，最后由工厂的定制集成部门把相关零件按照相关流程装配成所需的成品交付给用户。大量的基础平台工人、零件工人和流程工人不需要关心成品的样子，只有定制集成部门才需要看用户的成品需求设计图纸，然后分解所需的零件、分解装配流程、分解项目管理和质量管理等要素，最后完成成品装配。

虽然生产开发和定制集成都是工程化组织，但成熟工厂体系已经将两者进行了剥离。生产开发侧重技术工程化（与领域需求相关，这些领域需求来自产品战略规划输出的演化过程和演化结果），负责将满足行业80%以上领域需求的技术能力封装成基础框架、基础平台、基础零件和基础流程等基础架构；定制集成侧重业务工程化（与场景需求相关，这些需求来自用户的实际业务），负责对接上述基础架构和来自用户最后一公里的实际业务需求，最终装配出成品。

图 14 研发的工程架构

企业的生产开发，需要由面向成品的开发，转到面向基础框架、基础平台、基础零件、基础流程等基础架构的开发，然后交付给最懂业务的定制集成人员，甚至是用户自己的业务人员，再由他们完成最终的成品装配，从而保证从业务需求到成品交付的快速对接和无损落地。上述过程的核心，是将领域需求和场景需求划分开，从工程架构上实现技术和业务的解耦，打破业务对技术的依赖，让懂业务懂需求的人直接参与业务的构建和实现，将需求快速并准确地转化为成品，想到即做到，让业务人员专注业务本身，而不用关心技术实现。

在上述过程中，与产品相关的研发管理主要集中在生产开发环节，产品研发经理需要根据产品体系规划的要求，完成基础框架、基础平台、基础零件以及基础流程等基础架构产品的需求细化以及详细设计，由于这些产品的需求和设计与技术能力承载相关，与用户具体场景无关，因此，产品研发经理不仅要具备高度的解耦能力和抽象能力，还要具备扎实的系统架构能力。

另一方面，对于定制集成人员或者用户自己的业务人员而言，要通过业务工程化将上述基础架构和实际业务需求快速对接完成成品定制集成，此过程的最大挑战来自于需求结构化，原始需求是混沌的、杂乱的、没有条理的，只有将需求结构化，理清业务边界、业务构成和业务逻辑，才能实现对业务需求的准确和快速响应。

c. 技术架构：将系统和人解耦

代码艺术家擅于使用技术技巧解决难题，这种能力非常适合技术研究领域，然而在工程化领域，试图通过技术技巧解决复杂系统问题反而会引入更多新的问题，一来二去，系统复杂度反而会成倍增加，人和系统的耦合度也会越来越高；解决复杂系统问题的方式有很多，架构无疑是最科学的方法，架构的核心是解构、抽象和重构，先将复杂系统解构成多个原子构成，再抽象成简单模型，最后基于模型重构体系，架构是将复杂系统简单化的有效方式。

通过上述工厂模式在组织层面和工程层面的解耦，事实上已经把大型复杂系统解构并降维到多个简单场景和环节，对全栈型代码艺术家的依赖已大幅降低，但是在技术层面，仍然需要通过技术架构对每个场景和环节的具体问题进一步解构和降维，降低问题的复杂度和难度，从而降低岗位对个人技能的要求，张三能干，李四王五也能干，从技术架构上实现系统和人的解耦，完成复杂系统对应的大量岗位只需要熟练工，而无需艺术家，这种方式不仅可以保证系统的成功，同时也将个人对系统的影响降到最低。

3. 数字化转型的挑战

事实上，工业化时期催生并运用了大量系统工程和管理科学的方式方法，上述三方面的架构思想也是工业化时期的产物，在今天看来并不是什么新鲜事，然而，相较成熟的工业化管理，当前的研发管理还处于相对早期的发展阶段，还存在大量作坊式的小团队，上述架构思想仍然值得我们借鉴和学习，因为接下来的数字化转型会改变传统的生产力和生产关系；就供给侧而言，数字化转型对传统研发的影响，一定不亚于工业革命对传统工场手工业的影响，传统研发模式也一定会被数字工厂模式所取代，与数字化转型关系巨大的软件行业，一定会走上软件工业化的道路。企业要数字化转型，支撑转型的研发供给侧必先践行数字化转型，如果研发自身从组织、管理到技术都不知道如何理解和实践数字化转型，给客户谈数字化转型就是一句空话。

【结束语】

上述五篇文章，均来自过往20多年相关工作的积累、总结和抽象，尝试以产品为金线，将企业战略规划、研发管理和市场营销三大体系的有机串接起来，并实现企业资源的优化配置。旨在让更多To B领域高科技产品企业知道如何构建并管理完整的产品管理体系，了解产品管理对一个企业的价值和意义，同时也让更多人清楚企业资源配置的决策依据，熟悉产品市场营销的一般策略，揭开产品战略规划的神秘面纱，并且打破产品研发管理的传统认知。

图 15 产品管理方法论

数字化转型的暴风雨即将到来，既是一场革命，也是一场机遇，企业能否承受住未来的钢铁洪流，顺应时代发展的趋势，一定是让每个企业负责人或焦虑或兴奋地睡不着觉的问题。

本文只着重介绍产品管理的体系、框架和方法，篇幅有限，相关案例和实操这里不做展开，有兴趣的朋友欢迎私下联系讨论，可公众号留言或加个人微信：PEPSI_NJ

借此，感谢我最尊敬的良师益友童宁先生，童宁先生是产品管理领域的大师，是我进入产品管理领域的带路人，他教给我很多产品管理的理念和方法，非常乐于分享自己对于产品管理的理解、观点以及实践经验，感谢童宁先生对本文核心思想和体系框架的指导和建议；其次，感谢我入行时遇到的恩师彭涛先生，虽然在一起共事只有短短几个月时间，其体系化和架构化的思维方式，在我工作二十余年中一直深深地影响着我，并让我受用至今，感谢他对本文的审阅以及宝贵意见；同时，感谢本文的合作者周丹先生，周丹先生拥有近30年的银行工作经验，在金融科技领域研究颇深，对事物的抽象能力、对本质的洞见能力，对分析的逻辑能力以及对未来的预见能力让我受益匪浅，同时为本文的关键理念、方法和模型的形成提供了至关重要的指导和建议；最后，感谢2022，这个充满变幻的一年。

余不一一。

【完】

阅读原文

跳转微信打开

本篇主要阐述产品管理的职责框架：产品战略规划、产品研发管理以及产品市场营销，并着重讲述产品市场营销的策略以及产品市场经理的职责。

【第二篇：职责的框架】

上篇文章讲述了产品管理的首要职责，是为企业资源配置提供决策支撑，接下来阐述“职责的框架”，是为了让大家对产品管理的职责有个完整的概念，了解职责划分、职责内容以及职责关系。产品管理按职责可划分为产品战略规划（Product Strategic Planning）、产品研发管理（Product R&D Management）和产品市场营销（Product Marketing Management）三个部分，通过产品战略规划从上到下承接企业顶层战略的落地，通过产品研发管理和产品市场营销从后到前衔接内部研发和外部市场，具体关系如下：

图 6 产品管理的职责框架

产品战略规划的职责是支撑企业战略决策以及承接企业战略落地。企业顶层战略明确企业的长期方向，即“干什么事”以及“怎么赚钱”，产品战略规划要依据企业的长期方向明确相应的产品方向性需求，制定产品总体规划（或称产品体系规划），并完成规划论证，产品体系规划要进一步明确相关的产品构成以及产品与产品之间的相互关系，最终明确“做什么产品”和“卖什么产品”，其核心是通过产品对接战略、能力以及市场；

产品研发管理的职责是依据产品体系规划的要求对每个相关产品进行详细规划，明确每个产品的具体需求并给出产品详细设计，最后根据产品详细设计研发出所需要的产品，解决产品“怎么做”的问题，同时，支撑产品市场发布（Product Marketing Launch）和产品市场营销（Go to Market，GTM），并根据市场营销的反馈进一步优化和提升产品，其核心是对接能力和需求；

产品市场营销的职责是依据产品体系以及对应的具体产品，结合产品的市场需求，市场发展的阶段、产品自身的成熟度、复杂度以及标准化程度、产品所处业务及商业闭环上下游依赖关系、市场竞争对手的状况等内外部因素，制定并执行符合产品体系和具体产品特性的市场营销策略，解决产品“怎么卖”的问题，其核心是对接产品和市场；

在不同的企业，这三者职责可能集中在一个部门，也可能分散在不同部门，这三者职责可能对应一个人，一人分饰三职，也可能对应多个人，每人各司其职，完全取决于企业当前的发展状况、企业对于产品职责的定位、产品经理资源的多少以及产品的重要性和优先级。早期初创企业大多是创始人一肩挑，企业初具规模后会由几个人的小团队承担完整职责，企业做大之后会成立多个部门由多个团队来承担，但无论如何，这三者需要统一管理，协同一致，避免分而治之，彼此割裂。企业组织架构要适配这种关系，这样才能确保三者之间的体系关系得以正确的方式持续且高效运行，从而构成企业最强有力的核心发动机。在我原来的企业，每逢重要战略级产品，CEO总是亲自挂帅产品经理，主导规划、研发和市场的相关工作，并统筹各方资源，既凸显了产品的战略重要性，又高效贯彻了战略的原本意图，避免层层管理过程中的理解和执行偏差，最终确保战略产品的顺利落地。

【第三篇：市场的策略】

熟悉产品市场营销的朋友可以略过本篇。
1. 市场营销和销售的区别

讲完职责的框架，接下来先讲产品市场营销，虽然大家对市场营销这个词不陌生，事实上很多人依旧把市场营销和销售混为一谈，因此，有必要帮大家区分清楚，什么是市场营销（Go to market）什么是销售（Sales）。先说共同点，两者都关心产品怎么卖，最终目标都是为了把产品卖出去；再说区别，市场营销侧重目标市场选择、销售途径和方法、产品定价与折扣、生态与竞争关系等策略（Strategies）的制定和实施；销售通常是按照市场营销的既定策略，执行最后一公里的销售动作，最终签单把产品卖出去，考量的是执行层面的销售技巧（Skills）。

2. 市场营销的策略

谈及市场营销策略，诸如跨越鸿沟、龙卷风暴、科特勒6P模型、波特五力模型、STP分析、SWOT分析、4C、4R等等经典理论比比皆是，这里不做赘述。本篇主要从宏观角度介绍产品市场营销需要重点关注的几个维度：

图 7 市场营销的策略

a. 市场策略

这里的“市场”是指目标客户群体，也叫市场定位，市场策略是指对于目标客户群体、目标行业领域的选择，也叫市场划分和市场细分。把市场策略放在第一位，意味着首先明确你要把产品卖给谁？谁是你的客户？这个问题需要考虑几方面要素：1、产品解决哪类市场和客户的哪些方面问题，谁是潜在市场和客户？2、判断产品对应的市场处于哪个发展阶段？是早期市场？成熟市场？还是衰退市场？3、判断产品自身的所处的发展阶段，产品原型时期，产品快速迭代时期，还是产品稳定时期？在不同产品市场阶段，对于目标客户群体的选择大有讲究，不同时期选择不同行业不同客户作为目标市场非常重要。对于早期产品市场阶段，大家可以参考《跨越鸿沟》，这本书从理论到实践讲述了选择早期赞助者以及保龄球道的重要性，也就是如何选择早期目标客户群体。

b. 销售策略

销售策略包括产品销售途径、方式以及话术的设计和制订。产品销售途径可分为直销和分销（包括渠道代理、总代包销、生态带货等），此时要考虑产品的销售目标和销售政策如何制订；产品销售方式就是我们常说的销售打法，面对不同的行业用户、区域用户以及某类用户群体，应该采取什么销售技战术措施；产品销售话术（Sales scripts）是面对客户交流前准备的一套完整自洽的问答脚本，包括：了解现状、抓住痛点、引发需求、达成共识，然后介绍场景、解决方案、产品技术、竞争优势、预期效果、价值收益等相关内容。销售策略的制订，首先要看产品的属性，哪些是标准流水型产品，哪些是复杂交付型产品，其次再看产品和市场发展的不同阶段，需要因地制宜进行调整。产品销售策略不仅关系到让销售如何去卖产品，产品如何卖得好，还关系到产品签单方式、交付方式、验收方式、回款方式、确收方式、To B各环节利益分配方式，以及企业财务、法务、商务以及销售合规等一系列问题。

c. 竞争策略

竞争是市场发展到一定阶段的必然产物，市场无法避免友商和竞品的出现，同时，市场也需要竞争，有竞争才能成能叫市场，没有竞争就成垄断了。基于产品提升的良性竞争，有助于帮助客户获得更多的产品价值，促进行业和产业的发展，而基于产品低价的恶性竞争，长期将不利于整个市场的发展。关于在充分竞争的产品市场阶段如何制订科学的产品竞争策略，《龙卷风暴》、波特五力模型等都给出了较为完整的理论和技战术指导。回到战略高度，对于高科技产品公司来说，创新才是取得竞争优势的首选法宝，只有持续不断的创新，才能让产品永葆竞争优势。

d. 定价策略

产品定价（Pricing）一直是国内企业不太擅长的领域，常常碰到项目操作猛如虎年底一算二百五这种情况。国内企业习惯了按人头算成本的报价方式，不擅于产品报价。诚然，这跟国内强势甲方的采购习惯有很大关系，但更多的是项目型企业和产品型企业的本质差别。产品定价（公开价格、折扣价格等）需要同时兼顾多种因素，如：客户价值提供、市场稀缺性、产品成本构成、产品利润率指标、产品收入的连续性、竞争对手产品价格、各商业环节利润分配空间、项目重要性等等。科学的价格体系，会让产品维持良好的利润率，有充裕的资源投入产品创新，会吸引商业合作伙伴带来更多商机，会让竞争对手游离在投入产出比的边缘；非良性的价格体系，不仅让企业无法持续经营，甚至把一个新兴的细分行业逼入死角，出现劣币驱逐良币，影响市场价值判断，误导客户，造成客户找不到优质产品等恶劣问题。

e. 反馈策略

产品反馈包括正反馈和负反馈两个方面，既包括自身产品反馈，又包括竞争产品反馈。正反馈可以了解客户为什么选择你的产品，哪些功能匹配解决了哪些客户场景问题，哪些功能最能打动客户，是人无我有人有我优的，如何进一步巩固和加强产品优势，筑起产品技术的护城池；负反馈可以让你清楚地知道产品的能力弱点在哪里，需求遗漏点在哪里，接下来再考量如何投入研发把产品的木桶短板补齐。产品反馈策略既是产品市场需求验证的有效手段，也是产品能力验证的有效方式，同时也是快速打磨产品，打造产品场景的有效途径。

f. 传播策略

市场传播策略的目的是让市场和客户听到你的理念、观点、战略、品牌、产品、技术、场景、方案、案例等等，常见的传播方式有：用户Newsletter、企业公众号、客户/渠道/技术/合作伙伴峰会、产品/战略发布会、行业/产业专家座谈、客户沙龙、方案/技术/案例分享会等等，除此，市场传播策略还要掌握传播时机、传达内容、受众对象、预期效果等要素，市场传播策略在产品市场化过程中至关重要，它是教育市场、教育客户、宣传造势、展示自我、吸引商机的非常重要的手段。

g. 生态策略

产业分工越来越细化，单一产品越来越难形成完整业务闭环和商业闭环，因此，构成业务闭环和商业闭环的所有上下游资源需要有机协同，形成生态。生态策略主要关注如何借势和借资源，不仅要充分考虑多个需求场景下的技术生态，还要考虑不同市场场景中的商务生态。生态听上去比较软性，似乎可有可无，甚至短期无法看到效果，但生态可以依靠利益结盟的方式，让每个构成生态的单点聚合在一起，实现价值最大化。同时，任何生态体都是既合作又竞争的关系，所以，产品生态策略还要同时兼顾合作和竞争，求同存异，妥善处理合作和竞争的关系。

3. 产品市场经理的职责

综上所述，产品市场营销策略是企业顶层战略中实现商业闭环的具体细化指导措施，而不是教销售怎么拿项目和打单子。与产品市场营销职责对应的岗位是产品市场经理（Product Marketing Manager，PMM），PMM需要参与到一线活动中，协助销售参与客户交流、参与项目方案讨论、参与产品问题解决，目的是了解一线的实际情况，把握产品市场的脉搏，最终更客观、更有效、更及时的制订、验证和调整相关策略，但PMM的职责不是销售和售前，不是解决方案架构师，也不是售后技术支持，更不是项目经理。PMM需要把大量的精力用于思考策略的制订和优化，和客户、渠道、合作伙伴、销售、售前等干系人的沟通交流要关注策略是否有助于拓展客户和渠道、增加客户需求意愿、提升产品销售业绩、满足企业利润要求、增强合作粘性、提高市场影响力、改善产品质量等方面。

产品市场营销策略不是一成不变的，它围绕产品和市场的各方因素，因时因势不断发展变化，把产品当作内因、把市场当作外因，PMM需要时刻保持产品和市场的敏锐度，通过调研、制订、验证和调整四个过程，持续评估并优化产品市场营销策略，提前对市场做出正确的判断和响应。

下一篇将给大家带来“规划的逻辑”以及“研发的架构”两部分内容，帮助大家揭开产品战略规划的神秘面纱，打破产品研发管理的传统认知，是衡量产品管理功底和产品管理思维的重要能力标尺， 敬请期待，如有疑问需进一步讨论，可公众号留言或加个人微信讨论：PEPSI_NJ

【未完待续】

阅读原文

跳转微信打开

产品管理阐述以产品为金线，理解、构建和​管理企业的市场营销、战略规划和研发管理三大体系，并为企业经营者提供资源配置决策支撑的相关方法。本篇着重阐述产品管理的首要职责：为企业资源配置依据提供决策支撑。

【前言】

本文所阐述的观点均针对 To B市场中的产品类型企业，尤其是高科技产品企业，其中也包括客户是B端，最终用户是C端这种场景，但不包括以用户极致体验为产品需求，以羊毛出在猪身上为商业模型的To C产品范畴，此为约束条件；标题所言产品管理方法论，事实上是阐述一个企业如何理解、构建和管理其战略规划体系、研发管理体系以及市场营销体系，并为企业经营者提供资源配置决策支撑的相关方法，这几个方面对于任何高科技产品企业都至关重要，但大多数情况下这几者是各自为政分开讨论的，缺少有机关联，然而产品恰恰是天然串接的金线。

市面上关于产品管理和产品经理的书籍、文章、论述、培训、讲座、案例不胜枚举，其中不乏有见解的观点，但高质量、体系化的论述并不多；身边喊着做产品的企业和产品经理也越来越多，但真正具备产品思维的企业和产品经理并不常见；产品管理是企业的核心发动机，它从下到上支撑企业经营决策的制定，从上到下承接企业顶层战略的落地，从后到前衔接内部研发和外部市场，对产品有深刻理解和认知的企业，其经营状况通常都不差。

有些企业推崇技术驱动，诚然，没有技术支撑，产品无法落地，没有核心技术，就无法构筑市场竞争壁垒，转化为高额利润，但技术只提供了“使能”（Enable）的条件，将技术匹配到合适的市场需求，再转化为商业订单，恰恰需要产品的对接，缺少产品方向的指引，会让好技术无用武之地，会让大多数技术会陷入“屠龙之技”的尴尬境地；还有些企业标榜市场驱动（客户需求驱动），诚然，紧跟市场需求，保证产品不会跑偏，总有客户买单，但市场只提供当下的需求，无法确定当下市场的偶然性和必然性、有效性和长期性，更无法预测下一个市场机会，长此以往只能成为市场的跟随者和被动响应者，在红海市场中与人搏杀，而无法成为市场和趋势的引领者。

事实上，很多企业都对产品抱有愿景，但当下有太多企业不知道如何做产品，不知道如何通过产品管理实现企业资源优化配置，更不清楚如何通过产品构建战略规划体系、研发管理体系以及市场营销体系，导致企业资源管理混乱，缺少战略高度、决策短视、产品和项目无法区分、长期陷入项目的泥沼、误把客户需求当成产品需求、无法把握市场的脉搏和先机、到处都是友商和低价竞争，或者技术好而市场认可度不高、开创了市场却被别人篡取了红利，得势不得分等等不如预期的结果，因此，产品管理对一个企业至关重要，然而，有些人认为产品管理是拍脑袋或者耍嘴皮就能做好的，还有些人会把好的产品经理神话成艺术家或者哲学家，写本文的目的也是让大家打破对产品管理的各种误读和偏见，让大家了解产品管理应当关注和具备的一般方法论。

接下来，本文将依次从产品资源配置、产品职责框架、产品市场营销、产品战略规划以及产品研发管理五个方面，通过“资源的配置”、“职责的框架”、“市场的策略”、“规划的逻辑”以及“研发的架构”五篇文章，阐述以产品为金线，理解、构建和管理企业的战略规划、研发管理和市场营销三大体系，并实现企业资源优化配置的相关方法。

【第一篇：资源的配置】

从企业经营者角度来看，经营业务需要匹配资源，对于一个高科技产品类型企业而言，如何通过产品将各类企业资源正确的匹配在一起，需要有一套强大而科学的判断依据。本篇将以众多产品管理理论和实践为基础，介绍产品管理的首要职责：为企业资源配置提供决策支撑。

1. 产品管理的通识

a. 什么是产品？

产品是具备商业属性的交付物，其中“具备商业属性”是指满足“供需关系”和“价值交换” 两个基本条件。

b. 为什么做产品？

产品是一种商业模式，是通过满足最广泛的共性需求，获取长期可复制的市场长尾收益，最终使得边际收益最大化的一种方式。

谈到产品管理，相信大家对以下几个方法模型耳熟能详：

c. 产品生命周期理论模型

图 1 产品生命周期理论模型

传统的产品生命周期（Product Life Cycle，PLC）是指产品从进入市场到退出市场的周期性变化过程，它是指产品的市场寿命，而非产品的使用寿命，一般分为引入期、成长期、成熟期、衰退期四个阶段。现在的产品生命周期通常将产品构思（Idea）到产品发布这段研发期作为产品生命周期的起始阶段，将产品进入衰退期并完全退出市场作为产品生命周期的结束阶段，与此同时，其替代产品或下一代产品会进入新一轮产品生命的迭代周期。

产品生命周期理论主要让大家明白一个产品的完整生命周期大概会划分成哪几个阶段，在产品生命周期的不同阶段，销售量、利润、现金流、客户、市场竞争等经营要素都会有哪些不同特征，以及会推荐采用哪些市场营销策略。

表 1 产品生命周期各阶段特征

d. 产品市场生命周期模型

图 2 技术采纳生命周期模型

产品经理应该都熟悉《跨越鸿沟》一书中提到的“技术采纳生命周期模型”, 该模型也被称作“鸿沟理论模型”。该理论的核心有两点：其一是阐述在高科技产品发展的不同阶段，其目标客户群体的演化过程，对企业而言，其价值在于根据产品发展的不同阶段，如何正确选择目标客户群体（即目标客户市场的选择）；其二是提醒企业注意产品的早期市场和主流市场之间存在的巨大鸿沟，并建议企业如何采取策略完成从早期市场到主流市场的鸿沟跨越。因此，本文把该模型归类为“产品市场生命周期模型”。

e. 产品技术生命周期模型

图 3 Gartner技术成熟度曲线模型

经常看Gartner技术报告的人对上面这张图应该不陌生，一个产品（领域）是由众多技术构成的，产品（领域）在不同发展阶段所需要的技术集不同，同一时期不同技术的成熟度和成熟时间不同，最终反映了产品（领域）在不同阶段所展现出的技术成熟度如何影响客户（市场）对这个产品（领域）采纳的期望和信心，本文把该模型归类为“产品技术生命周期模型”。

值得大家注意的是，该成熟度曲线在最高点传达了一个关键信号，该信号代表客户（市场）对一个产品（领域）的理解和认知超过了企业供给侧，相关期望和需求也完全超过目前产品（领域）技术所及，于是客户（市场）对该产品（领域）出现了信心崩塌，前期膨胀的泡沫迅速破裂，期望值瞬间坠入谷底，该现象的发生时间与上述市场鸿沟的发生时间基本吻合，同时该模型对于市场期望出现断崖式下跌的判断与上述“鸿沟理论模型”中对于鸿沟的判断也基本一致。

综上这些模型，分别以产品的技术和市场作为内外部关键要素，通过不同的视角告诉产品管理者如何正确理解和看待产品自身发展、产品市场发展以及产品技术发展的一般规律，同时告诉产品管理者产品发展过程中会遇到哪些坑，以及“什么时期该执行什么样的产品策略”。

2. 产品生命周期资源配置

从企业经营管理的角度来看，“什么时期该执行什么样的产品策略”意味着“什么时间投放什么资源以及多少资源做什么事情”，其核心是如何做好产品生命周期的资源配置。

图 4 产品生命周期资源配置模型

在完整产品生命周期中，通常会涉及三类大规模资源的有序投入，分别是：

a. 研发资源

产品在投放市场之前，需要完成早期的需求分析、规划设计、可行性研究、核心技术公关以及产品原型开发等工作；投放市场之后，需要快速验证产品功能和市场需求，加速产品版本的迭代和发布，并且在跨越鸿沟之前，需要加大研发的资源投入，创造以产品为中心的价值属性；跨越鸿沟之后，仍然需要持续增加研发投入，满足以市场为中心的价值属性要求；在产品进入成熟期后，产品各方面需求日趋减少，所需研发资源也随即减少；产品进入衰退期后，仅需要保留少数研发人员做产品维护；与此同时，其替代产品或下一代产品的研发工作又拉开了帷幕，新一轮研发资源投放又启动了。

b. 市场资源

产品在早期研发阶段是不需要引入市场资源的，甚至在市场的引入期，在寻找早期技术赞助者和寻找保龄球道的过程中，也不需要太多市场资源的介入；然而，一旦产品跨越了鸿沟，得到了实用主义者的认可，开始进入早期大众市场，开启主流市场航道，就需要全力加大市场资源的投入，迅速攻城略地抢占市场；当市场进入成熟期，客户和市场趋近饱和，市场资源投入将逐渐减少，直至产品衰退并退出市场。

c. 运营资源

产品在跨越鸿沟之前不需要过多的运营资源，跨越鸿沟后，市场资源投入多，商机多，订单多，涉及到的运营资源就越来越多，常见的运营资源包括：订单管理、合同管理、财务管理、人力管理、生产管理、供应链管理、物料管理、备货管理、库存管理、授权管理、物流管理、交付管理、售后管理、培训认证等等一系列相关配套，这些运营资源按照既定流程彼此分工合作，相互协同支撑。产品发展到成熟期，竞争越发激烈，产品价格会逐渐降低，这个时期维持产品利润的最好方式就是通过卓越运营实现降本增效，市场的核心竞争力从产品和销售转移到综合运营，此时运营资源的投入最大，对运营管理的要求也最高，但随着产品进入衰退期，平均运营资源投入也开始等比降低。

了解到上述资源配置的规律，企业的经营管理者才知道在产品生命周期的不同阶段，如何科学制订相关的资源配置策略，确保产品稳健发展以及企业经营稳健发展。

3. 多产品结构资源配置

企业通常不只有一个产品，在多产品结构中，每个产品各自的发展情况和所处市场阶段不尽相同，作为企业经营者，需要考虑如何把有限的企业资源合理分配到多个产品中，解决这个问题通常用到我们熟知的波士顿矩阵分析模型。

图 5 波士顿矩阵分析模型

波士顿矩阵的创始人认为，公司要取得成功，就必须拥有增长率和市场份额各不同的产品组合，而组合的构成取决于现金流平衡，因此，波士顿矩阵模型的本意是通过业务的优化组合实现企业的现金流平衡，其目的在于通过产品所处不同象限的划分，使企业采取不同决策，以保证其不断地淘汰无发展前景的产品，保持“问题”、“明星”、“金牛”产品的合理组合，实现产品及资源分配结构的良性循环。通过四象限的分析，让企业经营者掌握企业产品结构的现状以及预测未来市场的变化，进而有效地、合理地分配企业资源。

综上所述，任何企业的资源都是相对有限的，对于高科技产品类型企业而言，需要清楚地知道，要给哪些产品投放资源？为什么要投放资源？如何给产品投放资源？在什么时间投放资源？投入什么样的资源？投入多少资源？资源投入多久？最终达到什么目标？相关资源的投放依据是什么？以上波士顿矩阵模型和产品生命周期资源配置模型，正是从多产品结构和单一产品生命周期两个层面为企业经营者提供企业资源配置的决策支撑。

对于高科技产品类型企业经营者，通常可以参考以下决策流程：首先，借助波士顿矩阵分析，将企业产品划分成四种不同类型，根据产品类型确定产品的经营策略，是加大资源投入、保持资源投入、改变资源投入还是放弃资源投入？从公司经营决策层面先做首次企业资源分配；其次，借助产品市场生命周期模型以及产品技术生命周期模型对具体产品进行分析，判断产品所处的发展阶段和市场阶段，并结合产品生命周期资源配置模型为产品下一阶段发展匹配合适的资源配置策略，再根据资源配置策略制订完整的研发、市场以及运营等资源的配置计划甚至包括工作计划，从而进一步完成企业资源配置的细化和管理。

因此，产品管理的首要职责是为企业经营者提供科学的资源配置依据，支撑其经营策略和经营决策的制定。

下一篇将给大家继续阐述“职责的框架”以及“市场的策略”两部分内容，敬请期待，如有疑问需进一步讨论，可公众号留言或加个人微信讨论：PEPSI_NJ

【未完待续】

阅读原文

跳转微信打开

《演化的高级威胁治理》系列，共六篇，更新完毕

演化的高级威胁治理系列，目前为止更新了六篇，系统性地阐述了2014年～2021年思考和规划“高级威胁治理”这个领域的全部过程，历经从趋势科技、亚信安全到360三个时期，这里感谢各位老东家对该领域的战略重视和理念输出，让我可以一直保持这个领域的专注和研究，能够不断深挖和提炼这个领域的奥秘。

安全行业一直被诟病碎片化严重，缺少主线和体系，故斗胆按照自己的理解和认知将“高级威胁治理”这个领域进行了体系化的整理和规划，用一年半时间陆续发表出来，既希望这个领域的甲乙双方共同看到较为完整的领域全貌，了解这个领域的演化脉络和演进方向，同时也欢迎大家不吝赐教共同帮助这个领域持续丰富和提升。

网络安全一直有“检测派”和“管控派”之说，“演化的高级威胁治理”这个系列主要以“检测派”为主，这里不是说“管控派”没有价值，事实上，“管控派”可以从另一种理念和实践解决80%的“高级威胁治理”领域问题，并且，“管控派”的价值远远不限于安全，它甚至可以服务于IT、数据以及业务等更上层更广泛的领域，因此，接下来我将会另起新的系列来进一步阐述，新系列为暂定《IT公有云》，有机会和大家一起分享。

本系列更新完。

阅读原文

跳转微信打开

高级威胁治理战略5.0 - NG-XDR，针对关键信息基础设施（CII）在面对国家级APT攻击时，在事前、事中和事后三个阶段需要采取和着重考量哪些针对性的技术和能力，作为XDR体系在高级威胁治理领域中最重要场景的落地。

6. 第六章 2021年战略5.0 - NG-XDR

阅读原文

跳转微信打开

一篇写于三年前的文章，在今天愈发更复杂的宏观条件下，如何更加有效地帮助SMB实现信息化/数字化转型，如何支撑SMB的业务敏捷性和连续性，​如何进一步降低SMB的IT预算的支出，是行业厂商需要进一步思考的地方，对SMB客户来讲也更具实际意义。

0. 本文背景

本文写于2019年10月，彼时刚刚入职某数字公司2个月，基于数字公司在当时的基因和核心优势，该如何拓展中小企业（Small and Midsize Businesses，SMB）市场的战略思考。虽然已过三年，但本文提出的IT公有云论断和方向，从安全到信息化的商业路径，以及战略的优劣分析、竞争分析和风险评估仍然值得行业继续思考和践行。

1. 未来SMB信息化市场在哪里？

过去10年，信息化建设的主要场景集中在数据中心云化，简称DC云化（指计算、存储、网络、服务以及应用等数据中心核心要素的云化），个人预测，接下来10年，除持续DC云化之外，IT云化（企业组网、边缘接入、资产管理、用户认证、访问授权、加密传输、终端管控、桌面管理、办公业务、服务编排等）将成为信息化/数字化建设的重要市场，原因如下： 

a. 传统IT组网方式正在向云化IT组网方式演变

移动终端、远程办公、多云服务、分支机构、合作伙伴、物联网等业务场景的出现，极大提升了传统IT组网的复杂度，同样使得企业边界更加模糊。如果将企业IT划分为云（数据中心）、管（运营商大网）、边（企业边界）、网（企业内网）、端（终端），那么来自运营商侧的大网技术变革正逐渐改善上述挑战。5G切片网络、SD-WAN、SDT、SDP等技术的出现，正在改变传统以企业内部物理网络为核心的IT基础架构，企业将IT主干网交给运营商的大网来承载，以往遍布在各地的企业内网成为附着在主干网上的各种子网，使得企业IT组网、接入方式以及边界管理变得更加简单和明晰，传统本地IT组网方式正在朝运营商云化IT组网方式演化。

b. 更多企业采用云化 IT 提升信息化/数字化的便捷性和灵活性

随着 SaaS 服务不断成熟，企业信息化升级将使用越来越多的 SaaS 服务，企业 IT 如何适配并打通各类 SaaS 服务（简称 SaaS 服务编排）成为企业信息化/数字化升级的关键，云化IT 的便捷性和灵活性将大大缩短业务编排和业务上线时间，提升企业信息化/数字化的效率。

c. SMB用户对于IT轻资产的诉求

B端用户，尤其是大量中小企业，对于IT轻资产有着明确的诉求，他们认为未来的可见IT资产只有终端设备，IT职能就像公有云服务一样可以随用随租，无需自己采购建设，而云化IT的出现恰好满足此类SMB用户的需求，除此，云化IT托管服务还进一步满足了此类用户的各类IT需求，比如，如何满足远程办公，如何组建虚拟办公网络，如何访问各类企业资源，如何将服务上线，如何适配并打通各类本地和SaaS服务等。

个人预测，在SMB领域，尤其是高科技SMB，云化IT市场以及云化IT托管服务市场将成为继云化DC市场之后，另一个信息化/数字化建设的重要领域。由此，未来的公有云市场，也将进一步细分为：1. 以传统云化 DC 为核心业务的 DC 公有云市场；2.以新型云化 IT 为核心业务的 IT 公有云市场。在国内，和DC公有云的早期用户群体一样，SMB也将是云化IT市场的第一批用户，同时也是IT托管服务的第一批用户。

2. 如何切入未来SMB信息化市场？

2.1. 商业机会

1. SMB高昂的IT建设成本、合规成本、管理成本
2. 缺乏专业的IT经验和能力
3. 业务云化、IT云化、安全云化的发展趋势

云化安全托管服务和云化IT托管服务的实际需求是成立的，和行业发展趋势也是相符的。

2.2. 商业逻辑

2. IT运营“变现”

2.3. 商业路径

3. 优劣分析

敏感内容，此处略去。

4. 竞争分析

敏感内容，此处略去。

5. 风险评估

敏感内容，此处略去。

6. 最后

阅读原文

跳转微信打开

抓住零信任的金线，是理解和落地零信任的第一步，本文作者基于多年甲方实践，带着对零信任深刻的理解和认知，深入洞悉身份和权限对于零信任的灵魂所在，预祝创业成功，为市场和客户带来更好的零信任产品。

    首先定义什么是零信任安全产品。众所周知，零信任是一种全新安全理念，其内涵是消除默认信任构建自适应信任，因此凡是遵循零信任理念并实现零信任核心能力的安全产品都可以称为零信任安全产品。

    零信任安全产品这些年发生变化的是产品力、覆盖场景、用户范围等，不变的是零信任理念所涵盖的底层核心能力。有人曾经说过，可以用互联网思维和技术重新做一遍传统产业，当前如火如荼的产业数字化改造验证了这一点。可类比的是，今天我认为绝对可以用零信任理念和相关技术组合重新做一遍传统安全产业覆盖的各类场景，针对各类场景下的安全痛点提供全新的解决方案，降本增效的同时带来更好的用户体验和安全保障效果。

    笔者过去作为行业市占率第一甲方的安全负责人，有机会接触国内外各类安全产品，加上自身带领团队在零信任领域做了大量深入实践，因此有机会近距离长期观察全球范围内的零信任安全产品的发展趋势和现状，通过今天这篇文章做个概述。首先来看看零信任安全产品这些年发生了哪些变化。

    第一个变化，零信任安全产品的设计视角变化带来更深更广的覆盖场景。过去厂商基于传统的安全攻防视角来做产品，但是随着IT基础设施和服务的云化发展，为了更好地解决实际问题必须基于业务视角去设计统一安全架构，在大力建设身份底座的基础上，从办公零信任到生产零信任，覆盖更多场景。过去提到零信任很多人想到的是替换VPN的SDP，实际上这是一个非常小的零信任应用场景，也是狭义的SDP，广义的SDP应该是真正的软件定义边界，支撑实现全链路全场景的安全访问管理。

    第二个变化，零信任安全产品的工作中心即安全保护目标发生了转变，从过去以网络隔离为中心转变到现在以资源保护为中心。按照OKR的理念来理解，产品最终目标是为了保护组织的数字资产，那所有的KR和TODO都需要围绕这个目标来设定。软件定义的边界通常执行两个动作，一是采集数据，二是执行策略，这两个动作都跟每次执行动作时要保护的特定资源强相关，而不是参照传统的网络边界模型，像防火墙一样强制做一层网络隔离。另外为了更好地适配这个转变，组织需要维护良好的资源层次结构进行基于资源的安全访问管理，我们去看谷歌、亚马逊和微软等大厂的安全架构，都有大量以资源为中心的访问管理工具和服务。

    第三个变化，零信任安全产品从单点产品到一体化解决方案的转变。这里的一体化不仅仅是办公零信任中的终端安全一体化，还包括端、网络管道、边缘计算和云的一体化。安全行业的一大痛点就是过于碎片化，大量公司在单点上进行红海竞争，却忽略了甲方用户到底需要的是什么。随着零信任安全产品覆盖越来越多的场景，越来越多的单点能力可以打通进行联动从而可以实现联防联控，甚至可以不局限于安全领域如延伸到运维桌管领域。这里国内其实急需一个事实上的行业对接标准，如日志和API等的格式规范，这样很多厂商可以专注把自己的核心能力做深做强做宽，既可以方便把自己的核心能力开放出去给其它厂商使用也可以方便引入其它厂商的核心能力，不用跨界做大量同质化产品也能活得比较好。

    第四个变化，零信任安全产品的交付内容和交付对象有了新的变化。交付内容角度从过去的一个安全管理类系统向最终的安全服务转变，不管产品形态私有云还是公有云，商业模式是订阅付费还是一次性买断。这个转变更加接近于用户的真实需求，可以降低产品的使用和运营成本，也减轻用户压力和提高效率。另外产品的交付对象即最终用户也发生了变化，过去可能只是给安全团队的小范围人员重度使用，但是现在还需要提供给运维、网络、开发及其他内部员工全员重度使用，对产品力的考验不言而喻。

    简单总结变化部分，全球市场上的零信任安全产品的产品成熟度正在持续提升。从过去的孤立死板的盒子产品在向服务化、自动化和智能化的方向演进。如果大家对零信任安全产品关注比较多的话，就会发现近两三年出现的部分零信任安全产品的产品力特别强，强到同类竞品和一些号称零信任的安全产品很难在一个水平线上竞争，特别是2020年左右创立的一些新公司越来越接近零信任的本质，越来越能完整实现零信任核心能力，如TailScale、ZeroTier、Perimeter81、Twingate以及其他更为优秀的零信任初创公司。相比之下，Zscaler等公司算一个成熟的已上市的零信任安全大公司，但绝算不上最为创新的零信任安全公司。所以零信任安全产品的产品力水位线越来越高，进入门槛也越来越高，想要进入这个市场并要发展好，已经越来越难。

    俗话说外行看热闹，内行看门道。那零信任安全产品有哪些不变的底层核心能力呢？

    第一个不变，身份是最为基础的核心能力。以泛在身份为基础支撑，就可以用零信任理念构建安全的万物互联世界，这里的泛在身份是指活人身份如员工、消费者、合作伙伴、非活人身份如设备、应用和API等。事实上，身份部分目前是比较低估的板块，国外近几年逐步起来，投融资也比较活跃，但国内做得好的相对比较少，也还是洼地，可挖掘的空间依然比较多，比如说很多传统访问控制和管理场景都还是使用IP作为身份的，但大家知道在零信任理念中IP是不建议作为身份的，仅从这一点讲零信任安全产品就有非常多的创新空间。

    第二个不变，在上面讲的构建泛在身份的基础上，应用于策略执行和行为分析的动态信任评估能力也是关键的核心能力。动态信任评估在设计和实现上难度都比较大，关键点就是在于这个动态，需要在运行时体现。

    第三个不变，在上面讲的构建泛在身份和动态信任评估的基础上，全面应用基于策略的访问控制技术。它的控制粒度更细，控制更精准也更灵活，能支持更广泛的场景，通过策略实现软件定义的安全服务，助力提供自动化和智能化的安全运营能力。

    简单总结不变的部分，不变的底层核心能力才是零信任安全产品的灵魂所在，套用云原生的说法，从底层开始就面向零信任理念设计的零信任安全产品才是真正的原生零信任安全产品，并不是修修补补套个近乎就可以做到的。

    以上权作抛砖引玉，期望能够看到更多好的团队好的产品新的风气逐步起来。

阅读原文

跳转微信打开

安全市场的机遇很多，当前市场不大以及增速不大的原因还是因为没有向外拓展更广泛的市场空间，大家都拥挤在传统的狭小赛道当中，没有在新的领域去突破创新，更没有认真思考如何让安全融入业务、成为业务、让安全创造价值。

【背景】

亲历网络安全近二十年的发展和演化，从防病毒到防勒索，从企业和黑产黑客的对抗到国与国之间的网军对抗，从早期法律法规空白到网安法、数安法、个保法以及等保、关保的相继出台，今天网络安全的内涵和外延已经发生了翻天覆地的变化，甚至已经不能再用“网络安全”这个词汇来概括，尤其是在大数据和数字化时代，安全正在逐步融入数据、融入业务，进入企业高层和监管机构的视野，开始为国家、社会、公共及个人安全提供越来越多的能力支撑。