产品经理如何打造自己的产品方法论?

7 评论 9674 浏览 80 收藏 13 分钟

 当产品经理积累大量实战经验与岗位认知后,学会从中总结方法论与心得能够帮助我们高速成长。那么具体要怎么做呢?过程中有哪些要点要掌握呢?笔者将结合这些点梳理如何打造产品方法论。

28岁岁末的时候,立了个flag,希望在30岁时,能形成自己的产品方法论,如今而立已过,开始做数据产品相关工作也近有五年;这五年来,因为人生轨迹的跳跃,产品本身所在的行业并不固定。好在产品逻辑本身可以触类旁通,加之无论行业如何,自己的兴趣和做的事情,都是数据产品本身。

行业上走过了电商O2O、在线教育、智能硬件、金融风控,产品范围也从之前的数据分析产品跨度到了数据服务、数据应用产品。

外人看来只见其宽,而自己而言,实际一直在数据产品的领域耕耘沉淀。

遂尝试着整理过往的思考和笔记,算是自己的成长,也是不成熟的分享。

01 建立自己理解业务的方法模型

理解业务是理解需求的大前提,所谓理解业务,往大了说是理解公司的商业模式,往小了说是理解产品的具体应用场景。事实上,即使是相同行业的不同公司,业务模型也是千差万别;掌握一套理解业务的方法论,能够使我们的产品之路不局限于行业和平台,快速向新的领域拓展自己的产品力,能够使我们快速的理解新平台的需求场景,更好的推进产品实施;

就实践而言,当我们接手一个新的产品之后,可以分以下步骤去了解业务,以及负责产品对业务的意义:

1. 与业务核心KP沟通,了解业务流程,并自己绘制一个业务流程图,明确以下信息

  • 整个业务分几个环节、步骤?
  • 每个步骤的具体内容是什么?
  • 每个步骤之间的依赖关系?

2. 梳理业务业务流程图后,对着业务流程图,我们要知悉并思考以下信息

  • 业务各步骤涉及的人员、应用系统都有哪些?
  • 我们负责的产品处于哪个步骤,涉及人员有哪些,解决的核心问题是什么?

这个时候,我们基本已经定位了自己产品所处的位置,以及产品解决的问题,那么就可以通过具体了解该环节产品涉及人员的具体操作流程,来理解产品的需求本质;

如果条件允许,最好自己参与到业务的实际操作中去;这种参与不是简单的用用自己设计的产品,而是要以业务角色的身份,融入到业务中。

02 掌握基本的产品研发流程

产品经理需要了解一个产品从需求到上线运营的整个流程。虽然各类产品课程都有这方面的介绍,但落地到每一个公司,这个流程又千差万别。

产品的实现的基本阶段可以分为以下几个环节:

  1. 需求阶段;(收集需求,需求调研,竞品调研)
  2. 产品设计阶段;(信息架构设计、交互原型设计、需求文档撰写)
  3. 开发实现阶段;(需求评审、排期、开发、测试、验收)
  4. 上线运营阶段;(发版、运营)

整个流程,根据各公司的组织结构、采取的开发模式不同,具体做的事情可能会不一致,比如很多后台产品,本质上没有竞品调研阶段;很多产品经理其实也没有信息架构设计的习惯,某一些研发团队会把需求评审和排期放一起,等等,不一而足。

但无论所处的环境如何,产品经理自己心中一定要有一杆秤,知道哪个阶段该干什么事情。

我们不一定非要按照哪本书定义的方式来,心中有杆秤的意义在于,如果需要我们从0开始打造一个团队打造一个产品,能够如何快速的组织起项目工作。

落到实践上,产品经理至少能画清楚三个流程图:

  1. 传统的瀑布开发模式下的研发流程图;
  2. 敏捷模式下的研发流程图;
  3. 自己当前所处的团队所采用的实际研发流程图;

以下是笔者之前整理的一个研发流程图:

流程图仅仅只是体现了研发过程的框架,我们还要知道并且能够写清楚,某一个节点的关键事项和输出,比如需要一个什么会议,产出什么文档;同时各公司可能都有自己的项目管理协作工具(比如teambition、jira等),我们要梳理清楚这个流程如何在协作工具上体现;如下图梳理了一个研发流程的关键动作以及输出:

对于很多公司而言,这个开发流程可能由专门的项目经理或研发经理搭建并把控。

笔者的意见是,无论流程具体的onwner是谁,将一件具体的事情抽象化、流程化,本来就是产品经理逻辑能力的体现,无论从提升自己的产品专业能力角度、还是加强自己的项目管理能力角度,都具有重要意义。

03 有一套自己的产品设计风格

我们常说的产品化,本质上是将一套解决方案固化下来,说白了,就是套路,产品化即套路实体化。

前述的业务理解模型、开发流程,亦是业务理解的套路、开发流程套路。

