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

　　当产品经理积累大量实战经验与岗位认知后，学会从中总结方法论与心得能够帮助我们高速成长。那么具体要怎么做呢？过程中有哪些要点要掌握呢？笔者将结合这些点梳理如何打造产品方法论。
　　28岁岁末的时候，立了个flag，希望在30岁时，能形成自己的产品方法论，如今而立已过，开始做数据产品相关工作也近有五年；这五年来，因为人生轨迹的跳跃，产品本身所在的行业并不固定。好在产品逻辑本身可以触类旁通，加之无论行业如何，自己的兴趣和做的事情，都是数据产品本身。
　　行业上走过了电商O2O、在线教育、智能硬件、金融风控，产品范围也从之前的数据分析产品跨度到了数据服务、数据应用产品。
　　外人看来只见其宽，而自己而言，实际一直在数据产品的领域耕耘沉淀。
　　遂尝试着整理过往的思考和笔记，算是自己的成长，也是不成熟的分享。
　　01建立自己理解业务的方法模型
　　理解业务是理解需求的大前提，所谓理解业务，往大了说是理解公司的商业模式，往小了说是理解产品的具体应用场景。事实上，即使是相同行业的不同公司，业务模型也是千差万别；掌握一套理解业务的方法论，能够使我们的产品之路不局限于行业和平台，快速向新的领域拓展自己的产品力，能够使我们快速的理解新平台的需求场景，更好的推进产品实施；
　　就实践而言，当我们接手一个新的产品之后，可以分以下步骤去了解业务，以及负责产品对业务的意义：
　　1。与业务核心KP沟通，了解业务流程，并自己绘制一个业务流程图，明确以下信息
　　整个业务分几个环节、步骤？
　　每个步骤的具体内容是什么？
　　每个步骤之间的依赖关系？
　　2。梳理业务业务流程图后，对着业务流程图，我们要知悉并思考以下信息
　　业务各步骤涉及的人员、应用系统都有哪些？
　　我们负责的产品处于哪个步骤，涉及人员有哪些，解决的核心问题是什么？
　　这个时候，我们基本已经定位了自己产品所处的位置，以及产品解决的问题，那么就可以通过具体了解该环节产品涉及人员的具体操作流程，来理解产品的需求本质；
　　如果条件允许，最好自己参与到业务的实际操作中去；这种参与不是简单的用用自己设计的产品，而是要以业务角色的身份，融入到业务中。
　　02掌握基本的产品研发流程
　　产品经理需要了解一个产品从需求到上线运营的整个流程。虽然各类产品课程都有这方面的介绍，但落地到每一个公司，这个流程又千差万别。
　　产品的实现的基本阶段可以分为以下几个环节：
　　需求阶段；（收集需求，需求调研，竞品调研）
　　产品设计阶段；（信息架构设计、交互原型设计、需求文档撰写）
　　开发实现阶段；（需求评审、排期、开发、测试、验收）
　　上线运营阶段；（发版、运营）
　　整个流程，根据各公司的组织结构、采取的开发模式不同，具体做的事情可能会不一致，比如很多后台产品，本质上没有竞品调研阶段；很多产品经理其实也没有信息架构设计的习惯，某一些研发团队会把需求评审和排期放一起，等等，不一而足。
　　但无论所处的环境如何，产品经理自己心中一定要有一杆秤，知道哪个阶段该干什么事情。
　　我们不一定非要按照哪本书定义的方式来，心中有杆秤的意义在于，如果需要我们从0开始打造一个团队打造一个产品，能够如何快速的组织起项目工作。
　　落到实践上，产品经理至少能画清楚三个流程图：
　　传统的瀑布开发模式下的研发流程图；
　　敏捷模式下的研发流程图；
　　自己当前所处的团队所采用的实际研发流程图；
　　以下是笔者之前整理的一个研发流程图：
　　流程图仅仅只是体现了研发过程的框架，我们还要知道并且能够写清楚，某一个节点的关键事项和输出，比如需要一个什么会议，产出什么文档；同时各公司可能都有自己的项目管理协作工具（比如teambition、jira等），我们要梳理清楚这个流程如何在协作工具上体现；如下图梳理了一个研发流程的关键动作以及输出：
　　对于很多公司而言，这个开发流程可能由专门的项目经理或研发经理搭建并把控。
　　笔者的意见是，无论流程具体的onwner是谁，将一件具体的事情抽象化、流程化，本来就是产品经理逻辑能力的体现，无论从提升自己的产品专业能力角度、还是加强自己的项目管理能力角度，都具有重要意义。
　　03有一套自己的产品设计风格
　　我们常说的产品化，本质上是将一套解决方案固化下来，说白了，就是套路，产品化即套路实体化。
　　前述的业务理解模型、开发流程，亦是业务理解的套路、开发流程套路。
　　产品经理要有一种无时无刻不在做产品的思维习惯，亦即无时无刻不在总结套路，所谓的自己的产品设计风格，即是自己做设计时有一套成型的方案套路。
　　总结下来，三个方面：
　　1。根据所在团队的开发偏好，确立自己的文档规范
　　BRD、MRD、PRD、原型图这些产品经理的产出文档，网上没有统一的模板，但作为个人要有统一的规范。
　　所谓的规范，即前后一致，逻辑自洽，比如写PRD的时候，同样是功能描述，一般有两种方式：
　　前端逻辑、后端逻辑、统计需求分开描述，好处是相关开发能够更快的get到自己要做的事情，坏处是任何一个开发都缺乏对功能的全局掌控，不清楚自己的这个接口、表设计最终展现给用户是什么形态。
　　主要描述交互逻辑，后端逻辑夹杂在交互描述中，好处是开发能以用户视角清楚功能最终的形态，坏处是前后端的逻辑要由开发做二次拆分。
　　产品经理可以根据开发团队的偏好，选择一种模式，但同一个项目下的PRD，最好保持相同的方式，而不是这个需求用第一种，另一个需求用第二种。
　　以下是笔者之前在某家公司的梳理的PRD文档规范：
　　2。原型设计时，有一套自己风格的素材库
　　很多产品经理会在网上找一些原型素材，作为自己设计的模板。
　　但进阶的产品经理，一定要能够将已有的素材融入自己的设计风格，甚至根据所在公司的业务特点和设计规范，自建自己的素材库。
　　当别人在看到一个原型、一个文档、一个产品时，能说出“这很有XXX的风格”，笔者认为，这就是产品经理的一步成功。
　　04选择并建立自己的产品理念
　　乔布斯、俞军、张小龙、梁宁等产品大佬都会在各种场合输出自己的产品价值、产品理念、方法论。
　　作为产品界的芸芸众生，对于这些理念当然先是理解，其次是尝试着在实践中运用。
　　但到了一定阶段之后，我们需要选择并坚持打磨，只有坚持的理念才能称为理念，也才算是理解。
　　再之后，就要尝试着建立自己的理念、价值、方法。
　　以下分享几条笔者坚持的产品理念：
　　MVP原则：抓住核心需求，以最小可行化最低成本方式去验证需求是否成立。
　　如无必要，勿增实体：一个功能、一个控件、一个操作的新增，很多时候并不是看起来那么简单，很可能会对现有架构、流程造成极大的改动。
　　取舍理念：这个世界没有十全十美的解决方案，任何一个方案，都有其优势劣势，你不是三井寿，不能什么都想要。
　　通用化：任何一个设计，不能只考虑眼前，一定要考虑是否兼容未来的规划和产品的最终形态。
　　再分享几条产品工作的方法原则：
　　坚持学习技术：要对自己负责的产品所使用的技术逻辑有基本的了解，才能更好的跟开发合作；
　　主动背锅：主动承担产品开发、运营过程中出现偏差的责任，当产品功能与预期不符时，首先一定要反思是否自己的需求描述没有讲清楚。任何时候，不要有开发理所应当这么理解的想法；
　　善意沟通：不要去为沟通对象预设立场，永远抱着解决问题的姿态去沟通。
　　关于产品理念和工作方法，这里只简单的点一下。更详细更多的内容，未来会单独整理文章。
　　这里想表达的核心是：进阶的产品经理，要有自己的做事方法、理念，而不再是见步看步，被环境左右。
　　这些其实都是平时整理的点点滴滴关于产品的思考和总结的拼凑。工作七年，产品工作五年，看了下为知笔记，在各公司各项目输出的规范、文档、流程该接近百万字了，平时吐槽不少，但却并没有时间好好整理自己的思考。
　　这是一个开头，如果你也热爱产品，热爱数据，赐教。