读书笔记-决胜B端：产品经理升级之路

市面上讲解B端产品经理的书籍实在是太少了，供给远远不足。因此本书一出版，便以极高口碑传播。收到多个安利，且豆瓣评分8分以上，印象中产品经理相关书籍，特别2B领域，这已属于评分top级别。本书旨在入门，对于非B端或初级B端从业人，展示了产品经理工作范畴全貌。难得的是总结了B端产品经理知识体系，并在概述每项技能后，推荐了拓展学习资料；二是贯穿大量案例，以分销业务为例，按照实际设计流程，走了一遍。缺点在于内容不深，范围太广导致深度不足。不同于C端产品经理，除了产品经理的基本功（调研、需求、场景、用户、原型、流程、PRD、迭代），B端涉及软件工程、项目管理、业务知识、企业管理、企业架构方方面面，都想涉及到，但只能粗略提及。例如业务调研、项目管理、数据分析、企业架构，读起来感受不深。而相关的知识点，如UML语言、设计原则，也只能作为因子，让不清楚的知道有这么一回事。不过上述缺点，也是B端产品经理行业现状导致的，一是从C到B，本身就是巨大的转变。也许C端可以做到人人都是产品经理，但B端的门槛，相对高出许多。不过这也可能是因我在B端，一种不客观的偏见情绪。为了照顾未入B端的同学，本书只能求全而不求细。例如做B端Saas，产品人应该去实施现场做几次交付，感受实际业务，进而有利于其产品设计能力，对于产品标准功能的把控。但若是去甲方做一次项目，就知道单单项目管理，里面多少门道。C端产品人可曾受过如此的委屈。因而项目管理不得不提，但又无法具体展开。像UML、架构图等，这是传统IT最基本概念，但C端未必清楚；二是目前的资料太少了，这里指的是从互联网产品经理出发，因规模发展到存量竞争，以及市场环境的影响，导致产品经理的发展方向，趋向精细化、以及向外蔓延。从C端扩展的B端，进而到B端产品经理。从这个路径来看，目前大家都处于摸索期，无完整知识体系。但若从传统IT软件工程来看，相关领域已十分成熟，不愁没供给的。如此看来，目前所说的B端资料少，是指从C到B的路径仍不明确。

做项目阶段，也接触过大公司的咨询顾问。大几千万的项目，顾问是真牛掰。。在回想互联网新生代，如何沉下心来打磨B端产品，交付传统公司使用。可能只是服务一家企业几十号、上百人，为了这么点钱、这破公司、破业务老员工，费劲心力，心态很难适应。有时为了把控产品标准功能、或项目范围，与甲方拍桌子，同样较难适应。对于Saas产品，名气响，实际发展前景如何？目前仍很难说。看过一篇文章，提及作者对于强管理属性Saas产品的悲观看法。若要转B端，尽可能往工具性、公司内外交互型以及弱管理属性产品方向转。深以为然，3月份照着这条建议跳槽吧。。

读书笔记

1. 概述
   1. 商业变现产品：搜索引擎营销、广告投放平台、在线广告联盟、增值服务
      1. 无论商业模式如何创新，企业的运作机制都是相通的 //拿着2000年的IBM项目管理流程、业务最佳实践来看，都不过时。
2. 产品建设

2. 业务调研

1. 2. 调研目标-调研对象-调研方法-调研计划
2. 整体方案设计
   1. 业务流程
   2. 产品定位
   3. 应用架构
   4. 功能模块。产品经理设计的功能模块代表了其对业务本质诉求的理解和提炼，蕴含了他对业务、系统未来发展的期望。 ///不过功能模块，找几个成熟产品参考下，向异性很少，取个并集绝对够了。关键还是看演进蓝图，他的实施侧率，一期做哪些，运转多久待业务稳定后，再开展二期，二期做哪些。经验不是体现在有哪些要做，而体现在今年做什么、明年做什么，甚至基于业务现状，3-5年都想的明明白白。

2. 细节方案设计
   1. 数据建模
   2. 流程和角色；业务流程，使用场景，页面流程
   3. 界面设计
      1. 反馈原则:反馈操作进度
      2. 隐喻原则:采用用户熟悉，常识性图标和知识表达功能
      3. 回退原则:允许用户撤销操作
      4. 一致原则:降低用户对系统上手难度
      5. 防错原则:系统应考虑防止用户操作错误交互
      6. 容错原则:及时反馈错误提示及解决方案
      7. 记忆原则:每个页面适时解释字段，降低用户记忆难度
      8. 灵活易用:简单易操作，符合常识
      9. 简约设计原则:避免冗余信息，突出重点
      10. 帮助原则:帮助文档协助用户自助了解系统
      11. 分页设计，前几页、最后几页的技术与数据安全风险，不支持全量导出
   4. 报表设计；不着急线上化、验证一段时间再推广；管理驾驶舱，套打 ///本质是原型法，先用excel做出来给业务看是不是他们想要的。做价值验证以及方法可行性验证后，再开发。

