创造价值，持续交付：B端产品经理的方法论

人人都是产品经理 • 4年前扫码分享

我是创始人李岩：很抱歉！给自己产品做个广告，点击进来看看。

编辑导语：产品经理这个岗位的出现也顺应了市场的需求，随着市场的不断发展，不同的行业分布明确，产品经理也在不同行业都设立了岗位；在如今这个大背景下，产品经理以创造价值为宗旨，产品经理也需要掌握多种方法；本文作者详细介绍了B端产品经理的方法论，我们一起来看一下。

一、市场和产品

只有在市场经济体系下才会有产品经理这一个角色的出现，这样的经济框架下，市场的活动主体、企业，通过与其它企业交易所带来的价值来维持本身的存在和扩张需要；而交易的载体就是产品——通过产品在双方或者多方之间的交换，所有的参与方都在交易中获得了各自追求的价值。

那么如何在实践中，洞察能触发各方交易的需求，转换能满足需求的解决方案为可交易的产品，从而促成交易的发生和价值的创造，则成为产品经理所有担负的使命和工作范畴。

产品经理不是一个新鲜的职业，只要有市场、有交易，就会有产品经理。

在互联网产品经理出现之前，这种发掘市场需求、整合资源、设计方案、研发产品的诉求就一直存在；所以第一位产品经理出现在传统的快销行业也就不足为奇了。

时至今日，不同行业（例如家电、通信设备、机械制造、金融行业等）都诞生和逐步设立了产品经理这一岗位，而不在是将此角色的权责分散在企业里的不同组织当中。

在工业时代，受制于信息传递方式、技术成本和科技普及率，以及市场需求的局限；大多数时候产品经理这一职责实际上是被在不同职能部门中的人员共同完成的。

而信息时代的到来，互联网和信息技术彻底改变了以往时代的生产要素的分配和市场需求。

先进技术的发展，大大拓展了企业的生产能力和信息获取能力，市场需求从简单单一转为快速多样和碎片化；这样的外界商业环境，促使了产品经理职能需要被独立抽取出来，形成一个独立的职位来整合产品各个要素，贯通整个产品的生命周期。

1. C端产品经理

科技的发展无论在广度和深度上都极大改善了信息的传播，借助这些信息渠道的形成，单个自然人作为交易消费主体的需求被放大和关注；满足这些需求的、针对个人(Customer)的C端互联网产品被不断推向市场。

在“人人都是产品经理”的号召下，借助于信息技术的普及和研发成本的下降，C端产品经理这一群体逐步壮大，不断延伸业务范围。

结合各类学科的理论和实践，C端产品经理对个人的需求进行彻底和深入的研究与探讨，以期寻找新痛点，创造新的产品；社交类型的互联网产品就是这一类型产品的代表，例如抖音、陌陌。

2. B端产品经理

伴随着个人流量红利逐渐退潮，ToC互联网产品和为之服务的C端产品经理开始迈向了饱和状态；但是借助国家推出“互联网+”的概念和积极的政策引导，各行各业都开始对接互联网企业的先进技术和最佳实践，希望通过“行业+互联网”的方式来实现改革创新和产业升级。

在当下的市场环境里，企业需要结合科技来支撑自身已有业务的运营；同时，因为借助于科技的发展，新的商业模式不断涌现，新的市场需求被挖掘；如此快速多变的业务需求，需要企业在市场捕捉、运营体系、管理机制上及时响应来保证企业的生存和发展。

因此，必须有这样一批具备以企业为服务对象的产品经理，通过结合行业知识、业务运营、技术和其他相关要素来针对业务诉求；快速合理的设计企业应用产品，及时落地实施，敏捷迭代优化。

B端产品经理的产品交付物因为离大众用户有相对的距离，而且职能活动有相对的专业领域门槛，所以在一段时间内关注度和曝光率相对较弱；产品经理需求的大环境改变，给B端产品经理的发展和壮大，带来了巨大机会，同时也带来了挑战，特别是在B段产品经理自身的业务能力和技能体系上。

B端产品服务的对象和需求来源是企业和组织——相对于C端产品需要针对个人用户的心流和痛点，来研发设计相关产品；在B端产品经理的工作范畴里则转变成了针对企业这个有机体的需求、组织行为、流程阻碍，以及业务模式与市场快速变化的不匹配等这些企业经营问题来设计和思考产品。

以企业运营架构和业务目标为背景，一个个业务团队或部门被抽象出来，通过观察和分析它们之间如何处理业务分工、规则设定、流程执行等事务；产品经理需要调动自己的商业分析能力和逻辑思维，从企业组织行为和组织目标来设计产品和定义功能，以期能解决企业的经营问题。

在此之外，B端产品经理还需要时刻观察和分析外部行业动态和内部运营数据，从而有预判性的和准确的对企业经营现状做出评估，通过B端产品的研发和迭代来驱动业务效能的提高、激发企业活力、实现自我提升。

B端产品的使用者也是个体自然人，类似C端产品，也会考虑交互体验；交互的界面享有相同的设计逻辑，也仅此而已；界面之后的产品驱动力和服务对象的不同，决定了产品经理所考虑的优先级，产品价值创造的逻辑大相径庭。

更进一步，B端产品所支持的业务诉求是依靠一系列使用群体共同协作通过产品来完成；产品经理需要在产品之外平衡各方利益诉求于产品生命周期内，从而达到共同的内在产品驱动。

因此，能否达到预期业务效果，并非仅仅局限于B端产品本身的研发，还有太多的其它核心但非产品因素会影响产品对业务目标的效果；产品成功和业务经营成功是分离的情况并不少见，这一点上B端产品不如C端产品同相关业务效果之间那么直接和紧密。

市场和行业的大环境需要更多的B端产品经理，它的工作范畴需要跨领域的全面综合能力，对产品的全生命周期驱动能力，和各项专业商业和技术能力。

本文试图介绍B端产品生命周期和对应的能力在各阶段的匹配实践落地，通过案例的阐述来描绘出一个产品经理的工作范畴、职能足迹和技能使用，希望为B端产品经理的产品方法论和能力框架提供一个模型。

二、B端产品经理的工作理念

1. 产品经理的工作和意义首先在于创造价值

彼得·德鲁克（Peter F. Drucker）曾经说过“价值只能由企业外部的客户来定义”。

Womack 和Jones 在《Lean Thinking: Banish Waste and Create Wealth in Your Corporation》一书中也强调价值只有在在正确的时间、满足合适的价格的前提下交付给客户才能产生。

外部商业环境的易变性、不确定性、复杂性、和模糊性日益增强，创造价值本身和它的时效性逐步凸显，这深刻地影响到了产品经理的工作原则和具体实践；市场迅速的变换，当大量的时间和资源针对最初企业经营需求被投入，等产品功能全部开发完整后，市场的趋势已经转移，企业的经营需求也已经变换。

2. Womack和Jones提出精益思想可以指导价值的创造

清晰界定价值，把创造价值的活动按最优方式来组织执行，且不受任何杂事所扰，有效的执行，排除浪费，一次比一次更优化。

Eric Ries 在《精益创业》里提出最小化可行产品（Minimum Viable Product, MVP）概念；简单地说，就是指开发团队，在新产品的开发过程中，通过提供最小化可行产品获取用户反馈；所以这样一个版本的产品能够用最小的资源投入来获得最大可能的被用户验证的反馈；通过执行这样一个概念，以期望有时效性地验证产品的价值。

在精益的思想下，拥抱变换、聚焦价值创造、精简快速地落地产品，成为产品经理所具备的思路。

与此同时，正如市场本身的变化，价值的创造不是静止的，产品的生命周期也不是线性不变的。

