

首页  思维导图  详情



决胜B端--产品经理升级之路 . (1)

2023-03-17 11:10:15   1  举报





AI智能生成

读书笔记

读书笔记思维导图

模版推荐

作者其他创作

大纲/内容

概述篇走近互联网B端

第 1 章互联网产品领域探秘

1.1 产品经理岗位的发展历程

1.1.1 产品经理的起源

1.1.2 传统IT信息化时代的产品经理

1.1.3 流量为王时代的产品经理

1.1.4 移动互联网时代的产品经理

1.1.5 互联网产品经理的本质

1.2 互联网行业的产品方向

1.2.1 什么是C端产品

1.2.2 什么是B端产品

1.2.3 什么是数据于策略产品

1.2.4 商业变现产品

1.2.5 什么是AI产品

1.3 互联网公司的盈利模式

1.3.1 广告变现

1.3.2 增值服务

1.3.3 佣金提成

1.3.4 买卖差价

1.3.5 不同盈利模式的产品诉求

第 2 章 B端产品概述

互联网行业的发展趋势

从事B端产品方向的优势

B端产品有哪些方向

如何转型B端产品方向

其他方向的产品经理

技术人员

传统IT人

设计篇从业务诊断到形成方案

第 3 章 B端产品建设概述

B端产品的总体建设流程

B端产品与C端产品建设流程的区别

第 4 章 B端产品的业务调研

B端业务调研的流程

B端业务调研的目的和分析框架

B端业务调研的方法

B端与C端产品业务调研的区别

第 5 章 B端产品的整体方案设计

核心业务流程

产品定位

应用架构设计

功能模块设计

演进蓝图设计（roadmap）

第 6 章 B端产品的细节方案设计

业务数据建模（实体建模、领域建模、业务对象建模）

设计理想版的业务客户模型

设计简化版的业务客户模型

业务数据建模错误会导致灾难

流程和角色（页面流转设计）

绘制业务流程图和角色

绘制业务的页面流转图

界面设计

界面设计的流程

线框图的绘制

尼尔森十大可用性原则

反馈原则

隐喻原则

回退原则

一致原则

防错原则

记忆原则

灵活易用原则

简约设计原则

容错原则

帮助原则

列表页经典设计方案

列表页设计Bug“找茬儿”

界面设计的建议

报表设计

报表设计与应用流程

报表引擎

二维表格设计Bug“找茬儿”

报表设计的建议

数据埋点

什么是数据埋点

常见的B端埋点工具

埋点工具的数据分析

B端产品与C端产品数据埋点的区别

权限设计

功能权限

数据权限

文档编写与管理

商用需求文档的管理

产品需求文档的管理

文档管理要点

文档命名要遵循一致的规范

对文档进行版本管理

将文档存档管理

UML和常用图表

ER图

跨部门流程图

状态机图

活动图

用例图

第 7 章 B端产品经理与技术方案

产品经理是否要懂技术

避免产品过度设计

避免技术过度设计

与技术人员沟通顺畅

预判需求的可行性

评估工时合理性

产品经理不需要关注技术方案

B 端产品经理的技术知识要求

具备基本的技术知识体系

理解一门编程语言

掌握并使用SQL

了解网络通信等计算机常识

了解程序设计的MVC范式

前端交互层

业务逻辑层

数据层

熟悉接口与调试模式

同步调用模式

异步调用模式

理解软件工程的“搭积木”设计

掌握数据库与SQL

第 8 章 B端产品的项目管理与实施工作

为什么需要项目管理

互联网项目管理的工作重点

设计并优化项目管理制度

负责大中型项目的立项实施

如何对B端产品做好项目管理与实施工作

B端项目管理面临挑战

容易发生跨端（跨系统）现象

项目周期长

如何协调并推动跨端协作

明确项目收益价值

找到KP并积极游说

保持强的推动力与执行力

如何把控项目进度

细化工作，明确交付

通过机制把控进度

编写内容清晰的项目日报或周报

保持足够的责任心

第 9 章 B端产品的运营管理

B端的产品运营岗

三个方向

SaaS方向

双边市场的供给端运营

针对内部业务系统的产品运营方向

B端产品运营岗的工作内容

产品功能推广培训

问题解答处理

需求采集过滤

项目效果分析

业务诊断分析

B端产品运营与C端产品运营的区别

团队定位不同

工作目标不同

技能要求不同

职业方向不同

B端的业务运营岗

B端业务运营岗的管理模式

业务部门划分

执行具体工作的一级业务单元（按地域划分）