1. 2. UML
2. 技术方案
3. 项目管理
4. 运营管理
   1. 产品功能推广培训
   2. 问题解答处理
   3. 需求采集过滤
   4. 项目效果分析
   5. 业务诊断分析
   6. 业务运营：业务支持，流程管理，策略制定，绩效考核制度制定，培训考核，系统运营，项目管理，合规质检，数据分析
   7. 组织架构设计，决定汇报关系，决定绩效考核。因而决定行事的动机，甚至做事方式。人和集体利益因此发生变化。

2. 迭代优化
   1. 初创、瓶颈、重构、稳定
   2. 试错成本、迭代成本 ///两个成反比的成本

2. 数据分析
   1. 不要担心提出的假设是错误的，这远好过没有假设，因为没有假设就没有切入点 ///方案也是，有想法了，60%，就可以拿着跟业务谈，根据反馈调整。

2. 应用架构

决胜B端：产品经理升级之路

杨堃

67个笔记

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

偏向实体产品经理的范畴

，帮助公司分析市场，识别需求，负责产品的设计、包装、宣传、推广和持续改进，提升公司销售额和利润。

BA资源最欠缺，oa是由开发人员直接对接需求。真的是惨不忍睹，被业务刷的团团转。新的paas平台，变成了运营管理部的专属系统了，天天给他们优化

很多软件产品甚至由软件工程师直接进行需求对接、方案设计和编码实现。

C端产品是被动艺术，就是说不需要销售与客服。与用户自然生长

不需要销售，很少需要客服

这时候的互联网产品经理拥有非常高的话语权和决策权，因为他们要承担经营压力：要全面负责商业分析、市场分析、需求分析、软件设计、项目实施、线上运营，还要对公司的核心经营指标负责。

互联网公司的核心竞争力不仅体现在流量获取和变现能力上，同时也更多地体现在业务模式创新、流程创新、精细化运营和效率提升上，这都对业务型产品经理提出了更高的要求。

2.1 互联网行业的发展趋势

这里是指管理成本，毛利润上不去

业务面临的各种问题不会被有效解决，规模化不会带来边际成本的降低，反而会让成本呈现出几何式增长。

2.2 从事B端产品方向的优势

软件工程+业务。sa 与ba

软件设计领域，又要涉足业务运营领域

是的。把咨询公司00年的资料拿来看，都不过时。

无论商业模式如何创新，企业的运作机制都是相通的

线上线下的模式正在被打通，很多创新的商业模式涌现出来。商业模式的创新必然会带来业务模式的创新，而新的业务模式就需要配套的运营、管理机制。

是的。即使SF都水土不服，太高端了，我们的线索要精准定位供地推刷，老外想不到的

而且销售区域和销售过程都需要基于门店坐标定位进行管理，传统的OCRM（操作型客户关系管理）软件根本无法满足这种对地理位置管理有很高要求的客户管理需求。

2.3 B端产品有哪些方向

叫法不一样，反应 定位是不同的。产品是个独立交付物，系统是要结合公司业务特点看整体。系统之美，如果改成产品之美 就能感觉到区别

传统企业，人们习惯将软件产品称为“系统”，在互联网公司，则习惯称之为“产品”

统一账户

企业客户账号管理体系。

这个最难。不同系统权限颗粒度不同，业务管理要求不同。尤其oa系统用惯的

权限管理平台。公司的业务人员经常要访问不同的内部业务系统，如果针对每个业务角色在各个业务系统分别设置管理权限，

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

设计人员要完成业务梳理、流程设计、组织架构设计、数据建模、界面设计、权限设计等一系列工作，既要有对宏观的把控能力，又要有对细节的专注力。

3.1 B端产品的总体建设流程

就是两个东西。任何idea，都是做价值验证，然后方法验证

业务还未开展，只讨论了初步的可行性，需要设计最低成本的试错方案。 ● 业务已经通过线下的初步验证，现在需要系统支持，实现线上化，全面推进业务。

● 核心业务流程：梳理整个业务主干流程，并确定其中哪些环节需要由该产品实现线上化。

