编辑导读：B端行业这两年的发展有目共睹，B端包含的产品琳琅满目，各有特点。如果对B端产品一视同仁的话，将必然遭致产品的的失败，进而逐步断送B端产品经理的职业生涯。那么，B端产品有哪些分类呢？本文作者对此进行了分析，与你分享。

我曾在一篇文章中探讨了B端产品的定义。

讨论B端产品的定义将B端产品与C端产品区隔开，而讨论B端产品的分类，目的是将不同特点、价值、商业机会的B端产品彼此区隔开。

虽然众多的产品都被划入B端产品，都属于我想要讨论的范畴，但是对B端产品一视同仁的话，将必然遭致产品的的失败，进而逐步断送B端产品经理的职业生涯。

我们在工作的时候，需要对自己所参与的产品有更清晰的认识，而在个人能力培养的过程中，也要围绕自己所负责的产品进行。而不同类型的B端产品之间的差异，除了影响我们能力积累的方向之外，也会将我们的职业前途带去不同的方向。

我期望从以下几个方面来探讨B端产品的分类：

1. 分类的维度
2. 不同维度下分类的方式
3. 重要的分类的产品，工作中需要注意什么

一、B端产品分类的维度

我们先来看一下分类的维度。

B端产品的分类有多个维度，同一款产品站在不同的角度看待，其会有不同的类别特点。

常用且比较重要的B端产品分类维度有：

1. 客户维度
2. 服务方式
3. 应用场景
4. 环境

二、客户维度

B端产品经理在工作的过程中要始终关注客户。

需要注重客户的原因很简单：

客户是B端产品的衣食父母。

B端产品成败的关键之一，以及B端业务公司能够生存下去的关键之一，就是该公司、该产品能够多大程度地切合客户的需要，提供客户价值。

从客户维度，我将B端产品分为两类：

• 内部产品
• 对外销售产品

内部产品分类顾名思义，客户是同公司或者同集团的同事或领导，公司或者集团组建一个产品研发团队，开发一款软件产品或者某个系统，提供给公司或集团内部的同事来使用，为的是解决公司或者集团内部的问题。

销售产品分类也很好理解，其客户主要是外部公司（自己公司有时也会使用），公司的主要收入来源是通过销售产品或者配套的服务，赚取利润。

设计产品给自己公司用与设计产品并销售出去，是完全不同的两种工作体验。导致区别的主要原因有以下几个：

1. 产品经理与用户之间的距离

对内部产品而言，用户往往是自己的同事，甚至自己也算是用户。与用户的近距离沟通会带来沟通上的便利，产品经理随时随地可以与最终用户沟通需求、确认方案，用户反馈与意见也能更加及时，即便产品研发和迭代的过程中遇到风险，也能及时调整。

对销售产品而言，产品经理与最终用户之间的距离就远得多，极端情况下，产品完成交付，连最终用户的面还没见到过。产品经理与最终用户之间隔着销售、售前、交付、客服，有时候还有客户侧的领导。距离用户过远，会导致需求获取相对复杂，不熟悉用户的应用场景，用户的意见与反馈也会不够及时。软件开发项目中常常遇到，千辛万苦设计了方案，最终被用户吐槽毫无价值，其中这种距离就是导致以上情况出现的主要原因之一。产品经理应该积极争取与客户交流的机会，不放弃任何观摩、体察用户的可能性，但是现实中这种机会往往非常难得。后文中我们会讨论如何应对这种风险，将影响降至最低。

2. 产品规划的出发点不同

对内部产品而言，公司决策建设或者采购或者集成一款产品，是站在自身经营的角度来考虑的。企业都需要提高效率、降低成本，还有各自的商业目标与规划。内部产品的规划要站在企业战略的出发点上，从企业运营的角度，以中、长期维度来思考问题，需要警惕产品规划过于超前或者当产品完成建设，已经“过时”了。而且要注意，必须跟随公司的信息化变化随时做出调整，有必要的话，及时跟相关部门与领导反复讨论并确认新的目标。

对于对外销售产品而言，不可能更不应该贴近一个公司来进行规划。对外销售产品解决的是领域问题、行业问题，不能局限于一家公司。客户购买产品的目的依然是为了提高效率、降低成本、或者规避风险，对于一家客户，其诉求与内部建设产品并无二致，其也希望该产品能够与其工作流程、环境甚至文化无限贴合。但是站在对外销售产品的角度，由于要面对很多的企业客户，其规划的首要目标是针对明确的领域找到通用的最佳解，向更多的客户销售经过抽象的精简方案，并允许二次开发或者定制，赚取销售产品之外的其他利润。

