读书笔记-B端产品经理入门
B端产品整体建设流程
产品总体建设流程大体上分为业务问题诊断、设计解决方案（包括整体与细节方案）、执行并优化解决方案（分为设计技术方案、实施、迭代）三大阶段。
业务调研
业务调研是在产品设计之前要开展的非常重要的准备工作，在这个阶段，产品经理要全面研究并理解业务的现状和规划，挖掘并总结业务问题。
在业务调研阶段，产品经理需要尽可能地用各种手段和工具收集业务关键信息，通过对业务负责人、一线业务人员等角色进行访谈，获取全面的信息；另外，可以邀请技术负责人一起参与业务调研，确保对业务的理解是一致的。通过业务调研找到关键业务问题，这是设计产品解决方案的核心前提。
整体方案设计
整体方案设计讲究体系性、结构性。基于对业务现状与发展方向的理解，产品经理需要和架构师、技术负责人一起，规划产品的功能范围、定位，以及和公司现有产品体系如何融合，形成对后续细节设计有指导意义的整体方案，包含以下方面。
- 核心业务流程：梳理整个业务主干流程，并确定其中哪些环节需要由该产品实现线上化。
- 产品定位：明确该产品有哪些子系统，分别支持哪些业务流程和业务版块。
- 应用架构：考虑该产品和公司现有系统的融合关系。
- 功能模块：基于对业务的理解，抽象出该产品的具体功能模块。
- 演进蓝图：根据业务优先级与发展策略，制订实现各功能模块的计划和节奏。
细节方案设计
数据建模，也叫业务建模或领域建模，是细节方案设计中最重要的环节，是保证产品设计严谨可行的关键工作。只有基于对业务的理解，抽象出合理且灵活的数据模型，才能设计出有持续灵活性和扩展性的应用系统。在后续的学习中，你会慢慢理解为什么数据建模是产品细节设计成功的基石。
角色与流程设计会涉及业务团队的组织架构和岗位编制，需要产品经理与业务负责人一起讨论决定。
界面与报表是业务用户直接看到的部分，在设计时最好能提供可以体验的交互界面，让业务用户提前感受并反馈意见，减少不必要的返工。
技术方案
产品的整体方案、细节方案都设计好后，就需要技术人员做技术方案设计了，从而保证软件系统在正确的技术选型和合理的技术架构下进行编码开发工作。
项目管理与实施
B端产品往往涉及多个业务部门，需要多个业务系统的跨端配合，如何推进跨端项目？如何保证项目如期高质量交付？做好项目管理是关键：完善的项目管理机制可以保证实施环节顺利进行；相反，如果项目管理混乱，任意变更需求、扩大项目范围，就会导致项目无限延期。
运营迭代
新系统上线后，产品经理要和业务人员一起参与产品的运营迭代工作，包括宣传、推广、使用效果分析、问题和反馈意见的收集，以及持续的迭代优化。
业务调研
业务调研的流程
明确调研目标：调研目标即调研的目的，有了明确的目标，工作才能朝正确的方向开展，因此这一步非常关键。具体应该如何确定调研目标，
选取调研对象：对于B端业务调研，调研对象一般包括业务高管、业务经理、一线业务人员、合作伙伴高管、合作伙伴经理、合作伙伴一线人员等。针对高管，可以了解业务战略定位、战略目标等信息；针对经理或负责人，可以了解业务的管理思路、经营思路等信息；对于一线业务人员，可以获取作业过程、操作细节等信息。
确认调研方法：调研方法包括定性分析法和定量分析法，具体包括访谈、轮岗实习、问卷调研等方法。在实践中，需要结合具体情况选取合适的调研方法。
执行调研计划：如果前面的准备工作做得足够充分、细致，那么具体执行时就会相对顺利且有效。调研工作需要耐心，需要专注和投入，每天晚上结束后还要整理素材或资料，保证获取的所有信息都能被及时准确地记录下来。
总结归纳输出：业务调研的主要目的是掌握业务情况、诊断业务问题。调研结束后，要产出一份详细的调研报告，总结业务现状和问题，并确定各个问题的优先级，以便为后续的方案设计和实施路径提供决策支持。
业务调研的目的和分析框架
业务调研有两个重要目的，一是梳理业务现状，二是总结业务问题。业务分析框架如下图：
战略层：战略层包括业务的战略定位和战略目标。战略是公司关于生产经营活动的顶层设计，决定了公司的走向和资源的聚焦点；战略决策会对公司的经营发展甚至存亡产生影响。公司战略是管理学中很重要的研究范围，制订战略需要研究市场、经济、环境等方方面面因素。业务调研首先要明确该项业务在公司中的战略定位，因为战略定位会决定具体的经营策略，并最终影响产品方案设计。理解战略定位、战略计划，可以在产品方案设计的关键点上做出正确选择。
战术层：战术层是对战略层的认知进一步具象化的层级，可以从经营策略、管控模式两个方面开展分析。经营策略，通俗来讲就是做买卖的思路，包括客群定位、定价策略、营销策略、渠道管理策略、供应链管理策略等，这其中的每一个主题都涉及庞大的知识体系，产品经理需要扩充各个领域的知识，最好对这些版块都形成基本的认知，这会对工作的顺利开展有帮助。业务调研的目的之一是理解公司的经营策略，确保对产品的定位。管控模式是指集团对下属企业的集权、分权管理策略，也可以指总公司对分公司的运营管理策略。不同的管控模式所需的配套管理系统当然大不相同，因此这也是B端业务调研需要弄清楚的事项。
执行层：执行层包含比战术层更具体的执行策略，包括管理层和运营层两方面。
- 管理层：在明确了经营策略、管控模式等基本方针后，需要梳理组织架构关系，以便对组织架构做出优化；还需要明确人力资源计划，从管理角度保障上层策略的落地。这是业务调研的又一个目标
- 运营层：接下来就是明确具体业务流程、绩效管理、风险控制等更加细节的规则，以便在实际运营中推进上层策略的落地。其中，梳理具体业务流程[2]是理解并掌握业务的重要途径，同时也能理清楚人员、岗位、职责的关系。流程合理会让管理和运营提效、风险可控，这也是B端产品的重要业务价值之一；流程不合理，会导致成本增加、服务质量降低。还要留意一点，流程规范化是一把双刃剑，一方面可以规范管理，另一方面可能导致僵化死板，在梳理、设计互联网公司的业务流程时要把握好尺度。
业务调研的方法
业务调研的常用方法包括深度访谈、轮岗实习、调研问卷、数据分析、行业研究。
深度访谈 ：深度访谈是了解业务全貌的最快的手段。通过一对一面谈，可以直面问题，迅速获得答案。在做深度访谈时，产品经理就像一个记者，要在有限的访谈时间内，赢得访谈对象的信任、好感，获得有价值的信息。深度访谈有以下注意事项：提前准备好访谈思路、大纲、问题，选好访谈对象，想清楚通过访谈想要了解什么。如果事前没有做好准备，就好比记者采访前没有准备好提纲，必然会导致对话内容发散、混乱，无法收集到足够多的有效信息。典型的访谈大纲模板如图所示：
从高级别人员开始访谈：从高级别人员开始访谈工作，按照从概览到局部、从全局到细节的顺序研究业务，更容易把握整体调研工作的脉络和节奏。如果一开始就陷入细节的汪洋大海，会导致抓不住关键问题。
提前研究访谈对象：访谈前要从各种渠道了解访谈对象的背景，尤其针对高级别访谈对象，了解得越充分、细致越好。比如，有些访谈对象可能在项目中是利益受损方，如果提前不知道这个情况，可能会得到很多干扰信息，对决策和判断产生影响。
和访谈对象保持联系：访谈结束后，最好和访谈对象建立长期联系，尤其是一线业务人员。人和人面对面聊过后，会产生基本的信任感和好感，要借助访谈的机会，拉近和业务人员的距离。如果后续项目中遇到问题，想获取最真实的一线反馈，可以联系之前的访谈对象，寻求帮助。
轮岗实习：产品经理深入一线，直接体验一线业务人员的具体工作，这是深入了解业务的最好方法。做产品经理，最忌讳的就是凭自己的主观感觉进行设计，脱离实际。如何准确挖掘客户的真实需求？要么不断地和客户沟通、确认，要么直接和客户一起工作，看看到底遇到了什么问题。深入一线是产品经理有别于传统需求分析师的重要特征之一。如果不能深入一线，而只是被动地接受需求，产品经理的价值就会大打折扣，产品经理的成就感和积极性也会越来越弱。只有投身于一线，才能深刻地理解业务，做出正确的决策。产品经理要当一个冲在前线的人，而不是在后方拍脑袋的人。
调研问卷 ：线上的调研问卷是比较灵活的调研手段，既可以进行定性分析，也可以进行定量分析，并且很容易推广。问卷的内容设计一定要谨慎，因为一旦问卷发出，就无法修改问题了，如果辛辛苦苦收回了大量反馈，却发现当初的问题设计不合理，是多么让人崩溃的事情。设计调研问卷时要注意以下几点。
激励用户完成填写：问卷调研首先要确保能够回收足够多的、有效的反馈结果。如果问卷冗长、乏味，用户填写到一半很可能就离开了，因此要控制问卷的长度。在问卷的开头部分，最好告知问卷设计的目的、预计占用的时间，以便填写者有大概的心理预期。最好能带一些活动礼物，提高大家参与的积极性。
控制好开放式和封闭式问题：问卷中的开放式问题和封闭式问题的比例要合适。一般来讲，建议大部分使用封闭式选择题，以便获取定量分析的数据支撑。在问卷结尾可以留一到两个开放式问题，以保证调研对象可以自由表达想法。如果开放式问题超过2个，你需要谨慎地思考每个开放式问题的意义是什么，是否必须采用开放式。毕竟很少有人愿意花时间填写大段的文字。
避免诱导性问题：在问卷设计中，要避免诱导式的提问，例如“我们要做一个更好的个人管理功能，您会使用吗？”而要尽量采用中性描述，也尽量不要设置非此即彼的问题，例如“您是否喜欢我们的产品呢？”可以提供多个描述主观感受的选项供调研对象选择。注意，选项要采用平均切分主观感受的描述，例如可以采用“非常喜欢”“喜欢”“一般”“不喜欢”“非常不喜欢”这样的设计，而不能采用“非常喜欢”“较为喜欢”“一般喜欢”“喜欢”“不喜欢”这样的设计，因为后者提供的五个选项中有四个都是“积极的”回应，显然有失公正性。
*数据分析** ：调研时，有必要掌握业务的关键过程指标和结果指标。对于分销业务来说，过程指标包括新客户开户时长、订单处理时长、分拣配送时长、销售拜访量、新销售线索进量、销售线索转化率等；结果指标包括订单量、客单价、收入、成本、利润率等。产品经理要像业务经理那样关心业务运行的各项数据，这样才能了解业务现状，并进行业务诊断”
*行业研究**
研究针对业务相关领域的经典管理案例：尽管互联网创新灵活，有很多独特的业务模式，但现代企业经营管理与业务运营的本质并没有变，总可以找到模式类似的经典管理案例进行分析参考，例如供应链管理、渠道管理、定价策略，不论是理论还是实操知识，都可以在网上获取大量参考资料。
研究市面上同类业务的商业软件特点：目前市面上大多数管理软件都有可以免费试用的SaaS版本，或具备丰富的应用案例资料。
整体方案设计
核心业务流程
从核心业务流程切入产品设计，是开展整个设计工作的非常好的起点。核心业务流程代表业务的主干脉络，需要思考业务的各个参与方、涉及的系统。
产品定位
产品定位是对产品概要性的总结和陈述，简明扼要地描述产品对业务的支持范围，或总体的功能目标。产品定位要说清楚产品针对谁提供什么支持。
应用架构设计
所谓应用架构，是指公司所有产品和系统的整体结构和布局，在设计一套新系统时，必须考虑如何和公司现有系统架构融合，不同系统的模块之间如何衔接。这项工作复杂度较高，不仅需要有丰富的架构经验，而且需要深刻理解业务特点和可能的演进方向，还要熟悉公司目前的系统架构，这样才能快速提炼出相关问题。一般由产品负责人和公司的架构师甚至CTO共同讨论确定。
功能模块设计
明确了应用架构，以及需要新建或改造的系统之后，我们需要进一步细化，为每个系统设计功能模块。这个系统应用于哪些业务场景？用户可能在系统中做的操作有哪些？通过思考这些问题来抽象出需要具备的功能模块。产品经理设计的功能模块代表了其对业务本质诉求的理解和提炼，蕴含了他对业务、系统未来发展的期望。
我们常说，系统建设要有规划、有节奏，实际上功能模块图就是一幅完整的规划蓝图，能体现出系统的一二级导航菜单结构，是系统的骨架。结合业务需求实现的每一个具体功能，都是在对骨架不断地填充血肉，让它更真实、更立体、更丰富。
演进蓝图设计
通过绘制系统的功能模块图，可以明确业务和系统的规划脉络。将能想到的功能集合都列出来，这是一个做加法的过程。但是我们不可能一次实现全部功能，而要根据业务优先级，拆分成几期来完成，所以接下来需要做减法：确认产品的功能规划与实现节奏，就是常说的演进蓝图（Roadmap）。
细节方案设计
业务数据建模
业务数据建模也叫实体建模、领域建模，或业务对象建模，是指针对业务特点，归纳并设计对应的底层数据模型的过程。B端产品进行细节设计的常见流程是，首先构建业务数据模型，然后基于流程确定页面流转图，再着手每个页面的具体设计，同时提前规划好系统用户角色，最后完成权限设计。
业务调整的灵活性取决于软件系统的灵活性，而软件系统的灵活性取决于业务数据模型的可扩展性。
业务数据建模能力体现的是设计人员对客观世界的抽象描述能力，只有对业务本质理解透彻，再结合积累的软件设计经验，才能抽象并构建出合理的业务数据模型。
流程和角色
流程角色
流程合理、角色清晰是系统正确设计的前提和保障。遵循自顶向下的设计思路，我们首先设计主干流程，在这个过程中可以进一步明确系统角色及业务岗位的安排，然后基于主干流程图设计页面流转图，最终完成页面细节设计。
通过跨职能分系统流程图，可以清晰地看出谁（操作角色）在哪儿（哪个系统）做什么（完成什么工作）。无论是大型系统设计，还是某个具体需求的设计，都应该绘制流程图来帮助自己梳理业务、理清思路。
页面流转
梳理完业务流程和角色，我们进行下一步的页面流转图设计。对于系统设计来讲，业务流程图依然属于比较粗粒度的概要性设计，如何将它与软件产品的页面设计对应起来呢？绘制页面流转图是一个很好的衔接方式。
页面流转图描述的是，用户完成某项工作需要访问的页面及页面跳转顺序。绘制页面流转图可以帮设计人员审视、思考系统中的页面设计方案，包括系统中总共需要哪些页面，哪些页面可以重复使用，哪些页面需要定制化开发。一般来讲，我们绘制页面流转图时，都是针对某个单一角色绘制某个特定场景下的页面访问和跳转逻辑，从用户的视角来梳理一遍所有相关页面，每到一个新页面时，都要思考：需要新做一个页面，还是可以复用原有页面？最终整理出系统涉及的所有页面的初稿。
界面设计
在团队分工明确、人力储备充足的情况下，在开发一套全新的B端业务系统时，界面设计的流程一般如下：
产品经理绘制线框图原型，表达软件中每个页面的设计需求。
UE设计师协助产品经理完善交互体验，并制作交互原型。
UI设计师基于交互原型进行美工设计，生成切图文件。
前端工程师拿到切图文件，进行前端开发，包括实现交互、动效等
尼尔森十大可用性原则
交互设计领域有丰富的理论沉淀，最著名和经典的理论当属人机交互大师雅各布·尼尔森（Jakob Nielsen）博士在1995提出的尼尔森十大可用性原则（ Jakob Nielsen’s Ten Usability Heuristics ），该理论是针对PC端交互设计提出的，但同时也适用于移动端交互设计。我们将结合具体案例详细阐述这十条指导原则，产品经理在绘制线框图时要注意遵循这些原则。
反馈原则（Visibility of system status）
系统应该在合理的时间、用正确的方式，向用户提示或反馈目前系统在做什么、发生了什么。人机交互的基本原则是，让系统和用户之间保持良好的沟通和信息传递。系统要告知用户发生了什么，预期是什么，如果系统不能及时向用户反馈合适的信息，用户必然会感到失控和焦虑，不知道下一步要做什么。以下是遵循反馈原则的一些常见设计案例：
安装程序时显示进度条，并预估还需要多久结束。
上传文件时显示进度条，并提示预估剩余时间。
提交表单时，如果校验失败，则在填写有误的内容旁边提示错误原因。
程序未响应时，系统会让用户选择是关闭程序还是等待程序响应
隐喻原则（Match between system and the real world）
系统要采用用户熟悉的语句、短语、符号来表达意思。遵循真实世界的认知、习惯，让信息的呈现更加自然，易于辨识和接受。在人机交互设计中，程序的沟通和表达、功能的呈现，都要用最自然的、用户容易理解的方式，避免采用计算机程序语言的表达方式。设计时要采用符合真实世界认知的方式，让用户通过联想、类比等方法轻松地理解程序想表达的含义。
回退原则（User control and freedom）
用户经常会不小心操作错误，需要有一个简单的功能，让程序迅速恢复到错误发生之前的状态。用户误操作的概率极高。对于误操作，软件系统应该尽量提供“撤销”“重做”或“反悔”的功能，让系统迅速返回错误发生之前的状态。当然，不是所有操作都是可以“反悔”的，比如，你可以撤销一笔错误的订单，但不能撤销一笔成功的转账交易。以下是遵循回退原则的常见设计案例：
- 编辑类软件都提供撤销功能，例如Word、美图秀秀等
- 点击删除或关闭按钮后，会让用户进行二次确认
- 电商平台允许在一定的规则下取消订单
一致原则（Consistency and standards）
同样的情景、环境下，用户进行相同的操作，结果应该一致；系统或平台的风格、体验也应该保持一致。软件设计、产品设计中有很多约定俗成的规范，虽然没有明文规定，但大家都在遵守，因为用户已经习惯了这些规范。我们在进行设计时，应该遵循惯例，并且保持系统的一致感，不要盲目地标新立异。
防错原则（Error prevention）
系统要避免错误发生，这好过出错后再给提示。进行设计时，首先要考虑如何避免错误发生，其次再考虑如何检查、校验异常。这样做一方面可以让问题更简单，另一方面可以让用户避免或减少无谓操作。
记忆原则（Recognition rather than recall）
让系统的相关信息在需要的时候显示出来，减轻用户的记忆负担。计算机应该减轻人们的记忆负担，而不是相反。例如，当切换页面时，不应该让用户记住不同页面的内容，而应该在合适的地方积极地呈现或提示之前的信息。例如，几乎所有的App和PC端的搜索引擎都会记录用户的搜索历史并呈现给用户。
灵活易用原则（Flexibility and efficiency of use）
系统的用户中，中级用户往往最多，初级和高级用户相对较少。系统应为大多数人设计，同时兼顾少数人的需求，做到灵活易用。灵活易用原则不仅是一个交互设计原则，也代表了一种软件产品设计理念：系统既要做得简单、易用，让所有中级用户用起来得心应手；也要提供必要的帮助，让刚入门的初级用户顺利上手；还需要支持灵活的个性化定制，让高级用户能够以进阶的方式使用系统，充分发挥其价值。让高级用户灵活定制的最典型的例子是各类软件和App的配置功能，基本上所有软件都会提供定制化功能，从快捷键设置，到页面布局，再到自定义参数，软件系统会尽量提供全面的个性化设置功能，来满足不同用户的使用诉求和习惯。
简约设计原则（Aesthetic and minimalist design）
对话中不应该包含无关的或没必要的信息；增加或强化一些信息就意味着弱化另一些信息。
容错原则（Help users recognize， diagnose， and recover from errors）
错误信息应该用通俗易懂的语言说明，而不是只向用户提示错误代码；提示错误信息时要给出解决建议。对于很多运行时错误或异常，计算机程序都会返回某个错误代码，但是对于用户来讲，看到这些错误代码并不明白发生了什么，所以一定要将错误代码转换成用户能看懂的语句，并告诉用户解决的建议。
帮助原则（Help and documentation）
对于一个设计良好的系统，用户往往不需要经过培训就能轻松上手使用，但是提供帮助文档依然是很有必要的。帮助信息应该易于检索，通过明确的步骤引导用户解决问题，并且不能太复杂。现在的软件产品，尤其是C端产品普遍做了良好的交互设计，可以帮助用户快速学习使用，而不用阅读、理解复杂的说明文档。然而，B端产品的复杂性比C端产品高很多，因为B端产品蕴含很多业务流程的规则，系统中的一个按钮可能代表了一个复杂的业务处理规则，如果不了解整个业务场景和处理规则，是很难理解按钮的操作含义的。因此，对于B端产品，用户进行自助服务、自助操作的难度高很多，B端产品的帮助文档依然有存在的必要。产品设计人员要尽量在前端交互上做好引导提示，对于复杂的规则和逻辑，可以考虑通过帮助文档来指导用户。”
报表设计
构建分析体系
之所以设计报表，往往是因为需要针对某个业务主题或业务诉求进行监控和分析。
构建分析体系之前，首先要明确分析目的，即需要通过分析发现哪些方面的问题；然后思考该采用什么方法来识别、诊断这些问题，其中可能的困难是什么。构建分析体系必须建立在对业务的深刻、准确理解之上，并且要和一线管理团队多沟通，可能很多问题的分析框架和思路已经被一线工作者发现并有效实践了，一定要善于发掘并参考、借鉴。
定义观察指标
理清了分析框架和思路，下一步要确定观察指标，设计具备明确业务含义的指标来考量业务。一般会先从大的方面拆分出几方面的观察指标，然后考虑是否将指标进一步拆解为二级指标，甚至三级指标，从而在更精细的维度观察、分析业务，更准确地反映业务特征。
设计呈现形式
确定了观察指标后，我们要思考以什么形式呈现这些指标，以便用户能够准确、快速地理解、掌握指标以及变化特征。例如，是采用数据表格还是柱状图呢？
跟踪指标变化
管理要用数据说话，报表数据就是诊断和决策的依据。管理人员要认真对待、分析报表中各种数字的变化、波动。如果只是走马观花地浏览报表，看不出任何问题，报表就失去了意义。作为一名管理人员，必须对数字非常敏感，能够快速地感知并解读数字背后的变化和问题，这是出色的管理人员必须具备的素质。如果指标发生了明显的波动，需要跟进分析波动的原因，分析工作可以由数据分析师完成。
跟进处理问题
分析出问题后，下一步当然是给相关部门或人员安排工作，解决问题，这也是报表设计的初衷。
权限设计
软件系统的权限包含两部分：
功能权限，指各个角色可以操作的界面、按钮等，例如管理员可以进行新增、删除、修改等操作；运营人员在同样的页面上只能使用各种筛选条件查看数据，无法做更改。
数据权限，指各个角色在各页面中能看到的数据范围，例如分公司管理员在订单查询页能看到分公司的所有订单，而区域主管在订单查询页只能看到所在区域的订单。
关于完整的功能权限设计，最经典的理论是1995年由计算机科学家Ravi Sandhu提出的RBAC（Role Based Access Control）模型，描述了一套用户、角色、权限组的设计理念，在业务系统设计中被广泛采用。如果产品经理需要设计功能权限管理系统或模块，就必须理解RBAC权限管理模型。
完整的RBAC模型理论称为RBAC96模型族，该模型对角色的继承关系、权限的约束关系等更复杂的话题进行了深入分析和指导。RBAC96是对计算机系统权限管理的高度抽象模型，适用于任何业务系统。如果对权限管理的理论有兴趣，可以继续深入研究RBAC96体系。
角色在页面中能查到的数据范围，叫该角色的数据权限。所谓能查到的数据范围，不是指能看到的数据字段，而是指能查出来的数据集合。例如，针对订单列表页，数据范围可能是某个城市的所有订单，也有可能是某个账户下的所有订单，也可能是某几个账户下的所有订单。
针对数据权限的控制，常见的实现方案如下。
方案一，通过组织机构树控制。该方案根据账号所在组织机构树中的节点位置，来判断能够查询的数据范围。这种方式最复杂，但最灵活，能够支持各种复杂的业务数据权限诉求。
方案二，通过客户地区控制。该方案根据账号所在区域来判断允许查看的数据范围。这种方式简单、容易实现，但灵活性差，只能满足非常初级的数据权限管理诉求。
文档
产品设计工作会涉及一些文档，主要包括BRD（Business Requirement Document，商业需求文档）、PRD（Product Requirement Document，产品需求文档）和MRD（Market Requirement Document，市场需求文档），三者的编写时间、受众、编写目的和重点各不相同
商业需求文档（**BRD**）的管理
在产品设计工作中，无论是研发还是产品经理，都喜欢“好需求”，所谓好需求，是指具备业务价值的需求。好需求都来自业务真实的痛点或问题，经过产品设计、开发实现后，能够帮助业务解决实际问题，带来收益和价值。
产品设计的好坏，首先取决于需求的质量。如果需求质量不高，产品设计再用心，也难以产生价值。实际上，很多需求都只是需求提出者的灵光一闪的想法，并没有经过严谨的思考。对于B端产品，尤其是业务系统，业务方一般都有需求管理团队，负责调研、整理业务需求，提交给产品经理。产品经理首先需要对需求进行判断，如果发现需求质量不高，就需要和业务方反复讨论，判断需求的真实性。
如果没有一些机制或手段，让需求提交者经过全面思考后再提交需求，则可能会造成需求泛滥，需求质量低下，进而导致产品经理需要耗费很多精力去鉴别这些需求的真实性和价值。要求需求管理团队以正式BRD的形式提交需求，可以在一定程度上提高需求的质量，并且可以作为正式备档文件留存，帮助项目组提高协作效率。
产品需求文档（**PRD**）的编写
在互联网公司，产品需求文档（PRD）由产品经理编写。不同公司、团队、项目组对PRD的要求不同，有的比较严格，有的比较宽松，甚至在有些创业团队中根本不需要PRD，在产品经理和研发人员的沟通讨论过程中，功能就开发好了。但是，随着公司规模扩大，规范的PRD管理是非常必要的，这可以让项目开展更加有序，大大方便产品经理和研发人员的沟通，让知识传播与传承更加准确有效。
编写PRD是产品经理需要掌握的一项基本功，产品经理需要在PRD中用清晰、通俗的文字将复杂、抽象的软件设计思路和方案描述清楚。
产品迭代优化
需求管理
B端产品的需求来源十分广泛，包括一线用户、产品运营人员、业务运营人员、业务领导等的反馈，需求内容也非常丰富，包括交互体验优化、业务调整要求、业务管理要求等，而能采集需求的手段也丰富多样，包括一对一面谈、问卷调研、轮岗实习，等等。
需求收集的要点之一是，通过各种渠道全面、迅速地收集建议，而且，无论是否采纳，都要给出反馈，例如意见是否采纳、预期的解决时间等，这样才能形成持续的良性互动。
收集到需求后，产品经理不应该简单被动地接受、执行，而要识别需求背后的真实问题、判断需求的价值，这很考验产品经理的判断能力。在日常工作中，产品经理要勤于思考，尽可能地理解业务，以提升自己的判断能力。面对需求时，产品经理可以思考以下问题，帮助自己准确、迅速地判断需求的价值：
- 这个需求背后的真正问题是什么？
- 这个问题是否有简单快速的解法？
- 这个问题的影响面有多大？如果只是个案，是否值得投入精力去研究解决？
- 如果是共性问题，优先级和紧急程度如何？
对于收集到的需求，经过初步判断、过滤后，要放入需求池进行管理跟进。
从记录在案开始，到实施上线，需求要经历完整的研发管理周期。可以通过一套项目管理软件（例如JIRA、Teambition）对需求进行管理，按照公司统一的项目管理规范来实现。如果公司对项目管理的过程没有明确的规范，或者缺少工具支撑，也可以通过Excel文件来进行需求管理。
对于需求池和迭代计划，可以对它们分开管理维护，也可以合并在一起管理维护，需要根据公司的现状和要求灵活处理。不论是合并管理还是分开管理，主要目的都是实现清晰准确的需求管理、迭代计划管理，并做到项目进度透明。
通过需求池统一评判需求优先级，管理并安排迭代计划，是产品经理最重要的日常工作之一。合理运用上述模板，可以帮助产品经理将需求和项目管理得井井有条。认真填写模板中的各项内容，可以帮自己较好地分析需求跟进情况、研发效率、工作量投入等。
如果某个需求涉及跨端或跨团队开发，则需要按照子项目将模板进一步细化，例如每个子项目要安排各自的研发负责人、产品负责人，有各自的工时、工期等，然后再填写具体字段。
所谓双周迭代，即两周完成一个迭代周期，其中，一个迭代周期是指从软件开发到上线的时间。图10-2通过甘特图的形式描述了包括两轮迭代（迭代1和迭代2）的双周迭代运作过程，其中W代表周，W1代表第1周；D代表天，D1代表第1天，以此类推。浅灰色背景是迭代1的准备阶段及执行过程，深灰色背景是迭代2的准备阶段及执行过程。
一个典型的双周迭代过程如下：
1.挑选需求并编写PRD（W1D1～W2D4）
在迭代1的开发工作启动之前，产品经理（在Scrum中叫PO，Product Owner）首先要从需求池（需求池在Scrum中叫Product Backlog，具体的需求项叫PBI，Product Backlog Item）中挑选需求，这需要产品经理和研发负责人一起沟通，根据需求复杂度和研发产能来挑选最需要满足的需求。然后，针对所选需求设计方案并编写PRD。
2.评审（W2D5）
PRD编写完成后，进入迭代1启动前的评审环节，评审环节要和需求方再次确认设计方案，并且给研发人员讲解产品设计方案，评审时，可以对需求范围再次进行讨论和调整。在Scrum中，评审工作叫Sprint Planning，进入迭代计划的需求清单叫Sprint Backlog。
3.技术方案设计（W2D5～W3D1）
评审结束后，研发人员要根据PRD进行技术方案设计，有的技术方案可能需要讨论几天才能确定下来。同时，产品经理开始做迭代2的准备工作。
4.开发实施与测试（W3D2～W4D4）
技术方案确定后，正式进入迭代1的开发和测试环节，对于研发人员来说，这是最紧张的阶段，这一阶段在Scrum中叫Sprint（冲刺）。在这个阶段，产品经理和研发团队每天都要召开简短的站会（Scrum中的Daily Scrum），以同步信息，并快速澄清疑问、进行决策。
5.上线（W4D5）
集中上线是一种提升研发效率和运维效率的好方法。所谓集中上线，是指将一系列功能点打包并一次性上线，而不是每做完一个功能点就进行一次上线。迭代1的功能上线的这天，正好是迭代2的评审日，研发人员可能白天要进行迭代2的评审工作，晚上要配合运维人员上线迭代1的功能。同时产品经理最好和QA一起做线上功能验收，集中打包上线的交付物（在Scrum中叫Potentially Releasable Increment，即在一个Sprint中完成的产品增量）。在上线之前，Scrum中还会有Sprint Review Meeting，产品经理和研发人员一起再次核对功能开发情况。一个迭代结束后，Scrum流程中还有Sprint Retrospective，对迭代进行总结。
以上是常见的双周迭代的产品开发流程，在研发人员开发一个迭代的功能时，产品经理开始下一个迭代的功能设计，工作交替进行，这样能保证设计工作和开发工作无缝衔接，在一个合理的时间周期内快速实现软件产品的升级迭代。
读书笔记-B端产品经理入门