作者：李宽
出版社：电子工业出版社
格式: AZW3, DOCX, EPUB, MOBI, PDF, TXT
B端产品经理必修课：从业务逻辑到产品构建全攻略试读：
内容简介本书主要讲述了“单个产品管理流程”，以展示B端产品经理的工作方法及B端产品的设计方法。本书分为三个部分。第一部分主要讲述的是B端产品经理的工作流程和定义（即单个产品管理流程），以及从事B端产品经理的职业现状和规划，还包括设计B端产品时需要了解的指导思想。第二部分是通过各个章节来讲述单个产品管理流程的框架，向读者介绍B端产品经理在工作时所做的事情。第三部分是分享笔者在产品经理工作中的经验，希望能够帮助到各位读者。
本书面向的读者是初入职场的产品经理新人、3～5年工作经验的B端或者C端产品经理以及想转行成为产品经理的研发人员。
未经许可，不得以任何方式复制或抄袭本书之部分或全部内容。
版权所有，侵权必究。
图书在版编目（CIP）数据
B端产品经理必修课：从业务逻辑到产品构建全攻略/李宽著.—北京：电子工业出版社，2018.9
ISBN 978-7-121-34773-3
Ⅰ.①B… Ⅱ.①李… Ⅲ.①企业管理－产品管理 Ⅳ.①F273.2
中国版本图书馆CIP数据核字（2018）第163390号
策划编辑：董 雪
责任编辑：张彦红
印 刷：北京季峰印刷有限公司
装 订：北京季峰印刷有限公司
出版发行：电子工业出版社
北京市海淀区万寿路173信箱 邮编：100036
开 本：720×1000 1/16 印张：12.75 字数：223千字
版 次：2018年9月第1版
印 次：2018年9月第1次印刷
定 价：59.00元
凡所购买电子工业出版社图书有缺损问题，请向购买书店调换。若书店售缺，请与本社发行部联系，联系及邮购电话：（010）88254888，88258888。
质量投诉请发邮件至zlts@phei.com.cn，盗版侵权举报请发邮件至dbqq@phei.com.cn。
本书咨询联系方式：（010）51260888-819，faq@phei.com.cn。推荐语
李宽在公司内部被尊称为宽哥、李经理，源于他超常的自律品格。这本书，是他在工作极度繁忙的间隙完成的，由此可见一斑。全书非常接地气，凝聚了宽哥多年的工作经验之精华，系统性地阐述了B端产品经理的工作流程和发展方向，为步入这一前景光明而又有趣的岗位的职场新人提供了指引，为职场老人重新梳理了思路。张涛 小米信息部副总经理
这本书作为B端产品经理的入门图书，语言通俗易懂而且有比较完整的架构体系，给读者提供了一个系统性的认知。B端市场在美国是个非常大的市场，而国内近年来也是突飞猛进。希望作者的总结思考可以帮助更多人进入到这个非常有潜力的行业。南迪尔 小米智能产品部设计总监，《触人心弦》作者
产品经理岗位发展到今天，已经开始细分，我们看到从不同维度上，细分出了“电商产品经理”“人工智能产品经理”“数据产品经理”，而现在，终于有同行专门为B端产品经理的学习成长做出了尝试，推荐大家阅读。苏杰 良仓孵化器创始合伙人，《人人都是产品经理》作者
B端产品经理门槛低，要做到及格并不难，比起C端产品经理要容易。想成为
高阶的B端产品经理却异常艰难，这意味着需要有深入的行业理解、扎实的架构功底和准确的迭代判断，因此大量的B端产品经理工作多年还是在新手村徘徊。《B端产品经理必修课》给出了一种如何成为优秀B端产品经理的路径，也许能够让你快速走出新手村，成长为独当一面的产品人。刘飞 《从点子到产品》作者，滴滴出行产品专家
作者透过大量实战成功案例和经验总结系统叙述了产品经理的职业发展、自我管理，生动讲述了单个产品管理流程、包括需求分析、管理、设计、开发、发布、监控等不同阶段的方法。这些方法能够启发产品经理通往产品专家之路，也是B端产品经理不可缺少的一本好书。胡晓 国际体验设计协会（IXDC）创始人
每一款B端产品为企业运营管理、市场营销提供着助力。这也让B端产品经理无限接近市场和商业的本质。由于B端产品本身是复杂、抽象的，从业者能找到的学习资料相比于C端产品要少很多。有道是，于无声处听惊雷。李宽的这本关于B端产品的书，为初学者提供了成为B端产品经理的学习路径以及设计方法，也为从业者提供了经验和产品方法论。这是一本开创性的好书。老曹 人人都是产品经理、起点学院创始人＆CEO
我理解本书中所讲的B端产品经理，所做的业务主要为内部和商用的相关系统。这两类系统的品质，对企业的长期发展至关重要，也势必会越来越受到优秀企业的重视。有志于在这个领域深造的产品经理，或对此领域感兴趣的任何同学，都可以将此书作为起点。隋国栋 什么值得买创始人
在“互联网+”的大趋势下，越来越多的产品经理需要同时具备to C和to B两方面的产品策划能力。李宽的《B端产品经理必修课》是一本面向B端产品经理的书。它从to B的基本概念讲起，将很多传统IT开发领域的方法论与互联网结合，加上作者的深入思考，配合大量有趣的案例，为读者一层一层剥开B端产品复杂的外壳，带领读者一窥B端产品策划的精髓。如果你有关于B端产品的困惑，相信本书可以给你一些启示。刘涵宇 腾讯高级产品经理，《解构产品经理》作者
对于用户体验从业者而言，面向用户的设计已经形成了各种完备的理论和方法体系。虽然设计to B的产品往往需要更加全面的垂直行业知识和技术理解，但市面上却鲜有成体系的书，大公司内部也没有为to B产品的员工们设立专门的能力模型和通道。所以很开心能看到李宽的这本书，可以专注而完整地阐述一个B端产品经理从职责定义到产品方法再到设计流程最后落地到自我管理，为想成为B端产品经理的从业者提供了教科书般的指引。文字精练、内容有条理，体现了李宽一贯的超强逻辑性思维和总结归纳力，值得一读。夏梦 腾讯高级设计师，《设计搜索体验》译者前 言
亲爱的读者，感谢你打开这本书，接下来我将为你介绍这本书的来龙去脉。
意外开始的写书之旅
我是一个喜欢看书的产品经理，并且涉猎历史、哲学、科学、经管、互联网、技术等各个领域的书籍。看书多了，自然就会萌生出写书的想法。我把写书列为一个长期的目标，规划了5年左右的时间。
有道是：不积跬步无以至千里。我以wideplum的笔名，从2017年开始坚持每周写一篇公众号文章，同时分享在PMCAFF和人人都是产品经理等行业网站上。希望能用这种积少成多的方式，慢慢积累素材，培养自己的写作能力。
在2017年的时候，我发布了万字长文《手把手教你做需求管理》，阅读量累计过万。文章阅读量的增加，也带来了很多读者加我微信。没想到其中的一位微信好友，使我开启了写作之路。
2017年7月19日的上午，电子工业出版社的图书策划董雪通过我的笔名找到了我的微信号。简单的聊天之后，董雪说明来意：看见了我的文章，咨询我是否有出书意向。我没有想到出书的梦想会这么快实现。我立刻答应了下来。之后，历经了提交样章、申报选题、签署合同等环节之后，在2017年的8月份，我的写作之路正式开始。
冰箱贴计划
为了给自己的写作计划增加仪式感，我给写作计划起名为“冰箱贴计划”。名字来自一个下午，我坐在客厅的沙发上，决定以我看到的一个物品名字来命名我的写书计划，结果第一眼我就看了冰箱贴。
写作不同于学习，因为学习即使遇到困难，总会在网上或者别的书上找到答案。而写作要完完全全靠自己想出思路和文案。
就拿选题来说，我作为B端产品经理的一员，在从事B端产品的相关工作时，发现周边只有零碎的文章介绍B端产品以及B端产品经理，但是没有专门的指导书籍能够系统地介绍它。于是，我就尝试填补这项空白。
B端产品经理的知识没有成型理论和体系，于是我就查阅大量现有的互联网、经管类书籍，还有大量的软件工程类书籍，以及学术论文。为了弄清楚一个经管的概念，我曾从麻省理工学院下载了一篇1981年发表的英语论文A PRIMER ON CRITICAL SUCCESS FACTORS。从查阅资料的过程中，也体会到发现知识本源的重要性。了解了知识的本源，才能够知道知识的核心要义。
写作的过程基本都是在早晨、夜晚及周末。从2017年8月动笔持续到2018年1月完成初稿，其中付出的辛苦和汗水一言难尽。幸好，我总算是坚持了下来。
阅读指南
本书分为三个部分。
第一部分是“To B or not to B，这不是问题！”主要讲述的是什么是B端产品及B端产品经理和B端产品经理的工作流程（即单个产品管理流程），以及从事B端产品经理的职业现状和规划，还包括设计B端产品时需要了解的思想。读者通过阅读完本章的内容，将会从宏观角度了解B端产品经理。
第二部分是“单个产品管理流程”。通过各小节来讲述单个产品管理流程的框架，向读者介绍B端产品经理在工作时所做的事情。通过阅读本章的内容，读者将会从软件工程和用户体验的角度，来理解B端产品经理的工作。
第三部分是“产品经理的自我管理”。通过对本章的阅读，读者将会获取到笔者在产品经理工作中的经验，希望能够从中帮助到各位读者。
本书的核心部分在第二部分“单个产品管理流程”，也就是书中经常出现的“5×5”方格。在这部分，笔者会通过大量的图表，向读者展示B端产品经理的工作方法。为了便于读者理解和回顾，在每一章的最后，都有对本章内容的总结和提示。
以上内容，希望在读者阅读本书时能提供帮助。
清河边上的漫步
我目前供职于小米公司信息部的仓储物流组。小米公司的办公地坐落于北五环的清河边上。在每个工作日的午后，我和研发的同事们经常在清河边上散步。在散步过程中，我们经常会天马行空般地畅谈。有时，我们经常会在聊到产品和设计时，在无拘无束的畅谈中总结着自己对产品的看法和观点。
后来，同事们开玩笑说，以后你就把你的思想称之为普拉姆思想吧。这个名字来自我的英文笔名wideplum中的plum。于是，我就把清河漫步中的普拉姆思想延伸到了我的朋友圈。我经常把我对产品的思考和观点，以“普拉姆原则”为署名的形式发布出来。这样，我能看一看身边的朋友对这些观点的认可度。当然，这些普拉姆原则的产品观点，大部分都融合在我的这本书中。
我希望通过思考和总结，为中国产品经理职业发展提供理论和实践的支持。希望我的书能帮助到各位读者。
最后，感谢在写书过程中一直支持着我的爱人——侯峥（May）。
感谢王海洲、张涛、杨轲等各位小米领导对本书的支持。
感谢张锦、韩亚、叶金涛、王晓宇、曹宏亮、满金欣、彭伟财、熊肖翔、谢勇、程晨、谢心斌、王文鹏等小米同事对本书的支持。
感谢杨宁、沈陶、姚一鸣、孟广博、张娟、焦健、李渊深对本书的支持。
感谢电子工业出版社的图书策划董雪，对本书出版所付出的辛苦和努力。自 序
To be, or not to be: that is the question.（生存还是毁灭，这是个问题。）——莎士比亚《哈姆雷特》
做不做B端（To B）产品经理，这可能还真是一个生存或毁灭的问题。
To B，or not to B: that is the question.
也许你是正处在毕业校招季的大学生，带着改变世界的产品梦想，一腔热血地投入到互联网大潮中，面对前端、后台、to B、to C的产品职位时，选择哪一个让你感到茫然。
也许你已经做了1～3年的前端产品经理，每天做着判断按钮颜色或交互体验的工作。随着年龄的增长，开始怀疑这个职业是否在吃青春饭，犹疑是不是要转做后台或者to B产品试一试。
也许你已经从事B端产品经理的工作，每天面对焦头烂额的业务逻辑、需求和永远跟不完的项目，同时很难找到B端产品做竞品分析，或者做B端产品久了而感到厌倦或缺乏激情。也许，此时的你，正探索着如何提升自己的职业竞争力。
如果你处在以上场景，请把这本书读下去。也许本书中所讲述的B端产品经理之路会对你有所启发。
请坚定这条信念：在产品经理职业生涯里，不管做出何种抉择，失败导致的后果其实并不像你想象得那么严重。
每个人都在不断地前进和成长。不要用现在的境遇，去推算未来。
当你思考问题的时候，其实已经在为解决问题而聚焦方向。
请坚信：产品经理，你所选择的这个职业，也许是世界上最有趣的职业之一。
轻松注册成为博文视点社区用户（www.broadview.com.cn），扫码直达本书页面。
●提交勘误：您对书中内容的修改意见可在 提交勘误处提交，若被采纳，将获赠博文视点社区积分（在您购买电子书时，积分可用来抵扣相应金额）。
●交流互动：在页面下方 读者评论处留下您的疑问或观点，与我们和其他读者一同学习交流。
页面入口：http://www.broadview.com.cn/34773第一部分 To B or not to B，这不是问题
成为乔布斯、张小龙这样的产品大神，也许是每一个产品经理的梦想。但残酷的是，成为他们的机会微乎其微。那么，众多产品经理的职业生涯之路将何去何从？
答案是，大部分产品经理的职业成功之路，是成为某个领域的产品专家。而做B端产品经理是一条成功率极高的路。第1章 点亮：了解B端产品经理
成功的产品必须合并内部和外部成分的所有不同的层面，协调地支持所有可见和隐藏的服务和操作。产品存在于一个复杂的交互网络中。——唐纳德·A·诺曼《设计心理学2——如何管理复杂》1.1 什么是B端产品
在B端或者to B中，B代表Business，即商业。所以，B端产品要符合商业组织的战略要求，能够满足商业用户需求，将已有商业运行逻辑进行系统化、信息化、高效化处理。
说得简单点，就是B端产品让企业更舒服、更快捷地运转，从而向消费者收费并提供服务。
B端产品可以为公司管理服务，也可以为公司运营服务。为公司管理服务的B端产品包括HR系统、OA系统等。为公司运营服务的B端产品包括供应链系统、ERP系统等。可以说，B端产品出生于商业逻辑和运营的娘胎，从生下来的那一刻就注定与商业有血缘关系。
回想一下我们在京东、淘宝下单的经历。
请先大步跳过首页、搜索等C端产品的范围，定格在商品详情页。只有在库存充足的时候，才能下单。在商品详情页的背后，有一个库存系统提供信息。有了库存才能把商品加入购物车，支付成功后生成订单。这时你已经在关注订单详情页了，接下来期盼的就是快点收到货。
此时，订单详情页展示的信息，由用户看不见的系统提供。订单系统将订单发送给仓库。仓库工作人员使用仓库生产系统生产订单中的商品。运输人员使用运输系统监控商品是否顺利送到你手上。
而以上描述的下单到收货的复杂过程，在前端展示给用户的只是简单的一条从下订单到送达的信息。
上面提到的库存系统、订单系统、仓库生产系统、运输系统都是B端产品在服务企业的商业运营。
而C端或者To C，是直接面向消费者（Consumer）使用的。比如微信、微博这类的产品。
B端产品和C端产品最大的相同点，都是要为用户提供价值。只不过C端商品是直面用户，而B端产品要曲折一些，比如给用户更快地送货，就需要优化订单系统、仓库生产系统、运输系统等多个系统。
B端产品和C端产品的不同，还体现在以下3点。
●产品的使用者
C端产品是面向大众用户的，谁都可以用，比如微信。C端用户数量，需要通过运营推广来不断扩大。
B端产品是面向企业或者商业领域内特定范围的用户的，使用者非常少。比如，公司内部的薪酬管理系统，可能只有几个人使用，以管理工资。
与扩大C端用户数量相比，B端产品更看重特定使用者的深耕细作，不断挖掘B端用户的需求。
●产品的提供者
C端产品的提供者来源于市场，用户都是通过应用市场或直接登录网页，来获取产品和服务。
B端产品可以由企业内部团队来开发，比如ERP（Enterprise Resource Planning，企业资源计划）、SRM（Supplier Relationship Management，供应商关系管理）。也可以向市场采购，比如SaaS模式（Software-as-a-service，软件即服务模式）、菜鸟的开放物流平台。
●产品的需求
C端产品用户体量大，需求有时并不清晰，所以需要挖掘整合，是一个从零到一的创造过程。产品上线必须通过数据分析、用户调研等方式，才能收集到反馈信息，从而进一步迭代产品。C端产品经理对用户的理解大多来源于生活习惯、感悟、竞品分析、行业发展。
B端产品更像是VIP服务，面向特定的群体，能够收集明确的需求，是从一到无穷大的整合过程。产品上线后，能够直面用户反馈使用，收集反馈，快速迭代。B端产品经理对用户的理解来自对特定行业的深入理解，熟知第一线使用人员的操作流程，会使收集的需求更加真实。
总结一下：犹如冰山，C端产品是浮于海平面之上的冰山一角，海面之下的B端产品更加庞大；犹如大树，C端产品是远见的葱绿风景，B端产品是深耕地下的健壮根系，枝叶与根茎相互支撑。
既然B端产品处在看不见的地方，设计它们的产品经理又是什么样的人呢？1.2 B端产品经理是谁
C端产品经理会关注产品的体验、转化、用户增长、市场等方面的内容。那藏在深水之下的B端产品经理，他们会关注产品的哪些方面呢？[1]
借用《企业应用架构模式》中企业应用的软件框架，我们来列出B端产品经理主要关注的3个方面：表现层、领域层、数据层。
●表现层
表现层即用户界面，用户直接与系统进行交互和操作。
在表现层，为了提升实现速度、提高使用效率并降低培训成本，[2]B端产品经理会关注界面设计中模式和组件的高效及是否可复用。比如，用户查看数据是一种固定操作行为，针对这种可预期的行为，界面设计会有解决方案（模式）。这个解决方案在界面上会由表格、按钮、搜索框组成，这些就是组件。
在表现层，产品经理会优先关注界面的可用性，其次是是否好用。
●领域层
领域层是商业和业务逻辑，这是核心的关注点。产品经理关注业务逻辑的流转并参与到其中的各种角色。产品经理要切分好每个业务逻辑的模块边界，并且划分好参与其中的角色。最终，实现模块与模块之间，角色与角色之间的高效协作。
●数据层
在数据层，关注的是系统之间的交互与数据存储。系统之间会以接口的形式传送数据，产品经理关注接口传输性能、传输内容等。
同时，理解数据是B端产品经理挖掘需求和分析需求的基础。产品经理要关注数据之间的关系。数据代表的事物究竟是什么？由什么组成？
比如，一个订单是什么？它包含了订单号、购买商品数量、用户信息等内容。这些数据存储在数据库中，产品经理要理解它们之间的关系是什么。
总之，产品经理是这样一群人——他们时刻关注每个需求和产品中的表现层、领域层和数据层。1.3 B端产品经理的工作流
B端产品经理不仅有传统软件开发中的需求分析师、项目经理的工作职责，而且具备了互联网行业关注用户体验的产品经理本色。所以，B端产品经理的工作要将软件工程与用户体验这两个领域结合在一起。在这里，我们搭建一个B端产品经理的工作框架（如图1-1所示），这个工作框架最基本的元素是活动。所谓活动，是指产品经理要做的事情。然后，我们将这些活动按横轴和纵轴进行分类。横轴是从软件工程角度，将B端产品经理的活动从工作流程角度进行分类。纵轴是从用户体验角度，在工作流程中的每个阶段，对这些活动从宏观到微观再进行一次分类。图1-1 B端产品经理的工作框架
为了进一步说明，我们把B端产品经理的工作比喻成厨师准备。厨师给宴席定好上菜顺序，比如先上凉菜、再上热菜、最后上主食。上菜的顺序是工作流程。如何做凉菜、热菜或主食，就是在工作流程的每个阶段具体要做的活动。
我们来一点一点拆解，首先搭建横轴——工作流程。
搭建B端产品的工作流程是软件开发中的工作流程。一般的软件开发流程包含5个步骤：业务分析、系统设计、实现、集成和部署、[3]运行和维护。在行业标准COBIT框架中，规范了4个软件工作内[4]容：规划与组织、获取与实现、交付与支持、监控。所以，根据软件开发的一般流程，将B端产品经理的工作流程归纳为五个阶段（如图1-2所示）。图1-2 B端产品经理工作流程的5个阶段
●规划阶段：基于组织的目标和战略，获取并分析需求，规划B端产品的发展方向和路径。
●设计阶段：基于需求和规划，设计产品信息架构、原型、交互、UI方案等。
●研发阶段：根据已经设计好的产品方案，设计技术实现方案及推动产品研发。
●发布阶段：制订产品发布前的部署和培训计划，推动产品上线。
●监控阶段：监控产品上线后的效果，收集并分析用户反馈的信息，并形成新的需求。
在监控阶段，产品经理收集完反馈的信息之后，重新进入规划阶段，开始新的工作流。整个工作流是一个环形，并且紧密前进。
搭建完工作流程之后，我们来搭建工作流程中的每个层级。在这里使用《用户体验要素》已经划分好的结构：战略层>范围层>结构[5]层>框架层>表现层。由原书中提到的用户体验领域，归纳扩展为产品经理的工作层级。层级中的活动从上至下，从抽象逐渐变得具体，从概念逐渐变得实践。便于理解，我们继续用做菜举例。
●战略层：B端产品经理在这一层级的活动，主要关注的是目标。什么是目标？犹如在黑夜中的行人，发现远处的灯光，虽然不知道要经历怎样的路途，只要沿着灯光的方向前进，就不会有错。以做菜为例，产品经理要关注吃饭、饱腹的目标。
●范围层：B端产品经理关注的是实现目标的边界。比如人饿了，吃饭是目标。但吃什么？中餐？西餐？这个时候，就要界定范围和边界。有了边界才能知道什么应该做、什么不应该做。
●结构层：B端产品经理要在界定的边界内，勾画出最终输出物的大体轮廓并列出要做的事情，以及每一件事情间的关系。比如，定好了做什么菜，产品经理就要知道准备什么食材和工具。同时，也要知道其作用，比如姜用来去腥，葱用来提味。
●框架层：B端产品经理要设计出具体执行的方案和路线图。它好比房屋装修的施工设计图。比如，菜谱中的做菜顺序，按照步骤对食材进行烹饪。
●表现层：此时，B端产品经理关注的是最终的输出物——产品。这一层离用户最近。就好比在做菜的尾声，一锅香喷喷的美食即将出锅。
基于以上信息，我们将软件工程和用户体验结合在一起，形成以B端产品经理为视角的工作流。为了便于使用，起一个更正式的名字——单个产品管理流程（如图1-3所示）。图1-3 单个产品管理流程
这里列出的活动及顺序，不代表先后顺序。比如，设计产品原型方案和设计信息架构是可以同时进行的。这里区分出活动的边界，是为了让大家明确每个活动具体做的是什么。同时，不是所有活动都是B端产品经理主导的。比如研发产品，这时产品经理做得更多的是协助和跟进。列出此类活动，是为了让产品经理明确整体产品的工作流，防止整个工作过程中遗漏内容，给自己“挖坑”。
在之后的章节，笔者将详细地展开每个阶段、每个活动的具体内容。
总之，我们以产品经理的视角梳理工作流，即单个产品管理流程，大概可以知道B端产品经理做什么。知道了做什么，才知道如何做，也就是知道B端产品经理需要掌握的技能。1.4 B端产品经理的技能树
B端产品经理的技能分为硬技能和软技能。
其中，硬技能能够让B端产品经理与其他职业区分，软技能是在各个职业间无缝切换的技能。
硬技能如图1-4所示，包括以下内容。软技能如图1-5所示，包括以下内容。图1-4 产品经理的硬技能图1-5 产品经理的软技能
B端产品经理在点亮技能树的各个技能时，还要借鉴“二八原则”：真正重要的知识，或者在实践中被反复使用的知识，只占全部知识的20%。换句话说，B端产品经理要在培养自己的技能树时，着重搭建知识骨架——20%的知识。也就是说，20%的知识是固态的，是根本和基础；80%的知识是液态的，是不断更新、动态变化的。
比如，学习用户研究的技能，可以学习用户研究的基础知识，如焦点小组、用户访谈、问卷调查等，弄清楚这些知识的基本概念、应用场景和所需技术，这样就形成了技能索引。在实际的工作任务中，根据用户研究的技能索引，选择相关知识，进一步学习并快速应用。
通过对以上内容的学习，大体了解了B端产品经理的工作内容。接下来我们一起探寻B端产品经理的职业生涯。[1]《企业应用架构模式》（Patterns of Enterprise Application Ardritecture），机械工业出版社。[2]《网站设计解构》一书中提到过可重用铁三角：交互式设计框架体系、设计模式、组件。[3]COBIT框架：Control OBjective for Information and related Technology，是目前国际上通用的信息系统审计的标准，由信息系统审计与控制协会在1996年公布。这是一个在国际上公认的、权威的安全与信息技术管理和控制的标准，目前已经更新至5.0版。[4]案例出自《需求分析与系统设计（第3版）》，机械工业出版社。[5]《用户体验要素》，机械工业出版社。第2章 解惑：B端产品经理的职业生涯
人生的道路虽然漫长，但紧要处常常只有几步，特别是当人年轻的时候。没有一个人的生活道路是笔直的、没有岔道的。有些岔道口，譬如事业上的岔道口、个人生活的岔道口，你走错一步，可以影响人生的一个时期，也可以影响一生。——柳青《创业史》2.1 B端产品经理的职业发展
一般产品经理的职业发展路径是：产品专员/产品助理>产品经理>高级产品经理>产品总监。这个路径比较通用，不区分B端还是C端。在这条职业发展路径的每个阶段关注的重点不同。
产品专员/产品助理主要关注具体执行层面的协作，对产品需求的细化，以及对原型的设计和文档的整理。
产品经理主要关注推动产品迭代、产品的实现与效果、数据和业务、感知业务和产品的发展方向。
高级产品经理主要关注商业价值和模式，以及从产品的全生命周期思考问题。
产品总监主要关注战略规划、业务发展以及团队管理。
沿着这条通用的产品经理发展之路，B端产品经理在以下方面又有自己的特色。
●B端产品经理具备特有的职业知识基础
在没有明确的产品经理称谓之前，B端产品经理的工作是由需求分析师、系统架构师、行业咨询师、项目经理等角色负责。这些角色的职能并不能代表B端产品经理的职能，但是这些角色的职业知识却融入了B端产品经理的技能中，比如项目管理、软件工程的相关知识。
●B端产品经理可以成为行业专家
入门B端产品经理需要一定门槛。比如，设计公司使用的财务系统，那至少要求产品经理有会计财务知识，理解公司的财务流转。所以，进入某一领域做B端产品经理，需要具备某一领域的行业知识。因为有入行门槛，B端产品经理的职业发展容易形成护城河，即更易成为某一行业的B端产品专家。这也衍生了一个现象，B端产品经理转C端成本相对低一些，但C端产品经理转B端成
本高一些。
●B端产品经理为组织战略而服务
B端产品从设计的那一刻，就与企业经营、管理有千丝万缕的联系，可以说是企业经营与管理的延续。所以，B端产品经理的职业规划非常明确。B端产品经理的职业进阶的目标是，B端产品经理的工作成果能够直接影响组织战略。
当然，任何类型的产品经理最终是殊途同归。产品经理都是走在“发现问题，解决问题，再出现问题，再解决问题”的职业征途上。2.2 B端产品经理的入行领域
从事B端产品经理这个职业，可以从很多领域入门。说得直白点，入行领域加B端产品经理是目前需求的职位。
我们用最典型的入行领域——企业资源计划即ERP（Enterprise Resource Planning）来举例。简单地说，它是一套管理系统的总称，为了企业经营管理、生产制造提供解决方案，涉及管理企业的物流、财流、信息流。ERP包含了很多子系统，比如会计核算、生产控制管理、物流管理、采购管理、库存管理等。可以说，ERP系统占B端产品的半壁江山，提供了大量的行业知识。ERP系统提供了大量的就业职位，涉及用友、SAP等企业。
不过，随着电商及新零售的蓬勃发展， ERP系统在原有的基础上进行了扩展，并带有了互联网特色。这里就涉及卖场系统、交易系统、订单系统、库存系统、物流系统、客服系统、进销存系统等。每个系统都需要B端产品经理参与其中。这些职位与电商企业的运营管理关系密切，比如淘宝、京东等。
ERP系统和电商系统太过大而全，毕竟要照顾公司的各个方面。但是，企业的核心诉求是挣钱。于是，演化出一类专门服务于商业模式和赚钱行为的B端产品，叫作商业产品，凡是负责它的叫作商业产品经理。比如广告是常见的赚钱方式，那就需要设计投放策略、点击计费的商业产品经理。
每个行业都需要B端产品或者后台产品去管理公司业务，比如金融、教育、O2O等。
最后，还有一个特别的领域——SaaS（Software-as-a-Service，软件即服务）是B端产品经理可以入门的领域。之前只有大公司养得起的ERP等系统，如今被互联网化，中小公司以最小的成本获取服务。比较典型的公司如阿里的菜鸟，将快递服务平台化。
总之，B端产品经理的入行领域是多种多样的。2.3 产品经理是否要懂技术
这是一个关于产品经理职业生涯的经典问题！
答案很简单，产品经理需要懂技术，但是懂技术不代表会写代码。
首先明确一个产品经理做产品的三重境界，即山水境界。
第一重境界：看山是山，看水是水。产品经理不要被约束，只需大胆而专注地创新。约束因素有哪些？可能是技术、环境、组织等。
第二重境界：看山不是山，看水不是水。产品经理要看懂约束，看到边界。产品经理能明白什么可为，什么不可为。
第三重境界：看山还是山，看水还是水。此时，产品经理已经懂得创新与约束和谐共济。产品经理已经可以戴着镣铐跳出最美的舞蹈。
产品经理最终要懂得创新和约束共舞。技术作为一种约束，产品经理肯定要懂。
再者，技术并不是高不可攀的。任何一门学科或者知识都可以分为道和术。道是知识的核心。而且，大道至简，一个知识的道往往是简单易懂的，而知识的术，则是具体的应用。只有理解了道，术才能顺理成章。
学技术和我们学习任何一种技能一样，都是业精于勤。所以，产品经理需要克服畏难的思想。学技术就像学游泳一般，只有大胆入水，消除对水的恐惧，才能利用水的浮力来畅游。针对产品经理如何懂技术，有如下建议。
1.找一些软件架构或者软件工程的书看。这些书讲述的是编程中更上层的思想，如何搭建一个软件和应用。这是学习道的过程。
2.学习一门编程语言，比如C语言、HTML、CSS、JavaScript等。学习的资源有很多，比如轻松入门编程语言的《深入浅出》系列丛书。这套书几乎从零基础开始教授编程语言。这是破冰的过程，无法偷懒，无法绕开，是学习术的过程。
3.和公司的程序员交朋友。产品经理遇到了技术问题，多请教身边的程序员同事，可以解决不少问题。尝试使用程序员的工具可以拉近与他们之间的距离，比如学会用Markdown写文档。
遵从以上建议，至少能让你消除对技术的恐惧。第3章 起步：以精益思想为产品方法
简单地说，精益思想就是精益，因为它提供了以更少资源来做更多事情的方法。它令你越来越接近客户，向他们提供真正想要的东西的同时，只需花更少的人力、更少的设备、更少的时间和空间。——詹姆斯·沃麦科（James Womeack）、丹尼尔·琼斯（Daniel Jones）《精益思想》3.1 精益：看不见的角落，更要有光
先来讲一个“在看不见的角落，点亮一束光”的故事。
20世纪90年代，互联网作为朝阳行业，蓬勃发展。无数的互联网公司演绎着创业传奇，其中就包括一家丹麦的门户网站公司——卡普特。它的创始人是米克尔·斯瓦内，一位具有商科背景的小伙子，他在互联网风潮正盛之时，去美国“取经”，将互联网思维带回了丹麦并创立了卡普特，而且被一家当地报社收购了，这令他风光无限。
然而在2001年，互联网泡沫被刺破了，随之而来的是无数企业的倒闭。米克尔·斯瓦内的公司也未能幸免。这种糟糕的境遇，使他不得不为生计发愁。但是，他并没有气馁，在一家为企业客户提供客服软件和解决方案的大型公司，找到了一份负责销售及培训客户使用软件的工作。此时，米克尔·斯瓦内无心插柳地进入了B端产品行业，无意中为他再次创业开启了一扇门。
以产品经理的直觉，他发现客服行业存在很多问题。首先，企业在购买、培训使用客服软件上花费巨大，但是客服作为成本部门又处于公司的底层，往往不受重视，导致企业不愿意投入资金。即使买入了复杂的客服软件，不投入精力培训和使用，也不能发挥效力。
再者，当时整个软件行业的销售模式非常落后。企业采购软件的决策者不是真正的使用者。软件公司还要削减先进功能来降低软件采购成本，以留住决策者。最终，使用者不得不面对复杂和烦琐的软件，而不能高效工作。
最后，他发现即使按照上述流程，客服软件在一家公司落地至少需要1年的时间，对企业管理和运营极具破坏性。
问题就是痛点，痛点就是机会。米克尔·斯瓦内决定再次创业，以精益的方式创建一家只有3个人的公司，构建一个不用销售宣讲、可以自由选择功能进行购买、用户体验优良的客服产品——Zendesk。
2007年，极具颠覆性的客服产品Zendesk诞生了。它是在网上搭建的一个客服平台，简单易用，整合即时聊天、邮件、电话等多种沟通方式，可以满足各类公司的核心业务。Zendesk以传统软件价格的20%，向客户提供80%的功能。并且，它让小公司也可以使用之前高昂费用的客服产品。同时，Zendesk也不需要销售人员，任何人都可以到网站体验试用，然后再决定是否购买。
Zendesk以精益产品的优势，为Twitter、索尼等大公司提供客服[1]产品，并于2014年成功在美国上市，市值一度达到27亿美金。
精益——正如故事中所提到的那样，以最小的资源为用户提供更有价值的产品。面对资源稀缺的事实，产品经理的工作必定需要精益思想去整合资源做事情。特别是B端产品经理为企业级用户设计产品时，需要深入了解商业和企业的运行逻辑，面对复杂的需求和有限的资源，更加需要精益的思想，来设计产品为战略服务。
这本书也是希望能够使用精益思想，将20%最有价值的设计产品的方法传递，并且能够快速应用，而不是大而全的介绍。
接下来，我们就用最实用的方式介绍精益的基本理念。3.2 精益思想：打造产品经理的心智模式
产品经理就是解决问题的人，精益的思想就是解决问题的工具。
这里所提到的精益理念，并不是对精益思想的概念解释，而是将精益与实际工作相结合而总结出的经验。精益理念是一种心智模式。[2]什么是心智模式？它是人们对周围事物的一般化理解。举一个例子，精益的理念兴起于日本的汽车制造业，他们采用了准时化（JIT）零库存的生产方式，降低成本、提升质量，不断占领着美国市场。在当时，美国汽车企业固守着原有的心智模式，认为美国消费者只会关注汽车款式，而不关心成本和油耗。所以，当美国管理者参观日本工厂时，他们觉得这是一个“假”工厂，跟他们所理解的工厂是不一样的。
心智模式是理解周围事物的方式。逐渐理解和接受这种心智模式，即精益理念，有助于我们理解B端产品。至少不会让我们的心智模式成为工作中的绊脚石。大道至简，这些理念并不是长篇大论，而是寥寥数语。解决问题的终极方法都是那些朴素的大道理和常识。
但是，常识并不常用，需要产品经理在工作中不断实践，训练为一种解决问题的条件反射，形成一种属于产品经理的心智模式。
●理念1：快“天下武功，唯快不破”，这是常识。《精益创业》中的MVP思路，也强调了快的打法。为什么要快呢？
以物流领域中权衡系统成本与效率的问题为例。物流业务的核心关注点是流速、流量、存量。关于处理效率和成本的关系，主要的方法是让系统快速地运转起来，提升效率，降低成本。效率的提升是流速、流量、存量得到优化的必然结果。
快，是成本与效率关系的解决之道。
●理念2：流动产生价值
有句俗语：不怕慢，就怕停。
如果河流淤塞，就会腐臭。如果食物长期搁置，就会发霉变质。卖不出去的货物堆放在一起，就会变成呆滞库存，成为不断消耗的成本。不经常打扫的角落，会越来越脏，越脏就越不会有人想打扫。
做需求、做产品也一样，长时间没有开发需求，就慢慢变得不实用。所以，需求要定期回顾它们的价值或者重新设计。
●理念3：Keep It Simple，Stupid“简单点，傻瓜”，简称为KISS原则。
这是美国飞机设计部门的名言。当飞机设计师们为某个方案争论不休的时候，就会搬出KISS原则，采用最简单的方案。
在产品设计中，经常会同时面对各有优劣的方案而举棋不定，或者面对复杂流程的产品方案而苦恼。这个时候，选取简单的产品方案或简化产品方案，可能是产品经理做出决策的优选项。
结构简单的系统，往往是可靠的。AK-47突击步枪在世界畅销的原因是，结构简单、坚实耐用、故障率低、造价低廉、适应各种作战环境。
●理念4：处在联系中的事物，才能被简化
简化并不是减少。纯粹地砍掉功能，不是简化。飞机设计界有一句名言：“为减轻飞机每一克重量而奋斗”。飞机重量变轻了，就会油耗小、成本低。如果去掉一个极少使用的功能，那么飞机重量可以减轻，大部分人的直觉应该是同意去掉。但这个功能是飞机防止功能失效后的备用安全系统，我们真的同意减去吗？所以，处在系统中的事物，将需要简化的部分在系统中进行了转移。[3]
举一个惠普打印机的例子。惠普的打印机业务遍布世界各地，所以打印机的电源要与各国适配。但是全球打印机的销量预测不会绝对准确，导致一些国家的打印机卖断货，而一些国家的打印机滞销在仓库。因为电源的问题，打印机不能马上调拨过去，还需要费钱、费时去改装。所以，惠普公司简化生产流程，打印机在销往当地后，再到客户的公司去适配电源。虽然打印机的售后环节变得复杂，但是节约了总成本。
●理念5：不害人的需求，不是完整的需求
通过惠普公司的案例，我们可以看到将适配电源的工作转移至售后环节，实际上增加了售后工作的复杂度。
软件领域的大师Gerald M. Weinberg在《探索需求》中提到Veblen原理：无论多坏的改变，都会有一些人受益；无论多好的改变，[4]都会使一些人受损。
在实际工作中，需求的提出者，可能是需求的受益者。但是，产品经理也要关注需求的受害者。换句话说，尽可能考虑更多的角色，在一个需求中谁有获利或受到损失，哪些人被友好地对待，哪些人被不友好地对待。当然，这有可能会有无限多的角色被考虑。所以，有些角色注定要被忽略。比如，公交专用车道的设计，就要损失私家车的利益，所以在设计规则时，要多角度地考虑获益和受损失的角色。
●理念6：化散乱为规律，化应急为预测
需求相关的工作就像工厂生产，根据市场和销量来预测每天产能。比如机器生产中，急停骤动是最损坏机器的。
没有预测，就会疲于奔命，四处救火。随时应对出现的问题。学会预测，是产品经理的必备技能。
●理念7：只可图示，不可言传
产品经理使工作或需求可视化是高效沟通、避免犯错的好方法。
有句话是一图胜千言。有些需求与其写三千字的文档，不如画一个流程图说得明白。有些沟通与其大家都干站着动嘴，不如用笔和纸画出问题所在。
在设计产品中，用看板的方式去展示需求的状态，会更加直观地发现问题。将抽象的内容投射成形象的图文，会更加有助于发现问题。[5]
举一个有意思的例子（如图3-1所示），在美国关押重刑犯的监狱——“恶魔岛”，为了防止危险的罪犯偷窃厨房刀具，于是将刀具有序地悬挂出来。如果被偷，一目了然。图3-1 “恶魔岛”的厨房刀具
有句话叫：眼不见，心不烦。为了提高工作效率、防止发生失误，还是眼见烦一下为妙。
●理念8：让公路排满车，就是堵车
我们都知道满负荷工作的机器，也需要休息。
产品经理在工作中，可能会希望团队资源全负荷地满载运转。然而，我们用生活中的例子思考一下：当一条公路车很少时，会非常畅通；当车排满公路的时候，就是拥堵了。
史蒂芬·柯维所著图书《高效能人士的七个习惯》中提到，要将工作的焦点逐步转移到重要不紧急的事情上去。
总是做迫在眉睫的事情，会让人丧失目标。个人或团队都是如此，留出一些时间去思考重要不紧急的事情，而不是一直做迫在眉睫的事情。
●理念9：目标明确的战士，即使身陷重围，也会向着胜利而战斗
聚焦目标才会带来明确的结果。做产品，如果想讨好所有的用户，就会分散目标，最终做出一个平庸的产品。
二战时，太平洋海战中的瓜岛海战，日军在作战计划中制订了三个同时要完成的目标：1.消灭美军航母；2.消灭瓜岛上的美军机场；3.掩护日军登陆瓜岛。然而当时的日军航母并不占优势，完成哪一个目标都极为困难。最后，日军用瓜岛海战的失败证明了制订多重任务[6]是作茧自缚。
资源总是稀缺的。只有通过目标的聚焦，才能利用有限的资源，实现预期的效果。
●理念10：持续改进，不忘初心
做出的第一个产品方案，肯定不会是最终方案，需要不断地优化。
丰田公司制造汽车的口号是：每天提升1%。通过不断地提升质量水平和生产效率，从而实现了精益生产。
在持续优化和改善产品的过程中，也要不断回顾最初的目标，防止跑偏。
我们都知道“温水煮青蛙”的故事，换成系统论的名词叫作“目[7]标侵蚀”。就像减肥一样，最初定下目标要减去10斤。在执行的过程中，发现禁不住食物的诱惑，就把目标改为了减去8斤。接着发现每天高强度的锻炼太累，就把目标改为了减去6斤……于是，目标一步一步萎缩。
所以，在工作中，产品经理会接触到各种各样的限制，要谨记防止目标侵蚀，时常回顾自己的目标。
●理念11：细节体现专业
细节是魔鬼。对事物的不断细分，才能体现专业。
例如，在地图领域，如何体现导航产品的专业呢？可以在不同的驾驶场景下，给司机用户不同的导航方案。比如，在司机上高架桥的时候，地图导航能给出在匝道上行驶的方案；在途经多个路口时，给出路口放大图来明确行驶方向。
●理念12：不要造永动机
著名的飞机设计师——程不时曾这样谈永动机：如果你只从细节上看，这里每种设计都有一定的道理，都有其巧妙之处，但在总体[8]上却是荒唐的、错误的、不能实现的。
思考产品要从整体思考，不要只陷入细节优化。就像一支球队，如果只重视强化进攻，而忽略防守，必然会被对手抓住弱点。
●理念13：先准确，后精确
在探索需求的时候，先力求需求准确，在此基础上再精确地探索需求。那么准确和精确的区别是什么？
比如，如果问你，从家到公司大概需要多长时间？你想了想，回答大概需要30分钟。这就是一个准确的答案。如果继续问你，到底需要多长时间？你可能会回答27分26秒，这就是一个精确的答案。B端产品经理在探寻需求时，就是在探寻准确和精确的答案。产品经理需要先把握需求的准确方向，然后深入探寻正确的细节。这仿佛是射击打靶（如图3-2所示），10环是打靶的目标，如果子弹分布在10环、9环、8环，可以说是准确但不精确。但是如果把子弹全部集中射击在1环，这就出现了精确但不准确的情况，显然有些糟糕。探索需求也是如此。图3-2 准确和精确的区别[1]案例来源《创业，从一个小目标开始》，米克尔·斯瓦内著，中信出版社。[2]名词来自《系统之美》。[3]案例来自《敏捷软件开发工具——精益开发方法》，清华大学出版社，2004年2月。[4]案例来自《探索需求》，清华大学出版社，2004年7月。[5]图片来源：http://cul2.jschina.com.cn/system/2013/06/08/017579435_29.shtml。[6]资料来源《天高歌长——我的飞机设计师生涯》。[7]名词来源《系统之美》。[8]资料来源《天高歌长——我的飞机设计师生涯》。
第二部分 单个产品管理流程
在上一部分，我们一起构建了单个产品管理流程的工作路线图。
接下来，我们就一起沿着路线图去构建B端产品，去挖掘知识宝藏。
带着问题，我们踏上征程，去探索产品经理这个行业带来的无限乐趣。
B端产品经理如何将概念落地为产品？
如何拆解逻辑复杂的B端产品？
如何清晰表达出业务人员和研发人员都能看懂的需求？
如何高效输出B端产品原型？
……第4章 规划阶段：产品设计的开始
在你规划行动方案之前，一定记得先问自己：有什么事情我如果“今天”做了，可以让“明天”更好，或者至少让“明天”不会更糟。我们要从规划阶段开始设计我们的B端产品。在规划阶段，我们要开展市场调研、用户调研、产品路线规划、需求分析、需求管理等活动。这些活动分布在战略层和范围层。在规划阶段，产品经理所做的事情，将会为之后整体的B端产品设计指引方向。——安迪·格鲁夫《格鲁夫给经理人的第一课》4.1 调研市场：如何找到B端竞品
调研市场，了解行业的发展动态，最好的方式就是调研竞品。
而B端产品经理的一个痛点是很难找到竞品。B端产品不像C端那样可以从应用市场里找到竞品，或者找到大量的测评或行业文章。B端产品经理找竞品，就像特工搜集情报一样，要从各个角落搜集整理信息。
那么，B端产品经理应该如何找到竞品？可以从以下5个方面入手。
1.明确目的。想清楚你要查询的信息，定好方向再起步。
2.与业务同事沟通。B端产品的需求，大部分来自业务。业务同事基本都用过所在领域的其他家B端产品。问一问都叫什么名字，使用起来有什么特点。接下来再搜索一下，看看这些产品的官网信息。
3.了解专有名词。大部分B端产品都可以追溯到传统软件领域，这就带来了一个好处：积累了大量专业术语和专有名词，比如ERP（企业资源计划）、WMS（仓储管理系统）。通过搜索这些专有名词，可以找到一些有用的资料。
4.找到同类的SaaS产品。SaaS的兴起，带来了传统软件的行业革新。传统软件基本都可以找到替代的SaaS产品，并且这些产品基本都会提供试用渠道。尝试体验一下这些产品，会拓宽自己的思路。
5.搜索信息的渠道。百度和谷歌肯定是首选的渠道。此外，在知乎和简书也能找到一些文章思路。搜索论文也是不错的途径，比如从知网、万方等网站搜索系统又专业的信息。
以上信息，都可以帮助你完成查找竞品的工作。实际上，我们所需要的信息不是太少，而是过剩。真正需要做的是从大量的信息中甄选出有用的信息。做到这一点的有效途径之一就是倾听用户的声音。
总结：调研市场
在这个活动中，产品经理做什么？
分析产品可能存在的机会和赢利点，获取行业经验和方向。
做之前要有什么？
1.产品创意。关于你构想的产品的点子和想法。
2.行业信息。搜集到的竞品信息和行业发展状况。
有什么可以提供帮助的工具或方法？
1.商业模式画布。
2.SWOT分析。
3.竞品分析。
做完得到什么？
1.竞品分析报告。报告应该包括：行业发展状况及有哪些竞品；竞品使用者和特性的描述；自己的产品与竞品之间的比较；通过分析得到的结论和信息等。
2.商业需求文档（Business Requirements Document）。文档应该包括：产品创意产生的背景、产品或解决方案介绍、产品规划、产品成本、产品收益、产品风险等。
还有什么要关注的？
如果你刚入行，那就先忽略商业模式。重点做竞品分析，毕竟做好产品才是关键。4.2 调研用户：倾听用户的声音
B端用户有很大概率是产品经理身边的同事，所以能很方便地调研用户。用户研究的方法有很多，比如用户访谈、问卷调查、焦点小组等。不管使用哪一种方法，最重要的是随时走到用户身边，去倾听用户的声音。
在B端产品经理起身离开办公桌，开启用户调研的奇幻旅行前，首先要明确一些原则，防止误入歧途。
1.用户的话不能全信。用户可能会为了引起产品经理对问题或者需求的重视，有意无意地夸大事实；用户也可能会因为害羞或者怕说错话，而不去真实地表达自己的想法。所以，需要产品经理对收集上来的信息多加思考。当然，这谈何容易。不过，做用户调研不是找到一个迎刃而解的方案，而是提升产品成功的概率。
2.能有的功能，用户希望都能有。人的本性是贪婪的。如果能多实现功能，何乐而不为呢。此时，产品经理应该让用户对想要的功能排优先级，确定他们最看重的，或者明确一下用户可能会失去的东西，比如加载速度变慢、操作流程变得冗长，再来让其判断最想要的功能是什么。
3.明确词语含义。词语是最容易产生误解的。词语在特定的语境下，会有特定的含义。有一个笑话：一个老外问汉语老师是否考过语言等级证书，老师狡猾地说了一句：考过，没考过。如果没有中间的标点，看的人肯定是一脸困惑。再比如，用户说“我感觉报表加载更快一点”，其中“更快一点”这个词就需要进一步明确，不如让用户复现一下打开报表的过程，看看究竟是哪里出现了问题。
4.尽量不要问有固定选项的问题。列出几个选项让用户选择，即使里面没有他想要的，他也会选一个出来。所以，与其这样，不如让用户给所有选项打分：0分是不满意，10分是很满意。或者问用户：产品有哪些功能特别让你满意？
5.重述用户所说的。把用户所描述的话，用产品经理自己的语言再说一遍，让用户判断说得对不对。这样可以检验一下是否真正理解了用户所述，也让用户重新思考自己表达的准确性。
6.别让用户预测未来。最典型的是，让用户设计产品的样子。与未来相比，用户当下的行为更有准确性。而且，设计产品方案更应该是产品经理做的事情。专业的人做专业的事情。
接下来，B端产品经理就要启程上路，开启用户调研奇幻之旅。那么应该用什么方式前行呢？[1]
在《用户体验和可用性测试》一书中，提到了“师徒式（Master/Apprentice Model）访谈”，这是一个不错的思路。
师徒式访谈是让产品经理拜用户为师傅，然后师傅一边教，徒弟一边练。有不懂的地方，产品经理就马上问。得到答案并记录后，产品经理检查自己是不是真正理解了。[2]
在请教问题时，可以采用如下的三段式问法：
●发现问题：你正在做什么事情？做的过程中有什么不舒服的地方吗？遇到了什么问题？
●分析流程：你现在用什么方法来解决这个问题？
●探索机会：为了更好地解决这个问题，你认为有什么办法能帮到你？或者哪些地方可以优化一下？
所以，师徒式访谈的一般流程是：请教>刨根问底>核实。
虽然，用户研究的奇幻之旅有可能充满荆棘，不过一路征程，也不要忘记为什么要启程。始终要明确做用户调研的目的和出发点，防止被自己带偏。
总结：调研用户
试读结束[说明：试读内容隐藏了图片]