3. 产品生命周期不同

对内部产品而言，产品的生命周期往往是与集团信息化规划、建设协同发展的。抛开集团的发展目标与战略规划，探讨内部产品的生命周期毫无意义。因此在我们经常会遇到某个B端的产品经理，其离职求职的原因是其负责的产品没有什么事情做了。这种情况往往是因为集团信息化的建设方向已经被转移，之前重点建设的项目进入了稳定期，只需要维护或进行少量迭代即可。如何应对这种情况，我们会在后文中单独讨论。

影响外部销售产品生命周期的因素非常多，客户的规模、行业的发展、技术的演进、政策的影响等等。对外销售产品的生命周期基本符合雷蒙德·弗农提出的《产品生命周期理论》，也就是介绍（引入）期，成长期，成熟期，衰退期。

4. 需求开发

对内产品的需求完全来源于内部。虽然产品经理也会参考各种类似的产品，但是这种参考应该仅限于学习的目的。需求开发应该立足于企业内部遇到的问题，或是来自于本企业的战略规划。对内产品切记盲目借鉴同类产品。看上去类似的功能，在不同的解决方案中，可能完全不是一个“味”。各个企业用户的专业水平也不一致，他山之石不一定能攻玉。

对外销售产品的需求来源较多，一些来自客户、一些来组用户、一些来自竞品，甚至一些来自上下游不同的领域。

三、服务方式维度

第二个重要的分类维度是按照服务的方式。

高质量的服务，是B端产品的生命线。

Salesforce远非第一家SaaS公司，却是第一家大放异彩的SaaS公司。起初其口号是：“没有软件”，摆出了一副传统软件颠覆者的形象，但是其真正做的事情，是将复杂的软件通过服务化的方式进行简化，使得CRM更加易得、廉价。

SaaS的成功改变了软件的服务方式，改变的又不仅仅是服务方式，因此我将这个维度也作为B端产品分类的重要维度。这个维度的分类很简单：

• 非SaaS产品
• SaaS产品

服务方式不同这是概括的说法，其中包括很多方面。

1. 交付方式不同

非SaaS产品分为软件交付和硬件交付。

软件交付是向客户交付软件安装包，交付团队的同事在客户环境中完成软件的安装，进行软件系统配置，并完成与客户侧其他必要系统的对接，比如活动目录服务器等。最终使得软件在客户环境中可以正常使用。硬件交付是向客户交付软硬一体的设备，通常已经在硬件中安装好了软件，设备拉到客户现场，插电联网做好配置后就可以使用。

SaaS产品的交付就简单很多，只需运营人员在后台为客户配置好租户，并开通账号，即可登录使用。一些SaaS产品也提供私有化部署的方式，如果这种情况，与非SaaS产品类似。

非SaaS产品在设计的过程中需要充分考虑客户侧的交付条件，交付团队的水平，尤其是如果产品的部署非常复杂，也需要帮助交付的人员设计相应的简化交付过程或者避免交付过程出错的相关功能。

2. 销售方式不同

非SaaS产品的销售需要多方配合完成，销售搞定产品购买的关键决策人，售前保证交付的方案能够符合客户的预期，甚至还会帮助客户来出一些方案，项目经理往往分前场和后场，后场的项目经理与销售关系不大，但是前场项目经理往往需要沟通整理用户的场景和需求。签订合同，客户付款之后，需要为客户提供产品授权。后续还有催收尾款等工作。

SaaS产品也需要销售人员来促成订单，但是区别于非SaaS产品的行销，SaaS产品往往依靠口碑、品牌还有流量。是的，没有说错，就是流量。随着SaaS软件行业的竞争愈发激烈，除了不断打磨产品和服务，如何获客也成为服务提供商需要面临的一道挑战。现在互联网是客户信息的渠道，为了能在客户寻找问题的解决方案时，出现在客户的视野中，SaaS产品公司想尽一切办法，通过流量的方式进行获客，信息流、SEM/SEO、广告投放、新媒体都是SaaS产品公司的战场。一些SaaS产品公司会有自己专业的营销团队。

3. 定价方式不同