● 产品定位：明确该产品有哪些子系统，分别支持哪些业务流程和业务版块。

● 应用架构：考虑该产品和公司现有系统的融合关系。

● 功能模块：基于对业务的理解，抽象出该产品的具体功能模块。

● 演进蓝图：根据业务优先级与发展策略，制订实现各功能模块的计划和节奏。

尽可能早的让用户体验，就是体验静态表单，包含的字段。以及报表功能

在设计时最好能提供可以体验的交互界面，让业务用户提前感受并反馈意见，减少不必要的返工。

3.3 案例：M电商公司的渠道分销产品设计

保持项目节奏感很重要，plus，前紧后松

会让自己感到踏实，有节奏感。如

4.3 B端业务调研的方法

经典资料永远是不愁的，关键还是组织能力 落地能力

尽管互联网创新灵活，有很多独特的业务模式，但现代企业经营管理与业务运营的本质并没有变，总可以找到模式类似的经典管理案例进行分析参考，

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

用户的作用是为了归来场景需求，非自然个人

主要是基于用户细分和用户画像的代表性用户

5.4 功能模块设计

确实是这样，但产品功能模块大同小异，可借鉴性很强

产品经理设计的功能模块代表了其对业务本质诉求的理解和提炼，蕴含了他对业务、系统未来发展的期望。

6.1 业务数据建模

首先构建业务数据模型，然后基于流程确定页面流转图，再着手每个页面的具体设计，同时提前规划好系统用户角色，最后完成权限设计。

业务调整的灵活性取决于软件系统的灵活性，而软件系统的灵活性取决于业务数据模型的可扩展性

6.2 流程和角色

it系统玩的就是信息流

一套软件系统就是对不同数据对象的增删改查操作的集合，

一套软件系统就是对不同数据对象的增删改查操作的集合，

6.3 界面设计

想清楚，再做

虽然在界面设计之前的流程很长，但只要你细心体会就会发现，我们对整个业务形态和系统形态都已经了然于心，对整个项目和产品的掌控力越来越强。此

当切换页面时，不应该让用户记住不同页面的内容，而应该在合适的地方积极地呈现或提示之前的信息。

增加或强化一些信息就意味着弱化另一些信息。

只会看10%

重点太多，相当于没有重点

之前确实没想到

分页设计绝对不是一个很简单的“小feature”，而是要经过慎重思考、处理的。

6.4 报表设计

调整工作节奏

Erp的报表几乎都属于次

建立业务分析监控体系，

报表的本质是满足管理与决策，因此是用户的自定义需求。也许下一个企业的需求是花里胡哨也可能，这不是关键，还是回归业务要求

作为一名业务管理人员，各种核心数据都是了然于心的，看一眼当天的数字，就知道有什么异常。管理人员需要的只是干净的界面和能够实时更新的准确数字，其他炫酷的交互效果并不需要。

套打是指在格式固定的单据或凭证上准确地打印数据，例如快递配送单、采购入库单、发票等

没有使用占位符。单元格中如果没有内容，不应该空着，容易让人以为漏掉了数据。根据数值的含义，要么填入0，要么填入占位符“-”。

产品经理都要尽量贴近业务，即便是被动地接受报表需求，也要努力思考其背后的设计思路。

6.6 权限设计

所谓能查到的数据范围，不是指能看到的数据字段，而是指能查出来的数据集合。

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

这里是“公司发展到一定规模后”，而不是“产品研发团队发展到一定规模后”，因为如果公司发展很快，即便产品研发团队规模很小（采用了外包方式），但是面临复杂的业务和爆发增长的需求时，依然需要严格的项目管理制度来规范管理、控制风险。

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

b端的特点。存在n个干系系统，对应不同产品团队、业务诉求。不过本应如此，吵出最优架构。不然不就是个信息孤岛了

跨端会带来各种困难，例如难以获得其他团队的支持、难以取得整体的排期等。

这不是b断项目风险，这就是项目的常见风险

而项目周期拉长，就会导致存在各种变数和不确定性，出现项目风险。

，仓储系统也可以从“客户属性”字段识别特殊诉求，但是为了保证业务的可扩展性，这里采用了通过订单来标识的方案。

可能基层团队之间一拍即合，合作后产生“化学反应”，比先找领导沟通再传达还要快。

为了项目，得罪人、吵架都是可以的

但只要是为了推动项目，为了要结果，为了有价值，最终大家都会认可并赞扬这种积极的态度。

纪要标注缺席人员

项目的各方核心参与人员必须准时出席会议，不能随意请假。

9.1 B端的产品运营岗