当一个MVP落地运行，开始满足企业经营基本需求的时候，产品本身对业务带来的效能和运营影响也开始被可以被衡量、评估和验证；通过获取真实反馈，分析业务数据，验证业务问题解决效果等一系列活动，新一轮的产品创造过程被启动，以用来矫正、优化或增加新的产品功能来解决新的业务问题。

这种迭代的思维帮助产品经理利用有限的资源快速验证和解决业务需求，持续的反馈又推进新的价值创造；纵观整个过程，产品本身的演进和生命周期结合业务需求，形成了完整的产品生命周期闭环，形成了持续交付的内生动力。

总结起来，创造价值、持续交付是产品经理的核心工作理念。

在上述理念中，创造价值是一系列的探索过程，试图锚定产品价值，解决业务问题，而持续交付则是搭建产品和验证产品价值效果的过程；在循环的过程中，不断自我矫正，适应外部和内部需求变化，达到产品和业务经营成功的完美结合。

某些行业对这一理念的实践并不陌生；比如在石油行业针对页岩气区块所采用的“滚动勘探开发”方法，或是美剧按季来推出新作品，甚至华尔街在几百年前的金融产品设计发行上都有蕴含这一理念；跨界的学习和借鉴，是产品经理不断自我提升、拓宽视野、丰富思路、打造适合的工作方法和理念的有效途径。

三、产品周期和范畴

产品本身的生命周期是一个循环的，螺旋上升迭代优化的过程。

在这一持续的过程中，随着时间的推移，产品经理需要承担不同的职能从而推动产品的演进和迭代：

第一阶段：需要不断的洞察业务或市场诉求，寻找和定位产品的需求（洞察需求）；
第二阶段：定位、定义和设计产品以及针对的目标（产品设计）；
第三阶段：整合资源推进开发落地（产品开发）；
第四阶段：最后推广和宣传产品，通过运营数据分析和用户反馈，进行下一轮的产品迭代更新重新开始循环第一阶段（产品运营）。

同时在每个阶段所关注的重点事项和优先级也随之改变。

1. 洞察需求

这个阶段的目的是定位企业的痛点，无论是新业务的拓展，或是现有业务的优化和变革，需要的是充分分析和洞察企业需要寻求新价值和变化的动力基础；在此之上是对企业发展的经济模型和商业模型的深入分析，从而结合所期望达到的目标来开始设计和定义相关的产品。

企业或商业体的存在就是在不断创造价值，它的行为也是为这一目的而驱动的；同时，企业作为市场里生存的有机体，随时需要根据外部环境的变化来做出相应的调整和适应；那么以公司或者商业体为服务对象的B端产品则是为了匹配这些需求而打造。

发现和了解企业背后的需求来源可以通过不同的渠道来获得，例如业务调研、梳理企业运营状况、厘清运营阻塞；或是，依照既定的业务路线图和长期规划来落实匹配的系统产品开发；也可以是，通过分析市场动态和对比行业竞争对手来寻找企业自身的变革需求。

发现具体业务需求后，产品经理则要立足于企业自身的商业模式和经济模型来开展工作；深刻理解企业为了商业目的所采取的策略和执行手段，以这些业务经营本质为基础，针对变革需求来匹配对应的产品设计和开发，从而达到了增加业务价值，匹配业务变化的结果；这样的结合是正向的匹配，即商业的动态和变化要求系统产品的跟进式匹配，是业务驱动的产品开发和价值发掘，动力方是在业务部门。

产品需求的渠道也可以是上一周期效能反馈；在系统产品搭建后，通过具体的数据收集、归类和洞察，然后提炼出无效率、资源浪费或需优化的地方；这些反馈也可以转化为企业变革的需求，这类需求以数据为基础，提出优化需求，让数据来驱动业务的变化，从而落地数据驱动的价值发掘。

无论是业务渠道还是数据渠道，在这个过程中，业务部门需要定义清晰业务目标的成功标准和衡量体系，于此同时是产品经理开始构思产品与之匹配的数据运营指标和衡量体系；例如，业务目标是落地一条新的业务线，那么这条业务线在企业组织里的成功搭建，和在预计时间内的启动运转会是业务部门这一阶段的业务目标。

那么与之匹配的在产品构思就需要考虑，如何通过梳理新业务线的业务流程和运作模式来设计新的企业应用产品，以及此应用产品和已有的其他产品间的关系；同时，需要设计相关新产品抓取和衡量产品本省是否能支持业务目标的数据点。

通过数据点的数据收集，会为之后的产品运营打下基础，同时也是验证应用产品本身的有效性，和未来提出新的产品改进思路的数据理论基础；从而推动和形成产品进化闭环，双向流动，互为推手，已更高价值和更优效率为目的，交替驱动，不断提升。

另外，需要关注的事项是决定业务需求的优先级和重要程度——在业务洞察需求阶段，总是会有纷繁复杂的诉求和问题需有待解决；在此过程中需要反复权衡利弊，根据企业自身的特点和基础，决定优先级，判断做哪些和不做那些，先做哪些和后做哪些。

2. 产品设计

产品设计阶段有两条主线横跨整个进程，互相驱动和支撑；其中一条相对于产品经理比较明显，是匹配业务需求和痛点来设计产品方案；而另外一条更强调的是和具体开发工作所需厘清的事项，例如软件架构、技术选型、测试策略等等，为之后产品开发阶段的产品具体实现落地，和适合的技术方案选型做前期技术准备。

产品总体的设计思路是从自顶而下，整体到细节，逐步细化，层层推进；通过业务诉求分析和运营诊断，产品经理从具体的业务事务和流程当中抽象和演化出具体产品功能模块和设计产品的效果。

在开始一个产品解决方案时，首先需要的是评估是该方案的所针对的业务和现有的企业解决方案之间的关系。

这个新的业务问题需要的是对已有的系统平台进行改造优化，还是有全新的技术方案需要开发，或者是两者的混合模式；好比你要在一个装满点心的盘子里要在放入一块新的蛋糕，它的放入不可避免的会对已经在盘子里的其它糕点造成影响；也许要挪挪位置，从新排列组合，腾出点空间给新的蛋糕，或是把一些不想吃的点心挪出盘子。

一个新的系统产品的出现必然会影响到已有的企业软件架构和组织，如何有序和有规划的安排，是产品经理和受影响的业务部门需要探讨和决定的；而这一过程中，需要平衡各方面的诉求和利益，但是必须以业务整体优化目标为结果导向。

在这样的一个基础上，产品经理和相关业务、技术人员开始梳理整个产品解决方案的业务核心流程；在这个过程当中，相关业务参与人员描述现实工作当中处理业务问题的步骤，方法和涉及的操作方等；通过这些信息，业务的主干脉络被用业务流程图绘制出来，从而进行分析和改进，形成最终解决方案的基础依据。

在业务流程梳理过程中，通过对业务的理解和涉及到的业务对象，通过逻辑抽象，归纳整理出来需要服务或使用产品的对象，及其在整体方案中的功能定位和实现目标。

接下来就是将分类出的对象下所需要执行的业务工作，本质诉求和目标，进行提炼和归纳为具体的商业功能模块——这需要产品经理具备基础的企业管理和商业知识，配合具体企业业务部门的领域知来进行规划设计；在这个步骤当中，各种的功能需求会被建议和提出；当汇总完成后，就形成了整个产品的路线图（Roadmap）；如之前所讨论的，企业的诉求多样和市场变化十分迅速，不可能一次性完成所有的功能点，这也不适合现在提倡的精益和聚焦价值，快速迭代的理念；产品经理需要帮助业务部门定义产品的MVP，逐步推进路线图的落地。

从整体到局部，下一步就是具体的产品细节设计；这一部分的工作是把一个个抽象的功能模块概念、可视化成为一页页可以同用户交互的界面，以及设计界面背后的数据模型、权限和逻辑等的事项。

