tob产品设计的方法论「产品开发逻辑」

今天给大家普及一下tob产品设计的方法论「产品开发逻辑」相关知识，最近很多在问tob产品设计的方法论「产品开发逻辑」，希望能帮助到您。

产品经理是个非常玄学的岗位，没有具体的技术，或者是知识点等作为背景，但是要想做好一个产品经理确实非常不容易，它所包含的知识点是一般的书籍或者专业课所涉及不到的。因此经验和天分就变得非常重要。

作为一名多年的B端产品经理在中后台领域还是有一定的发言权，所以接下来我将把目前短暂几年的产品经验，尽量捞干货的总结总结。

PM被戏称说是最接近CEO的岗位，但大家却从来不提具体怎么成为CEO，CEO成功=方法论*（人 势）。可见对于大多数的PM和CEO的相似点也就只有方法论了。那么我们今天就以B端PM来说说PM与CEO的相似点——方法论。

作为B端PM平日里最常打交道的就是系统，流程，逻辑等等，但优质的PM还需要在整个产品周期中形成完整的方法体系。一个B端PM的完整工作流程一般包含场景调研，需求分析，系统功能实现，管理运营，以及进阶思考5个主要模块。

一、场景调研

场景是需求设计的前提，是需求使用的载体。没有场景就没有需求，脱离了场景的需求即使做的再漂亮也是在做无用功。PM在进行需求阶段之前都会做详细的场景调研，证明需求的可用性。通常场景调研包含用户诉求，竟对情况，行业潜在背景几个方面。

1.1 用户诉求

对于B端产品经理所要面对的用户通常是本公司内部的同事，例如CRM系统的面向用户就是公司内的业务同事，做订单交易的PM经常要打交道的是公司内部的采购，交易员等等。

因此了解用户诉求首先要做的就是明确调研目标，知道本次需要了解的核心问题点是什么，带着问题点去调研思考有利于节省资源，直击问题，避免事倍功半；其次需要选择调研的对象，分清楚此次需求要面向哪些用户，进而对他们开展调研，只有这一部分直接使用者才最有发言权；在调研过程前要准备好要开展的方法，常用的几种调研方法有问卷法，调查法，访谈法，电话法等，不同的对象，不同的场景都需要使用不同的方法对待，这对一个PM的灵活应变能力是个不小的挑战；例如采访地位较高的用户时就不能简单地使用问卷法，应尽量用访谈的形式等；接下来就可以实施调研了，实施过程中需要PM灵活应变可能出现的各种情况，不论期间困难与否，一定要记着最初的行动目标，这或许可以在关键时刻对你有不小的帮助；最后一步是调研回来后输出调研报告，调研报告在此不赘述，本人做事比较随性，个人认为只要能有条理的说明白了，说全了就行，形式不限。1.2 竟对情况

不止是PM同学们，各行各业的从业人员只要是为了牟利而生，都无可避免地要做竟对分析，其实PM的竟对分析更多的还是与对手在功能或是一些细节上的PK，而商人们则是更全方面地，尤其是在收益角度地分析竟对。因此本节我就引用著名经济学家刘润的竟对分析理论，用商业的角度分析一下PM行业的竟对评估。

目标用户，做PM的核心点就是在各个行动阶段都要把握目标，分析竞对时也不例外。首先需要明确要跟竞对对比的产品的主要受众群体是哪些人，该批人群的特质是什么，最重要的是该批人有什么需要，毕竟你的需求做出来是要给用户使用的。那么竞对也一样，所以需要优先分析你和竞对的目标用户到底有什么异同，例如：携程旅行网的目标用户主要是针对高端商旅用户。因此推荐一些机票高星酒店的搭配组合就比较合适，但是途家民宿则更倾向于自由旅行者，所以旅游景区等元素就变得更重要。

产品定位，分析完有需求的用户后，还要对自家产品和竞对产品的定位有清晰的认识。通常来说一个产品的定位不会是满足所有场景或所有用户，往往采用优先解决某些痛点问题的方法，定位于具体的某块领域。之后在已有的业务定位上开始扩展或转型，例如keep，最初的定位就是针对健身的爱好者，提供切入市场的训练课程，在积累一定用户后开始转型于社交和电商，实现多方面盈利。