关键用户

但很多时候产品经理需要运营人员的协助和支持。

往往没有产品运营团队一说。

1. 关注业务关键用户，往往是部门秘书，或老业务用户。前者接受快，时间闲。后者稳定不离职。部门的操作问题，先咨询关键用户；

2. 问题处理，itil，分级，走运维服务

这种日常的针对业务全员的问题解答，必须由专门的产品运营团队负责，以保证处理效率。产品运营人员首先要在第一时间解答问题，为业务用户提供最快速有效的服务支持；另外，还需要经常归纳总结问题，

9.3 产品经理、产品运营人员、业务运营人员如何高效协作

所以产品经理有权利和义务在某些时刻跳出业务线，从客户利益或公司整体利益出发，对业务部说“不”，必要时将问题升级到CEO级别去处理。

一是合并团队，二是更细致地界定工作边界，例如，业务部的系统运营人员只负责问题解答，产品部的产品运营人员只负责工作推广……然而，这么细致的划分实在没有必要

因为产品经理对系统的控制权和运营权依然是割裂的，无法形成合力来挖掘价值

10.1 B端产品的需求管理

也是解决用户痛点，不过是类用户

解决业务问题

研发负责人一定是研发的整体负责人，而不应该分成后端负责人、前端负责

太细了没必要，作为总清单

待跟进、需求调研、PRD编写、待PRD评审、待技术评审、待排期、待开发、开发编码、待测试、测试验证、待验收、待上线、已上线、挂起、拒绝。

10.2 B端产品的迭代管理

只要研发团队的水平靠得住，一套全新的系统在全力运转的状态下对业务支持一年的时间，应该是绰绰有余的，而一年正好是验证业务是否能够存活下去的关键时间点。

这种往往是六周一个迭代，如erp。一个月不够，两个月太长

其中某一期的最小功能集合依然比较复杂，则可能无法在一个迭代内完成它。例如，涉及流程调整的需求，需要一次性实现完整功能集合，才能保证业务正常运作，

布鲁斯克定律

软件工程和流水线作业不同，无法简单地通过加人数的方式来缩短工期。

itil侧重it服务，虽然v4偏向价值驱动。企业架构，还是要看togaf

（如ITIL体系）

11.1 数据分析的流程

不要担心提出的假设是错误的，这远好过没有假设，因为没有假设就没有切入点，分析工作会更加束手无策，理不出头绪。

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

很多信息孤岛 不是主数据问题。transanction

，就会知道借助主数据的设计思想，构建客户主数据、供应商主数据、商品主数据等

好的架构基本是各产品、业务吵了n次，修改n次达到系统最优

有些决策从你所负责的业务和系统的角度来看并不合理，你感到很困惑。当你从公司整体业务的角度去思考时，这些疑问往往就会豁然开朗。

13.1 小微型企业的应用架构

所有的软件系统从本质上讲都是对数据的增删改查操作的集合，可以说，如果使用得当，Excel也可以做出一套小型的软件系统。

14.1 集团企业的应用架构

nice

但是电商总监对于信息技术部开发效率低的情况早有耳闻，他想快速推进实施项目，不希望被一些不可控因素影响，导致自己的项目延期，因此没有采纳CTO的意见，CTO对此心怀不满。

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

解决方案-产品部，同样的演进节奏

信息技术部也与时俱进，将需求管理部调整为产品部，培养并招聘产品经理，以便信息技术部能够和电商部、理财事业部的产品技术团队较好地沟通协作，并对业务产生有意义的影响。

14.3 集团强化中台能力建设

对内按照3PL（Third-Party Logistics，第三方物流服务公司）的模式提供服务支持，仓配部门和业务下游形成财务结算关系，对服务收费，保证品质。这是公司尝试将成本中心转型为利润中心的一个大胆尝试

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

不影响核心系统功能，兼容运行，先验证价值可行性

新业务发生变化的可能性大，失败的可能性也大，因此可以考虑新建独立的微小型应用系统来支持新业务，以避免改造成熟核心系统，影响其稳定性和健壮性。

新业务发生变化的可能性大，失败的可能性也大，因此可以考虑新建独立的微小型应用系统来支持新业务，以避免改造成熟核心系统，影响其稳定性和健壮性。

应用架构设计的首要目标是支持业务发展。在企业创业初期和成长时期，业务还在试错，活下去是关键，系统建设要全力支持业务，而不要过于追求架构的完美，

大方向与局部偏差

另一方面，在必要时要允许局部偏差的存在，局部偏差的修正成本是比较低的。

微信读书