另外非常重要的一点就是对应的功能和页面交互的数据埋点和收集工作，需要在整个阶段定义清楚；为之后的产品运营打下基础，也是形成产品闭环、聚焦价值所需；一些具体的技能要求，在接下来的章节里有相关的介绍。

在整个产品方案设计过程中，业务流程图是一个非常核心和关键的工件；它是连接现实业务和系统开发工作的桥梁，让业务、产品和开发团队使用同一个语言背景来讨论问题和推演方案。

在设计当中，业务流程图自身的不同层级对业务流程步骤的描绘、逻辑的细节，具体操作交互等的深入和细化，不同职能的参与方（业务、产品、技术等）都可以在相应的层级主导和提供支持方案的最优设计。

另外一条工作主线则是相应的技术方案选型和准备工作，这部分的工作主要是开发技术人员来主导，产品需要了解过程和提供对应的信息支持；首先是应用技术架构和新的产品解决方案之间的适配性的思考；例如，现存的软件架构是单体式架构（Monolithic），而新的业务形态和方案需要使用微服务（MicroService）来支撑；然后是一些具体的技术选型（例如,前端开发技术语言等）和开发策略问题的讨论；需要如何匹配产品设计方案来更加准确，高效的达到产品目标——这是一个反复讨论和平衡利弊的过程。

3. 产品开发

当产品路线图和具体的产品开发时间规划确定后，接下来就是具体的产品开发执行阶段；在有些企业，产品经理可以放手让开发团队的负责人来相关的工作，只需等待验收结果；而有些情况下，产品经理还需要参与到日常的工作当中去，支持具体的开发工作。

这种情况下，产品经理将要担负起项目经理的职责，对产品进度的推进落地进行把控。

首先是，针对之前规划的项目时间表计划的执行完成度的把控，确保开发人员能够按计划执行和完成相关的工作；在此期间，随着开发细节的不断深入，一些之前未考虑到的产品设计盲点将会浮现出来，需要产品经理的分析和确认。

其次是对产品项目相关者的沟通和把控，持续和业务部门沟通进度，把握业务部门的脉搏，让当下的产品交付结果满足业务的需求和时效性。

根据市场的变化和业务价值的优先级，产品经理还需要动态的调整产品功能交付的优先级和范围，在项目管理角度把控下一步的计划和安排；与此同时，阶段性的开发成果需要积极邀请业务方参与验收评估。

虽然整体功能不能全部展现和贯通，但是结合一些技术措施（例如使用Mockup来表示未来实现后的效果），把已经开发出来的功能点给予展示，可以及时收到业务的反馈，保证目标和方向的正确性和一致性。

这个阶段，产品经理更多是在项目管理上起到主导作用。更多的是辅助开发团队高效落地方案；积极沟通业务相关方，同步进度信息，匹配业务动态。

4. 产品运营

基于精益思维，产品本身都具有阶段性，仍然需要不断的迭代和优化；所以在产品运营阶段，运营事项里面不但包含了业务在产品上日常的运营、监控和管理等事项，还包含了产品经理会往外对产品进行游说、推销和积极搜集反馈、主导或辅助一切能让产品本身被更广泛使用增长和优化的事项。

与此同时，根据之前在需求洞察阶段定义的绩效指标和数据埋点，这个阶段可以用于从不同的角度来观察和分析产品效果。

关注的重点从分析产品本身是否解决企业业务问题着手。

如果是从0到1的产品线搭建，那么需要考察的是，这条产品线是否已经通畅运行，业务部门在上面执行的关键业务环节是否有异常和阻塞；新业务线的搭建，是否帮助企业获取到了规划的目标市场，业务部门和用户有多少人开始通过产品来执行新的业务，以及在此产品上的业务成交量的大小。

因为是新的功能和业务，产品经理需要提前准备和积极参与功能的推广宣传和业务培训事项；充分结合和调动业务部门负责人的资源和参与度，从而获得更好的用户接受度和使用率；如果涉及到重大企业组织结构级别的变动，还需要提前制定变更管理计划；产品在被使用过程中，也会涉及到逻辑答疑、业务数据分析和解释、系统Bug修改等支持活动，需要产品经理参与和帮助协调资源解决问题。

如果是优化迭代性质的产品，那么需要观察和分析的是，根据产品的使用数据反馈，是否能带来之前针对业务痛点的改善，是否可以进一步提升了业务整体目标，不论是营收规模还是运营效率的提高。对于迭代优化类型的产品来说，更多的是关注其对业务目标的帮助。这个阶段可以引入OKR的框架来衡量产品价值。

在与业务日常运营的交流中，该阶段产品的局限性和故障被总结，业务部门的反馈和新要求被收集，从而形成下一个阶段的需求池；同时，系统记录的绩效数据和数据埋点可以从客观上提供不同的分析视角和改进需求。

例如，在某维修公司，业务部门提出把属于一个上门点的所有维修工单统一归纳到一个服务请求下来；这样可以做到一次请求，多个工单同时解决，从而避免多次上门和重复业务流程的目的；该产品功能上线以后，业务人员确实在使用，也提出了不少的改进建议；但是数据分析发现，大部分的服务请求下，实际只包含了一个工单，没有达到预取的效果，维修人员还是多次上门服务，重复流程，这些发现是通过系统数据发掘的；客观的指出了——产品的使用层面的成功并没有带来预期的业务效果，这些运营数据就可以成为产品功能优化和改进的参考。

另外一方面就是参考用户行为数据的分析；用户旅程地图（User Journey Map）的数据埋点和热力图等来验证用户和产品之间的交互是否是按照设计来执行，从而推演出产品的实际业务效果数据和用户使用行为之间的关系；如果效果不好，那么是否是因为用户没有按设计的交互场景来使用，或者是效果很好的原因是因为用户使用的方法与设计有高度的吻合。

总之，运营阶段需要关注的是产品功能运营工作和对应的产品数据运营工作。整个阶段也为产品下一个周期优化升级开始做准备。

汇总上面所述的产品的生命周期，那么在产品经理需要在周期的各个阶段需要关注的重点如下：

创造价值，持续交付：B端产品经理的方法论

四、B端产品经理的能力

1. 商业洞察能力 (Business Insights)

产品经理的使命是创造价值，商业洞察能力能够帮助产品经理准确地定位价值在企业当中的所在；通过分析企业商业信息，了解业务规则和具体的执行，才能搭建出与之匹配，适合业务的系统产品。

产品经理的商业洞察能力是一个很宽泛的范畴，包含了经济学、组织行为学、经营管理、市场营销、金融财务等等；这些基础学科和领域知识给予产品经理对应的通识能力和批判性思考框架，从而可以透过事物纷繁复杂的表面现象来定位核心问题，锚定企业变革需求的实质问题。

例如，在许小年的《商业的本质和互联网》一书当中就充分的阐述和分析了各类商业模式和和对应的互联网企业的案例；透过这一系列的案例，各类互联网企业的盈利模式和经济效应模型被剖释，让读者明白助力这些互联网企业发展壮大的商业本质是什么；同时也揭露了一些企业的伪经济模型和其为何无法盈利，哪怕当时这些企业意气风发，风头正盛。

这些解析后的思维，正是产品经理所需要具备的商业洞察能力。俞军曾经在一次发言中也提到，产品经理实际是从总经理这个岗位上剥离出来的角色，那么作为这个角色就需要具备总经理一样的商业洞察能力，做市场定位，洞悉人性，像总经理一样考虑周全，不断打磨迭代产品。

1）商业经济模型

这里利用一个案例来讨论经济模型和剖析企业的商业模式，从而反映出这类能力如何能帮助产品经理更好和更有效地针对企业的变革需求来打造对应的产品，使之与业务目标匹配。