产品功能，产品功能是竞对分析中最大的一块内容，也是最耗时的，它需要沿着从外到里，从粗到细的体验竞对，严格按照树状结构一步一步操作竞对产品，对于每一步的背景，触发，结果都要尝试一遍并记录。从外到里指的是从首屏入口进入，沿着不同垂直线条走到操作终点，分析线条上的每一步情况；从粗到细指的是从整体功能触发，按层级顺序纵向操作，横向对比，把每一个功能都细化到具体场景，或许可以得到不同的分析结果。当然，功能是产品的核心，在使用中每个人都有自己的方法，无论怎么测用，能达到目的就好。

运营策略，产品服务于目标，一定不是上线功能就截止的，后续的运营策略必不可少，如果说产品是一个具象的产物，那运营策略就是基于这个产物的具体玩法以便于达到具体目的。很多产品的迭代改善就是通过运营过程中发现的问题而演变出来的，因此竞对的运营产品策略也是需要特殊分析对待的。

1.3 行业潜在背景

行业情况，一个高级的产品经理，分析竞对的时候除了基础的产品和用户分析外，往往还要更关注宏观上行业的潜在情况，无论公司大小，在资本市场中生存都如泛海行舟，再大的公司也无法改变随着行业忧戚与共的命运，行业兴则公司兴，行业衰则公司衰。

行业是社会演变的风向标，顺势而为才是公司生存之道，这样公司的产品也会有了明确的设计方向。近几年兴起的生鲜和配送就是社会演变的产物，在这个上升期的行业内也渐渐催生出像每日优鲜，美菜等优质公司。

公司定位，通常情况下，所选竞对公司应同属一个行业，在行业大环境明确的前提下，每家公司在行业内的定位也往往不一样，这很大程度上决定了公司内部产品规划的方向，所以一个团队的管理者需格外注意。

举个例子，马蜂窝在流量落地过程中开展酒店机票等业务，他们在OTA行业的定位就主要是重点发力于海外市场，因此他们的产品设计也会更海外化，他们的竞对目标主要并不是携程美团等，而是海外品牌Agoda，Booking等。

二、需求分析

在前期调研结束后，我们通常会收集到各式各样的信息，也会有各式各样的要求，但是一定要注意此时经常出现的“信息陷阱”。在海量数据下，看似有非常多的问题亟待解决，也有非常多的需求需要满足。但是在这种信息瀑布中我们更要谨慎对待，不是所有的信息都是有用的信息，不是所有的需求都是真正的需求，应避免落入陷阱中。因此我们就需要用一系列分析方法，仔细评估需求。

2.1 诊断需求

辨别需求的真伪，在拿到用户反馈的一些列需求中，我们首先要做的就是筛选出哪些是具体真正的需求，因为用户是直接使用者，提出的问题也是直观使用问题，往往不能通过表面问题揪住本质反馈，就会出现自己也不知道自己到底想要什么的情况，这时就需要产品经理的专业理性分析，从繁乱的需求点中找出真正的需求。

举个例子：在一则寓言故事中描述了一段对话

问：“你在做什么？”

答：“我在修篱笆”

问：“为什么修篱笆？”

答：“因为我要搞个花园”

问：“为什么要搞个花园呢？”

答：“我要自己种菜吃”

问：“为什么自己种菜吃呢？”

答：“因为我想省一部分生活花销”

你看看，如果有人给你说要修篱笆，那你是真的帮他把篱笆修的漂亮，还是想办法给你找到便宜又美味的蔬菜呢？

分析需求的背景，需求往往由所处的环境和所面对的问题所决定，在充分分析完问题后也要注意需求的背景，同样的需求放在不同的背景下，所产生的效应也是不一样的，不能一概而论。就像30年前的电影院诉求和今天影院诉求有着天壤之别。

2.2 行业现状

需求要适应行业

每一个特定的行业都有一套自己的玩法，需求在行业内也要符合行业的规则，逆着行业趋势很可能会浪费公司资源，严重的话还会为公司带来损失。例如生鲜行业的发力点在于库存，供给，物流等，那么偏偏注重会员体系的需求注定是失败的，倒也不是说不做，只是应该先紧着核心诉求点罢了。

行业主流方案