产品经理要有一种无时无刻不在做产品的思维习惯,亦即无时无刻不在总结套路,所谓的自己的产品设计风格,即是自己做设计时有一套成型的方案套路。

总结下来,三个方面:

1. 根据所在团队的开发偏好,确立自己的文档规范

BRD、MRD、PRD、原型图这些产品经理的产出文档,网上没有统一的模板,但作为个人要有统一的规范。

所谓的规范,即前后一致,逻辑自洽,比如写PRD的时候,同样是功能描述,一般有两种方式:

  1. 前端逻辑、后端逻辑、统计需求分开描述,好处是相关开发能够更快的get到自己要做的事情,坏处是任何一个开发都缺乏对功能的全局掌控,不清楚自己的这个接口、表设计最终展现给用户是什么形态。
  2. 主要描述交互逻辑,后端逻辑夹杂在交互描述中,好处是开发能以用户视角清楚功能最终的形态,坏处是前后端的逻辑要由开发做二次拆分。

产品经理可以根据开发团队的偏好,选择一种模式,但同一个项目下的PRD,最好保持相同的方式,而不是这个需求用第一种,另一个需求用第二种。

以下是笔者之前在某家公司的梳理的PRD文档规范:

2. 原型设计时,有一套自己风格的素材库

很多产品经理会在网上找一些原型素材,作为自己设计的模板。

但进阶的产品经理,一定要能够将已有的素材融入自己的设计风格,甚至根据所在公司的业务特点和设计规范,自建自己的素材库。

当别人在看到一个原型、一个文档、一个产品时,能说出“这很有XXX的风格”,笔者认为,这就是产品经理的一步成功。

04 选择并建立自己的产品理念

乔布斯、俞军、张小龙、梁宁等产品大佬都会在各种场合输出自己的产品价值、产品理念、方法论。

作为产品界的芸芸众生,对于这些理念当然先是理解,其次是尝试着在实践中运用。

但到了一定阶段之后,我们需要选择并坚持打磨,只有坚持的理念才能称为理念,也才算是理解。

再之后,就要尝试着建立自己的理念、价值、方法。

以下分享几条笔者坚持的产品理念:

  1. MVP原则:抓住核心需求,以最小可行化最低成本方式去验证需求是否成立。
  2. 如无必要,勿增实体:一个功能、一个控件、一个操作的新增,很多时候并不是看起来那么简单,很可能会对现有架构、流程造成极大的改动。
  3. 取舍理念:这个世界没有十全十美的解决方案,任何一个方案,都有其优势劣势,你不是三井寿,不能什么都想要。
  4. 通用化:任何一个设计,不能只考虑眼前,一定要考虑是否兼容未来的规划和产品的最终形态。

再分享几条产品工作的方法原则:

  1. 坚持学习技术:要对自己负责的产品所使用的技术逻辑有基本的了解,才能更好的跟开发合作;
  2. 主动背锅:主动承担产品开发、运营过程中出现偏差的责任,当产品功能与预期不符时,首先一定要反思是否自己的需求描述没有讲清楚。任何时候,不要有开发理所应当这么理解的想法;
  3. 善意沟通:不要去为沟通对象预设立场,永远抱着解决问题的姿态去沟通。

关于产品理念和工作方法,这里只简单的点一下。更详细更多的内容,未来会单独整理文章。

这里想表达的核心是:进阶的产品经理,要有自己的做事方法、理念,而不再是见步看步,被环境左右。

这些其实都是平时整理的点点滴滴关于产品的思考和总结的拼凑。工作七年,产品工作五年,看了下为知笔记,在各公司各项目输出的规范、文档、流程该接近百万字了,平时吐槽不少,但却并没有时间好好整理自己的思考。

这是一个开头,如果你也热爱产品,热爱数据,赐教。

 

作者:尘寰;公众号:第四阳关少年录

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

题图来自Unsplash,基于CC0协议

给作者打赏,鼓励TA抓紧创作!
2人打赏
更多精彩内容,请关注人人都是产品经理微信公众号或下载App
评论
评论请登录
  1. 进来学习

    回复
  2. 感谢

    回复
  3. 写的很好 受教了

    回复
  4. 文章写的很中肯,想请问一下,数据产品经理的核心能力你觉得是什么呢?

    回复
    1. 1.略懂技术:有足够的技术原理敏感性,能够快速理解产品的技术框架和实现原理。
      2.业务逻辑能力:文中有提,能明确业务流程框架,进一步定位数据在业务中应用模式。
      3.数据分析能力:掌握基本的数据分析框架模型,知道分析师对数据的使用场景。
      4.产品经理的常规技能:其他产品经理具备的传统能力也要具备,比如项目管理,沟通,设计,理解用户等等。

      回复
    2. 十分感谢!

      回复
  5. 刚入行一年的产品小白,受教了 😉

    回复