《决胜B端》读书笔记
2022-05-06 18:37:13 2 举报AI智能生成
《决胜B端：产品经理升级之路》提炼出互联网B端产品设计得通用思路以及方法，概括了互联网行业的模式以及发展趋势，比较推荐^-^
作者其他创作
大纲/内容
《决胜B端》
业务还未开展，只讨论了初步的可行性，需要设计最低成本的试错方案。【不需要设计完整的产品，只需要设计一个方案，让业务以最低成本做初步尝试，论证可行后再考虑产品化支持】
业务已经通过线下的初步验证，现在需要系统支持，实现线上化，全面推进业务。【需要做全面的产品化支持工作，我们要讲的就是这种情况下的总体建设流程】
业务情况
产品经理需要尽可能地用各种手段和工具收集业务关键信息，通过对业务负责人、一线业务人员等角色进行访谈，获取全面的信息；另外，可以邀请技术负责人一起参与业务调研，确保对业务的理解是一致的。
明确调研目标
对于B端业务调研，调研对象一般包括业务高管、业务经理、一线业务人员、合作伙伴高管、合作伙伴经理、合作伙伴一线人员等。针对高管，可以了解业务战略定位、战略目标等信息；针对经理或负责人，可以了解业务的管理思路、经营思路等信息；对于一线业务人员，可以获取作业过程、操作细节等信息。
选取调研对象
调研方法包括定性分析法和定量分析法，具体包括访谈、轮岗实习、问卷调研等方法。
确认调研方式
执行调研计划
调研结束后，要产出一份详细的调研报告，总结业务现状和问题，并确定各个问题的优先级，以便为后续的方案设计和实施路径提供决策支持。
总结归纳输出
核心流程
业务调研
业务问题诊断
● 核心业务流程：梳理整个业务主干流程，并确定其中哪些环节需要由该产品实现线上化。
● 产品定位：明确该产品有哪些子系统，分别支持哪些业务流程和业务版块。
● 应用架构：考虑该产品和公司现有系统的融合关系。
● 功能模块：基于对业务的理解，抽象出该产品的具体功能模块。
● 演进蓝图：根据业务优先级与发展策略，制订实现各功能模块的计划和节奏。
产品整体方案设计
业务数据建模也叫实体建模、领域建模，或业务对象建模，是指针对业务特点，归纳并设计对应的底层数据模型的过程。
业务数据建模的过程就是将业务对象及其之间的关系抽象出来的过程，ER图呈现了业务数据建模的结果。
数据建模
会涉及业务团队的组织架构和岗位编制，需要产品经理与业务负责人一起讨论决定。
遵循自顶向下的设计思路，首先设计主干流程，在这个过程中可以进一步明确系统角色及业务岗位的安排，然后基于主干流程图设计页面流转图，最终完成页面细节设计。
流程角色
是业务用户直接看到的部分，在设计时最好能提供可以体验的交互界面，让业务用户提前感受并反馈意见，减少不必要的返工。
系统应该在合理的时间、用正确的方式，向用户提示或反馈目前系统在做什么、发生了什么。
如果系统不能及时向用户反馈合适的信息，用户必然会感到失控和焦虑，不知道下一步要做什么。
反馈原则（Visibility of system status）
系统要采用用户熟悉的语句、短语、符号来表达意思。遵循真实世界的认知、习惯，让信息的呈现更加自然，易于辨识和接受。
隐喻原则（Match between system and the real world）
用户经常会不小心操作错误，需要有一个简单的功能，让程序迅速恢复到错误发生之前的状态。
回退原则（User control and freedom）
同样的情景、环境下，用户进行相同的操作，结果应该一致；系统或平台的风格、体验也应该保持一致。
一致原则（Consistency and standards）
系统要避免错误发生，这好过出错后再给提示。
防错原则（Error prevention）
让系统的相关信息在需要的时候显示出来，减轻用户的记忆负担。
记忆原则（Recognition rather than recall）
系统的用户中，中级用户往往最多，初级和高级用户相对较少。系统应为大多数人设计，同时兼顾少数人的需求，做到灵活易用。
灵活易用原则（Flexibility and efficiency of use）
对话中不应该包含无关的或没必要的信息；增加或强化一些信息就意味着弱化另一些信息。
简约设计原则（Aesthetic and minimalist design）
错误信息应该用通俗易懂的语言说明，而不是只向用户提示错误代码；提示错误信息时要给出解决建议。
对于一个设计良好的系统，用户往往不需要经过培训就能轻松上手使用，但是提供帮助文档依然是很有必要的。帮助信息应该易于检索，通过明确的步骤引导用户解决问题，并且不能太复杂。
帮助原则（Help and documentation）
交互设计-尼尔森十大可用性原则
界面设计
明确分析目的，即需要通过分析发现哪些方面的问题。
思考该采用什么方法来识别、诊断这些问题，其中可能的困难是什么。
构建分析体系
设计具备明确业务含义的指标来考量业务。
定义观察指标
管理人员需要的只是干净的界面和能够实时更新的准确数字，其他炫酷的交互效果并不需要。
设计呈现形式
能够快速地感知并解读数字背后的变化和问题，这是出色的管理人员必须具备的素质。
跟踪指标变化
最好每周分析上周数据走势、变化背后的原因，以便及时、准确地掌握业务变化情况及原因。
分析变动原因
分析出问题后，下一步是给相关部门或人员安排工作，解决问题。
跟进处理问题
报表设计
在网站中注入分析工具提供的代码片段，以便网站分析工具能够准确捕捉用户行为的工作，就叫数据埋点。
数据埋点的流程一般包括申请分析网站账号、获取埋点代码片段、将代码片段埋入网站或App、观察分析数据。
B端产品，尤其是业务系统，往往借助埋点观察并研究用户对各项产品功能的接受程度、使用情况，以及用户的操作习惯等，从而进一步评估功能设计是否合理，是否帮用户提高了效率等，为持续优化提供依据。
C端产品通过数据埋点来持续优化设计。C端产品对交互设计要求高，非常重视用户体验。因此C端产品经理和运营人员要想尽办法持续优化功能，而优化的前提是细致、全面的数据埋点和分析，这样优化方向才是明确的。
诉求不同
B端产品多为PC端Web站点，在Web埋点工作中，很多时候只需要分析页面级别的流量和行为就足够了，所以只需要部署一次公共Java Script代码片段就完成埋点工作了，然后就可以做基本的分析监控了。
C端产品多为移动端App版本，用户的操作都在屏幕的方寸之间完成，保证良好的用户体验非常重要，因此C端产品对各种点击、交互行为的监控非常严格，会对所有交互行为做细致的埋点，以便全面掌握用户的动作，并进行准确优化，工作量会大很多。
方案不同
B端产品与C端产品数据埋点的区别
数据埋点
● 功能权限，指各个角色可以操作的界面、按钮等，例如管理员可以进行新增、删除、修改等操作；运营人员在同样的页面上只能使用各种筛选条件查看数据，无法做更改。
● 方案一，通过组织机构树控制。该方案根据账号所在组织机构树中的节点位置，来判断能够查询的数据范围。这种方式最复杂，但最灵活，能够支持各种复杂的业务数据权限诉求
● 方案二，通过客户地区控制。该方案根据账号所在区域来判断允许查看的数据范围。这种方式简单、容易实现，但灵活性差，只能满足非常初级的数据权限管理诉求。
● 数据权限，指各个角色在各页面中能看到的数据范围，例如分公司管理员在订单查询页能看到分公司的所有订单，而区域主管在订单查询页只能看到所在区域的订单。
权限管理
前期可行性分析时
编写时间
老板、投资人
受众
论证商业模式可行性
编写目的
分析市场、产品定位、盈利模式
编写重点
BRD（Business Requirement Document，商业需求文档）
开发之前
研发人员
理解软件功能设计
功能描述、原型描述
PRD（Product Requirement Document，产品需求文档）
立项之前
市场、销售
说明产品要点
产品形态、大纲
MRD（MarketRequirement Document，市场需求文档）
在B端产品领域，BRD一般由需求方填写，用于提交需求；PRD由产品经理编写；MRD在B端产品中鲜有涉及。
文档撰写
产品细节方案设计
设计解决方案（包括整体方案和细节方案）
● 技术方案和产品方案相互影响：有些技术选型问题会直接影响产品方案设计，或者产品方案直接决定了技术方案，此时产品经理要和技术负责人讨论清楚。例如，如果要做App，那么究竟是针对i OS系统和Android系统各做一套原生的，还是对i OS和Android系统做一个壳子，里面用同一套H5版本？抑或是直接做H5站点？这些问题既是产品方案问题，也是技术方案问题。
● 技术方案可能导致项目风险。例如，有些工程师喜欢尝试新技术，选用一些非常小众或新颖的技术框架。遇到这种情况，产品经理一定要严肃地和工程师、领导进行沟通确认。B端产品要支持业务运转，追求稳定和可持续，对新技术的诉求不高。如果在项目中采用了非常小众的技术形态，有可能导致开发人员难以招聘，人员离职后无人能够接手项目。
外框
从专业分工的角度来讲，技术方案是工程师分内之事，产品经理没有必要干预。
但是在下面这两种情况下，产品经理必须关注并参与技术方案探讨。
理解一门编程语言
掌握并使用SQL
了解网络通信等计算机常识
具备基本的技术知识体系
MVC是Modeling、View、Controller的缩写，代表软件设计的分层理念。Modeling指数据模型，View指前端交互视图，Controller指业务逻辑
任何一套软件系统运作的本质都是相同的：用户在前端交互层操作后，系统通过业务逻辑层处理数据层的数据。
了解程序设计的MVC范式
接口的调用方会一直等待被调用方返回执行结果
同步调用模式
接口调用方给被调用方发出指令，但不会等待结果
异步调用模式
熟悉接口与调用模式
数据库表设计
SQL查询语句
掌握数据库与SQL
B端产品经理的技术知识要求
技术方案
设计并优化项目管理制度
负责大中型项目的立项实施
互联网项目管理的工作重点
● 容易发生跨端（跨系统）现象
● 项目周期长
B端项目管理面临的挑战
明确项目收益价值
（Key Person，关键人物）决策人员
找到KP并积极游说
能够记着事儿，不忘事儿，上着发条追进度，盯过程，要结果。
保持强的推动力与执行力
如何协调并推动跨端协作
细化工作，明确交付
通过机制把控进度
编写内容清晰的项目日报或周报
保持足够的责任心
如何把控项目进度
如何对B端产品做好项目管理与实施工作
项目管理与实施
● Saa S方向，该方向的运营岗位偏销售、BD职能，属于销售管理和客户开发的范畴
● 双边市场的供给端运营方向，例如商家运营、店铺运营，这种运营岗位的工作内容和C端运营相似
● 针对内部业务系统的产品运营方向
B端产品运营岗分类
产品功能推广培训
问题解答处理
需求采集过滤
项目效果分析
业务诊断分析
B端产品运营岗的工作内容
● 团队定位不同：对于业务模式较重的互联网公司，B端产品运营是配合业务部门达成业绩目标的支持团队，间接对业绩指标负责；对于以线上业务为主的互联网公司，C端产品运营是需要对业绩直接负责的业务团队。
● 工作目标不同：B端产品运营通过挖掘B端产品能力，帮助业务线提升管理效能、改善核心指标（不同业务线的考核指标不同，例如，销售线可能是销售额，采购线可能是采购成本，配送线可能是配送效率）；C端产品运营帮助C端产品提升核心指标，常常包括用户量、活跃度、转化率和收入等。
● 技能要求不同：B端产品运营人员要掌握相关业务领域的专业知识，例如供应链管理知识、仓储配送业务知识，以及数据分析、文案编写等辅助技能；C端产品运营人员要具备创造性思维，掌握热点时事和各种新媒体运作方式，具备数据分析、文案编写等多种综合技能。
● 职业方向不同：B端产品运营可以成长为某个细分领域的业务专家，例如CRM销售管理业务专家；C端产品运营可以成长为某个细分行业或产品方向（例如社交领域、电商领域）的运营专家。
B端产品运营与C端产品运营的区别
运营管理
包括一线用户、产品运营人员、业务运营人员、业务领导等的反馈
需求来源
包括交互体验优化、业务调整要求、业务管理要求等
需求内容
包括一对一面谈、问卷调研、轮岗实习等
采集手段
通过各种渠道全面、迅速地收集建议，而且，无论是否采纳，都要给出反馈，例如意见是否采纳、预期的解决时间等，这样才能形成持续的良性互动。
收集要点
● 这个需求背后的真正问题是什么？
● 这个问题是否有简单快速的解法？
● 这个问题的影响面有多大？如果只是个案，是否值得投入精力去研究解决？
● 如果是共性问题，优先级和紧急程度如何？
判断需求的价值
需求的收集
描述需求所在业务线（或对应的系统），例如CRM系统或客服系统等。
业务线
产品需求、产品需求（插入）、技术需求、技术需求（插入）、线上Bug
需求类型
需求的一句话概述。
主题
需求的具体描述。
内容
需求的提出者。
来源
收到需求的日期。
需求提出日期
重要紧急程度。
优先级
如果采用了敏捷开发模式，就需要标记需求排期开发时的迭代版本。
迭代版本
业务负责人
产品经理
研发负责人
测试负责人
待跟进、需求调研、PRD编写、待PRD评审、待技术评审、待排期、待开发、开发编码、待测试、测试验证、待验收、待上线、已上线、挂起、拒绝。
状态
计划上线日期
实际上线日期
后端开始日期/后端结束日期
前端开始日期/前端结束日期
测试开始日期/测试结束日期
发版计划
需求池管理的模板
需求池管理
B端产品的需求管理
研发人力资源安排图
迭代中的研发资源管理
迭代中的技术优化资源分配
1．挑选需求并编写PRD（W1D1～W2D4）
2．评审（W2D5）
3．技术方案设计（W2D5～W3D1）
4．开发实施与测试（W3D2～W4D4）
5．上线（W4D5）
即两周完成一个迭代周期
典型的双周迭代模式
无法保证最小功能集合可以在一个迭代周期内实现
跨端项目协同非常复杂，研发节奏互相依赖
很难准确预估工作量投入
双周迭代模式的局限性
B端产品的迭代管理
迭代优化
执行并优化解决方案（又分为设计技术方案、实施、迭代）
总体建设流程
B端产品的总体建设流程
明确主题
提出假设、验证假设
得出结论
数据分析的流程
● 统计学：掌握基本统计学常识，帮助自己判断、认识数据特点。例如，要理解方差、均值、中位数、众数等概念。
● Excel：Excel具备各种强大功能，足以作为初级、中级数据分析工作者的首选甚至唯一工具。
● SQL：掌握SQL可以快速提取原始数据，并完成数据预处理。
● 数据可视化：在工作实践中，多数情况下都是通过观察图表来发现、识别问题的，采用合适的图表形式，可以让分析更直观、高效，例如通过瀑布图、直方图、桑基图等观察数据特征和变化情况。
● 计算机数据基础：有的时候我们需要对原始数据进行一些编码处理，这就需要理解一些编码基础知识，例如什么是ASCII、UTF-8、UTF-16、Unicode，如何通过Ultra Edit等软件进行编码处理（例如，有时在Linux环境下运行SQL语句，导出的数据需要进行编码转换才能在Windows环境下使用，如果自己不会处理，就需要每次都求助于人）；此外还要了解计算机常见的数据存储格式，例如CSV、JSON、XML等。
● 正则表达式（Regular Expression）：正则表达式是一种非常巧妙的、用来处理文本的逻辑公式，在某些时刻，使用正则表达式可以解燃眉之急。
● 数据分析方法论：基于不同的分析诉求，有很多成熟且经典的数据分析方法论，例如分析C端产品的获客增长模型AARRR、分析客户消费行为特征的RFM模型、分析留存率的COHORT模型，这些方法论中蕴含了成熟的分析思路和手段，是针对各种确定的分析场景的最佳实践。
方法工具
业务知识既包括行业知识、领域知识，也包括具体公司的商业模式、运营流程细节等。
业务知识
细心耐心
数据分析的要点
● 提出论点：报告的开篇要简明介绍背景，以及分析的结论，让人产生兴趣并继续关注下去。
● 进行论证：论证过程要有数据支撑，并且数据的呈现一定要专业又易读。人们都喜欢看简明易懂的数据图表，而不喜欢读复杂的数学推演。因此，配有丰富、清晰图表的报告读起来会给人生动有趣感，讲解起来也容易吸引人的注意。
● 陈述总结：再次阐述并强调结论，加深阅读者或听众的印象。
报告的编写思路
一般按照“总分总”的形式编写，包括提出论点、进行论证、陈述总结三部分。
● 没有数据来源：这就像食品包装上没有产地和成分，会导致阅读者无法判断结论的可信性。标明数据来源可以体现数据的合理性、合规性、合法性。
● 没有标记坐标轴含义：图中没有标记坐标轴含义，阅读者需要猜测横纵轴数据的含义。
● 没有标记单位：两张图表的纵坐标呈现的是收入，但是却没有标明单位（如“元”或“万元”等），阅读者难以理解收入到底是多少。
● 数字格式不规范：对于纵坐标的收入数据，两幅图都没有采用千分符；小数部分的格式也不规范，左图不含小数位，右图却包含2位小数，但都是0，没有意义。
● 标题不清晰：报告的每一页都要有明确的主题。
● 没有陈述总结：每一页报告都应该有一句总结性陈述，让读者清晰地知道这一页想表达的观点究竟是什么。
报告的排版美化
在实际编写报告时，无论是用PPT还是用Word，都需要十分注意这些问题。
数据分析报告
B端的数据分析
MRD：市场需求⽂档，常⻅的为竞品分析，⼀般⽤于⽴项，基于⽬前市场数据及竞品等进⾏项⽬提出，⼀般⽤于提案。
PRD：产品需求⽂档，⼀般是说明实现的过程，较为详细。有些公司为了敏捷开发需要很多时候会直接在原型图上⾯通过注释⽅式进⾏更直观的展示。
PMD：项⽬管理⽂档，⼀般包括项⽬进度、项⽬资源、责任⼈和项⽬输出物，常规通过visio进⾏⽢特图绘制管理。该⽂档⼀般贯穿整个项⽬全程，衡量项⽬进度。
BRD：商业需求⽂档，是基于商业⽬标或价值所描述的产品需求内容⽂档（报告）。其核⼼的⽤途就是⽤于产品在投⼊研发之前，由企业⾼层作为决策评估的重要依据。其内容涉及市场分析，销售策略，盈利预测等
DRD：交互设计⽂档，⼀般⽤来承载交互说明，并交付给前端、测试以及开发⼯程师参考的⽂档。
FSD：功能详细说明，定义产品功能需求的全部细节。FSD⼀般通过⼀张张的截屏和⼀条条功能点来定义产品规格
PSD： 产品规格⽂档
UI：⽤户界⾯，泛指⽤户的操作界⾯，UI设计主要指界⾯的样式，美观程度
UE or UX：指以⽤户体验为中⼼的设计
HTML：超⽂本标记语⾔，⽹⻚的本质就是超级⽂本标记语⾔，通过结合使⽤其他的Web技术可以创造出功能强⼤的⽹⻚
IP：⽹络之间互连的协议，它是能使连接到⽹上的所有计算机⽹络实现相互通信的⼀套规则，规定了计算机在因特⽹上进⾏通信时应当遵守的规则
API：程序编程接⼝，是⼀些预先定义的函数，⽬的是提供应⽤程序与开发⼈员基于某软件或硬件得以访问⼀组例程的能⼒，⽽⼜⽆需访问源码，或理解内部⼯作机制的细节
UML：统⼀建模语⾔/标准建模语⾔，它是⼀个⽀持模型化和软件系统开发的图形化语⾔，为软件开发的所有阶段提供模型化和可视化⽀持，包括由需求分析到规格，到构造和配置
UV：唯⼀访问量，可以理解为⻚⾯被多少⼈看过
PV：⻚⾯浏览量，可以理解为⻚⾯被⼈看过的总次数。⽤户每1次对⽹站中的每个⽹⻚访问均被记录1次。⽤户对同⼀⻚⾯的多次访问，访问量累计
术语解释
C端产品也叫2C产品，是面向终端用户或者消费者的产品，往往承担流量获取和转化的重任。
用户基本是个体：使用C端产品的是独立的个人，而不是一个企业或机构。
强调交互体验：C端用户要求低的使用成本和学习成本，他们可能会因为体验上的一点不满意而轻易离开App。因而，C端产品非常重视交互设计，对每一个按钮的位置、大小，每一张图片的设计、配色，每一句话或短语的字数、用语，都要做到充分思考、论证、测试，以提供极致的交互体验。
数据驱动设计：C端产品对每一个按钮、组件、页面都要进行全面、精确的数据监控，通过数据分析来调整方案并持续优化，最终达成目标。
收益容易量化：C端产品关注的核心指标主要包括日活、UV、PV、转化率等，任何功能的设计都可以确定明确的考核指标，项目收益容易量化和评判。
运营决定存亡：对于C端产品来说，产品运营和产品设计同样重要，共同决定了产品的成败。设计一般的产品加卓越的运营，很可能取得成功；设计优秀的产品加糟糕的运营，很可能走向失败。
特点
● PC端产品：包括Web版的官网、主站，以及运行在PC上的安装软件包，例如迅雷、360助手。
● 移动端产品：包括运行在所有手机、移动设备上的原生App或H5应用。
● 其他设备端产品：包括智能硬件、车载环境下运行的软件。
按照运行的设备可分为
● 工具类产品：提供独立功能解决某一类具体需求，例如墨迹天气、随手记、美图秀秀等。
● 内容类产品：为原创或聚合内容提供分享平台，内容产生形式包括OGC（Occupationally Generated Content，职业生产内容）、PGC（ProfessionalGenerated Content，专业生产内容）和UGC（User Generated Content，用户生产内容），例如今日头条、喜马拉雅FM等。
● 社交类产品：实现陌生人、熟人之间的沟通交流，例如微信、陌陌、脉脉等。
● 平台类产品：作为双边市场平台服务方，帮助买卖双方实现交易撮合，例如淘宝、滴滴、Airbnb等。
按照实现的功能可分为
分类
C端产品
B端产品也叫2B（to Business）产品，使用对象是企业或组织。B端产品帮助企业或组织通过协同办公，解决某类经营管理问题，承担着为企业或组织提高收入、提升效率、降低成本、控制风险的重任。
● 目标用户是一个群体：B端产品用户群体是某个业务团队或组织，这一组人需要共同协作来完成工作，所以需要B端产品来帮助他们实现分工协作。
● 效能第一体验第二：B端产品的目标是解决组织的某类业务问题，因此聚焦于流程，提升业务效能是最重要的，打磨交互体验则处于次要地位。例如，产品设计时并不会过多地考虑UI设计，也不会为了几个按钮的摆放位置花费太多时间，即便某个功能的交互设计不太符合常理，业务人员为了完成工作也还是会使用软件（但这并不意味着B端产品经理可以无视交互体验）。
● 强调抽象和逻辑：B端产品背后的业务复杂度高，人员、分工、协作、流程、规则随时可能调整，这就需要产品经理有非常强的抽象能力和逻辑思维，将看似散乱无章的业务抽象出共性，进行合理建模和设计。
● 收益难以量化：B端产品要支持、解决业务问题，但业务成效的影响因素非常多，很多时候并非取决于B端产品设计的好坏。
● 私有化部署：将软件部署在公司自己的IDC以及专门配置的主机与存储设备中，与外部网络隔离，安全性强，网络稳定。
● 云部署：将软件部署在第三方云服务商（或企业自建IDC实现云管理），在保证安全性的前提下节省数据中心成本。业务系统一般采用私有云部署，安全性相对较高。
部署方式可分为
● B/S（Browser/Server）架构，即浏览器/服务器模式，用户通过浏览器访问系统。目前市面上的B端产品基本都采用B/S架构实现产品设计。
● C/S（Client/Server）架构，即客户端/服务器模式，这是早期的PC软件普遍采用的架构模式，用户需要安装客户端来使用软件，每次软件升级都需要进行客户端更新，非常烦琐。现在这种模式已经很少使用。需要注意的是，通过原生代码编写的移动端App，也属于C/S架构。
技术架构可分为
业务支撑类产品：支持企业经营管理或核心业务的开展，例如仓配系统、CRM系统。
办公协同类产品：支持企业内部办公协同，例如OA系统、HRM系统。
对企业内部的B端产品，又可以分为两类
对企业外部的B端产品，主要是指商家端的产品，即平台型企业给卖家提供运营管理支持的系统，例如淘宝的卖家管理系统、美团的商家管理后台。
业务方向可分为
B端产品
数据类产品是对企业内外部所有数据进行挖掘并利用的产品，通过数据反映出来的深层次信息来有效提升对应业务的绩效。
● 数据仓库建设：设计公司底层数据仓库，包括业务数据模型、指标体系等。通过对业务的理解，设计一套合理的指标体系，识别业务的过去和现状、趋势和变化，协助诊断业务。
● 报表设计：将成熟的数据分析体系和思路，通过操作简便、易于理解的可视化工具呈现出来，让阅读者能够轻松、快速地通过图表解读数据。
● 算法策略输出：结合业务诉求，对数据进行探查与挖掘，设计出各种策略算法（包括画像标签的建设），并应用在不同产品方向。例如，基于价格敏感度分析的优惠券投放策略、外卖系统的派单与路径规划策略、电商首页的千人千面以及商品推荐策略。
● 数据监控：设计并持续优化监控工具，向客户售卖监控工具并提供相关服务。埋点产品（例如神策、Growing IO），以及网站统计分析产品（例如Google Analytics，百度统计），往往也属于数据产品的范畴。
产品经理以下工作方向
● 对内产品：可视化报表或策略算法输出都是供企业内部使用的，给企业赋能。
● 对外产品：将企业的数据或算法或报表工具提供给外部客户使用，可以是免费的（例如百度指数、阿里指数），也可以是收费的（例如阿里云Quick BI等）。
基于使用对象，还可以将数据与策略产品分为
数据与策划产品
商业变现类产品，顾名思义，就是帮助互联网企业将流量转化为收入的产品。
● 搜索引擎营销（Search Engine Marketing，SEM）：最古老、最有效的互联网商业变现手段，对于百度、谷歌来说，SEM是其核心主营业务收入；很多其他互联网平台也开通了这项业务，例如淘宝、京东、58同城，都会售卖搜索关键词，实现按点击付费（CPC，Costper Click）的广告投放，也就是常说的竞价排名。
● 广告投放平台：拥有研发实力的流量型互联网公司，往往会设计适合自己平台的创意广告形式，以及投放管理后台，从而方便广告主管理广告投放。例如，抖音会设计符合自己App风格的广告素材与投放管理后台。
● 在线广告联盟（Ad Network）：拥有流量的中小网站和App可以通过Ad Network实现广告变现。Ad Network是一套完整的广告交易平台，在Ad Network中，广告主发布广告内容，中小网站和App承接广告，将自身的流量变现。Ad Network是一个概念，更是一个生态和产业。有很多互联网巨头实现了自己的Ad Network产品生态，例如谷歌AdSense、百度网盟、阿里妈妈等。
● 增值服务：给消费者提供的比基础服务更高层次的服务，一般都是收费的。例如，QQ虚拟道具的设计和售卖、会员权益售卖等。
产品形态
商业变现产品
凡是利用人工智能技术的产品，都属于AI产品。AI产品体系包罗万象，包括操作系统、图像识别、语音交互、无人驾驶等。AI产品的核心是数据、算法和应用场景的结合。
AI产品的功能模块包括数据的收集处理、算法的优化、应用场景的设计和策略的落地。
AI产品
互联网行业的产品方向
业务模式轻
变现快
业务特点
流量丰富的C端产品
产品投放平台
支持销售人员转化服务客户的B端产品（例如“CRM\"）
产品诉求
百度、今日头条
代表企业
广告变现
黏性很强的C端产品
腾讯、优酷
增值服务
利润率低
流量稳定的C端产品
强大的商家管理后台
强大的运营管理后台
各类支撑业务运转的B端产品
广告变现产品
经营分析报表平台
淘宝、滴滴、美团
佣金提成
利润率高
京东
买卖差价
互联网公司的盈利模式
供业务部门使用的产品，以及对这些产品提供基础服务支持的产品，可以统称为业务产品，属于业务平台方向。业务产品可以进一步细分出多条产品线，包括垂直业务线、基础服务产品线、交易平台产品线。
该方向产品线为每一个具体的垂直业务单元提供支持，例如给销售团队使用的CRM系统、给仓储团队使用的WMS等
● CRM：Customer Relationship Management，客户关系管理。广义上的CRM包括从客户开发、管理、营销、服务的客户全生命周期管理；狭义的CRM是指给销售人员使用的销售过程管理软件。
● SCM：Supply Chain Management，供应链管理。广义的SCM包括完整的供应商管理、采购管理、仓储和配送管理；狭义的SCM指供应商管理。
● WMS：Warehouse Management System，仓储管理系统，用来支持仓库管理业务。
● TMS：Transportation Management System，运输管理系统，用来支持配送管理业务。
● ERP：Enterprise Resource Planning，企业资源计划管理。广义的ERP是一套庞大复杂的体系，涵盖原材料采购、生产制造、仓储配送管理、财务管理，甚至还包括客户管理、销售管理等；狭义的ERP常常被理解成财务系统，或轻量级的进销存系统。
● Call Center：呼叫中心。广义的呼叫中心包括客服平台与话务平台，涉及软件、硬件、通信这一套完整体系；狭义的呼叫中心是指支持客服进行呼入呼出业务的软件系统，包括客服系统、质检系统、知识库系统等。
垂直业务线
在软件体系搭建过程中，有必要将各个系统都需要的、功能重复的软件模块抽象出来，统一建设维护，所提供的服务叫作基础服务。
● Passport：企业客户账号管理体系。对于开展了多个业务的企业，建设一套统一的客户账号管理平台，可以让客户更加顺畅、便捷地体验企业的所有产品和服务。
● MDM：Master Data Management，主数据管理。主数据管理是企业架构设计中非常重要的概念，简单来讲，一家企业应该有且只有一套客户资料存储系统和一套商品信息存储系统，以保证数据管理的一致性。
● Auth：Authorization Management，权限管理平台。公司的业务人员经常要访问不同的内部业务系统，如果针对每个业务角色在各个业务系统分别设置管理权限，那么管理成本将很高，并且浪费研发资源。常见的做法是通过集中的权限管理平台，把全公司业务系统统管起来。
● Org：Organization Management，组织架构管理平台。公司不同的业务团队有各自的管理层级，需要一套系统来统一管理业务团队的组织架构，并且允许其他业务系统获取组织架构数据。
● Msg：Message Service，消息服务。对于短信、通知、公告等各个业务系统常见的通用功能模块，条件具备时可以统一建设，避免重复开发。
● SSO：Single Sign On，单点登录服务。单点登录服务可以让用户只登录一次系统，就能访问所有接入单点登录服务的其他业务系统。单点登录服务是非常重要的业务系统基础服务，可以给用户带来极大的方便。
基础服务产品线
我们常把电商的后台产品称为交易平台。
交易平台的概念比较宽泛，大体上包括支付模块、商品管理模块、营销管理模块、订单管理模块等，有的公司将C端的收银台和支付页也纳入交易平台的范畴。
交易平台产品线
产品线
业务平台方向
支持企业内部办公管理高效运转的业务系统，属于办公协同产品。
● OA：Office Automation，办公自动化。主要提供资料查询、单据审批等功能，是最基本、最常用的办公软件。
● 内部IM：内部沟通工具，有条件的公司会选择自研，多数公司会选择钉钉、企业微信、Lync（外企常用）等。如果不用内部IM会怎样？假设你的公司用微信沟通，工作中建立了多个群组，每当有员工离职时，及时找到他所在的群并在每个群里删掉该员工，就是一件让人崩溃的事情。
● HRM：Human Resource Management，人力资源管理软件，包括招聘、简历管理、入职管理、薪酬管理等功能。
● 财务管理系统：这是专业性最强的业务系统，公司一般会采购成熟的财务软件。
办公协同方向
平台型互联网公司为商家提供了交易的平台。为了保证平台的持续、良性运转，公司需要对入驻的商家进行资质审核和服务管理，这就需要设计并开发企业内部使用的商户管理系统；同时公司需要给商家提供一套强大的经营管理后台，方便商家进行自主管理。
对于入驻企业平台的商家，企业需要利用强大的后台系统来进行全面管理和控制，这就是商户管理系统，主要实现处理商家账号、管理商家订单、进行风险评估、资质审查等功能。
商户管理系统
商家成功入驻平台后，需要在平台上实现经营管理，因此企业还需要为商家提供自主管理平台，实现商品管理、订单管理、营销管理、售后管理等功能，有条件的平台还会实现广告投放管理功能。除此以外，还涉及财务管理、报表管理等功能。
商家自主管理系统
商家管理方向
B端产品有哪些方向
收藏
0 条评论
回复 删除
下一页