跟随行业主流并不是随大溜，人云亦云的表现，因为这样对于用户的学习成本最低，可以很快让用户接受，而且行业之所以如此存在一定有他的道理，行业现状也一定是在前人们无数次探索和教育用户之后形成的行业现象。翻开搜狗搜索，头条搜索，百度搜索的三家页面，你就会发现他们的设计几乎出自同一个模板，在满足核心功能满足用户的基础上再适当进行创新即可。

2.3 收益平衡

在分析需求时还有一个核心关键点就是要注重收益，这个收益包含纵向的成本收益关系，也包含横向的交叉业务成本，可以说收益对于需求是否要做起着决定性作用。

做需求的收益分析，首先从它的利弊影响入手，也就是说做这个需求会带来什么好处和什么坏处，如果有坏处，那么所带来的好处是否能够cover掉坏处。如果可以那么则需求可能成立，否则一定会被老板们拍回来，在之后的需求设计阶段还要注意将弊端最小化，尽可能的减少损失。

ROI回报，需求分析的核心因素就是要就算方案的投入产出比，老话说赔本的买满不能干，从企业角度说，做了就是为了要获得收益，需求分析应本着用最小的代价获得最大的收益为原则，尽量提升ROI。当然这里的收益也不全指金钱收益，可能也体现在用户收益，体验收益，流程收益等等，很多时候是无法量化的，这就非常需要产品经理的全面衡量。

说完需求纵向的自我分析，还有很重要的横向交叉业务分析，一个需求，尤其是对于B端需求来说，总会涉及到上下游不同系统之间的交互，因此对于其他团队的影响也是要考量在内的。

2.4 未来规划

这一点道理是众所周知的，方案需要有一个长久的规划，不能只看眼前，但是真正做到的人却很少。特别是在创业型公司，多数情况的方案都是应急方案，一个产品的生命周期甚至只有几周。其实这种现象也是可以理解的，毕竟创业期本身就是在多方向试探，精益求精的阶段，产品为业务发展也改变也很正常。

因此产品的未来规划可以从以下两个方面进行：

需求本身的可持续性，在调研完成后，产品经理应该对于整个行业和业务有个自己的判断，应具备主流方案的灵感，让需求方案本身就有一个较长的规划期，甚至项目初期就可以规划出至少3期迭代，保证核心功能可以不断完善，而不是只为了应急救火而打补丁。业务规划发展，对于业务型系统来说，业务主导需求的情况非常普遍，这是业务就是产品团队的用户方，产品经理应该熟练掌握业务节奏，在不偏离大方向的基础上完成眼前的需求，这样即使后边有变化也可以进行兼容，不至于推翻重做。

这里我另附一个最常见的需求分析公式——HMW——how might we…?（我们可以怎样…？）

在一个场景里，我们首先要明确用户和他们遇到的问题，例如：一对情侣去了公园却发现没有能坐下来的地方。

接下来加上拆解问题的不同方向：

正向：我们可以怎么解决情侣想坐下的问题？

逆向：我们可以怎么避免这对情侣坐下？

转移：我们可以怎样使这对情侣除了坐下外，去做点别的事情？

接下来在每一方向之后思考各需要几步解决，然后仔细评估每种方法的利弊，以最小的代价最好地解决问题永远是王道。

三、系统功能设计

具体功能设计永远都是大家乐此不疲地争论模块，一个产品经理总会为自己的系统方案付出全部生命力，业内有句话说，要像对待自己孩子一样对待自己的产品，哪个人不会善待自己的孩子呢？那么又有哪个产品经理会轻视自己的产品呢？

所以很多产品经理变成了“某怼怼”，誓死要为自己的“孩子”据理力争。

另外每个人有自己的设计经历和见解，具体系统功能也会依托具体的业务要求，因此在这里我不会就功能设计详细展开，只聊聊常用的B端产品的共用设计方法。

3.1 核心业务流程

核心功能是每一期产品的必要前提，特别是现在很多公司开始倡导敏捷开发，在有限时间和资源分布的情况下，必须要保证每一期的核心诉求完备，之后才能进行分期迭代。

把握好核心功能后，整个产品周期将会变得明确，即使出现分支问题，也能快速抓住核心提出解决方案。

3.2 模块化流程

