决胜B端：驱动数字化转型的产品经理（第2版）

这是今年读完的第31本书。因为三年前读过第一版，所以第二版读得比较快，书中列举的场景实例也没有仔细分析，读这本书的目标在于以现在的视角“查漏补缺” 整体来看，我觉得第二版已经可以作为产品经理转型、入门、初级到中级提升的标准化读本，几乎涵盖了B端产品经理的方方面面 当然，正是因为覆盖面广，也让这本书在深度上略有欠缺。毕竟从产品视角来看，“大而全”和“小而精”本就是相互矛盾难以兼得的。即便作者让书的厚度增加了近一倍，但很多方面也不能继续深挖 所以，我以一位忠实读者的角度希望杨老师后续能够在某几个细分领域写出一系列的产品进阶套餐 关于产品经理的工具书，我觉得值得多读几遍的有以下几本： 《俞军产品方法论》、《SaaS创业路线图》、《SaaS产品经理从菜鸟到专家》、《幕后产品》，现在又增加了一本《决胜B端2.0》 书中的内容在此不多赘述，直观感受是很厚、很全面、很经典、很用心、很易读，也补充了我近些年产品工作的很多盲区 尤其是对于一些辩证性、博弈性的话题，作者能够提炼出相对准确、多角度的总结，确实功力深厚 另外，读完这本书之后最大的感受是：产品是产品、书是产品、人也是产品。我们都应该以产品思维不断迭代 因为经常围观作者的朋友圈，所以对于第二版的升级内容，作者的日常工作、生活状态有些许了解，给我的感受就是杨老师在以“产品”定位不断升级 随着时间的发展，结合自己持续的工作总结，迭代输出。这种状态让人既羡慕、又惭愧 我从去年开始对外输出以来，虽然有一些产出，但都是聚焦于某几个细节，并没有从中观维度体系化编排梳理，所以很多输出缺乏连续性，对自己反向促进也很有限 因此，这本让我“查漏补缺”的书读完之后，我发现了自身工作经历的盲区，比如商业视角、数据思维、更全面的架构能力，以及对于互联网技术的了解 我相信大多数同行都有类似的问题，受限于自身团队、公司的发展和视野，只能够从局部出发了解产品，提升产品能力，犹如盲人摸象 所以能有一本更加全面的教材拓展认知边界，真的要对杨老师说一声感谢 希望书中所讲，书中所学能够运用到工作和生活中，也推荐不同层级的产品经理拿来一读，从不同的视角吸取书中经验，感知作者传递的理念 毕竟，每个产品经理也需要不断迭代提升~

随时保持空杯心态，放低姿态，愿意打破舒适圈，突破自己，在职场中一切皆有可能 🌈刻意练习100次|N.91🌈 📖【阅读书籍】：《决胜B端》 👩‍🌾【作者】：杨堃 🌟【阅读感悟】： ☀🌳每天写东西的时候，忽才发现这才是最快乐的时刻。 ☀🌳停下来很久没有读这类数据，读一本让自己重新巩固行业知识。 ☀🌳杨堃说，一个合格的产品经理，手机上一定装成百上千个APP，仔细端详每个产品的业务逻辑和实现逻辑。 ☀🌳读完我最大的感受是，做好一个产品，从客户角度出发，把每个业务流程用条线的方式展现出来，然后去细化每个条线设置的点，一点点去检查条线中的逻辑点。 ☀🌳之前我领导最常说过的一句话是：你把业务场景罗列出来，每一个场景交互一次，走到的每个结束的节点，按照你的假设去看看到底能不能完成。 ☀🌳那个时候，并不懂这么深刻的道理，今天读完这本书，才恍然开悟。 ☀🌳才发现，之前写的每个测试点是零散和毫无关联，而他的思路是从头开始交互一环扣一环，清楚并明确的清扫了每一个错点。 ☀🌳领导所做到的，就如杨堃所说的，设计人员要完成业务梳理、问题诊断、产品定位、业务建模、界面设计、权限设计等一系列工作，既要有对宏观的把控能力，又要对微观细节的专注力。 ☀🌳我对行业的认知，远不足他理解的一半，未来继续从事的行业中，我始终看好这个行业，人才的领悟能力才是这个行业最稀缺的部分。 ☀🌳读完这本书，也积累了好几本书，比如《计算机网络》、《幕后产品》、《SaaS创业路线图》、《俞军产品方法论》等等口碑较好的数据，接下来就开始好好读一把，然后分享给大家。 #推荐一本好书#推荐书单#自我提升

