前几天有人问我：“你做产品有没有什么方法论？” 当时我愣了几秒钟，意识到其实我是有方法论的，但是从没有认真总结过。也就是说：对于怎样做产品这件事，我并没有形成一套适用于自己（也可能给他人有借鉴意义的）的思维方式。既然如此，那现在我应该总结一下echo的产品方法论。

方法论一：产品满足的本质需求和商业目的起码在当下，应该明晰。

首先，为何会有一个产品被创造出来？其背后必然是有一个或多个需求，凡是未看到需求而盲目生产出来的产品都是耍流氓。因此，做产品之前不做需求分析显然是不可行的。然而，无论在任何以营利为目的的商业实体中做产品，该产品总应该实现该实体的商业目标，或是赚取利润，或是提高流量，没有任何商业目的的产品，也是无法获得生存下去的理由的。

由于我所在的互联网金融行业在过去的几年里似乎比较热门，常常会听到有人说：“哎，我们家也想做个互联网金融平台，你看怎么做一下比较好？我们有这个资源那个资源。”那我就想问一句了：“做互联网金融为了达到什么样的商业目的呢？你想拉流量？放贷赚钱？卖理财产品赚钱？”通常问到这以后，对方就陷入沉吟，或者赖皮的说：“你帮我想一个吧！”

事实上作为产品经理，给企业规划产品目标确为本职工作，但对于没有具体需求却已预先定好解决需求的工具的老板，我只能说一句：“臣妾做不到啊~”要么我需要知道有什么需求，要么我需要知道有什么商业目的；对于需求不明目的不明，却规定好你必须用互联网金融这个工具的商业机构，我想说的是，老乔下凡也帮不了你什么。（嘿嘿嘿，事实上这种公司还真不少！）

方法论二：产品的规划应该由用例发起，用例验证。

鉴定好了产品的需求或商业目的之后（起码是当前已经确定），应该进入产品的业务架构阶段。

现在到处在讲究MVP，一夜之间产品做得挫都可以堂而皇之得称之为为了敏捷开发，快速上线。好一块遮羞布！我在产品业务架构这一步的主要执行方式是实用主义至上，先用例后功能。

技术出身的产品经理一定知道用例是什么，但其他背景的产品经理对于用例可能比较陌生，但可以这里把用例理解为“用户故事”，即做这个业务的所有人，在这个业务中的行为是什么。每个用例都有一个明确的目的。例如投资者这个业务主角，他有一个关键用例称为”投资“。“投资”用例中，可能包括投资者的实名认证和绑卡；而“绑卡”则一般不会称为一个单独的用例，因为，一般来说投资者不可能单纯为了绑卡而绑卡，且没有下一步目的的。我们的目标，是为了找出所有系统相关人员在这个产品的所有目的。这个“目的”，其实正对应着第一步的“需求”。

从零到一规划一个产品的工作通常是这样：你需要凭空想象出一件物体，并假设这个物体已经制造出来了。这时，你需要向他人描述这个物体，描述它是做什么用的；描述它的形状、质地、硬度、大小，它是不是有什么气味，摇晃一下听会发出什么声音；或者使使劲韧性如何。描述完毕后，会有人（开发兄弟们）把这件物体制造出来。也许你觉得在脑中已经想到了这件物体的每一个零件，在制造的过程中还是会有各种各样的问题。按照我一个老朋友的话说：“尼玛做实现的不是你啊！”如果用例不走通，功能当然也会设计的相当残缺。如果不幸已经进入了研发流程，那么当程序猿拿着走不通的流程来问你的时候，如果你是男生恭喜你，你还能下跪求原谅；如果你是个妹子，你说你该怎样吧。

说到这里有人会疑惑，既然产品的业务架构如此繁琐，那MVP到底还存在吗？我想说，一定还是存在的。一个产品的功能可以简单，比如只有一个功能，满足一类使用者的一类业务目的，但这个业务目的的满足，一定是完善的。打个比方，如果你有两枚一元硬币，要你交出一半，你是给出一个硬币，还是用刀把两枚硬币都切成半圆，然后给出两个半圆？MVP需要你给出一个硬币，而不是两个半圆。即“可使用的最小产品”而不是’残缺的大产品“。很多时候我们MVP给不出来的原因并不是我们规划的太细了，而是，我们把产品规划的太大了。

产品的业务架构做的差不多了，这时候各种文档也应该出齐了。我并不觉得文档出的越齐就代表产品做得越好或做的不齐就没法开发。文档齐不齐和研发测试团队的默契程度、专业背景都有关联。但是为保证产品能够顺利迭代，以及人员变动不会给产品带来影响，最好保持较完善的需求文档或主用例文档。

有的团队在产品规划出来之后还面临着拆分任务。即拆分功能点给不同的产品经理进行进一步完善的工作。在这点上我认为功能点任务的拆分，在产品这方面应依据技术任务的拆分来做。例如某个功能点，是研发小组A来实现，则应匹配产品经理A，功能点B由研发小组B来实现，则应对应产品经理B。这样可以有效避免产品经理的跨研发小组沟通，以及技术部门之间需求协调不畅的问题。产品功能的协调问题，在产品组内解决，功能模块间的通信与耦合，在技术组内解决，泾渭分明。

方法论三： 没有一劳永逸的产品架构，早期产品可能随时被推翻。因此应尽量简单。

按照三段式理论，现在应该是方法论的最后一点，研发中的需求变更和产品迭代问题的处理方法。

在互联网行业中我们都应该习惯了“只有变是永远不变的”。初入行时，还常常为变来变去的需求和经常白做的功能感到惋惜，而现在已经能泰然面对了。

当我们在上述的第二步业务架构时，一般就应该对产品的生命周期及未来一两个版本的迭代有基本的预估，这样在第三步时，可以有效避免产品持续迭代中的荒腔走板。如果产品在老板（或“未知力量”）的影响下，发生了重大变更，那事实上可以认为是研发一个新产品，而不是在当前产品上的变更了。

鉴于此，MVP其实是非常重要的，这意味着我们必须有一个非常简易且扩展性强的业务架构，而设计出这种架构的前提又是对业务的高度熟悉。因此，在互联网行业，尤其是互联网金融行业中，如果要适应快速的业务变动，对于产品经理的要求，应该是对业务理解到能抽象的程度，所以，我们时时刻刻都应该检视自己，金融到底学的怎么样？对金融的本质有多少的理解，而不仅仅拘泥在”这个按钮应该放这还是放那？“这种UI层面的问题上。

产品经理是互联网职业中入门门槛最低的一个职位，但是，在互联网金融领域，它的入门门槛就不是那么低了。所以，当你做来做去还是觉得自己业务能力没有什么提升的时候，我觉得问题主要出现在：你把自己的职能范围缩得太小了。而为什么缩小，可能是你的潜意识把你的学习能力圈在舒适区了，你说呢？

本文由 @echo回声 原创发布于人人都是产品经理 ，未经许可，禁止转载。