我们谈产品架构、画图示、写文档，归根结底的价值，在于表达对“需求—>功能—>扩展”等方面的深度理解，并传达其他人。否则，一切只是流于形式。反过来，也不必拘泥于形式。本文将产品经理工作过程进行拆解，洞悉“好的产品经理”如何把工作落地。问起产品体验要素，很多人脱口而出：战略层、范围层、结构层、框架层，表现层。
战略层对应产品目标、用户需求。是对目标，需求的商业化方案的归纳。
范围层对应产品的信息和功能点，涉及到产品的侧重点和取舍。
结构层对应产品的实际落地，产品在这个层面开始具体化。
框架层对应产品具体内容的呈现，产品进一步具体化，落实到界面。
表现层对应产品的视觉传达，是产品的美化。
曾面试一个产品经理：怎么理解“产品架构”？他回答的也是这五层。似乎Jesse James Garrett老爷子的这十个字就是产品经理的B格句子。很明显，这个五层压根没跑出一个产品的设计范畴。而冰山80%的内容是表现层看不到的。特别是后端产品经理的思维格局核心，绝对不是在这五个层面。
如果我们也将产品经理的工作重心分个层次，我认为产品经理的工作（尤其是泛后台、中台、B端产品）是四层：业务层（抽象业务诉求）
功能层（界定功能定义）
数据层（设计数据结构）
实现层（探讨实现机制）
这四项几乎包含了整个产品方案诞生的全部。其中前两项是产品经理担责任，后两项技术人员担责任。作为团队“布道者”和产品“owner”的产品经理，要做好一个大系统，四项缺一不可。因为你真正掌握了业务足够的素材，修复运营（或用户）反馈的场景的闭环；又洞察到如何调度内部结构和未来扩展，弥补着技术人员对需求洞察的边界；“兵者，国之大事，死生之地，存亡之道，不可不察也。”
同理，调研需求，是获得立题的基础。分析需求，是脱胎出产品雏形的依据。
因为我们看到的用户行为是杂乱的，用户的需求也是无序的。这时候进行归类和穷举，再提炼并抽象出用户的需求模型。
需求分析有三种方式：面向故事、面向对象、面向结构。用户故事就是“谁，做啥，价值”，也就是“作为谁，我想做什么，以实现什么”。也就是角色的抽象、需求的抽象、目标的抽象。在此基础上结合场景，即在什么场景下，谁，做啥，实现啥价值。形成故事矩阵。故事矩阵的穷举，把用户故事组织成用户故事地图，并输出技术场景下的需求定义：领域模型。
领域模型，是对领域内的概念类或现实世界中对象的可视化表示。是对业务角色和业务实体之间应该如何联系和协作以执行业务的一种抽象。
2. 从提取出来的名词中总结业务实体，区分名词中的属性、角色、实体、实例，形成问题域中操作实体的集合;3. 从业务实体集合中抽象业务模型，建立问题域的概念(例如，我们把容易变质的水果称之为"短期保持水果");4. 用UML提供的方法和图例进行领域模型设计、确定模型之间的关系;
领域模型设计是需求分析的关键步骤。它帮助用户及需求分析人员建立业务概念，确定用户业务的问题域，系统涉及的业务范围等等，为功能的脱胎提供依据支持。
有了业务场景和诉求，就可以把这些诉求转化为以产品为载体的功能。也就是从用例模型，向功能模型的转化。通过触发，响应式实现目的，连接用户层和功能层。需求是靶点，功能是箭。有时候需求范围很大，就很难命中痛点。同样，功能常常也有局限性。举个例子：在O2O电商平台，商户有700家门店，每个门店1万种商品。组合成700万门店*商品的矩阵数据。那么，批量上下架很难全部一次执行。就算执行完毕，也要预防用户无意识地反复操作。这会给服务器带来“潜在风险”。在后端产品设计中，有一句话：“不能让用户用着太舒服”。是不是与“别让我想、别让我等、别让我烦”相悖呢？其实都是相对的。
过于舒服的操作，用户感受不到背后的复杂逻辑。轻轻点击一个按钮，服务器要承载多大的压力。后端产品数据量可能瞬间暴增到极点。基于这种思维，对于案例中的功能，通常有四种方案：功能替代、交互补偿、组合功能、降维处理。即：全量商品上下架时，系统要求必须是单门店。等做好一个门店的时候，其余门店可以复制这个门店的商品的上下架状态。
这个方案从后台处理量来说，和直接支持全门店全商品差不多，但是操作的“复杂”，会减少用户频次，起到一定避灾作用。
我们发现在定义功能之前往往是多套功能方案，筛选比对后的取舍结果。需要注意的是，功能模型需要结合到产品模型中去。也就是尽量做成通用的轮子。将弱逻辑并入到强逻辑中，尽量不要为弱逻辑关系制造岔路。随后，进一步是将产品或功能落地为DEMO，这个是我们最熟悉的画原型，这个环节对应的是框架层和表现层。同时要明确，功能是有边界的。避免坠入需求蔓延或镀金之路。数据就像血液，我们要搭建起来血管系统，定义出数据运行的秩序，也就是数据关系结构。需要说明，到这里不是产品经理负责的，我们只是从业务层面，将实体映射为数据结构。为开发提供清晰的表达。我们把功能中的名词拿出来，也就是事物实体，根据该事物可能用到的属性，构建E-R模型。我们只需要知道第一范式，就可以从业务角度界定出需要多少数据表。具体可以参考书籍《后端产品经理宝典》，或另一篇文章：数据库是接近技术世界的窗口之所以要参与数据，是因为我们发现，当开发人员面对功能的时候，常常是不见森林的，他们要把许多功能碎片串联起来，才能构建一个完整的数据体系。而反过来，产品经理在搭建产品模型的时候，就同时在考虑数据的复用、数据的流转、数据唯一性等。当我们列出数据清单的时候，对开发不仅是提示，更是一种检查清单，同时也是一种数据结构式的需求传达方式。举例：下图左侧向下，是正常的流程图；右侧是用到的数据的结构。配合使用就能很清楚看到数据的流向、使用逻辑。
我们需要知道数据表的维度。比如发货这件事，以订单维度最合适。但是存在一个订单多个商品，多个包裹的情况。与此同时，唯一键就出现了。他是为了标示数据的唯一性：在业务中，遇到重复的，可以进行一些处理措施。在定义类似场景的时候，一定要定义出什么算是“重复数据”。比如这样：
这一点就简单了，比如：人的年龄是数字，范围不会超过200；员工是否在职是布尔型的，不可能出现空，只会是是或否。需注意：数据表重点约束与前端的约束可以不同。也就是数据库可能支持很多个字，但是前端为了保证整齐度，只让输入4个字等。
对一个功能来说，你看得到的静态页面，实现机制变数不大。能做的无非是想法减少HTTP请求数、压缩网页元素、样式表放在网页head部分、JS文件放到网页底部等。这些看前端的水准了。功能实现机制更多的心思是后端方案。而后端方案最终是考虑数据的运行。
把数据比作为血管，那么实现机制就考虑如何触发心脏跳动勃血等。这时候考虑数据变更的触发因素、数据的流转机制、过滤机制、异常机制、复用性等。有时候触发的机制是双向的。比如，在B2C业务中，每次有仓库库存变化，都要查询发货仓库配置关系，然后计算出各仓可供应的汇总库存。同时，我们应该想到，若发货仓库配置关系变更，也应该通知重新计算库存（因为总库存是要展示在商城端的）。那么这样就要做两套接口，一套是：商品库存后台，请求仓库，一套是仓库请求商品库存后台。但实际还可以有一种方案，只做一个公共的触发重新计算库存的服务，配置接口，仓库和商品中心满足触发条件的情况下，各自调用。再看一个例子：
想象一个对码功能：检测平台销售的商品编码，在ERP能查到，查到即为对码成功。以确保能正常发货。
触发条件：创建平台后台的商品的时候、手动点击对码的时候、从平台下载商品的时候，挺多的。
那么就可以把这个对码服务做成通用的插件，供多处调用。
这些可以被共同调用的，可视为中间件，将其用模型化的通用的轮子。当技术架构是这种架构的时候，就可算微服务架构。
在微服务架构中，每个服务都是自我包含的，并且实现了单一的业务功能。
到这里需要明确，我们不是指导开发写代码建数据表，甚至也不是干涉。而是基于业务提出的业务视角的技术设计建议。最终以开发的为准。
我们也只需知道技术的原理即可。
产品经理能整理出检查清单，并辅助开发人员同步跟进，会让开发轻松，整个项目的质量会得到很大提升。不会导致产品经理像听天书一样陪衬，同时也会增强自己在团队的信任度。总结：作为产品经理，是否全栈、是否或切图等都是次要的，首要是作为布道者把事情理清楚，以产品思维，做产品经理的本质工作，确保产品环节的质量落地到实处。