支撑一线单元运作的业务运营部（管理中枢/支持中心）

B端业务运营岗的工作内容

业务支持

流程管理

策略制订

绩效考核制度制订

培训考核

系统运营

项目管理

合规质检

数据分析

产品经理、产品运营人员、业务运营人员如何高效协作：调整组织架构改善合作关系

方案一

优点

统一调度研发资源

有利于从企业利益出发考虑问题

产品经理和产品运营人员相互补位

缺点

距离业务有一定距离

容易与业务运营部下属的系统运营部产生冲突

缺少决策人

方案二

优点

控制人力成本

避免工作内容冲突

缺点

产品部的权利被弱化

方案三

优点

更加贴近业务

更容易推动方案落地

缺点

判断和决策带有倾向性

缺少全局观

不能最大限度地发挥产品经理的价值

部分产品人无法接受向业务部汇报工作这样的安排

方案四

优点

充分授权发挥产品经理的价值

缺点

业务运营人员缺少对产品经理牵制力

方案五

优点

企业架构设计得到一定保证，双线汇报促织产品经理必须关注全局

缺点

效率可能略有损失

第 10 章 B端产品的迭代优化

B端产品的需求管理

需求的收集

需求来源

一线用户

产品运营人员

业务运营人员

业务领导

需求内容

交互体验优化

业务调整要求

业务管理要求

采集手段

一对一面谈

问卷调查

轮岗实习

需求池管理

需求池管理模版

业务线

需求类型

主题

内容

来源

需求提出日期

优先级

迭代版本

业务负责人

产品经理

研发负责人

测试负责人

状态

计划上线日期

实际上线日期

前端开始日期/前端结束日期

前端研发工作量（人日）

发版计划

B端产品的迭代管理

迭代中的研发资源管理

迭代中的技术优化资源分配

初创阶段

瓶颈阶段

重构阶段

稳定阶段

典型的双周迭代模式（敏捷模式Scrum模式的变体）

挑选需求并编写PRD

评审

技术方案设计

开发实施与测试

上线

双周迭代模式的局限性

无法保证最小功能集合可以在一个迭代周期内实现

跨端项目协同非常复杂，研发节奏互相依赖

很难准确预估工作量投入

选择合适的迭代模式

瀑布模式

敏捷开发

第 11 章 B端产品的数据分析

数据分析的流程

明确主题（焦点）

提出假设

验证假设（最复杂，需反复进行）

得出结论

数据分析的要点（三个核心要素）

方法工具

统计学

Excel

SQL

数据可视化

计算机数据基础

正则表达式

数据分析方法论

业务知识（数据分析的灵魂）

细心耐心

数据分析报告

报告编写思路

提出论点

进行论证

陈述总结

报告的排版美化

格式问题

没有数据来源

没有标记坐标轴含义

没有标记单位

数字格式不规范

排版问题

标题不清晰

没有陈述总结

不同图表的分析被揉在一起

太多的居中对齐

进阶篇支撑企业运转的整套产品体系

第 12 章企业级应用架构概述

什么是企业级应用架构

定义

设计要点

如何进行企业级应用架构设计

借鉴常见的软件产品体系设计

软件之间如何协同、模块之间如何搭建，已形成成熟的方法论

使用应用架构图呈现整体结构特征、逻辑分层特征、功能模块的抽象性特征

学习企业级应用架构的益处

加深对业务和产品设计的理解

理解企业如何运作

理解支撑企业运作的成熟产品方案

理解多个产品如何协作

理解应用架构是随着业务发展而演变的

培养大局观

获得更好的职业发展机会

第 13 章传统企业的应用架构演变

小微型企业的应用架构

小门店的Excel管理之路

采购记录

商品信息

交易记录

小超市的ERP之路

商品

订单

库存

为中等规模的超市建立的CRM系统

中型企业的应用架构

中型连锁超市的组织架构

法务部、人事部、财务部

信息技术部

采购部、仓配部

零售业务部

建设DW和BI支付企业经营分析

建设数据仓库的原因

整合ERP系统和CRM系统的数据

让报表分析与多维数据探查更轻松，让业务分析更加高效。

助力统一管理汇总数据和指标计算

数据仓库和大数据的区别

理念

技术方案

应用领域

建设OCRM系统支持企业客户服务

方案一：采购一套独立成熟的OCRM系统

优点

缺点

方案二：在原有CRM系统的基础上自主开发OCRM模块

优点

缺点

拓展：CRM体系

帮助企业获取销售线索并转化为客户的销售管理

帮助企业对客户进行营销管理的CRM