T公司是一家运营了多年的2B类型汽车维修企业。企业从一家小维修公司开始，发展自己维修服务业务，与此同时逐步通过打造自己的IT业务平台，慢慢演化成了专为企业级客户提供车辆维修业务的服务外包商。

T公司首先和大型运输企业客户签订维修商业外包合同，使得客户可以在系统平台上提交车辆维修工单；另一方面，T公司在全国各地招募汽修企业入驻到系统平台上，每当客户企业在某区域有维修工单产生，平台会通过算法匹配分发给在该地区适配的已签约入住系统平台的汽车维修公司。

创造价值，持续交付：B端产品经理的方法论

基于这样一个商业场景，在解决业务诉求和运营痛点的时候，到底是以什么经济模型来评估产品的价值和业务目标呢？

它的底层经济模型是和滴滴或者Uber一样，遵循梅卡夫效应（Metcalfe‘s Law），通过正向推动刺激来扩张经营业务的么？

Uber为消费者提供了匹配服务，它帮助乘客找到司机，同时帮助司机匹配乘客；随着司机不断加入和服务覆盖区域的扩张，这一商业模型的内在增长动力开始出现。

乘客越来越多，随之带来的越来越多的司机，这样叫车等候的时间又进步一步缩短，司机空载的几率降低，单位时间内可以达成更多的交易；这样供给双方的互相正向刺激形成了良性循环，爆发性地拓展了业务的边界和经营规模。

还是说，它是基于双边效应下的商业模型？

梅卡夫这一效应的强大在于每个节点间的互动与活跃，在此前提下的商业模式才具有更高的经济估值；而对与某一类网络商业模式来说，交互只存在特定种类用户之间，比如AirBnB上的房东和房客之间，跟谁学上互动和交易仅存在于学生和老师之间进行。

在互联网的平台商业模式中，用户分为两大类是常见的现象；同时，供应商同供应商之间鲜有往来。消费者之间大体也是“鸡犬之声相闻，老死不相往来”；是正如郭德纲所说，同行是冤家。用一个简单图形表示，如下：

而这类互联网平台的价值来源于供应方和需求方的相互吸引和相互促进。在交易平台上，不同类型用户之间的正反馈、交互所产生的价值就是双边市场效应。在这个经济效益模型下，平台企业所需要针对的是如何刺激交易和吸引更多的入驻用户，从而放大该商业模型给企业带来的价值。

也许T公司的这个商业模式，没有列在这里所说的经济效应模型当中。它只不过是做着传统生意的买卖，无外乎是迁移了经营场所而已。实际上的使用的是以下经济模型

在这样的经济模型下，T公司签订客户，把汽修工单交给维修公司，居中阻断了企业客户和维修公司的互动，实际上是削弱了梅卡夫效应和双边市场效应；而企业的盈利来源是从这些交易中获得提成收益。

在这样的业务模型下，企业的盈利是靠降低单个交易成本，提高交易数量和流转速度来达成的；那么与之匹配的产品设计的核心目标就是要围绕这个商业逻辑来打造，提高单个工单的处理时间和效率，降低单个工单的资源成本，推动企业拓展和获取外部客户的能力就成为产品经理在考量系统产品价值时所针对的优先指标。

而拓展外部客户这一事项，有需要产品经理具备行业的基本知识，能够分析行业动态和业务的定位，针对需要拓展的客户开发相关的产品；比如说，如果之前的T公司的客户都是大型公交系统客户，那么在产品平台上所处理的配套的汽修工单都是针对这类型客户的车辆特性来设计的；那么如果企业现在需要拓展出租车维修市场，那么现有的产品特性和处理逻辑是否匹配，有何需要改良，就是产品经理需要提前预判和研究的问题。

产品经理的商业洞察力也会针对业务形态和成熟度有不同维度的运用；通常是通过设计和实施应用产品来推动和支持业务运营目标的实现，从而达到业务驱动型价值；另一方面，在已经处于运营阶段的产品系统，产品经理可以通过数据的运营和发掘，或者新技术的引进，引导企业改善运营现状，提高企业现有商业模式下的效能，从而实现产品驱动型价值；产品经理需要清晰的了解业务所处的状态和产品本身的能力，从而预判不同业务痛点所需要的产品方案。

这个分析能力的运用贯穿整个产品的生命周期，虽然在不同的阶段的密集程度不一样，但是对于产品从概念到落地都有十分重要的意义。

在洞察阶段，解读商业模式，确定产品的目标和定位。设计匹配业务目标市场和行业的产品方案MVP。

在设计阶段确定业务逻辑和交互原则，让产品设计逻辑和交互更加贴近业务的特性、优化流程、提高效率、支持核心业务目标；在实施阶段帮助开发团队进行逻辑验证和迭代规划，确保交付产品的业务价值，把控投入开发资源和业务效益的平衡；运营阶段又重新回到舞台中央，主导产品的生命周期主要事项，监控和评估产品落地后的效益和运营改善事项。

2）业务组织结构

了解和研究业务组织架构能够帮助产品经理在工作过程中厘清工作目标，处理好协作关系，从而保证工作的高质量开展和高效完成。

企业的发展阶段需要不同的组织架构来支撑其业务形态和发展目标；从某种程度上，组织架构就反映出了业务价值重点的分布和优先级；例如，各大互联网企业随业务和市场变化而进行商业事业部调整。通过匹配合理的组织架构搭建，企业可以正确的引导业务部门的运作往规划的价值方向发展，也锚定了每个业务人员的共同目标。

组织架构决定了汇报关系，进而决定了绩效考核方式。同时，汇报关系、绩效考核方式会影响人做事的动机、行事的方式，以及个人和团队的利益；厘清了这些组织结构所反馈出来的业务价值和利益关系，产品经理可以从企业经营的角度来平衡产品价值优先级，优化资源投入和产品组合。

业务组织架构的理解也和之后要谈到的产品项目管理能力和产品经理的布道者能力相关。在执行项目时间表和沟通具体事项时，能够快速的定位关键人员，可以帮助锚定业务对产品价值的评估，解决协调困难，加速推进产品落地实施。借助组织架构，产品远景和价值也能更有效的传递。

在一个理想的情况下，企业组织有明晰的组织架构和共同的价值目标，把企业互相独立的力量聚集成一股合力；这种环境下，产品经理可以充分发挥和聚焦产品研发本身。

3）商业工具

还有其他理论和工具来引导企业运营和商业因素的分析，这些理论从不同角度对企业经营经行梳理，帮助产品经理有结构、有体系框架的了解产品服务的对象。

以下列举几个常用的方法：

4）业务拓展和延伸

除了关心现有的业务经营范围，产品经理也需要拓展相应的产品思路和全局观，把握行业脉搏，同时跳出当下，对企业发展的走向有思考。

以上述例子里的T 公司为例。现在的企业经营的业务线只在公交系统的车辆维修，那么如何拓展除了这条业务线以外的其他市场，比如说货车、的士等？或者说，目前公交系统这个细分市场里，还有什么可以延伸的客户？比如之前可能只覆盖市内公交系统车辆，那么城际车辆和长途车辆呢？

另外的一个延伸是对应的系统技术这个角度；目前T公司是作为服务公司，使用系统平台来服务客户和对接汽修公司；那么针对希望自己运营管理维修工单，不愿意使用这种外包服务模式的客户公司，是否可以提供技术平台，以SaaS的模式为客户提供服务。

以上只是从两个维度来拓展衍生业务。

如之前介绍的，产品经理有时需要已总经理的角度来考虑企业经营，市场定位和产品打造。

2. 产品设计能力 (Product Design Skills)