非SaaS产品的价格不怎么透明。产品会有一套定价体系。但是最终产品的销售价格则取决于多方因素，包括：客户的预算，关键决策人的心理预期，招标的情况，定制需求的情况，承诺的服务等等。

SaaS产品的定价相对固定，决定因素无外乎几种：

• 服务时长——理论上时间加长会有一定程度的优惠；
• 功能选购——并不是每个客户都会采购所有的功能；（这里跟SAP有点类似）
• 授权数量——一般会设定阶授权数量与价格的梯式；

还可能会有一些定制的功能，尤其是涉及到跟客户侧的其他系统进行对接。（一般SaaS产品都准备有对外的标准数据与指令接口）

4. 售后服务不同

无论是SaaS产品还是非SaaS产品，售后服务都会包括以下内容：

• 培训与辅导
• 驻场
• 技术支持
• 使用反馈
• 问题应对
• 等

其中的重点是：问题应对。

非SaaS产品的售后往往是专门的团队，一个成熟的B端产品公司，会组建一线现场人员、二线专家等多级的专业服务团队。为了保障服务的及时性和质量，研发团队也会组建相应的虚拟支撑组织，有时被称为“三线”。一线在现场第一时间接收问题，并尝试解决，受限于一线人员的能力、对产品熟悉程度等因素，一旦无法定位或解决问题，会将问题向二线专家传递。二线专家经常是通过远程的方式对问题尝试解决。如果还是无法搞定，就会将问题继续升级，传递给产品的研发团队。

为什么要重点讲一下这个过程呢，因为产品经理为了保证产品的可服务性，需要考虑这个服务过程中的场景，设计方便一线、二线、三线沟通、分析、定位问题的功能；而且还需要考虑到客户环境的限制。一些客户的环境是无法通过互联网传输信息的，更不能允许二线、三线人员远程接入解决问题，因此一些定位并导出日志的功能就非常必要。

SaaS产品的售后服务大多在线上完成，研发团队也能够比较简单地登录系统，实际排查问题。不过要注意的是一些客户的数据要做好隐私保护，不能让客户的经营数据直接暴露在研发人员面前。另外在SaaS产品公司，售后的团队可能不会有一线、二线的区分，遇到问题可以通过售后电话或者线上立刻进行投递与反馈，研发团队经常直接响应，在问题完全解决前，也会给出临时的应对方案。

四、价值维度

客户购买B端产品的目的是要解决问题。更准确的说法是：

购买B端产品的目的，是为了解决客户以为的问题。

这句话有几层意思：

• 客户购买产品是为了解决问题
• 客户只能看到他认知范围内的问题，至于这个问题是否是真正的关键所在，客户不一定真正把握
• 产品要能解决客户以为的问题，也要尽量触及真正的关键点

按照B端产品在客户企业中的使用价值，分为以下几个类型：

沟通协作：

1. 企业通讯
2. 工作协同

工具：

1. 运营工具
2. 生产工具
3. 管理工具

这样划分的几个类别是贯穿企业经营管理的。我们可以看一下这张图。

沟通协作对于一个企业的整体运营效率至关重要。又可以分为两个方向，一个是人与人之间的沟通，另外一个是基于事务的配合。前一个是企业通讯，后一个则是工作协同。

1. 企业通讯

进入移动互联网时代之后，人和人的沟通是随时随地的。在全民“内卷”的时代，不少人吐槽自己24小时都被工作环绕，关于夜里要不要接领导电话，回不回工作群里消息的讨论也不绝于耳。

当然，移动互联网时代的“work life balance”并不是我想要讨论的话题，讨论也不见得会有结果。

我想说的是在企业活动中，围绕工作的沟通跟2C场景下人和人，人和群的沟通有完全不同的痛点。

具体来讲，有以下几个方面：

1. 信息的时效性，2B场景的信息需要永久保存。永久保存这种特性导致了其他的应用场景，比如对信息的存储、检索等。
2. 信息的反馈，2B场景中非常强调信息的反馈，因此消息已读这样的设计在2C的应用中并非必须，但是2B的通讯软件中几乎是标配，一些软件还提供更强的提醒，比如钉钉的“叮”，甚至还有直接拨打AI电话的。
3. 人员和组织的管理，2C领域好友关系是双向的，两个人决定是否是好友，能否通信，是否共享朋友圈，但是2B领域中组织的管理尤为重要，而且这种管理往往是中心化的。
4. 企业通讯作为最贴近员工的产品，往往会被当成各种场景下触达用户的工具，这一点跟2C的社交软件有点类似，只不过区别2C产品对接媒体、电商等应用，企业通讯软件对接的是工作中的各种流程工具与系统。