模块化是B端产品一个很重要的思维模式，B端产品最常打交道的就是复杂系统，我经历过的最长的一个电商交易链条，涉及过10几个大系统，20几个细分小系统的开发，他们之间相互关联，交互耦合。每次遇到这类需求时都像解数学题一样，这边可以了，那边又出现问题。

如管理学中讲的阿米巴经营一样，系统功能上我更崇尚模块化，每个功能系统都是自己的最小单元，完善封装后只是负责向外提供标准接口，尽可能对复杂系统解耦。

另外基于模块化思维的一个具体实现方式就是配置化，在每个模块下抽象出共性因素，组成配置因子，根据业务不同，对不同的因子做排列组合搭配，实现不同的业务流程。在我进入第二家公司之后不久，就应用这种方法重构了原本非常复杂的供应链系统，使系统可以支持更复杂的业务场景，变得更灵活。

3.3 数据建模

俗话说：兵马未动，粮草先行。在功能系统设计之前，我们需要设计好相关的业务数据，业务数据就是系统的粮草，有了数据才会有信息流，有了信息流才可以在系统中流转起来，不然系统就是个空架子毫无用处。必要时可以请数据产品们协助，一起制定数据维度和指标。

基础数据完善的作用很关键的还有在于功能数据评估上，系统开发之前需要定好未来的数据分析维度指标，可以通过数据表现来分析系统问题，这样后面的产品迭代也可以有迹可循。

举个电商系统的例子：京东销售的某品牌背包，在外网看上去是一个背包，它背后其实是非常细化的数据颗粒的组合，包括产地，品牌，材料等基础信息，另外在整个交易流程中，每个步骤上还有埋点记录用户行为的业务数据。当产品经理拿到这些数据后会建立自己的指标体系，用来分析该产品的详情情况和数据情况，后续便于规划迭代方向。

这样蕴含在实物流下的一套信息流就建设完成，因此我们常说PM应该具备一个较强的数据能力。

3.4 流程创建

如上所述有了基础数据流，有了模块化的系统单元之后，就可以根据业务场景把每个系统单元串起来，构建完整流程。构建流程是B端产品的精髓地方，提前需要了解好历史逻辑和可能涉及到的坑点，方案本身一定要在纵向上考虑周全，覆盖掉方案可能引起的所有问题，横向上也要注意跟其他系统之间的交互，不要留坑。

3.5 界面交互

对于B端产品来说，流程功能是里子，而界面交互是面子，好的产品不仅要做好里子，更要做好面子，这样无论用户是谁都能有较好的使用体验。

B端产品和C端产品的界面交互上往往存在一些差异，C端界面更注重视觉，美感，会站在用户的心理角度衡量页面上的每一个交互跳转和文案图标；而B端产品则侧重界面对于功能的体现，然后才是交互的提示，美工。B端产品的界面设计往往偏工程化，从界面则可见产品的逻辑，不需花哨的装饰。

3.6 角色权限

最后一块功能设计，我们说说权限系统。权限系统是在业务功能全部实现的基础上进行的功能管理，完备的权限分配不仅可以充分管理系统分工，有时还能巧妙的解决流程问题。就像一把锁一样，把不匹配的流程跟用户隔离开。

角色权限系统一般设计时包含资源树管理，角色管理，权限配置几个部分。首先需要将所有系统模块资源化，每个功能都作为一个资源；其次按照组织架构或是功能架构，把用户分为不同维度的集合；最后通过权限分配，将模块化的功能制定给具体某一批用户角色。例如管理员有对薪资系统的编辑，修改和查看权限，而普通用户则只有查看权限。

四、运营管理

系统功能上线并不是重点，反而上线后的运营和迭代才是产品生命周期的重头戏。通常上线功能后需要保证培训宣贯给使用者，然后定期进行后评估，并实施策略调整等。

4.1 项目运营

培训宣贯，系统功能只是初步搭起了功能的舞台，“戏”具体要怎么唱，主要还是看后期的具体运营方法。但首先需要给一线的使用者做好充分的讲解培训，必要的话可以安排课后测试，择优上岗等方法。完备的公司体系通常还设有专门的培训部门，建立专人专项的培训制度。可以看出培训对于B端产品来说的重要程度。