产品设计能力需要把产品从抽象概念、可视化的、有结构的展示出来；这样的能力的技巧就涵盖了信息架构、原型设计、原型交互和用户旅程地图、UI设计和各类产品文档的撰写事项；例如，商业需求文档 (Business Requirement Document )，产品需求文档 (Product Requirement Document )，和市场需求文档 (Market Requirement Document )等。

1）信息架构

产品经理通过信息架构的设定来统筹和规划整个产品设计所覆盖的范畴。同时，信息架构本身也提纲挈领地指导其它产品设计技能的实践。

一款产品是通过系统与用户之间的交互，以数据为桥梁推动业务流程的流转。

那么什么信息应该展示和如何更加有效的展示，从而让用户便捷获取所需信息，方便地执行操作，这都依赖于信息架构的指引；要直接了解信息架构是哪些组件构成是相当困难的，用户只和部分组件直接交互，而其他躲在幕后的组件，用户却没有感知；在《信息架构 – 超越Web设计》中，信息架构被分解为4个组件。

基于这些组件，产品经理搭建与产品相匹配的信息架构。在众多信息架构所涉及的领域来说，最直接的一项就是产品/系统页面菜单。菜单结构本身不但蕴含了与业务流程的映射，同时也兼顾了用户习惯，让用户快速获取信息。

2）原型设计

接下来的一步就是每个交互页面的设计。匹配在流程图所设定的操作步骤，页面应该提供相应的操作信息。在这一步上，也有相关的框架和最佳实践可以遵循。

每一个页面可以解构为一个或多个设计模式的组合，而每个设计模式又是针对某种特定活动提供的设计方案；比如，信息的查看、搜索、下载这些活动都有对应的设计模式；这样，每个界面上所要承载的各种活动都可以用相关的设计模式来承载；所以通过确定页面上的操作动作，可以选定设计模式，然后通过把各个模式进行布局和组合，最终就可以形成产品原始表现的页面。

这个方法，在具体落地设计时，通过分步来实现；首先是采用线框图粗略表达必要信息的展示方式和布局，采用用户画像、亲和图、业务主题锚定、遵循先例等手段；产品经理设计出线框图，通过可视化的手段、带入场景、验证假设和讨论效果，从而不断优化推动下一步开发；接着是进一步在视觉上深化，设计样机模型（mockup）。

线框主要代表产品的结构，而样机模型则显示了产品的外观；它还不能实现点击滑动等交互操作，但是拥有更高的清晰度。最后是高保真图的开发和设计。

此外，一般系统产品都会提前准备一套产品组件，例如，输入框、按钮、侧边栏、分页符等；组件是设计的基本元素，组件的使用可以保证设计上的一致性，方便后续的产品设计工作，同时也帮助提高产品经理的工作效率；产品经理需要了解和灵活使用，避免重复造轮子，或是过度资源投入在新组件的开发上。

在色彩方面有需要注意的是，配合组件的设计，颜色搭配可以适用在可能出现的场景里；比如，一个按钮的不同状态下，按钮的颜色变化也适配对应的页面整体视觉效果；另外一个需要关注的是法律、行业或其他合规要求对色彩使用的规定；例如，针对视觉障碍用户，标准字体14px-20px的色彩对比率要达到4.5:1。

3）原型交互

在产品页面的设计过程中，页面间的交互设计也已经同时被讨论和开发出来。原型的交互设计有各种的理论和技巧被研讨过。

最为经典的是Jakob Nielsen 提出的10大可用性原则（10 Usability Heuristics for User Interface Design）；产品经理需要在理解这些原则的基础上，结合具体的问题，灵活使用，参与交互设计工作。

虽然2B类型的产品服务对象是企业组织群体和业务目标，但是它的日常操作是同每个个体经行交互和执行的。用户使用过程的流畅、高效将会对产品本身成功落地和发挥效能起到推波助澜的作用。

4）用户旅程地图

用户旅程地图（User Journey Map）是一个帮助产品经理充分了解和分析用户使用行为的工具，同时借此可以优化产品与用户的交互，达到产品使用催化剂的效果；用户旅程地图可视化地将用户与产品或服务之间的互动，按业务流程分阶段地把用户体验、行为、感受和想法展示出来。

通常，一个旅程图包括3个部分的内容：

用户旅程地图的制作步骤如下：

基于操作流可视化来圈定范围，搭建数据埋点方案，然后在产品运营阶段，可以通过埋点数据来分析旅程每个阶段捕获的交互相关信息（如操作时间、等待时间、操作步骤和次数等数据信息），来发现其中可能存在的问题，从而提出相应的解决方案，以优化用户交互来提升产品有效使用。这些解决方案可能是对原有流程的全面改造，也可能是对某个环节的局部优化。

例如，对于一个火锅店来说，重要的一个业务事项就是如何缩短从客户开始点菜，确定菜品到最后的客户买单离店这样一个过程——针对整个事件场景，我们可以搭建对应的流程模型，对各个环节进行分析；当按照旅程地图制作步骤，获得了问题症结的假设后开始进行对应的优化安排。

当然，同样的流程和操作场景，也会因为业务关注点和目标的不同而产生不同的优化方案；例如，如果以上的餐饮场景是发生在精品私房菜或者日系居酒屋上，追求的最佳用户感官和菜品定制体验上，那么用户旅行地图的使用会得到不一样改进方案和优化方向。

UI工程师基于交互原型进行美工设计，生成切图；前端工程师拿到切片文件，进行前端开发，包括交互、动作效果等；产品配合UI工程师确定设计质量，同时为衔接前端工程师开始相应的开发。

产品设计能力大部分涉及到和用户个体的交互事项，所以和2C的能力有高度重合，毕竟2B的产品需要人来操作；抽象事务和概念的可视化过程，结合业务和审美，提高美学的修养和实际工程的结合。

总体来说，这些技巧的使用会因产品本身匹配的业务而灵活运用，但是也有不少的日常最佳实践可以帮助到日常工作，提高产品经理工作效率和质量。

首先，设计时，需要参考企业内部已经约定俗成的方法；保持新的产品设计和已有产品之间的一致性，减少使用教育成本。

其次，尽量参考的市面流行产品设计模式；比如微软的office 套件，大家都用，容易识别，没有过多的认知困难，同时还省开发时间。

另外，如非必要，可以直接采用常用设计软件（Axure, Visio 等）的标准控件；产品经理需要平衡为产品单独定制所耗费资源与定制带来的收益，过度的追求设计上的新意，容易舍本逐末，浪费工作资源。

在交互方面也可以借鉴流行产品的设计，例如用户操作提供保存提醒可以借鉴Word；在移动设备上，某产品功能希望用户操作前，能习惯性下拉屏幕已获得最新的数据更新，则可以参考微信的设计。

B端产品应当简单直接设计，以解决业务问题和效率为核心指导思想，先落地；在之后的运营阶段，各个页面被使用，通过数据埋点，热力图等方法了解用户习惯，随后可以不断针对性的迭代优化。

5）产品文档

产品设计能力的一部分是对应文档的撰写，尽管在敏捷价值里提出了工作的软件高于完善的文档；但是文档在整个产品开发生命周期中，作为信息传递的渠道，以及组织和协调相关资源中的重要性不言而喻；众多的文档中，最为关注的就是产品需求文档 (PRD)。

不同企业或团队，产品需求文档的定义和形式会有所不同，但是基本的核心内容是十分相似和统一的；产品需求文档是在产品开发过程中用来向各个参与部门来沟通和介绍相关产品需要包含的能力的工具。

它需要包含的内容会作为其他后续文档的参考指导，以下是一个基本的内容框架和介绍：

撰写产品需求文档是产品经理的必备技能，不但要求产品经理有产品本身全局的概念，还要能够高度抽象和精炼的把各个事项描述清楚，通俗易懂。