2. 工作协同

亚当·斯密说：“分工是国民财富增进的源泉。”

分工与协作像是硬币的两面，它们共同构成了现代企业运作的基石。分工与协作在实际中是靠着一个又一个流程来联系在一起的。有些流程很成熟，比如各种工单的流转；有些流程很简单，比如人事、考勤的审批；有些流程很复杂和漫长，比如产品生命周期管理，光是产品退市就经常要跨越一两年的时间；还有些流程还没有稳定下来，比如需求管理或者需求变更。同样的流程，不同企业的方案、成熟度也差异巨大，就拿软件发布距离，一个版本发布，有些企业需要动员产品、研发、测试、运维等三到四个部门，有些企业则完全实现了自动化。

工作协同产品就是为了解决工作中的各种流程问题。

工作协同产品要充分考虑当前企业协作现状，在做规划和设计的的时候还需要考虑这些问题：

1. 这个流程产品是自研合适还是采购合适？
2. 流程参与者的能力和水平现状是什么样的？
3. 当前的流程哪些地方可以优化？并且优化不能脱离实际。
4. 流程的目的是什么？
5. 优化的方向是什么？
6. 如何能判断优化效果的好坏？
7. 公司领导层对优化的预期是什么？

在面试的时候经常遇到做企业信息化的同学，问起项目的成就，他们认为最主要的成就是将线下流程搬到了线上，然后罗列出运营多长时间，积累下来的数据。但是进一步问，衡量产品好坏的标准是什么？下一步应该朝什么方向前进？这些问题回答得往往不好。数字化只是信息化的第一步。

生产、运营、管理，是现代企业的生命线。

3. 生产工具

任何一家“正经”企业，都是要生产一些东西的。可以是实物产品，食品、衣服、日用化工，也可以是软件、新闻内容、视频、游戏、金融产品，甚至数据和服务。如果一家公司不生产任何东西，那这是非常值得“玩味”的。

科技进步已经充分渗透企业生产，实物生产企业已经从机械化、自动化、信息化迈向智能化。与之对应的，是各种生产中的生产工具。一些生产工具负责控制生产实物，另一些生产工具则直接生产出产品。

生产工具的产品经理，一定要是该领域的专家。很难想象，一个代码编译工具的产品经理不懂软件研发和代码，一个修图软件的产品经理不懂图像处理。但同时又不能只作为专家，还要站在普通用户的角度来设计更简单、跟便捷的功能。

4. 运营工具

运营是对企业经营过程中的计划、组织、实施与控制，是产品生产和服务创造相关的各项工作的总称。在更宽泛的定义中，企业的运营还包括了对产品或服务的推广、销售。

在企业的运营中，人们需要管理供应商、生产资料、库存、商机、客户、订单，等等；需要收集财务数据，制作月度、季度和年度的报表；需要对接市场的信息，包括竞争对手和市场的分析；需要采集用户的反馈，产品或服务的表现信息。这些都离不开运营工具的支持。

运营工具的目标是保证企业某个领域上运营活动的顺畅进行，并能够进行一定程度的优化。在处理运营工具的时候，要搞清几个问题：

1. 针对的是企业经营中的哪个领域？
2. 这个领域在企业经营中占据什么样的位置？
3. 这个领域的关键参与者是谁？在企业中扮演什么样的角色？
4. 重要的流程是什么？
5. 运营的效率如何评估？
6. 该领域的运营人员有什么样的特点？
7. 当前运营工作中的痛点是什么？

很多时候企业对于运营工具使用采购加自研结合的方式。如果能够参与到采购工具的决策中，那么对于以上的问题更需要了然于胸。

5. 管理工具

高效的生产与运营离不开管理，对生产过程的管理，对运营效果的管理，对团队人员的管理。作为企业的管理者，经常会遇到这样的问题：

• 我该把有限的资源投到哪些技术上？
• 我应该砍掉不盈利的产品线？还是加大投入？
• 是否需要招聘更多的销售？
• 研发团队的结构如何调整？
• 为什么我的项目总是超期，应该如何改进？

有专门的软件来解决这类的问题。我在这里称之为管理工具。