本书作为一本入门书籍，整体上还是不错的，知识面广，涉及产品全流程，整个阅读过程对于我自己也是一个知识梳理的过程，系统化构建个人产品知识架构。 工作范围从商业洞察开始，到产品运营截止，覆盖企业战略运营全周期。 技术产品不是简单的将线下工作投影到线上，投影过程只是实现了信息的线上化，产品设计要基于企业战略，梳理企业流程，重构流程，然后才能线上化，因此产品构建是需要结合企业业务特性，平衡产品需要与业务需要，基于企业发展阶段，产品经理需要不断调整策略。产品本身并不解决问题，产品只是一种表现形式，若问题真的有价值，没有产品，业务也会有替代方案，解决问题的是产品背后的业务模式，通过业务模式调整业务行为。 产品工作主要需要商业能力，产品能力，技术能力，其中产品能力是作为产品的基础，产品设计是一个需要洞察人性的工作，因此经济学、心理学是必不可少的基础知识。除此之外，产品是一个复杂任务落地的过程，对于复杂任务统筹能力与管理能力也是必不可少的。

有收获，一直边读边对比我们的产品，貌似都没有提到多租户模式。 只要你能够通过深耕积累成为业务型产品专家，形成个人的竞争壁垒，不论在哪个赛道、哪个方向，都会在职场中非常抢手，取得良好的职业发展路径。

杨老师职业生涯并没做过 SaaS 和 PaaS 之类的 toB 商业化产品，真正做过只是公司内部用的后台产品，很多东西都来自于咨询反馈和逻辑归纳，可能也就对初中级产品经理有帮助吧。每个职能都有把自己弄得更专业的倾向，但这对实现业务目标并没有完全正相关的帮助，只把自己当产品经理来发展的人很难有好的职业生涯