网上有不少的PRD模板可以借用，产品经理需要针对具体的开发项目，适当调整匹配，以有效和准确沟通为目的；同时，对于有些部分，无需急于一次完成，还是有一个不断优化完善的过程。

3. 开发技术能力（IT Competence）

“不是内行，但必须是行内”这是对产品经理在开发技术上的总体要求。

好比作为建筑设计师，在设计新的建筑的时候，是要对现阶段的工艺、材料和项目施工难度有基本把握的；如果设计的建筑没有相应的落地工程方案，那么这个设计就只是艺术品，而不是真正的产品——这里的道理实际上也是同样可以应用在软件产品的开发事项上；产品经理需要对产品实施方案的技术框架和可行性有基本的了解，在一些情况下还要对不同的开发实现方法与产品价值实现之间进行平衡和取舍。

了解开发技术的另外一个益处则是可以对技术难度的开发时间有自己的初步预判，快速调整和响应变化；对相关的时间影响，项目推进有基本的预判和提前安排；同时可以提供非纯粹开发人员的角度来给予思路，帮助团队拓宽解决方案的视角。这个能力同下支持下一部分介绍的项目管理能力、互相支撑。

在纷繁复杂的技术领域，有许多值得了解和学习的内容；针对于产品经理的日常工作，以下初略列出几个方面的内容可以学习研究来增强开发技术能力。

1）软件开发元素和团队分工

软件开发所涉及的主要元素和对应的人员分工能够帮助产品经理在宏观上了解具体搭建落地所涉及的事项。

如同建筑工程，整个建设过程是多个不同专业工种配合完成的，多个工种又会对具体实现的工艺为了匹配设计来平衡选择，那么对于软件产品开发也是同样的逻辑。

首先，是知晓软件开发编码需要使用的开发语言；程序开发是用一种计算机语言来表达外界事务的逻辑和处理的事项关系；无论是什么具体的开发语言，例如 C，Java，还是PHP都是为了这个目的。通过学习编程语言，产品可以了解编码的基本逻辑和所涉及的操作，从而更好的理解编码开发的原理和日常活动。

其次是了解数据库和使用SQL 来对数据库里的数据进行操作，进行数据分析和查询；简单来说，数据库是对数据按一定规则进行组织存储和管理，同时支持外界对数据进行增删改查操作的技术。

简单来分，有关系型数据库和非关系型数据库这两类：

关系型数据库通过二维表及数据字段和字段类型来表示数据；关系型数据库中，现实世界的实体被映射成二维表，然后数据之间的关系模型，通过实体关系来关联不同的表来实现。常见的关系型数据库就有Oracle、DB2、MySQL等。
而非关系型数据库是一种新的数据存储模型，储存的结构相对松散，可以不严格按照结构范式进行存储；非关系型数据库没有关系型数据库那样的严格数据结构约束，在存储的形式上也不同；常见的产品有MongoDB等。

两种数据库会针对不同的数据存储需求而选定。了解数据库和对应的技术使用，能够帮助产品经理优化功能设计和平衡利弊，把控开发进度。

例如，一些产品功能需要调用分布在不同数据库技术平台上的数据，那么相关的技术可行性、实现难度和性能问题和使用影响等，都会需要产品经理参与讨论，作为最终方案确定的依据。

而SQL（Structured Query Language）是数据库操作语言，被用来对数据库执行指令；SQL可以对数据库进行各类的操作，包括数据库表的创建和修改；它本身的语法并不复杂，但是用好它也需要不断学习提升水平。

SQL的学习和使用，可以帮助产品经理进一步了解表结构和表与表之间的关系，从而从数据模型角度进一步理解产品背后的数据逻辑实现方式；另外，可以提升产品和开发之间的理解，减少信息传递间的误解；问题的讨论可以当具体到某个表，某个字段，避免歧义；在数据查询和分析时，了解SQL可以大大方便产品的工作效率和质量。

了解了基础的开发技术和工具，接着就是操作这些工具的人员之间的分工和合作；产品经理需要了解不同职能分工，在处理开发事项时，快速定位需要沟通的对象，和调整沟通时需要的背景信息。

简单来说——从技术角度上开发人员分为前端开发，负责用户所能看到的展示界面，与用户交互的部分；和后端开发，主要针对服务端，让服务器、应用程序和数据库进行交互；虽然职能分工不同，但是工作都是相辅相成的，所以在一些具体实现的时候，会需要彼此平衡技术难度和工作量，达到最有效且精简的方案。

开发工作进行和完成的同时都需要质量的把控，所以会有测试工程师（QA）这个角色；从字面理解可以看出，这个角色主要是针对开发质量相关工作的。

这里有几个重要的理念需要强调，就是质量是谁的责任的问题；好比生产汽车的流水线上各司其职在制作产品，每个环节都需要有质量把控，每个人都要对自己环节的质量负责，确保最后的质量检测的合格达标。

同样，在软件产品开发当中，质量不是靠QA最后来测试来发现和确保合格的，而是每个开发人员的本职工作；在规划对应的产品测试战略和方法的时候，需要以此为基本出发点来统一协调团队的认知。

另外就是——质量容错的阈值；在敏捷开发，快速迭代的理念下，质量测试的力度需要平衡；不能一味的追求极致完美而投入和占用资源而措施战机，要达到质量把控，也要避免过度测试。

在开发工作过程中还有重要的一组就是数据库管理员（DBA）——DBA的职能覆盖从数据库涉及、测试到部署交付和运维的全生命周期的管理；产品经理需要和DBA打交道最多的就是对应的数据查询和分析事项；另外在一些产品性能和设计优化上，DBA也是需要被咨询和听取意见的人员。

2）基础设施

产品经理也要对基础设施有大概的了解。产品的开发过程中和开发完成后的部署都需要对应的基础设施来支持。

这里涉及到机房、服务器、网络、路由器、交换机等等相关的软硬件的概念；在以往的开发发布的环节上，企业需要把完成的代码打包发布在公网上服务器上，让外界可以使用；这种情况下，企业需要自己搭建机房和对应的基础设施或外界租用这些设施；而现在云的迅猛发展，让软件产品的开发和发布成本大大降低。

软件产品开发出来后，企业可以直接部署在云服务商（例如，阿里云、AWS、华为云等）的平台上；这样省去了购置服务器和搭建机房的费用，而只要支付流量使用费用，也无需操行基础设施设备的维护，升级等事项。

简单的比方就是——以前是每个企业自己买柴油发电机，自己发电，自己用；维护成本高，而且使用率也不是最优；而现在云平台类似统一接入到国家电网，按使用量付费。

两种方法各有优劣，而且随着企业业务发展需求和具体软件产品的使用情况而变化；产品经理需要知晓这个领域的知识，参与和推动对应的决策和管理影响。

3）系统架构

跳出具体的开发事项的关注，在更高层面来看，无论是已有产品模块改进优化还是新的产品模块的引入，首先要做的分析就是其对现有系统架构的影响和适配性。

好比一栋20年的老房子，房屋结构单一，工艺落后；现在突然一家新的住户搬家进来，决定要加盖新风系统和电梯；这个时候就需要考虑已有的建筑结构是否能支撑这些新的建筑模块。

同样，如果新的产品模块需要通过新的技术来实现，或者需要采用新的语言来开发，都需要考虑适配性；例如，在移动APP的开发中，新的产品功能时使用最新的Flutter还是原生系统开发，以及开发的产品模块是否可以适配老的系统框架，和如何使用。

这些技术上的细节决定和讨论不是产品经理的专长，但是需要产品经理有对应的敏感度和基本认知，了解这些问题是需要覆盖的事项。这个对整个产品项目落地和交付范围规划都有影响。