对管理工具的界定并不是企业运营过程中各个环节的管理系统，那些属于运营工具的范畴。也不是领导用于审批假期、报销、预算的系统，这些属于协作的范畴。这里的管理工具是指企业的真正决策者使用的工具或者系统，或者是提供决策者所需信息的系统。

管理工具的规划与设计要具备管理思维，也可以解释为企业经营思维。想要回答“老板”们关注的问题，就要站在老板们的角度思考。科学的经营决策需要数据的支撑，企业内的运营数据，企业外的市场数据，要以不同的角度来看待同一个问题。

五、客户端维度

这个维度的分类很好理解，讲的是我们的产品最终是在哪些终端上应用的。
这里主要包括：

1. 手机端
2. PC

除此之外还有一些特殊的设备，比如ATM机、智能电视、智能音箱等等。

这个维度的分类需要考虑的是各个终端的特性。终端的不同将导致：

1. 人机交互习惯不同
2. 信息可呈现的多少与方式不同
3. 用户使用场景不同

如果还要继续细分的话，手机端又可以分为：

1. 小程序
2. APP
3. WAP

PC端也可以分为：

1. 网页
2. 客户端
3. 插件

客户端还会分不同的操作系统。

六、技术应用

最后一个分类维度叫做技术应用。

严格意义上讲，技术应用作为分类的方式有些牵强。不过随着B端产品的复杂度不断提升，越来越依赖当前前沿的技术。大家都在谈论云、大数据、人工智能。甚至连招聘的岗位也在不断细化，从产品经理变成了“数据产品经理”、“云基础设施产品经理”、“开放平台产品经理”等等。

于是，产品经理难以避免地要熟悉这些技术，了解这些技术的价值、先进性、局限性、发展趋势。不少的产品经理的JD中，都会要求：

“熟悉前沿的技术，能够持续跟踪新技术的动态”。

我们经常运用到的技术包括有：

• 云
• 大数据
• AI
• 物联网
• 等

1. 云

这是一个万物上云的时代。有人甚至已经在探讨能否通过将人的意识上云来实现永生，幻想碳基生命向硅基生命的转化。

对于企业而言，“云”已经不是一道选择题。新兴的企业直接在云上构建服务，使用各种SaaS软件搭建办公体系；传统的企业在努力将应用和业务向云上迁移。
在《剑指云端：引领企业IT未来的最佳实践》中，作者作为亚马逊AWS全球企业战略团队总经理，向广大的企业高管、云计算技术人员、企业信息化从业者，以布道的方式讲述了，如何向云迁移，如何构建起有竞争力、有生命力的云服务，如何通过向云迁移的过程，持续优化团队的技术氛围，从而达到组建云团队、培养云专家的目的。

云平台技术分层模型：

1. IaaS（Infrastructure as a Service）：基础设施即服务，提供虚拟机或者其他资源作为服务，提供给平台的开发者。
2. PaaS（Platform as a Service）：平台即服务，将开发平台作为服务提供给用户，也即开发者
3. SaaS（Software as a Service）：上文已经提到了，软件即服务，将应用作为服务提供给最终用户

云平台服务模型：

SaaS：

• 随时随地访问
• 支持公开协议
• 多租户

PaaS：

• 提供友好的开发环境
• 提供丰富的开发服务
• 自动化资源调度
• 精细化的管理与监控

IaaS：

• 资源抽象
• 资源监控
• 数据管理
• 资源部署
• 安全管理

我们首先需要搞清楚，自己做的是云的基础架构，还是在云环境上搭建应用、提供服务。

如果做的是云的基础架构，产品经理除了需要熟悉以上内容之外，还要懂DevOPS和持续集成。

如果做的事云上的服务与应用，那么更多聚焦在SaaS层，同时需要考虑云基础设施对上层业务带来的性能、稳定性、可拓展性等的影响。

2. 大数据

大数据的应用已经润物细无声了。从新冠疫情中的流调分析、追踪病例，到电商和服务领域的大数据杀熟。这些都是大数据技术支撑的应用。

做数据相关的产品，要了解以下内容：

1. 数据采集与预处理：利用ETL工具将分布的、异构数据源中的数据，抽取到临时中间层后，进行清洗、转换、集成，最后加载到数据仓库或者数据集市中。
2. 数据存储与管理：利用分布式文件系统、数据仓库、关系数据库等，实现对结构化和非结构化海量数据的存储和管理。
3. 数据处理与分析：利用分布式并行编程模型和计算框架，结合机器学习、数据挖掘算法等技术，实现对海量数据的处理和分析。
4. 数据可视化呈现：采用可视化工具，对数据分析结果进行可视化呈现。