帮助企业进行客户服务管理的CRM

第 14 章多元化业务带来的应用架构演变

集团企业的应用架构

在线商城业务带来了互联网化管理

建设电商部

招聘电商部门负责人，直接向CEO汇报

自主研发整套电商业务系统

优化客服部

组建电销中心，支持线上线下的售后诉求

搭建CallCenter系统协助开展业务，负责电话作业

信息孤岛与主数据管理

解决信息孤岛问题的思路

主数据管理是解决信息孤岛问题的经典方法

加强基础服务建设，为新业务赋能

将通用功能抽象成基础服务

将CRM、WMS等业务系统的消息模块功能合并，提供一致的消息服务。

构建统一鉴权管理系统Auth模块，将所有业务系统的权限管理、角色管理统一接入Auth模块。

将商城支付模块剥离，构建高度服务化的Pay模块，提供统一的支付清结算服务。

加强数据团队建设，设立数据挖掘与策略输出模块，丰富客户画像，加强经营分析能力，产生更多的数据策略输出。

强健的基础服务支持新业务快速搭建

结合业务的实际情况，从整体架构的角度来判断哪些系统需要重新开发，哪些可以复用现有系统。

Passport与客户资料管理

Passport是企业管理客户账号的系统，也是企业储存客户账号的数据中心。

Passport系统和客户数据库是两个完全不同的概念

在B端业务中，某B端客户在系统的客户数据库中只有唯一的客户ID（企业/集团），但是该客户可以有多个账号（不同角色的人使用）。

在C端业务中，某个用户可能注册了多个账号，如果没有做身份验证，企业便无法识别这些账号是属于哪一个客户的。

集团强化中台能力建设

业务部强化中台能力建设

提升管理效率

控制经营成本

提升业务部门的管理灵活性和战斗力

产研部门加强中台能力建设

设计思路：对通用的、重复的东西进行抽象、合并、下沉，对外统一提供支持和服务。

第 15 章通用的企业级应用架构设计

抽象出通用的企业级应用架构

第一层：对外系统（官网、公众号、C端系统、商家端系统）

第二层：C端系统对应的管理后套（订单、会员、售后、风控）

第三次：业务单元支持系统（电话销售、客服、地推、仓配）

第四层：职能单元支持系统（法务、财务、人力部门）

第五层：基础服务支持系统

第六层：数据底层和应用

不同发展阶段的互联网企业的应用架构畅想

初创企业的应用架构畅想

公司规模：初创团队，团队小，产品简单，如石墨文档

业务模式：工具类产品

应用架构：对外系统（官网、公众号、C端）、C端系统对应的管理后套（CMS、会员）、职能单元支持系统（账号管理）

成长型企业的应用架构畅想

公司规模：成长型企业，拥有自己的广告投放管理平台，如今日头条

业务模式：主要为C端客户提供信息流咨询服务，聚焦广告变现

应用架构：对外系统（官网、公众号、C端、广告投放B端）、C端系统对应的管理后套（CMS、风控、广告后台）、业务单元支持系统（OCRM）、职能单元支持系统（Finance、OA、HRM、Mail）、基础服务支持系统（Passport、Msg）、底层数据支撑（BI、DW）

成熟企业的应用架构畅想

公司规模：成熟的互联网公司，如美团

业务模式：为供需平台建设，帮助消费者和服务方撮合交易，并对交易的商品进行配送。

应用架构：对外系统（官网、公众号、团购C端、团购商家端、外卖C端、外卖商家端）、C端系统对应的管理后套（CMS、商品、营销、订单、售后、风控、会员）、业务单元支持系统（OCRM、CallCenter、TMS）、职能单元支持系统（Finance、OA、HRM、Mail）、基础服务支持系统（Passport、Auth、GIS、Msg、Pay）、底层数据支撑（BI、DW、MDM）

企业级应用架构设计的建设

业务定位和边界要清晰

系统要实现耦合、高内聚

不要让易变的新业务影响现有业务的稳定性

系统之间要实现数据的单向流转

综合考虑架构的合理性和业务发展的需要

深入思考新系统与旧系统的关系

浅谈企业架构-EA模型

业务架构：关注组织架构、领域模型、业务需求、业务规划、业务流程等要素。

数据架构：关注数据集成、主数据管理、元数据管理、数据治理、数据安全性等主题。

应用架构：软件系统的设计模式，或是软件系统在应用功能层面的逻辑关系和视图。

技术架构：关注服务器、网络、中间件、操作系统等偏技术层面的要求。