编辑导语：产品经理这个岗位的出现也顺应了市场的需求，随着市场的不断发展，不同的行业分布明确，产品经理也在不同行业都设立了岗位；在如今这个大背景下，产品经理以创造价值为宗旨，产品经理也需要掌握多种方法；本文作者详细介绍了B端产品经理的方法论，我们一起来看一下。
一、市场和产品
只有在市场经济体系下才会有产品经理这一个角色的出现，这样的经济框架下，市场的活动主体、企业，通过与其它企业交易所带来的价值来维持本身的存在和扩张需要；而交易的载体就是产品——通过产品在双方或者多方之间的交换，所有的参与方都在交易中获得了各自追求的价值。
那么如何在实践中，洞察能触发各方交易的需求，转换能满足需求的解决方案为可交易的产品，从而促成交易的发生和价值的创造，则成为产品经理所有担负的使命和工作范畴。
产品经理不是一个新鲜的职业，只要有市场、有交易，就会有产品经理。
在互联网产品经理出现之前，这种发掘市场需求、整合资源、设计方案、研发产品的诉求就一直存在；所以第一位产品经理出现在传统的快销行业也就不足为奇了。
时至今日，不同行业（例如家电、通信设备、机械制造、金融行业等）都诞生和逐步设立了产品经理这一岗位，而不在是将此角色的权责分散在企业里的不同组织当中。
在工业时代，受制于信息传递方式、技术成本和科技普及率，以及市场需求的局限；大多数时候产品经理这一职责实际上是被在不同职能部门中的人员共同完成的。
而信息时代的到来，互联网和信息技术彻底改变了以往时代的生产要素的分配和市场需求。
先进技术的发展，大大拓展了企业的生产能力和信息获取能力，市场需求从简单单一转为快速多样和碎片化；这样的外界商业环境，促使了产品经理职能需要被独立抽取出来，形成一个独立的职位来整合产品各个要素，贯通整个产品的生命周期。
1.C端产品经理
在“人人都是产品经理”的号召下，借助于信息技术的普及和研发成本的下降，C端产品经理这一群体逐步壮大，不断延伸业务范围。
结合各类学科的理论和实践，C端产品经理对个人的需求进行彻底和深入的研究与探讨，以期寻找新痛点，创造新的产品；社交类型的互联网产品就是这一类型产品的代表，例如抖音、陌陌。
2.B端产品经理
伴随着个人流量红利逐渐退潮，ToC互联网产品和为之服务的C端产品经理开始迈向了饱和状态；但是借助国家推出“互联网+”的概念和积极的政策引导，各行各业都开始对接互联网企业的先进技术和最佳实践，希望通过“行业+互联网”的方式来实现改革创新和产业升级。
在当下的市场环境里，企业需要结合科技来支撑自身已有业务的运营；同时，因为借助于科技的发展，新的商业模式不断涌现，新的市场需求被挖掘；如此快速多变的业务需求，需要企业在市场捕捉、运营体系、管理机制上及时响应来保证企业的生存和发展。
以企业运营架构和业务目标为背景，一个个业务团队或部门被抽象出来，通过观察和分析它们之间如何处理业务分工、规则设定、流程执行等事务；产品经理需要调动自己的商业分析能力和逻辑思维，从企业组织行为和组织目标来设计产品和定义功能，以期能解决企业的经营问题。
在此之外，B端产品经理还需要时刻观察和分析外部行业动态和内部运营数据，从而有预判性的和准确的对企业经营现状做出评估，通过B端产品的研发和迭代来驱动业务效能的提高、激发企业活力、实现自我提升。
B端产品的使用者也是个体自然人，类似C端产品，也会考虑交互体验；交互的界面享有相同的设计逻辑，也仅此而已；界面之后的产品驱动力和服务对象的不同，决定了产品经理所考虑的优先级，产品价值创造的逻辑大相径庭。
更进一步，B端产品所支持的业务诉求是依靠一系列使用群体共同协作通过产品来完成；产品经理需要在产品之外平衡各方利益诉求于产品生命周期内，从而达到共同的内在产品驱动。
市场和行业的大环境需要更多的B端产品经理，它的工作范畴需要跨领域的全面综合能力，对产品的全生命周期驱动能力，和各项专业商业和技术能力。
本文试图介绍B端产品生命周期和对应的能力在各阶段的匹配实践落地，通过案例的阐述来描绘出一个产品经理的工作范畴、职能足迹和技能使用，希望为B端产品经理的产品方法论和能力框架提供一个模型。
2.Womack和Jones提出精益思想可以指导价值的创造
清晰界定价值，把创造价值的活动按最优方式来组织执行，且不受任何杂事所扰，有效的执行，排除浪费，一次比一次更优化。
EricRies在《精益创业》里提出最小化可行产品（MinimumViableProduct,MVP）概念；简单地说，就是指开发团队，在新产品的开发过程中，通过提供最小化可行产品获取用户反馈；所以这样一个版本的产品能够用最小的资源投入来获得最大可能的被用户验证的反馈；通过执行这样一个概念，以期望有时效性地验证产品的价值。
在精益的思想下，拥抱变换、聚焦价值创造、精简快速地落地产品，成为产品经理所具备的思路。
与此同时，正如市场本身的变化，价值的创造不是静止的，产品的生命周期也不是线性不变的。
当一个MVP落地运行，开始满足企业经营基本需求的时候，产品本身对业务带来的效能和运营影响也开始被可以被衡量、评估和验证；通过获取真实反馈，分析业务数据，验证业务问题解决效果等一系列活动，新一轮的产品创造过程被启动，以用来矫正、优化或增加新的产品功能来解决新的业务问题。
这种迭代的思维帮助产品经理利用有限的资源快速验证和解决业务需求，持续的反馈又推进新的价值创造；纵观整个过程，产品本身的演进和生命周期结合业务需求，形成了完整的产品生命周期闭环，形成了持续交付的内生动力。
总结起来，创造价值、持续交付是产品经理的核心工作理念。
在上述理念中，创造价值是一系列的探索过程，试图锚定产品价值，解决业务问题，而持续交付则是搭建产品和验证产品价值效果的过程；在循环的过程中，不断自我矫正，适应外部和内部需求变化，达到产品和业务经营成功的完美结合。
某些行业对这一理念的实践并不陌生；比如在石油行业针对页岩气区块所采用的“滚动勘探开发”方法，或是美剧按季来推出新作品，甚至华尔街在几百年前的金融产品设计发行上都有蕴含这一理念；跨界的学习和借鉴，是产品经理不断自我提升、拓宽视野、丰富思路、打造适合的工作方法和理念的有效途径。
三、产品周期和范畴
产品本身的生命周期是一个循环的，螺旋上升迭代优化的过程。
1.洞察需求
企业或商业体的存在就是在不断创造价值，它的行为也是为这一目的而驱动的；同时，企业作为市场里生存的有机体，随时需要根据外部环境的变化来做出相应的调整和适应；那么以公司或者商业体为服务对象的B端产品则是为了匹配这些需求而打造。
发现具体业务需求后，产品经理则要立足于企业自身的商业模式和经济模型来开展工作；深刻理解企业为了商业目的所采取的策略和执行手段，以这些业务经营本质为基础，针对变革需求来匹配对应的产品设计和开发，从而达到了增加业务价值，匹配业务变化的结果；这样的结合是正向的匹配，即商业的动态和变化要求系统产品的跟进式匹配，是业务驱动的产品开发和价值发掘，动力方是在业务部门。
产品需求的渠道也可以是上一周期效能反馈；在系统产品搭建后，通过具体的数据收集、归类和洞察，然后提炼出无效率、资源浪费或需优化的地方；这些反馈也可以转化为企业变革的需求，这类需求以数据为基础，提出优化需求，让数据来驱动业务的变化，从而落地数据驱动的价值发掘。
通过数据点的数据收集，会为之后的产品运营打下基础，同时也是验证应用产品本身的有效性，和未来提出新的产品改进思路的数据理论基础；从而推动和形成产品进化闭环，双向流动，互为推手，已更高价值和更优效率为目的，交替驱动，不断提升。
2.产品设计
产品设计阶段有两条主线横跨整个进程，互相驱动和支撑；其中一条相对于产品经理比较明显，是匹配业务需求和痛点来设计产品方案；而另外一条更强调的是和具体开发工作所需厘清的事项，例如软件架构、技术选型、测试策略等等，为之后产品开发阶段的产品具体实现落地，和适合的技术方案选型做前期技术准备。
产品总体的设计思路是从自顶而下，整体到细节，逐步细化，层层推进；通过业务诉求分析和运营诊断，产品经理从具体的业务事务和流程当中抽象和演化出具体产品功能模块和设计产品的效果。
在开始一个产品解决方案时，首先需要的是评估是该方案的所针对的业务和现有的企业解决方案之间的关系。
这个新的业务问题需要的是对已有的系统平台进行改造优化，还是有全新的技术方案需要开发，或者是两者的混合模式；好比你要在一个装满点心的盘子里要在放入一块新的蛋糕，它的放入不可避免的会对已经在盘子里的其它糕点造成影响；也许要挪挪位置，从新排列组合，腾出点空间给新的蛋糕，或是把一些不想吃的点心挪出盘子。
一个新的系统产品的出现必然会影响到已有的企业软件架构和组织，如何有序和有规划的安排，是产品经理和受影响的业务部门需要探讨和决定的；而这一过程中，需要平衡各方面的诉求和利益，但是必须以业务整体优化目标为结果导向。
在业务流程梳理过程中，通过对业务的理解和涉及到的业务对象，通过逻辑抽象，归纳整理出来需要服务或使用产品的对象，及其在整体方案中的功能定位和实现目标。
接下来就是将分类出的对象下所需要执行的业务工作，本质诉求和目标，进行提炼和归纳为具体的商业功能模块——这需要产品经理具备基础的企业管理和商业知识，配合具体企业业务部门的领域知来进行规划设计；在这个步骤当中，各种的功能需求会被建议和提出；当汇总完成后，就形成了整个产品的路线图（Roadmap）；如之前所讨论的，企业的诉求多样和市场变化十分迅速，不可能一次性完成所有的功能点，这也不适合现在提倡的精益和聚焦价值，快速迭代的理念；产品经理需要帮助业务部门定义产品的MVP，逐步推进路线图的落地。
从整体到局部，下一步就是具体的产品细节设计；这一部分的工作是把一个个抽象的功能模块概念、可视化成为一页页可以同用户交互的界面，以及设计界面背后的数据模型、权限和逻辑等的事项。
在整个产品方案设计过程中，业务流程图是一个非常核心和关键的工件；它是连接现实业务和系统开发工作的桥梁，让业务、产品和开发团队使用同一个语言背景来讨论问题和推演方案。
在设计当中，业务流程图自身的不同层级对业务流程步骤的描绘、逻辑的细节，具体操作交互等的深入和细化，不同职能的参与方（业务、产品、技术等）都可以在相应的层级主导和提供支持方案的最优设计。
另外一条工作主线则是相应的技术方案选型和准备工作，这部分的工作主要是开发技术人员来主导，产品需要了解过程和提供对应的信息支持；首先是应用技术架构和新的产品解决方案之间的适配性的思考；例如，现存的软件架构是单体式架构（Monolithic），而新的业务形态和方案需要使用微服务（MicroService）来支撑；然后是一些具体的技术选型（例如,前端开发技术语言等）和开发策略问题的讨论；需要如何匹配产品设计方案来更加准确，高效的达到产品目标——这是一个反复讨论和平衡利弊的过程。
3.产品开发
这种情况下，产品经理将要担负起项目经理的职责，对产品进度的推进落地进行把控。
根据市场的变化和业务价值的优先级，产品经理还需要动态的调整产品功能交付的优先级和范围，在项目管理角度把控下一步的计划和安排；与此同时，阶段性的开发成果需要积极邀请业务方参与验收评估。
虽然整体功能不能全部展现和贯通，但是结合一些技术措施（例如使用Mockup来表示未来实现后的效果），把已经开发出来的功能点给予展示，可以及时收到业务的反馈，保证目标和方向的正确性和一致性。
4.产品运营
基于精益思维，产品本身都具有阶段性，仍然需要不断的迭代和优化；所以在产品运营阶段，运营事项里面不但包含了业务在产品上日常的运营、监控和管理等事项，还包含了产品经理会往外对产品进行游说、推销和积极搜集反馈、主导或辅助一切能让产品本身被更广泛使用增长和优化的事项。
与此同时，根据之前在需求洞察阶段定义的绩效指标和数据埋点，这个阶段可以用于从不同的角度来观察和分析产品效果。
如果是从0到1的产品线搭建，那么需要考察的是，这条产品线是否已经通畅运行，业务部门在上面执行的关键业务环节是否有异常和阻塞；新业务线的搭建，是否帮助企业获取到了规划的目标市场，业务部门和用户有多少人开始通过产品来执行新的业务，以及在此产品上的业务成交量的大小。
因为是新的功能和业务，产品经理需要提前准备和积极参与功能的推广宣传和业务培训事项；充分结合和调动业务部门负责人的资源和参与度，从而获得更好的用户接受度和使用率；如果涉及到重大企业组织结构级别的变动，还需要提前制定变更管理计划；产品在被使用过程中，也会涉及到逻辑答疑、业务数据分析和解释、系统Bug修改等支持活动，需要产品经理参与和帮助协调资源解决问题。
在与业务日常运营的交流中，该阶段产品的局限性和故障被总结，业务部门的反馈和新要求被收集，从而形成下一个阶段的需求池；同时，系统记录的绩效数据和数据埋点可以从客观上提供不同的分析视角和改进需求。
例如，在某维修公司，业务部门提出把属于一个上门点的所有维修工单统一归纳到一个服务请求下来；这样可以做到一次请求，多个工单同时解决，从而避免多次上门和重复业务流程的目的；该产品功能上线以后，业务人员确实在使用，也提出了不少的改进建议；但是数据分析发现，大部分的服务请求下，实际只包含了一个工单，没有达到预取的效果，维修人员还是多次上门服务，重复流程，这些发现是通过系统数据发掘的；客观的指出了——产品的使用层面的成功并没有带来预期的业务效果，这些运营数据就可以成为产品功能优化和改进的参考。
另外一方面就是参考用户行为数据的分析；用户旅程地图（UserJourneyMap）的数据埋点和热力图等来验证用户和产品之间的交互是否是按照设计来执行，从而推演出产品的实际业务效果数据和用户使用行为之间的关系；如果效果不好，那么是否是因为用户没有按设计的交互场景来使用，或者是效果很好的原因是因为用户使用的方法与设计有高度的吻合。
四、B端产品经理的能力1.商业洞察能力(BusinessInsights)
产品经理的使命是创造价值，商业洞察能力能够帮助产品经理准确地定位价值在企业当中的所在；通过分析企业商业信息，了解业务规则和具体的执行，才能搭建出与之匹配，适合业务的系统产品。
产品经理的商业洞察能力是一个很宽泛的范畴，包含了经济学、组织行为学、经营管理、市场营销、金融财务等等；这些基础学科和领域知识给予产品经理对应的通识能力和批判性思考框架，从而可以透过事物纷繁复杂的表面现象来定位核心问题，锚定企业变革需求的实质问题。
例如，在许小年的《商业的本质和互联网》一书当中就充分的阐述和分析了各类商业模式和和对应的互联网企业的案例；透过这一系列的案例，各类互联网企业的盈利模式和经济效应模型被剖释，让读者明白助力这些互联网企业发展壮大的商业本质是什么；同时也揭露了一些企业的伪经济模型和其为何无法盈利，哪怕当时这些企业意气风发，风头正盛。
这些解析后的思维，正是产品经理所需要具备的商业洞察能力。俞军曾经在一次发言中也提到，产品经理实际是从总经理这个岗位上剥离出来的角色，那么作为这个角色就需要具备总经理一样的商业洞察能力，做市场定位，洞悉人性，像总经理一样考虑周全，不断打磨迭代产品。
1）商业经济模型
这里利用一个案例来讨论经济模型和剖析企业的商业模式，从而反映出这类能力如何能帮助产品经理更好和更有效地针对企业的变革需求来打造对应的产品，使之与业务目标匹配。
T公司是一家运营了多年的2B类型汽车维修企业。企业从一家小维修公司开始，发展自己维修服务业务，与此同时逐步通过打造自己的IT业务平台，慢慢演化成了专为企业级客户提供车辆维修业务的服务外包商。
T公司首先和大型运输企业客户签订维修商业外包合同，使得客户可以在系统平台上提交车辆维修工单；另一方面，T公司在全国各地招募汽修企业入驻到系统平台上，每当客户企业在某区域有维修工单产生，平台会通过算法匹配分发给在该地区适配的已签约入住系统平台的汽车维修公司。
基于这样一个商业场景，在解决业务诉求和运营痛点的时候，到底是以什么经济模型来评估产品的价值和业务目标呢？
它的底层经济模型是和滴滴或者Uber一样，遵循梅卡夫效应（Metcalfe‘sLaw），通过正向推动刺激来扩张经营业务的么？
Uber为消费者提供了匹配服务，它帮助乘客找到司机，同时帮助司机匹配乘客；随着司机不断加入和服务覆盖区域的扩张，这一商业模型的内在增长动力开始出现。
还是说，它是基于双边效应下的商业模型？
梅卡夫这一效应的强大在于每个节点间的互动与活跃，在此前提下的商业模式才具有更高的经济估值；而对与某一类网络商业模式来说，交互只存在特定种类用户之间，比如AirBnB上的房东和房客之间，跟谁学上互动和交易仅存在于学生和老师之间进行。
在互联网的平台商业模式中，用户分为两大类是常见的现象；同时，供应商同供应商之间鲜有往来。消费者之间大体也是“鸡犬之声相闻，老死不相往来”；是正如郭德纲所说，同行是冤家。用一个简单图形表示，如下：
也许T公司的这个商业模式，没有列在这里所说的经济效应模型当中。它只不过是做着传统生意的买卖，无外乎是迁移了经营场所而已。实际上的使用的是以下经济模型
产品经理的商业洞察力也会针对业务形态和成熟度有不同维度的运用；通常是通过设计和实施应用产品来推动和支持业务运营目标的实现，从而达到业务驱动型价值；另一方面，在已经处于运营阶段的产品系统，产品经理可以通过数据的运营和发掘，或者新技术的引进，引导企业改善运营现状，提高企业现有商业模式下的效能，从而实现产品驱动型价值；产品经理需要清晰的了解业务所处的状态和产品本身的能力，从而预判不同业务痛点所需要的产品方案。
这个分析能力的运用贯穿整个产品的生命周期，虽然在不同的阶段的密集程度不一样，但是对于产品从概念到落地都有十分重要的意义。
在洞察阶段，解读商业模式，确定产品的目标和定位。设计匹配业务目标市场和行业的产品方案MVP。
在设计阶段确定业务逻辑和交互原则，让产品设计逻辑和交互更加贴近业务的特性、优化流程、提高效率、支持核心业务目标；在实施阶段帮助开发团队进行逻辑验证和迭代规划，确保交付产品的业务价值，把控投入开发资源和业务效益的平衡；运营阶段又重新回到舞台中央，主导产品的生命周期主要事项，监控和评估产品落地后的效益和运营改善事项。
2）业务组织结构
了解和研究业务组织架构能够帮助产品经理在工作过程中厘清工作目标，处理好协作关系，从而保证工作的高质量开展和高效完成。
企业的发展阶段需要不同的组织架构来支撑其业务形态和发展目标；从某种程度上，组织架构就反映出了业务价值重点的分布和优先级；例如，各大互联网企业随业务和市场变化而进行商业事业部调整。通过匹配合理的组织架构搭建，企业可以正确的引导业务部门的运作往规划的价值方向发展，也锚定了每个业务人员的共同目标。
组织架构决定了汇报关系，进而决定了绩效考核方式。同时，汇报关系、绩效考核方式会影响人做事的动机、行事的方式，以及个人和团队的利益；厘清了这些组织结构所反馈出来的业务价值和利益关系，产品经理可以从企业经营的角度来平衡产品价值优先级，优化资源投入和产品组合。
在一个理想的情况下，企业组织有明晰的组织架构和共同的价值目标，把企业互相独立的力量聚集成一股合力；这种环境下，产品经理可以充分发挥和聚焦产品研发本身。
3）商业工具
还有其他理论和工具来引导企业运营和商业因素的分析，这些理论从不同角度对企业经营经行梳理，帮助产品经理有结构、有体系框架的了解产品服务的对象。
以下列举几个常用的方法：
4）业务拓展和延伸
除了关心现有的业务经营范围，产品经理也需要拓展相应的产品思路和全局观，把握行业脉搏，同时跳出当下，对企业发展的走向有思考。
以上述例子里的T公司为例。现在的企业经营的业务线只在公交系统的车辆维修，那么如何拓展除了这条业务线以外的其他市场，比如说货车、的士等？或者说，目前公交系统这个细分市场里，还有什么可以延伸的客户？比如之前可能只覆盖市内公交系统车辆，那么城际车辆和长途车辆呢？
另外的一个延伸是对应的系统技术这个角度；目前T公司是作为服务公司，使用系统平台来服务客户和对接汽修公司；那么针对希望自己运营管理维修工单，不愿意使用这种外包服务模式的客户公司，是否可以提供技术平台，以SaaS的模式为客户提供服务。
以上只是从两个维度来拓展衍生业务。
如之前介绍的，产品经理有时需要已总经理的角度来考虑企业经营，市场定位和产品打造。
2.产品设计能力(ProductDesignSkills)
产品设计能力需要把产品从抽象概念、可视化的、有结构的展示出来；这样的能力的技巧就涵盖了信息架构、原型设计、原型交互和用户旅程地图、UI设计和各类产品文档的撰写事项；例如，商业需求文档(BusinessRequirementDocument)，产品需求文档(ProductRequirementDocument)，和市场需求文档(MarketRequirementDocument)等。
1）信息架构
产品经理通过信息架构的设定来统筹和规划整个产品设计所覆盖的范畴。同时，信息架构本身也提纲挈领地指导其它产品设计技能的实践。
一款产品是通过系统与用户之间的交互，以数据为桥梁推动业务流程的流转。
那么什么信息应该展示和如何更加有效的展示，从而让用户便捷获取所需信息，方便地执行操作，这都依赖于信息架构的指引；要直接了解信息架构是哪些组件构成是相当困难的，用户只和部分组件直接交互，而其他躲在幕后的组件，用户却没有感知；在《信息架构–超越Web设计》中，信息架构被分解为4个组件。
基于这些组件，产品经理搭建与产品相匹配的信息架构。在众多信息架构所涉及的领域来说，最直接的一项就是产品/系统页面菜单。菜单结构本身不但蕴含了与业务流程的映射，同时也兼顾了用户习惯，让用户快速获取信息。
2）原型设计
这个方法，在具体落地设计时，通过分步来实现；首先是采用线框图粗略表达必要信息的展示方式和布局，采用用户画像、亲和图、业务主题锚定、遵循先例等手段；产品经理设计出线框图，通过可视化的手段、带入场景、验证假设和讨论效果，从而不断优化推动下一步开发；接着是进一步在视觉上深化，设计样机模型（mockup）。
线框主要代表产品的结构，而样机模型则显示了产品的外观；它还不能实现点击滑动等交互操作，但是拥有更高的清晰度。最后是高保真图的开发和设计。
此外，一般系统产品都会提前准备一套产品组件，例如，输入框、按钮、侧边栏、分页符等；组件是设计的基本元素，组件的使用可以保证设计上的一致性，方便后续的产品设计工作，同时也帮助提高产品经理的工作效率；产品经理需要了解和灵活使用，避免重复造轮子，或是过度资源投入在新组件的开发上。
3）原型交互
在产品页面的设计过程中，页面间的交互设计也已经同时被讨论和开发出来。原型的交互设计有各种的理论和技巧被研讨过。
最为经典的是JakobNielsen提出的10大可用性原则（10UsabilityHeuristicsforUserInterfaceDesign）；产品经理需要在理解这些原则的基础上，结合具体的问题，灵活使用，参与交互设计工作。
虽然2B类型的产品服务对象是企业组织群体和业务目标，但是它的日常操作是同每个个体经行交互和执行的。用户使用过程的流畅、高效将会对产品本身成功落地和发挥效能起到推波助澜的作用。
4）用户旅程地图
用户旅程地图（UserJourneyMap）是一个帮助产品经理充分了解和分析用户使用行为的工具，同时借此可以优化产品与用户的交互，达到产品使用催化剂的效果；用户旅程地图可视化地将用户与产品或服务之间的互动，按业务流程分阶段地把用户体验、行为、感受和想法展示出来。
通常，一个旅程图包括3个部分的内容：
用户旅程地图的制作步骤如下：
例如，对于一个火锅店来说，重要的一个业务事项就是如何缩短从客户开始点菜，确定菜品到最后的客户买单离店这样一个过程——针对整个事件场景，我们可以搭建对应的流程模型，对各个环节进行分析；当按照旅程地图制作步骤，获得了问题症结的假设后开始进行对应的优化安排。
UI工程师基于交互原型进行美工设计，生成切图；前端工程师拿到切片文件，进行前端开发，包括交互、动作效果等；产品配合UI工程师确定设计质量，同时为衔接前端工程师开始相应的开发。
产品设计能力大部分涉及到和用户个体的交互事项，所以和2C的能力有高度重合，毕竟2B的产品需要人来操作；抽象事务和概念的可视化过程，结合业务和审美，提高美学的修养和实际工程的结合。
总体来说，这些技巧的使用会因产品本身匹配的业务而灵活运用，但是也有不少的日常最佳实践可以帮助到日常工作，提高产品经理工作效率和质量。
首先，设计时，需要参考企业内部已经约定俗成的方法；保持新的产品设计和已有产品之间的一致性，减少使用教育成本。
另外，如非必要，可以直接采用常用设计软件（Axure,Visio等）的标准控件；产品经理需要平衡为产品单独定制所耗费资源与定制带来的收益，过度的追求设计上的新意，容易舍本逐末，浪费工作资源。
B端产品应当简单直接设计，以解决业务问题和效率为核心指导思想，先落地；在之后的运营阶段，各个页面被使用，通过数据埋点，热力图等方法了解用户习惯，随后可以不断针对性的迭代优化。
5）产品文档
它需要包含的内容会作为其他后续文档的参考指导，以下是一个基本的内容框架和介绍：
撰写产品需求文档是产品经理的必备技能，不但要求产品经理有产品本身全局的概念，还要能够高度抽象和精炼的把各个事项描述清楚，通俗易懂。
网上有不少的PRD模板可以借用，产品经理需要针对具体的开发项目，适当调整匹配，以有效和准确沟通为目的；同时，对于有些部分，无需急于一次完成，还是有一个不断优化完善的过程。
3.开发技术能力（ITCompetence）
“不是内行，但必须是行内”这是对产品经理在开发技术上的总体要求。
好比作为建筑设计师，在设计新的建筑的时候，是要对现阶段的工艺、材料和项目施工难度有基本把握的；如果设计的建筑没有相应的落地工程方案，那么这个设计就只是艺术品，而不是真正的产品——这里的道理实际上也是同样可以应用在软件产品的开发事项上；产品经理需要对产品实施方案的技术框架和可行性有基本的了解，在一些情况下还要对不同的开发实现方法与产品价值实现之间进行平衡和取舍。
在纷繁复杂的技术领域，有许多值得了解和学习的内容；针对于产品经理的日常工作，以下初略列出几个方面的内容可以学习研究来增强开发技术能力。
1）软件开发元素和团队分工
软件开发所涉及的主要元素和对应的人员分工能够帮助产品经理在宏观上了解具体搭建落地所涉及的事项。
如同建筑工程，整个建设过程是多个不同专业工种配合完成的，多个工种又会对具体实现的工艺为了匹配设计来平衡选择，那么对于软件产品开发也是同样的逻辑。
首先，是知晓软件开发编码需要使用的开发语言；程序开发是用一种计算机语言来表达外界事务的逻辑和处理的事项关系；无论是什么具体的开发语言，例如C，Java，还是PHP都是为了这个目的。通过学习编程语言，产品可以了解编码的基本逻辑和所涉及的操作，从而更好的理解编码开发的原理和日常活动。
其次是了解数据库和使用SQL来对数据库里的数据进行操作，进行数据分析和查询；简单来说，数据库是对数据按一定规则进行组织存储和管理，同时支持外界对数据进行增删改查操作的技术。
简单来分，有关系型数据库和非关系型数据库这两类：
两种数据库会针对不同的数据存储需求而选定。了解数据库和对应的技术使用，能够帮助产品经理优化功能设计和平衡利弊，把控开发进度。
而SQL（StructuredQueryLanguage）是数据库操作语言，被用来对数据库执行指令；SQL可以对数据库进行各类的操作，包括数据库表的创建和修改；它本身的语法并不复杂，但是用好它也需要不断学习提升水平。
SQL的学习和使用，可以帮助产品经理进一步了解表结构和表与表之间的关系，从而从数据模型角度进一步理解产品背后的数据逻辑实现方式；另外，可以提升产品和开发之间的理解，减少信息传递间的误解；问题的讨论可以当具体到某个表，某个字段，避免歧义；在数据查询和分析时，了解SQL可以大大方便产品的工作效率和质量。
了解了基础的开发技术和工具，接着就是操作这些工具的人员之间的分工和合作；产品经理需要了解不同职能分工，在处理开发事项时，快速定位需要沟通的对象，和调整沟通时需要的背景信息。
简单来说——从技术角度上开发人员分为前端开发，负责用户所能看到的展示界面，与用户交互的部分；和后端开发，主要针对服务端，让服务器、应用程序和数据库进行交互；虽然职能分工不同，但是工作都是相辅相成的，所以在一些具体实现的时候，会需要彼此平衡技术难度和工作量，达到最有效且精简的方案。
这里有几个重要的理念需要强调，就是质量是谁的责任的问题；好比生产汽车的流水线上各司其职在制作产品，每个环节都需要有质量把控，每个人都要对自己环节的质量负责，确保最后的质量检测的合格达标。
同样，在软件产品开发当中，质量不是靠QA最后来测试来发现和确保合格的，而是每个开发人员的本职工作；在规划对应的产品测试战略和方法的时候，需要以此为基本出发点来统一协调团队的认知。
另外就是——质量容错的阈值；在敏捷开发，快速迭代的理念下，质量测试的力度需要平衡；不能一味的追求极致完美而投入和占用资源而措施战机，要达到质量把控，也要避免过度测试。
在开发工作过程中还有重要的一组就是数据库管理员（DBA）——DBA的职能覆盖从数据库涉及、测试到部署交付和运维的全生命周期的管理；产品经理需要和DBA打交道最多的就是对应的数据查询和分析事项；另外在一些产品性能和设计优化上，DBA也是需要被咨询和听取意见的人员。
2）基础设施
产品经理也要对基础设施有大概的了解。产品的开发过程中和开发完成后的部署都需要对应的基础设施来支持。
软件产品开发出来后，企业可以直接部署在云服务商（例如，阿里云、AWS、华为云等）的平台上；这样省去了购置服务器和搭建机房的费用，而只要支付流量使用费用，也无需操行基础设施设备的维护，升级等事项。
简单的比方就是——以前是每个企业自己买柴油发电机，自己发电，自己用；维护成本高，而且使用率也不是最优；而现在云平台类似统一接入到国家电网，按使用量付费。
两种方法各有优劣，而且随着企业业务发展需求和具体软件产品的使用情况而变化；产品经理需要知晓这个领域的知识，参与和推动对应的决策和管理影响。
3）系统架构
好比一栋20年的老房子，房屋结构单一，工艺落后；现在突然一家新的住户搬家进来，决定要加盖新风系统和电梯；这个时候就需要考虑已有的建筑结构是否能支撑这些新的建筑模块。
同样，如果新的产品模块需要通过新的技术来实现，或者需要采用新的语言来开发，都需要考虑适配性；例如，在移动APP的开发中，新的产品功能时使用最新的Flutter还是原生系统开发，以及开发的产品模块是否可以适配老的系统框架，和如何使用。
这些技术上的细节决定和讨论不是产品经理的专长，但是需要产品经理有对应的敏感度和基本认知，了解这些问题是需要覆盖的事项。这个对整个产品项目落地和交付范围规划都有影响。
4）DevOps基础
以上是介绍了基本开发过程可能涉及的基本元素，无论是技术、流程还是参与人员的职能分工；如之前提到的，产品经理对于开发技术需要有一定的敏感度，了解最流行和广泛的行业实践，这样可以与开发团队有相通的语境和概念框架来沟通。
但是随着敏捷开发的理念的广泛推广实施，和商业环境对产品快速发布部署的要求越来越高，开发和运维一体化，从而达到运维工程师和开发工程师参与整个服务生命周期的一系列实践被积极提倡。
在维基百科里DevOps被定义为：“DevOps是一种软件工程文化和实践，旨在统一整合软件开发和软件运维；DevOps运动的主要特点是强烈倡导对构建软件的所有环节（从集成、测试、发布到部署和基础架构管理）经行全面的自动化和监控；DevOps的目标是缩短开发周期，提高部署频率和更可靠的发布，与业务目标保持一致”。
从核心上来看，DevOps是敏捷开发的延续，将敏捷思想和精益的原则在运维领域来实践应用。
虽然狭义上DevOps只涉及到软件生命周期，但是它也是一种IT组织管理的发展趋势；力图通过各种方式打破原有IT职能部门之间的壁垒和合作模式，使之行动更加紧密，从而适配和促进业务迭代速度，解决业务痛点。
在这里也有一些DevOps经常被使用的工具需要基本了解：
DevOps被业界快速接受，内涵和概念也不断延伸。
在各方专业人士的分析和解读下，DevOps概念涉及到的知识内容正变得越来越庞大，模型也变得愈加丰富、深入和细分；与理论并行的就是新的架构范式和工具的出现，来支持DevOps的落地和实践。其中最为火热和流行的就是“云原生”Cloud-Native。
云原生计算基金会（CNCF）致力于培育和维护一个厂商中立的开源生态系统，来推广云原生技术；我们通过将最前沿的模式民主化，让这些创新为大众所用。
这么绕口难懂的定义，简单概括为4个要素：持续交付、DevOps、微服务、容器。
云原生是一个概念集合，既包含微服务、容器，也包含更多的管理方法，比如持续交付、DevOps和重组等。
需要强调的是——在绝大多数情况下，产品和产品背后的业务才是驱动价值的动力；没有产品这个载体，再美好的技术也是没有用武之地。
技术很重要，但是最终的目的是服务客户；过度的追求技术的完美和先进，而影响了产品的落实和价值实现，这是本末倒置的行为。
产品经理一定要时刻保持全视角思维，跳出当下技术迷思，以商业目标为导向要做抉择和驱动产品。
4.项目管理能力（ProjectManagement）
5.瀑布式开发与敏捷交付
软件行业在上世纪六十年代末提出了“软件工程”的概念，试图借鉴建筑行业领域的最佳实践，来找到适合软件行业的多人协作开发高质量大型软件产品的方法；软件工程的交付理论随着时代的变迁和外部市场的变化也出现的多样性的和各异性，随着时代的迁移和外部环境的变化，针对不同形态的产品或开发任务，可以选用不同的方法——其中最有名的就是“瀑布式”和敏捷交付。
Dr.WinstonRoyce在主导完成了一个大型软件项目开发工作后，描述了一种软件开发模型；在这里模型里包含了：系统需求、软件需求、分析、程序设计、编码、测试和部署运行几个阶段；而且各个阶段顺序相衔接，类似一个瀑布，从而称之为“瀑布软件开发模型”。
而在互联网时代，企业外部环境变化极具加快，业务问题和目标需要更快、更敏捷的解决方案来应对；同时，瀑布模型在指导软件开发的局限也突显出来，特别是在对待不确定因数的问题上。
当下，企业讲究的是抓住稍纵即逝的机会，低成本的、精益的去落地实现方案，尝试各种业务探索和试错；这样的环境下，敏捷软件开发这一理念被广泛采纳，用于指导产品的研发事项。
敏捷开发的核心思路是将复杂的需求进行拆分，遵循业务价值高低来安排交付；简短的开发周期、按照固定节奏开发、按需发布，逐步迭代来实现和优化解决方案；而且不断的根据内外因素来自我调整。
本质上来说，敏捷模式较好的匹配了当下快速变化市场环境和商业形态；它的指导核心理念是先解决问题、落地方案，虽然初期不是理想方案，后期可以逐步优化；这就和瀑布式开发模型的内在核心理念不同的关键。
但是需要注意的是——敏捷开发不是一种软件开发方法，也不是一个体系完整的方法论；它是满足敏捷宣言及原则的一组轻量软件开发方法的集合，是一种开发理念。
下图展示的是这组集合中最为常见的敏捷流程框架、Scrum：
图中包含了Scrum里重要的几组概念：三个角色，三个工件，五个活动，企业可以按照实际情况来调整周期，落地实施。
1）PMBOK
项目管理最常引用的就是美国项目管理协会（PMI）的理论，其在发行的ProjectManagementBodyofKnowledge（PMBOK）详细的阐述了一套项目管理知识体系。
按照PMBOK的定义，项目是为创造独特的产品、服务或成果而进行的临时性工作；而项目管理是为了达到项目要求，把知识、技能、工具和技术应用于项目的活动；在最初的版本中，基于的是瀑布式开发模型，但是在最近的版本中，已经开始引入和覆盖基于敏捷理念的交付该如何进行项目管理活动的内容。
PMI的理论，针对项目管理由5大项目管理过程组，10个知识领域和49个管理流程；在介绍这些事项的过程当中，有大量的工具、方法和工件被介绍。
产品经理可以参考理论，使用这些工具来处理项目经行当中需要处理的事项和问题；产品经理应该不断熟悉和理解，增加相应的能力。
在传统的瀑布软件开发方法中，工作任务的分解时根据活动阶段来划分的。
而从业务视角出发，将一个项目的所有业务需求划分为多个小的业务功能模块，每个功能模块以业务用户的视角来描述它形成用户故事，方便介绍和了解背后的业务价值。
需求的拆分是解析一个产品的构成的范围和内容实质，这一过程中产品经理可以使用MEMC、WBS等方法工具来辅助进行。
用树形图的方式，把每个功能模块模拟成树枝，然后把每个用户故事挂在相应的树枝上。
那么，每次交付的内容，是以业务价值为中心的；通过选择在不同树枝上的，高价值和优先级的故事卡片，组成当下迭代里最有业务价值的产品交付；之后再重复这个过程。
这种方式让业务人员能够及时得到可以开展业务的产品，获得市场反馈；同时，给与产品开发团队实时的反馈，以便于评估开发效果、调整和优化产品、响应市场变化。
小批量，持续的交付，尽早的获得收益，加速价值流动——这样的方式，也带来了交付的灵活性；一旦外界和业务发生变化，团队可以快速处理手中的任务，转向其他事务，同时还可以保证系统的完整性。
需要强调的是——虽然这种开发方式可以快速带来收益反馈，但是也有成本代价；除了每次迭代后要将开发完成的产品部署到生产环境，还要回归测试前期交付的所有软件功能可以正确进行；验证成本投入会逐步增加。
从微观来看，每次迭代，产品经理最为需要注意的是把握每次迭代的产品价值，以此为中心来规划交付内容；而从宏观来看，2B类型的产品往往比较复杂，且工作量大，需要多个迭代的持续交付来实现的。
在项目管理和交付理念上，产品经理需要由独立的判断能力，平衡不同交付方法的使用，以目的为导向，提升能效，解决业务问题；合适才是最好，无需一味追求流行和时髦。
黑猫白猫，抓到老鼠就是好猫。
5.布道者能力(Champion)
在这里使用“布道者”这样一个词来形容产品经理所要具备的一种综合能力；英文单词是Champion，对应的字典解释是“一个为了某项原则、理想、权力而全力以赴支持、捍卫和奋斗的人”
当然，任何新的事物的引入，必然会引发对应的变革和利益调整；产品经理需要站在更高的角度，平衡各方利益，寻找最大公约数和共同利益；推进各个部门之间的配合，力求达到业务和产品之间的匹配；同时又要对诉求的轻重缓急有深刻的了解，产品经理需要搞清楚，在当前阶段，哪些功能可以带来更高的价值，从而引导资源倾向于最有价值的地方。
2C类型的互联网产品通常通过市场运作、运营活动等方式来让用户使用产品，实现推广；而2B类型的产品除了业务的自主使用外，产品经理也需要在各种场合宣讲和推动产品的使用，甚至担当拉拉队的角色来激发和赞扬对产品推广使用有益的事项；唯有产品被使用，真实的产品有效性才能被收集，分析和优化，才能达到给业务创造价值的目的。
在这个能力下所包含的各项软的技能，需要产品经理在日常工作中去分析提炼，通过实践去打磨和优化。
五、总结
产品经理的工作具有很强的实践属性，虽然产品经理总是以创造价值为宗旨，但是所处的环境和产出物的目的是变化的；即——受当下社会市场环境影响，也受偏好、认知、制度、经济能力等约束的影响。
企业的决策本身就需要基于社会环境这个大背景，这也是为什么一些产品放在今时今日不一定可以取得现在这样的成功；因为各类影响因素的变换，复用性受情景约束等。
汇总之前所述的要点，可以用下图来展示B端产品经理的能力要求，以及其在各个产品生命周期中的参与度。
“学我者生，似我者死”，总结经验，提炼通用的规律和准则，作为参考和借鉴分析的材料，为打磨个人能力，提升自我做基础。
因此，虽然这里阐述了一套B端产品经理的方法论和能力架构，但是如何使用在实际操作中，真正的发挥效果，那就真的是“运用之妙，存乎一心”。
本文@流蛋原创发布于人人都是产品经理。未经许可，禁止转载。