4）DevOps 基础

以上是介绍了基本开发过程可能涉及的基本元素，无论是技术、流程还是参与人员的职能分工；如之前提到的，产品经理对于开发技术需要有一定的敏感度，了解最流行和广泛的行业实践，这样可以与开发团队有相通的语境和概念框架来沟通。

软件工程或者软件开发的方法和理念的不断演进，与之匹配交付方式和理论也随之产生；在过去很长一段时间，软件产品的开发周期较长，每次发布时间之间的间隔也比较远；因此，周期中的主要矛盾是在需求变更和研发效率上，而发布部署的时间成本和资源占用的成本相比起来不是那么突出。

但是随着敏捷开发的理念的广泛推广实施，和商业环境对产品快速发布部署的要求越来越高，开发和运维一体化，从而达到运维工程师和开发工程师参与整个服务生命周期的一系列实践被积极提倡。

在维基百科里DevOps被定义为：“DevOps是一种软件工程文化和实践，旨在统一整合软件开发和软件运维；DevOps运动的主要特点是强烈倡导对构建软件的所有环节（从集成、测试、发布到部署和基础架构管理）经行全面的自动化和监控；DevOps的目标是缩短开发周期，提高部署频率和更可靠的发布，与业务目标保持一致”。

从核心上来看，DevOps是敏捷开发的延续，将敏捷思想和精益的原则在运维领域来实践应用。

虽然狭义上DevOps只涉及到软件生命周期，但是它也是一种 IT组织管理的发展趋势；力图通过各种方式打破原有IT职能部门之间的壁垒和合作模式，使之行动更加紧密，从而适配和促进业务迭代速度，解决业务痛点。

如下图所示，DevOps希望做到的是软件产品交付过程中IT工具链的打通，形成良好闭环，使得各个团队减少时间损耗，更加高效地协同工作，增加整体的产出。

在这里也有一些DevOps经常被使用的工具需要基本了解：

DevOps 被业界快速接受，内涵和概念也不断延伸。

在各方专业人士的分析和解读下，DevOps 概念涉及到的知识内容正变得越来越庞大，模型也变得愈加丰富、深入和细分；与理论并行的就是新的架构范式和工具的出现，来支持DevOps的落地和实践。其中最为火热和流行的就是“云原生”Cloud-Native。

2015年，Google联合其他20家公司宣布成立了开源组织 Cloud Native Computing Foundation (CNCF)，并且给出了云原生的定义：“云原生技术有利于各组织在公有云、私有云和混合云等新型动态环境中，构建和运行可弹性扩展的应用；云原生的代表技术包括容器、服务网格、微服务、不可变基础设施和声明式API。这些技术能够构建容错性好、易于管理和便于观察的松耦合系统。结合可靠的自动化手段，云原生技术使工程师能够轻松地对系统做出频繁和可预测的重大变更。

云原生计算基金会（CNCF）致力于培育和维护一个厂商中立的开源生态系统，来推广云原生技术；我们通过将最前沿的模式民主化，让这些创新为大众所用。

这么绕口难懂的定义，简单概括为4个要素：持续交付、DevOps、微服务、容器。

云原生是一个概念集合，既包含微服务、容器，也包含更多的管理方法，比如持续交付、DevOps和重组等。

以上是针对产品经理的开发技术能力的一些关注的知识点和领域。

需要强调的是——在绝大多数情况下，产品和产品背后的业务才是驱动价值的动力；没有产品这个载体，再美好的技术也是没有用武之地。

技术很重要，但是最终的目的是服务客户；过度的追求技术的完美和先进，而影响了产品的落实和价值实现，这是本末倒置的行为。

产品经理一定要时刻保持全视角思维，跳出当下技术迷思，以商业目标为导向要做抉择和驱动产品。

4. 项目管理能力（Project Management）

项目管理事项在一些企业是有专门的项目经理来负责，但是，大部分的企业还是会由产品经理来承担相关的责任；所以具备一定的项目管理能力是一种刚需；同时，通过项目管理的执行，产品经理可以更好的把控和了解产品的开发周期中的状态，并且积极参与和干预产品开发过程中遇见的挑战，从时间和资源管理上更好的推动产品解决业务问题的时效性。

5. 瀑布式开发与敏捷交付

软件行业在上世纪六十年代末提出了“软件工程”的概念，试图借鉴建筑行业领域的最佳实践，来找到适合软件行业的多人协作开发高质量大型软件产品的方法；软件工程的交付理论随着时代的变迁和外部市场的变化也出现的多样性的和各异性，随着时代的迁移和外部环境的变化，针对不同形态的产品或开发任务，可以选用不同的方法——其中最有名的就是“瀑布式”和敏捷交付。

Dr. Winston Royce在主导完成了一个大型软件项目开发工作后，描述了一种软件开发模型；在这里模型里包含了：系统需求、软件需求、分析、程序设计、编码、测试和部署运行几个阶段；而且各个阶段顺序相衔接，类似一个瀑布，从而称之为 “瀑布软件开发模型”。

这样的开发方式在一段时间内相当的流行，成为行业的标准；其中很大一部分的原因在于，曾经的软件开发活动所针对的业务问题相当复杂；而且因为信息技术的成本，只有大型的企业才有资源和能力对软件开发进行投入；而这类企业，相对来说保守和稳定，注重审批和决策流程，需要的是成熟可靠的交付和管理体系；更重要的是当时的外部环境节奏缓慢，不需要快速反应，需求单一且稳定。

而在互联网时代，企业外部环境变化极具加快，业务问题和目标需要更快、更敏捷的解决方案来应对；同时，瀑布模型在指导软件开发的局限也突显出来，特别是在对待不确定因数的问题上。

当下，企业讲究的是抓住稍纵即逝的机会，低成本的、精益的去落地实现方案，尝试各种业务探索和试错；这样的环境下，敏捷软件开发这一理念被广泛采纳，用于指导产品的研发事项。

敏捷开发的核心思路是将复杂的需求进行拆分，遵循业务价值高低来安排交付；简短的开发周期、按照固定节奏开发、按需发布，逐步迭代来实现和优化解决方案；而且不断的根据内外因素来自我调整。

本质上来说，敏捷模式较好的匹配了当下快速变化市场环境和商业形态；它的指导核心理念是先解决问题、落地方案，虽然初期不是理想方案，后期可以逐步优化；这就和瀑布式开发模型的内在核心理念不同的关键。

但是需要注意的是——敏捷开发不是一种软件开发方法，也不是一个体系完整的方法论；它是满足敏捷宣言及原则的一组轻量软件开发方法的集合，是一种开发理念。

下图展示的是这组集合中最为常见的敏捷流程框架、Scrum：

图中包含了Scrum里重要的几组概念：三个角色，三个工件，五个活动，企业可以按照实际情况来调整周期，落地实施。

1）PMBOK

项目管理最常引用的就是美国项目管理协会（PMI）的理论，其在发行的Project Management Body of Knowledge（PMBOK）详细的阐述了一套项目管理知识体系。

按照PMBOK的定义，项目是为创造独特的产品、服务或成果而进行的临时性工作；而项目管理是为了达到项目要求，把知识、技能、工具和技术应用于项目的活动；在最初的版本中，基于的是瀑布式开发模型，但是在最近的版本中，已经开始引入和覆盖基于敏捷理念的交付该如何进行项目管理活动的内容。

PMI的理论，针对项目管理由5大项目管理过程组，10个知识领域和49个管理流程；在介绍这些事项的过程当中，有大量的工具、方法和工件被介绍。

产品经理可以参考理论，使用这些工具来处理项目经行当中需要处理的事项和问题；产品经理应该不断熟悉和理解，增加相应的能力。

2）活动拆分和时间表规划

