和纯银级别的大佬聊他的产品方法论
昨天和纯银级别的大佬聊他做产品的方法论。恰好最近也在看梁宁老师的《真需求》，就一起聊聊和探讨下。
他的方法论主要是五部分：
一、概念化能力
能够将复杂的问题抽丝剥茧并拆分成易于理解的概念，强调事情和任务的核心是什么？更便于沟通和决策。
你看哈，拢共三层：
- 所有的产品都是为「人」服务的。「人」的划分维度 —— “大明”、“小闲”和“笨笨”。基于这三类典型用户再去拆分；
- 帮助「人」去解决对应的「事」。「事」的划分维度 —— 依照「人」的划分，将「事」赋予到「人」身上，拆分事情的优先级；
- 产品最后能从有价值的「人」身上挣到「钱」。「钱」的划分维度 —— 核心业务和边缘业务得到的商业价值，结合业务目标反推有价值的「人」和「事」。
拆解产品时，从上到下一步步拆解；做业务目标时，从下到上一步步梳理。
二、找关系能力
识别不同事物、概念或数据之间的联系和相互作用。
对于产品经理来说，关系能力抓三层 —— 用户需求、业务目标、产品策略。可以划分成：“用户业务”、“输入因素”、“实施逻辑”、“输出结果”四部分。可以梳理成四句话：
- 将用户业务诉求基于用户画像整体成标准化和通用化的解决路径；
- 业务路径下每一个输入因子的关联关系，以及输入因子的数据结构是怎样的；
- 原产品流程的主逻辑和每一个输入因子的分支逻辑是怎么样的？影响范围又是什么？
- 每一个节点的输出结果的数据结构和关联模块的影响范围又是什么？
这是计算机的元规则。任何需求都可以按照这路径去梳理，输出主流程和分支逻辑流程。尤其是数据的流转路径。
最简单的方式：上游输出的内容包括哪些字段数据？哪些字段传给下游？里面的逻辑是怎么处理的？下游输出又是哪些字段？
三、搭结构能力
能够将零散的信息或元素组织成有逻辑结构，使之系统化和流程化。
首先是分层梳理，可以采用“自上而下”或“自下而上”的方法来建立分类体系。自上而下是从产品目标出发，根据功能清单和用户场景建立信息分类；自下而上则是从已有的内容和功能需求出发，逐步构建出反映产品目标和用户需求的结构。
同第一部分的“概念化能力”。
更底层的内容可以使用分层解耦的设计思路，将产品信息开发定义了用户层、内容层、表达层、业务层、数据层五个层级，各层聚焦用户体验的不同特征，彼此独立。分层迭代时不影响其他层的特征，只需要做关联即可。
继续拆一拆：
- 用户层 —— 负责收集用户的输入和向用户展示信息。关注信息的获取和提供直观易用的操作界面；
- 内容层 —— 负责管理内容和数据，包括数据的存储、检索和更新。关注更高效的处理存储数据；
- 表达层 —— 处理数据的展示逻辑，将内容层的数据转换成用户层可以显示的格式。关注如何将内容有效且主次的方式呈现给用户；
- 业务层 —— 负责实现业务逻辑，处理业务规则和流程。关注更便捷且有效的正确地帮助业务执行操作；
- 数据层 —— 负责与数据库或其他数据源的交互，执行数据的增删改查操作。关注更有效率且安全的访问数据。
产品经理这五层关注的优先级：业务层 ＞ 用户层 ＞ 表达层 ＞ 内容层 ＞ 数据层。
四、挖本质能力
透过现象看本质，识别问题或情况的根本原因。一定要深入理解问题，避免表面化的解决方案。
甄别问题太太太重要了。
问题是啥 —— “现状”与“目标或理想状态”的差距。可以通过一个清单来梳理（需求也可以这么来梳理）：
我们在沟通和求证的时候也应该从这些情况去一一分析。后才制定可行的解决方案。
五、抽象化能力
从一个个具体实例或数据中提炼出普遍适用的原则或规则。针对于产品经理来说，本质上三层抽象：
- 需求抽象化：能够把用户各种各样具体的、零散的需求整合并提炼为统一的、有层次的产品需求；
- 业务流程抽象化：对于复杂的业务场景，业务主流程和分支流程抽象，结合业务模块形成通用的流程；
- 产品架构抽象化：将产品的各个功能模块视为一个整体，提炼出它们之间的关系和交互模式。
前面四部分都有囊括抽象化能力。但是核心是，能否第一时间往这块想？抽象化的路径又是怎样？
这五块能力是对产品经理能力的总结，其实无外乎三个：找用户、找业务、找商业。
然后再结合《真需求》的一些思考：
微信公众号：产品狗聚集地
版权声明
本文来自互联网用户投稿，文章观点仅代表作者本人，不代表本站立场。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如若转载，请注明出处。如若内容有涉嫌抄袭侵权/违法违规/事实不符，请点击 举报 进行投诉反馈！