“谋定而后动”，做好需求调研是项目成功的关键，但在实际工作中却常常被业务人员草草完成，所以一直以来都想对最薄弱的客户需求调研工作总结出一套可落地的系统方法，不求拉高上限，但求对齐底限。近期有幸阅读《决胜B端》《有效需求分析》《软件需求最佳实践》三书，再结合ToB工作实践，今日终于整合完成，记录如下，供后续工作时常参阅： 《客户前期调研基本方法指南》（暂且这么命名吧...遗憾表格格式无法复制，略微影响下文阅读体验） 一、目标 1.于项目立项前，更好地明确和挖掘客户需求，确定项目价值及定位； 2.提升前期调研质量，减少后续客户需求变更，避免增加不必要的项目成本，同时提升客户满意度； 3.提升产品及业务人员的调研能力，在客户侧建立更好的专业度形象。 二、适用范围 1.适用于打造通用产品的客户调研； 2.适用于项目制的客户调研。 三、适用人员 建议所有产品经理、项目经理、业务负责人参考。 四、适用阶段 以下调研工作属于客户前期调研，建议需在立项前完成。 五、具体调研方法 1.调研目的： 1.1挖掘客户需求，明确产品/项目要解决的问题/机会； 1.2跟客户确定解决方案思路，明确产品/项目定位； 1.3确定主要业务事件的流程，用于梳理对应业务架构及规划应用架构设计。 2.调研前准备： 2.1尽可能提前收集客户信息，为后续调研沟通工作开展提前了解更多背景信息： 【可收集的信息】如：单位基本信息（单位业务范围、人员数量、营收情况、商业模式等）、单位组织结构信息（部门、职责、负责人、负责人背景信息、部门人数、人员分工等）、各组织考核目标、和所调研方向密切相关的管理办法/制度/流程文档、信息化建设现状（已有系统建设情况、使用情况、优缺点）、网络环境、设备情况等。 【收集方式】部分信息可通过上网/找业务负责人了解，其余无法了解到的信息需提前发调研信息给到客户单位对接负责人，由对接人进行信息收集汇总，或者由对接人安排对应单位人员进行远程会议沟通。 备注：1）若对新业务领域缺少基本常识，建议提前阅读相关论文、行业报告或专家访谈等方式提前进行学习了解； 2）对于为什么需要收集这些信息，需要跟客户阐明价值出发点，以便引导客户更有积极性来提供相关内容。 2.2竞品、行业标杆案例信息整理： 【竞品、行业标杆案例清单】竞品选择上尽量选择该领域下市占率高的Top3厂商，行业标杆案例上重点关注同行业下Top2单位的系统建设情况。 【竞品调研关注点】除基本功能服务梳理外，重点分析其产品亮点、存在问题、商业模式、运营状况、合作过的优秀客户案例/失败案例及原因分析。 【行业标杆案例关注点】关注其项目背景（现状及目标）、解决方案（不止关注系统建设情况，也包括比如人员组织情况、项目建设节奏、运营推广方案等）、解决效果（若能了解到量化数据更佳）、分析可借鉴点&待提升点等问题。 【整理竞品、行业标杆案例信息】形式不限（如PPT、直接演示系统等），核心在于以合适的方式达到在后续调研中可跟客户进行演示及引导挖掘客户需求的目的。 备注：1）若对客户关注需求已有初步解决方案（尤其已有产品亮点），建议可提前准备产品原型图用于客户展示，在缺少竞品、行业标杆案例的情况下，这项工作则更为重要； 2）客户演示时，注意不要纯罗列功能逐个讲解，要以业务工作场景作为线索，先把工作的业务步骤列出来，作为整个串联的情节，然后让用户带着这样的线索来审视系统的操作过程，看看是否合理、是否满足需求。要让用户不仅仅关心用户界面的样子，更要关心流转和交互过程，以减少后续主流程的需求变更。 2.3拟定调研提纲，并提前发给用户： 调研计划大纲可以包括如下内容： 【调研计划大纲】（此前已整理成表格，上下对齐阅读） 访谈主题： 访谈要点 期望部门 备注 访谈人 访谈时间 用简短的话概述 抽取关键点 指定理想的访谈对象 访谈具体内容文件名信息 由客户方联络人指定 由客户方联络人指定 【各角色访谈具体内容】 需要考虑按访谈对象设计不同的访谈内容： 访谈对象 计划要点 备注说明 高层管理人员 （1）罗列出部分问题/机会点（售前获取一些信息） （2）备相关优秀实践案例 （3）列举潜在的解决方案 确认已列出的问题/机会点，探讨潜在的问题/机会点，明确项目目标方向，标识出关键干系人 中层管理人员 （1）罗列出相关的业务事件列表 （2）收集与特定业务事件相关的资料 （3）准备一些业务事件的关键问题点、需求点 （4）准备一些相关的管理控制点 确定每个业务事件的流程，收集中层管理人员的问题点、需求点 操作层 （1）罗列出相关的业务活动 （2）收集与特定业务活动相关的资料 （3）针对业务活动的问题点、需求点 进一步确定每个业务事件/活动的流程，收集操作层人员的问题点、需求点 备注：1）在干系人关注点分析时，要从两个角度出发：一是他们希望系统解决什么问题、提供什么业务支持；二是他们希望避免出现什么样的负面影响，这样才能够立体地完成干系人分析； 2）拟定调研提纲后，应将问题提前发给用户，让用户打有准备之战，发送时间建议提前2-7天，不宜太早，也不宜太迟。 3.调研过程： 3.1 沟通注意事项： 需求调研的过程是人和人打交道的过程，是各位展示自己沟通能力的地方，需要学会一些和人打交道的策略，有以下几点经验分享： 3.1.1 需求捕获应该是主动的，需求分析人员在整个过程中应该充分发挥出主动性，要善于把握主动权，能够根据每次访谈的对象制定相应的计划。 3.2.2 需求捕获应该是聚焦的，不要让用户发散地提需求，要帮助用户梳理工作流程及痛点，从而将问题聚焦。 发散问法举例：你对这个系统有什么需求？（这种问法容易产生很多镀金需求、非重要需求） 聚焦问法举例：当XXX的时候，希望以什么形式体现？收到后，你们一般会进行什么样的处理？在这个过程中需要做什么配套工作？原来处理时存在什么困难？有哪些问题是比较棘手的？ 3.3.3 要注意对变更需求的捕获，以下问题有助于提前了解这类需求，便于后续考虑系统设计的灵活性。 - 你们上次组织结构调整是什么时候？ - 这个流程以前也是这样的吗？如果不一样，是什么时候的事呢？ - 这些规则是来自外部法规，还是内部制定的？ - 如果是外部法规，这些法规通常几年会更新一次？ - 如果是内部制定，是由哪个部门制定的？依据什么会进行调整？ ... 3.3.4 要注意用户说的是问题还是解决方案，通常越有经验的用户越喜欢直接说解决方案而不是问题，这时候一定要多问“why”，因为用户并不是最合适的解决方案专家。 3.3.5 从用户的肢体语言、表情都会反馈出一些语言之外的信息，一个优秀的访谈人员应该能够抓住这个异常现象，以便对问题建立更清晰、准确的理解。 现象 内涵 语速极快、描述过程逻辑性强 1.传达的信息是用户很熟悉的工作 2.描述的信息可能是理想化的制度 语速缓慢、中间有很多的停顿 1.用户对讲述的信息不够熟悉 2.传达的信息是平时考虑不多的 3.这些信息很容易产生变化，需要注意 突然改变语气、脸色 1.所问的问题是对方很敏感的 2.涉及公司政治、有利益影响 3.传递的信息有明显的误解 回答某问题时眼睛经常向左上方转动 对方可能在回忆，信息相对真实 回答某问题时眼睛经常向右上方转动 对方可能在“创造”，真实性待确认 回答比较强势，甚至有攻击性 对信息系统的建设有反对意见或敌意 坐姿很随意，诸如翘着二郎腿 对访谈内容重视度不高 3.3.6 访谈时一定要就预先计划的问题逐一得到解答，因此在访谈过程中需要不断地检查，以确认没有遗漏的问题。 备注：在实际的访谈过程中，预先计划问题和即兴问题有时并不需要截然分成两个阶段。具体来说，可以根据被访谈者的特点来决定。 - 思维比较发散：那么就可能会把话题带得过偏，从而导致占用了大部分时间；这种情况下就应该尽量回归到预先计划问题上，先保证不遗漏这些问题，再对即兴问题进行处理。 - 思维比较聚焦：有些客户是比较有控制力的，他们会控制话题，这时可以适当地穿插即兴问题。 3.2 调研形式： 3.2.1 用户访谈：这也是我们实际工作中最常见的形式。 【被访谈者】 最常见的被访谈者包括高层管理人员、中层管理人员、操作层3类（可根据目标及风险识别关键干系人，通过项目目标可识别出和哪些部门相关，通过风险可识别出如可能会带来大量负面影响的基层员工、有一票否决权的评价者<财务、审计、法规等监管部门>等）。 通常对高层管理人员的访谈结果是访谈中层管理人员时的指导，同样对中层管理人员的访谈结果是访谈操作层时的指导，也就是说，在不同阶段应该访谈的人是不同类型的，而且对于不同类型的被访谈者的话题中心、访谈目标都是不相同的。 另外，被访谈者选择需注重代表性：每个具体的干系人，在专业背景、职业经历、个人价值观、组织地位、工作经验等方面都会存在一定的特殊性。因此，选择出的一位或多位代表，应该能够覆盖各种差异的干系人。 【访谈时空安排】 时间：一般来说，一次用户访谈的时间应该控制在1小时以内，如果时间不够用可以考虑中场休息或者安排下一次访谈。 空间：为了避免访谈过程中受到外界的干扰，应尽可能选择诸如会客室、洽谈室等相对封闭、不易受干扰和被打扰的地方进行访谈，特别应该尽可能避免办公室。 【访谈中的记录工作】 建议采用“自己做笔记+录音”的组合方式。同时在访谈过程中，可采用及时反馈策略，每当被访谈者陈述完一段话之后，就用自己的话简要复述一下，以保证双方达成共识。 3.2.2 问卷调查：当存在大样本用户、跨地域用户时，可能需要用到问卷调查。 【问卷设计】 （1）注意问题的篇幅与布局 - 填写问卷的时间不超过20分钟。 - 问题应该按由易到难的顺序排列。 - 问题排列应该注重逻辑相关性，否则会干扰被调查人的思路，从而降低问卷的填写质量。 （2）注意问题类型的选择 - 在需求调查问卷中应该尽可能避免使用封闭式问题，因为这类问题很容易诱导被调查人，从而产生不准确的结论，而解决的方法，就是用半封闭性问题来代替。 - 尽量让开放式问题跟随在相关封闭式、半封闭式问题之后；因为这时用户在脑海中有一些答案，填写出来的可能性就会大大增加。 举例： 当你想了解被调查喜欢什么样的运动时，就应该采用如下所示的问卷设计方式： 你喜欢什么运动？（可多选） □足球 □篮球 □围棋 □器械 □其他（请写出）_______ 当用户没找到可选项时，在其他的后面写出他喜欢的运动的可能性就会大大加强，如果将这样的开放性问题放在最后，就很可能收到白卷。 【问卷分析】 - 注意筛除无效问卷：调查问卷的填写质量是良莠不齐的，因此在分析统计之前一定要把无效问卷先排除掉。有两个线索能够很好地标识出无效问卷：一种是存在大量的空白，第二种是连续出现相同的答案。 - 对问卷的填写人进行分类：我们不仅需要对所有的问卷做统计，还应该将问卷的填写人按职位、地域、年龄段、从业时间等方面进行分类，然后对每类填写人的问卷进行统计，这样就会发现这些差异是由什么原因造成的。 3.2.3 现场观摩：在对业务知识、业务场景不熟悉时、需要对复杂流程建立更深入的了解时、在对关键任务理解不清晰时、在很多东西用文字表述不清时，都是建议使用现场观摩的时机。 【观摩方式】 - 任务示范：也就是要求用户示范如何执行特定的任务。 备注：不应大张旗鼓地进行，否则容易出现“观摩”失真、“示范”失真的现象； 有条件的情况下，建立可重复观摩的场景，也就是将观摩的过程录制下来。 - 做学徒：也就是和用户坐在一起，通过观察、问问题，并在用户指导下完成一些工作来学习。 3.3 工作文档收集： - 在对每个业务事件的流程进行分析时，标识出各个业务活动所要处理、传递的表单，形成一个表单列表，让用户根据这个列表来提供对应文档。 - 收集文档时，应该尽可能让用户提供带有部分真实数据的样本。 4.调研产出物： 4.1 访谈过程记录：访谈录音文件（如果有录音）；访谈文字版记录（含调研前信息收集+调研过程记录）。 4.2问题定义：问题需要被清晰定义，对问题进行了正确的定义，意味着已经成功了一半，同时应将问题及发生问题的本源跟客户达成一致。 备注：要注意分析问题背后的问题，也就是寻找问题的本源，可运用两种工具，一种是定性分析的鱼骨图，另一种是定量分析的帕累托图。 问题卡片模板（如果有多个问题，则对应产生多个问题卡片） 问题/机会 编号 为每个问题场景设置一个编号，用于需求跟踪 描述 客观地从业务描述问题 影响了谁 如果有多个被影响人，则列出多个；请注意指代清晰、具体到人 产生的后果 与“影响了谁”对应起来；要确保视角匹配、推理合理 解决方案 要点 说明主要的策略 优点 当有多个可选解决方案时，在此说明为什么推荐本方案 4.3 干系人分析结果： 干系人分析卡片模板 类别 包括发起人、使用者、评价者、其他四种类型：发起人为项目发起人；使用者就是未来会直接、间接使用系统的用户；评价者通常是财务、审计、法规、行业监管部门等会提出验收标准的、通常拥有一票否决权的干系人；开发团队、维护团队、领域专家、技术专家等干系人就属于其他类 代表 人员姓名+职位，如有多人则记录多人 人员职责 管理及工作范围、核心考核绩效 联系方式 便于后续联系 相关度 项目与他直接相关吗？涉及他的利益或责任吗？可以使用“高、低”两级评估或“高、中、低”三级评估 影响度 他对项目的方向、验收有很强的影响力吗？可以使用“高、低”两级评估或“高、中、低”三级评估 核心关注点 编号 内容 重要性 逐条写出该关键干系人的关注点（正需求）、阻力点（负需求），还可以考虑写出相应的功能需求 判断重要度（可以使用“高、中、低”或“关键、重要、有用、一般”进行评估） 备注 记录一些其他便于理解干系人的相关信息，如专业背景、职业发展过程等 4.4 已有系统建设情况： 系统名称 系统说明 建设阶段 客户评价 和本项目关系 系统名称 系统价值（用于解决什么问题），核心包括哪些模块/功能 待建设（预计什么时候启动建设）/建设中（预计什么时候建设完成）/已完成建设（投入使用时间） 应用情况如何？ 1）系统优点： 2）系统问题： 系统集成/数据互通/替代关系（历史数据是否要迁移）/其它等 4.5 文档清单： 4.5.1 相关管理制度、办法、流程等文档； 4.5.2 相关工作表单清单； 4.5.3 重要问题记录：如网络环境、设备、硬件等情况； 4.5.4 其它相关业务文档。 4.6 业务架构分析： 可参考《2-公司信息化总体架构设计方法论_v3.4》4.2.1章节内容（为另一文档...）。 4.7 应用架构规划（初稿）： 可参考《2-公司信息化总体架构设计方法论_v3.4》4.2.2章节内容（为另一文档...）。