在传统的瀑布软件开发方法中，工作任务的分解时根据活动阶段来划分的。

如下图所示，产品的端到端开发被切割成不同阶段，只有由上一个阶段的全部完成才会开始下一个阶段，这使得项目产品直到最后联调测试阶段才知道开发的效果；这样造成业务无法及时验证产品有效性，而且这样一次性所有产品点都做，同时开发，没有主次之分，通常的开发时间都比较冗长，无法面对业务快速变化；业务的重点价值实现的落地被其他低优先级的开发事项拖延。

而从业务视角出发，将一个项目的所有业务需求划分为多个小的业务功能模块，每个功能模块以业务用户的视角来描述它形成用户故事，方便介绍和了解背后的业务价值。

需求的拆分是解析一个产品的构成的范围和内容实质，这一过程中产品经理可以使用MEMC、WBS等方法工具来辅助进行。

用树形图的方式，把每个功能模块模拟成树枝，然后把每个用户故事挂在相应的树枝上。

那么，每次交付的内容，是以业务价值为中心的；通过选择在不同树枝上的，高价值和优先级的故事卡片，组成当下迭代里最有业务价值的产品交付；之后再重复这个过程。

这种方式让业务人员能够及时得到可以开展业务的产品，获得市场反馈；同时，给与产品开发团队实时的反馈，以便于评估开发效果、调整和优化产品、响应市场变化。

支撑这一操作的基本理念是精益思维和敏捷开发，每次上线的产品点总是某一功能树枝上优先级高的故事卡；因此，很多时候已经上线的功能模块的并没有包含全部功能点，这也赋予了产品各个功能模块及其特性以时间的属性。

小批量，持续的交付，尽早的获得收益，加速价值流动——这样的方式，也带来了交付的灵活性；一旦外界和业务发生变化，团队可以快速处理手中的任务，转向其他事务，同时还可以保证系统的完整性。

需要强调的是——虽然这种开发方式可以快速带来收益反馈，但是也有成本代价；除了每次迭代后要将开发完成的产品部署到生产环境，还要回归测试前期交付的所有软件功能可以正确进行；验证成本投入会逐步增加。

从微观来看，每次迭代，产品经理最为需要注意的是把握每次迭代的产品价值，以此为中心来规划交付内容；而从宏观来看，2B类型的产品往往比较复杂，且工作量大，需要多个迭代的持续交付来实现的。

有时还会出现某个最小功能集合依然无法在一个迭代内完成的情况，另外，多数产品功能需要跨团队的配合来实践；这样总情况下，产品经理就需要搭建整体产品项目时间计划表。预先把所有的功能或故事点，按迭代来排期做初步规划，通过这个项目时间计划表来统筹各个参与方的节奏和工作内容。

项目时间表的搭建对产品经理有着非常重要的意义。

第一，在拆分具体项目活动的过程就是同相关参与人员共同交叉确定产品范围理解，查漏补缺和预估工作量的过程；在此过程中，参与人员可以同步对于开发事项的理解，充分讨论需求的边界上下文，交流初步技术方案的预想，对开发目标、质量标准和验收条件达成一致，建立共识；这里也需要用到上一章节讲述的产品经理的技术开发能力。

第二，确定开发活动的优先级和事件之间的依存关系，确保每个事项有对应的负责人和完成时间节点；一个事项一定要有对应的负责人，如果需要拆分成多个负责子事项给不同人员，也需要指定出一个总体协调负责人员，避免“人人负责”变成没有人负责。

第三，项目计划表的搭建是个反复优化和调整的过程；首先，项目总体时间必须在预先确定的时间范围内，如果产品总体交付时间超过预期，那么需要针对整体交付产品的范围和关键路径，特别时分组合作的情况下，进行分析和优化；其次，初次整体产品项目排期的完成，只是反应了当时的产品功能点所蕴含的价值优先程度；基于整体的项目规划框，动态的秉承敏捷的理念，可以周期性的根据业务价值调整交付物；最后，MVP和精益思维可以用于指导项目计划表的搭建和优化

第四，项目时间表还承担了沟通和协调开发进度的作用，产品经理在负责项目管理的时候，可以使用时间表来监控和控制开发进度；因为所有的需求点都是相关人员共同参与讨论过的，所有产品经理针对偏离正常进度的事项更加有信心来纠正；同时也给了开发人员明确的时间框架和开发事项，做到责任到人，奖惩清晰。

第五，项目时间表是“活”的，需要产品经理关注和管理；在具体每日的状态跟踪事项上，通常开发团队可以负责和总协调，产品经理需要支持；但是在一些情况下，产品经理也需要承担起驱动时间表和事项执行的任务，统筹相关事项——这也需要产品经理需要有对应的IT能力和思维，在遇见具体的技术相关事项和执行问题是，产品经理自己有相关的一个初步判断；通过事项本身对上下游利益相关者的影响，来推导思路；同时，可以积极借用先例处理方法，遵循先例来调整和规划方案事项。

有时，产品经理需要跳出项目自身资源配置，积极寻求更广范围内的资源来支持，例如公司内的技术负责人或者此专项的专家；以结果为导向，保护时间表，保持强的推动力和执行力，确保截止日期内完成相关事项。

在项目管理和交付理念上，产品经理需要由独立的判断能力，平衡不同交付方法的使用，以目的为导向，提升能效，解决业务问题；合适才是最好，无需一味追求流行和时髦。

黑猫白猫，抓到老鼠就是好猫。

5. 布道者能力 (Champion)

在这里使用“布道者”这样一个词来形容产品经理所要具备的一种综合能力；英文单词是Champion，对应的字典解释是“一个为了某项原则、理想、权力而全力以赴支持、捍卫和奋斗的人”

产品经理参与和推动整个产品生命周期的过程当中，需要面对和处理各种不同的利益相关人员的关系，同时扮演不同的角色；无论是在事项的主导、负责、咨询、支持或是被知晓的过程当中，产品经理需要时刻都保持者一份champion的意志和责任心。

在产品设计的初期，产品经理需要经行业务调研和商业分析，以期厘清业务痛点，总结和理解业务现状，开展规划；在这期间，产品经理需要组织和协调各相关业务部门负责人、系统架构师、技术负责人等，一起规划产品的功能范围、定位以及和公司现有产品体系如何融合。

当然，任何新的事物的引入，必然会引发对应的变革和利益调整；产品经理需要站在更高的角度，平衡各方利益，寻找最大公约数和共同利益；推进各个部门之间的配合，力求达到业务和产品之间的匹配；同时又要对诉求的轻重缓急有深刻的了解，产品经理需要搞清楚，在当前阶段，哪些功能可以带来更高的价值，从而引导资源倾向于最有价值的地方。

在开发过程中，产品经理需要紧密配合开发团队，有些公司会有专职的项目经理负责协调具体开发事务和项目进度的跟进；更多的时候，产品经理需要承担这一部分的职能，除了具体设计或开发事项的决定外，还需要对产品的远景和业务价值准确清晰的传达给相关人员，调动参与人员的内在动力，共同打造有价值的产品。

产品的开发落地不代表产品生周期的结束。产品经理还需要担当销售的角色；产品经理需要积极宣传和推销相关的产品，游说业务使用产品。

2C类型的互联网产品通常通过市场运作、运营活动等方式来让用户使用产品，实现推广；而2B类型的产品除了业务的自主使用外，产品经理也需要在各种场合宣讲和推动产品的使用，甚至担当拉拉队的角色来激发和赞扬对产品推广使用有益的事项；唯有产品被使用，真实的产品有效性才能被收集，分析和优化，才能达到给业务创造价值的目的。

在这个能力下所包含的各项软的技能，需要产品经理在日常工作中去分析提炼，通过实践去打磨和优化。