和纯银级别的大佬聊他的产品方法论

纯银和苏杰算是国内最早的一批产品经理了,他们的很多方法论、认知都是很有积累的。这篇文章,作者分享了和这一批产品的方法论认知,供大家参考。

图片

昨天和纯银级别的大佬聊他做产品的方法论。恰好最近也在看梁宁老师的《真需求》,就一起聊聊和探讨下。

他的方法论主要是五部分:

一、概念化能力

能够将复杂的问题抽丝剥茧并拆分成易于理解的概念,强调事情和任务的核心是什么?更便于沟通和决策。

你看哈,拢共三层:

  1. 所有的产品都是为「人」服务的。「人」的划分维度 —— “大明”、“小闲”和“笨笨”。基于这三类典型用户再去拆分;
  2. 帮助「人」去解决对应的「事」。「事」的划分维度 —— 依照「人」的划分,将「事」赋予到「人」身上,拆分事情的优先级;
  3. 产品最后能从有价值的「人」身上挣到「钱」。「钱」的划分维度 —— 核心业务和边缘业务得到的商业价值,结合业务目标反推有价值的「人」和「事」。

拆解产品时,从上到下一步步拆解;做业务目标时,从下到上一步步梳理。

二、找关系能力

识别不同事物、概念或数据之间的联系和相互作用。

对于产品经理来说,关系能力抓三层 —— 用户需求、业务目标、产品策略。可以划分成:“用户业务”、“输入因素”、“实施逻辑”、“输出结果”四部分。可以梳理成四句话:

  1. 将用户业务诉求基于用户画像整体成标准化和通用化的解决路径;
  2. 业务路径下每一个输入因子的关联关系,以及输入因子的数据结构是怎样的;
  3. 原产品流程的主逻辑和每一个输入因子的分支逻辑是怎么样的?影响范围又是什么?
  4. 每一个节点的输出结果的数据结构和关联模块的影响范围又是什么?

这是计算机的元规则。任何需求都可以按照这路径去梳理,输出主流程和分支逻辑流程。尤其是数据的流转路径。

最简单的方式:上游输出的内容包括哪些字段数据?哪些字段传给下游?里面的逻辑是怎么处理的?下游输出又是哪些字段?

三、搭结构能力

能够将零散的信息或元素组织成有逻辑结构,使之系统化和流程化。

首先是分层梳理,可以采用“自上而下”或“自下而上”的方法来建立分类体系。自上而下是从产品目标出发,根据功能清单和用户场景建立信息分类;自下而上则是从已有的内容和功能需求出发,逐步构建出反映产品目标和用户需求的结构。

同第一部分的“概念化能力”。

更底层的内容可以使用分层解耦的设计思路,将产品信息开发定义了用户层、内容层、表达层、业务层、数据层五个层级,各层聚焦用户体验的不同特征,彼此独立。分层迭代时不影响其他层的特征,只需要做关联即可。

继续拆一拆:

  1. 用户层 —— 负责收集用户的输入和向用户展示信息。关注信息的获取和提供直观易用的操作界面;
  2. 内容层 —— 负责管理内容和数据,包括数据的存储、检索和更新。关注更高效的处理存储数据;
  3. 表达层 —— 处理数据的展示逻辑,将内容层的数据转换成用户层可以显示的格式。关注如何将内容有效且主次的方式呈现给用户;
  4. 业务层 —— 负责实现业务逻辑,处理业务规则和流程。关注更便捷且有效的正确地帮助业务执行操作;
  5. 数据层 —— 负责与数据库或其他数据源的交互,执行数据的增删改查操作。关注更有效率且安全的访问数据。

产品经理这五层关注的优先级:业务层 > 用户层 > 表达层 > 内容层 > 数据层。

四、挖本质能力

透过现象看本质,识别问题或情况的根本原因。一定要深入理解问题,避免表面化的解决方案。

甄别问题太太太重要了。

问题是啥 —— “现状”与“目标或理想状态”的差距。可以通过一个清单来梳理(需求也可以这么来梳理):

图片

我们在沟通和求证的时候也应该从这些情况去一一分析。后才制定可行的解决方案。

五、抽象化能力

从一个个具体实例或数据中提炼出普遍适用的原则或规则。针对于产品经理来说,本质上三层抽象:

  1. 需求抽象化:能够把用户各种各样具体的、零散的需求整合并提炼为统一的、有层次的产品需求;
  2. 业务流程抽象化:对于复杂的业务场景,业务主流程和分支流程抽象,结合业务模块形成通用的流程;
  3. 产品架构抽象化:将产品的各个功能模块视为一个整体,提炼出它们之间的关系和交互模式。

前面四部分都有囊括抽象化能力。但是核心是,能否第一时间往这块想?抽象化的路径又是怎样?

这五块能力是对产品经理能力的总结,其实无外乎三个:找用户、找业务、找商业。

然后再结合《真需求》的一些思考:

图片

作者:John 微信公众号:产品狗聚集地

本文由 @John 原创发布于人人都是产品经理。未经作者许可,禁止转载

题图来自Unsplash,基于CC0协议

该文观点仅代表作者本人,人人都是产品经理平台仅提供信息存储空间服务