日常运营，B端的系统最鲜明的特点就是面对的使用者是“自己人”，能及时的收到第一手反馈资料，并通过群体化运营直接和使用者沟通，高效提供解决方案，即使是做SAAS服务的平台，对于用户的反馈也是可控的。

4.2 策略调整

很多需求的优势和劣势往往在设计初期并不知道，只有经历了市场实战的洗礼才会被暴露出来。数据分析就像一台医疗仪器，可以把复杂系统中存在的问题客观显现出来，以便于制定后续产品规划方向。

对于非纯功能性系统，例如交易性平台，电商平台等在搭建完系统功能后还需要注重策略的分析，毕竟此时系统也背上了很多业务和收益指标。需要B端PM立足于产品功能，放眼于收益管理，发现问题，调整策略。

4.3 需求迭代

需求迭代分为主动和被动，理想状态下在系统设计之初就能对系统功能有长远的规划，并利用多期迭代实现最终目标；但现实中还经常存在被动的需求迭代，目的是为了补以前留下的坑点或者遗漏点。但无论哪种，都算是产品生命周期里重要的组成部分，仅靠PM很难在初期就排查出所有问题，只能说需尽力筹划，逻辑谨慎严密。

业内为了适应变化莫测的需求场景，开始逐渐倡导敏捷开发，以MVP最小版本快速满足每一期的核心需求，这样以最小单位快速迭代的方法不仅可以及时调整业务方向，也能快速对之前遗留坑点做到补救，是目前产品规划里较受欢迎的方式。

五、进阶思考

整体介绍完产品设计的基本方法论后，最后一个大模块简单阐述一下产品的进阶思考。每个人的经历和所处的行业背景不同，对于进阶的看法也会不一样，我把业务型B端产品的进阶思考主要分为业务趋势规划和系统功能拓展，其中企业级系统系统架构的发展值得单独拿出来讲述。

业务发展规划，无论面向什么用户的系统，最终都是需要交付使用的，从电商交易到企业内化使用者都为其规划了明确的发展方向，系统作为核心支持模块当然也不能脱离业务实际。

高阶的产品经理除了对于产品自身的打磨外，还需要具备参与业务的能力，要深入业务其中和一线的使用者，管理者共同规划业务发展，在合理业务前景的前提下设计系统方案，这样也会对于产品迭代节奏有整体把控。

系统功能规划，如上所述，系统在业务沿着线条的走向而规划肯定是铁律，每个产品经理都应明确自己负责系统所对应的业务场景，即使不能做决策，也要在设计方案中有体现。产品的迭代路线大体上就是业务发展的方向，在共同前行的路上不仅为业务提供功能支持，也要承担起实时校验业务走向的作用。

下面附上一张图，描述的就是迭代产品在业务规划中的体现，在确定要制作机动运输工具的业务指标下，每次的产品迭代都会辅助业务重新修订方向，最终达到完美解决方案。

企业级系统规划，最后我觉得有必要单独把企业系统发展拎出来说说清楚，其实作为B端产品经理的技能是可量化描述的，对于企业来说需要的系统总是逃不过基本的架构，如下图所示：

产品经理应该把这几块系统的设计流程作为基本功，打好基本功的前提下再去做上述的特点拓展，业务运营等工作，这样有助于产品经理形成系统的知识体系，做事情也能条理清晰，不至于手足无措。产品经理在企业级别的系统规划中还应该具备大局观，并不是每个业务系统都是一成不变的，在基础的架构上需要进行适当的增删改，才能满足各业务细节。

例如早期小型企业可能只有订单交易和首付款流程，一套简单的ERP就能满足所有业务场景，但随着发展壮大，需要对于客户做一些运营策略，或者需要对于公司内部人员做统一管理，这时就需要CRM系统和人力资源系统的加持。

总结一下

通篇文章介绍了侧重于B端产品的系统方法论，从场景调研，到需求分析，功能设计，到运营管理和进阶规划。

诚然，本文只是从整体框架角度介绍方法论的布局模块，其中具体每个模块都是值得编写一本书的，在这里篇幅有限，均不展开赘述，如有兴趣的朋友，欢迎私信留言交流~

本文由 @雪顶斜阳 原创发布于人人都是产品经理。未经许可，禁止转载

题图来自Unsplash，基于CC0协议