除此之外，还需要了解大数据主流平台框架。比如Hadoop、Spark、Storm等。以及各个平台框架的特点，比如：

1. 成本：对廉价计算设备的支持情况
2. 性能：内存占用情况，磁盘读写速度等
3. 可靠性：是否支持高可用等
4. 可扩展性：扩容的难易程度
5. 语言支持：是否支持多种开发语言
6. 云环境支持：是否支持多种云环境
7. 数据库支持：支持数据库的种类
8. 容错性：消息队列发生拥塞时候的处理能力
9. 易用性：API简便，且进一步开发简单
10. 等

大数据要想落地，产生实际价值，还需要与具体的业务领域深度结合。常用的数据模型，规则算法，都需要有一定的了解，如果能花上精力深入研究成为专家那就更好了。

3. AI

虽然不断有人在嘲弄，当前的人工智能更像是“人工智障”。但是依然有人工智能方面的项目成功让人瞠目结舌：自动驾驶在一天天逼近，各种大公司推出的智能助手愈发“乖巧伶俐”，人工智能写出的歌词、剧本以假乱真。

无可否认，人工智能是近年来发展最快的领域。这项技术也逐渐渗透到生活中的方方面面。

做AI产品需要了解前沿的AI技术，比如：

1. 深度学习
2. 强化学习
3. 对抗性神经网络
4. 等

产品经理虽然没有要求能够写算法，但是要理解这些技术的基本原理、技术优势、局限性。并且需要掌握自己负责的领域是如何使用这些技术的。

做AI的产品除了产品设计之外，还需要为人工智能建立学习的环境以及评估模型。比如做图像识别的人工智能，还需要为AI设计训练工具——人工标注，以及打分工具。

4. 物联网

如今“万物互联”已经不再仅仅是一个口号了。物联网产品包括以下特性：

• 网络连接：无论是公网还是内部网络，物联网产品必须加入通信网络。现在的产品倾向于通过无线的方式联入网络，一方面减少布线成本，另一方面也减少物理的接口。
• 数据采集：也许某个产品并无数据采集的能力，但是由多个物联网产品组成的整个物联网系统中通常会拥有一种或多种数据传感器。传感器负责采集环境或者产品的运行数据，作为给出指令的依据。
• 控制单元：物联网系统中会有一个或多个控制单元，通过控制单元，可以进行人为操控，也可以写入控制策略。

七、产品分类的应用

讲了这么久关于B端产品的分类，这些知识要如何应用呢？

探寻事物的分类是建立事物认知的过程。逻辑学中，分类是使用事物本身具备的属性来对事物进行区分。

因此B端产品经理在工作中需要首先了解自己负责的产品到底属于哪个分类。在确定了分类之后，我们可以快速代入该分类下产品的特征，包括且不限于：

• 用户特点
• 面对的困难
• 常见的问题
• 经常使用的策略
• 等

同时，竞品分析、市场研究也需要通过分类定位到同类或者相似的产品，只不过做竞品分析的时候，我们往往使用更加精细的产品分类方式，以及更具备市场前瞻性的视角。

代入产品分类相关的这些信息可以帮助我们更快地上手，也可以在工作中帮助我们检验自己的第一判断是否符合行业常识。

而且我们在上一份工作中积累下来的经验往往是与产品类别相关的。有些公司习惯招聘有同类产品经验的人，就是这个道理。

另外，在面试的过程中，如果能在面试之前了解，或者在面试过程中快速确定自己面试的岗位所负责产品的分类的话，代入上文提到的知识点以及注意事项，从恰当的角度来思考面试官的问题，会对面试非常有帮助。即便没能在面试过程中对答如流表现出色，到了反问面试官的环节（假设有这个环节的话），也能让面试官对你刮目相看。

当然，并不是说我们只需要考虑产品分类，就能帮助我们做出正确的产品决策，除了同类型产品的通用特点之外，脚踏实地地分析我们负责的B端产品，分析并解决工作中的个性问题，仍然是最重要的事情。

本文由 @产品糙叔 原创发布于人人都是产品经理，未经许可，禁止转载

题图来自 Unsplash，基于 CC0 协议