遇见这本书真的如获至宝，不管是产品经理、开发人员、运营人员、部门管理者、企业管理者，甚至是新手小白，都是一本极其实用的书，既可以当做工具书使用，也可以作为科普读物，可以把读者的视角，拉高到宏观的层面去全面的理解掌握B端业务和产品体系，存在的价值，以及行业发展趋势等等，深入浅出。其中不乏有很多真实和虚构的案例来帮助读者理解所涉及的内容，通篇无废话，语言精炼，陈述全面。

对于没做过产品的同学可能会觉得内容很多很杂，感触不深：对于经历过完整项目周期但是经验不是特别丰富的的产品来说是一个很适合查漏补缺的书，可以看到自己曾经在工作中忽略的很多细节，将理论和实践结合做反思和复盘；但是对于经历过多个项目，经验很丰富的产品来说可能有些缺乏深度，但是总体来说还是推荐的。

帮助蛮大的，前五章还有项目管理的章节，以及很多章后面的资源推荐，很有用，要学的东西好多，沉下心捋捋，一步步来

花了70多币永久购买了本书，书币有效期30天，攒够70个也不容易。这本书算是个工具书，或者叫字典书，帮助构建知识体系，内容比较庞大，案例辅助对理解具体业务场景有些效果。这本书的内容本来应该是作为从业的个人自主建构的，有此书的帮助个人建构知识体系会更容易些。还有一点很好的是，作者推荐的其他书籍也很有份量，这当然很好，但也要警示其他读者，除非你下决心钻研，不然读推荐的其他书会非常占用你宝贵的时间，任何一本推荐都值得花和本书同样的精力去学习。综合来说，这本书值得打四分。