入行产品经理之前，经常听前辈说做产品要形成自己的工作方法论，这样才算是一位合格的产品经理，那么，你形成了自己的工作方法论了吗？不妨大家来交流一下。

按照产品的生命周期，我们产品经理的工作可以划分为下面几个阶段：需求调研、产品设计、业务评审、技术评审、测试评审、开发跟进、上线验收。所以，接下来我也按照这个几个阶段分别分享下我的工作方法论。

一、需求调研

我们的需求来源有两方面：

别人提的，比如老板、业务部门提的需求。

自己提的，比如自己提出的对系统的迭代需求。

1、敢于拒绝不合理的需求

如果你做的是后端产品，那么需求大部分都是业务部门提的。接到这类需求时，一定要了解清楚需求的背景、目的是什么，并且要基于我们系统和业务的现状，判断该需求合不合理，如果跟系统架构或业务架构有冲突，比如现阶段系统实现不了，或者实现成本比较大，投入产出比不划算，那么我们要敢于拒绝此类需求。

那问题来了，如果业务方执意要实现此需求，怎么办呢？

首先，对于比较紧急的需求，一定要给出临时的解决方案，这也是我们产品经理的责任。其次，对于不紧急的需求，给出长期方案，比如跟业务方说，要实现此需求，系统架构需要改造下，改造完成后我们会帮你实现，这样也算是对业务方有个交代。

2、场景要考虑全面

一个新产品上线，很多时候业务方只考虑怎么把这产品卖出去，所以跟我们提需求时也仅限于系统如何配合支持该产品的售卖，但对于整个产品的服务周期，比如产品的逆向流程，如客户购买后需要退款、变更产品等这些场景往往他们是没有考虑到的。这些如果我们也没有考虑到，会导致后期系统对产品的服务跟不上，埋下许多坑。所以，作为产品经理，我们要时刻意识到，业务方提的需求只是其中一个场景，还有很多场景他们是遗漏的，而我们要站在整个系统上考虑，来帮他们梳理业务。

3、带着问题去调研

如果是自己提的需求，比如对现有系统的优化改造等，那么在这之前，必然要对业务部门进行调研。那么我们调研之前，我建议，自己一定要有准备，比如调研大纲、调研的对象、调研内容等，这样不但能防止遗漏了调研内容，而且也能让对方感知到我们的专业性，这样他们会更认真对待。

4、形成需求跟踪文档

需求调研后，我们需求记录下来，注意，这些需求是原始的，不经过加工的，这样做的目的是方便以后跟踪查阅，等产品设计出来后可以对照下我们有没有帮业务方解决了这些原始需求。

5、调研拉上开发测试

当我们接了业务方需求之后，会初步有我们自己实现该需求的想法，这时候，先不要画原型，而是先开个需求调研讨论会，拉上技术、测试聊聊，这样做的目的是他们或许对该需求有更好的想法，另外，你把你对该需求的想法跟技术、测试交流过了，在技术评审阶段让他们接受你的产品方案也就容易多。

6、会议要有主线

开需求调研讨论会，也有技巧，总不能大家各抒己见，议论纷纷，这样的讨论会没完没了，也很难有个结论，大家难以达成一致，效率极低。所以开会一定要遵循一定的路线，我习惯的做法就是按照该需求所涉及的产品线来展开讨论。比如一个新产品上架需求调研讨论会，那么我会循着产品上架、售卖、输出服务、退款、转换这路线来主导会议，到哪个环节就聚焦在哪个环节来讨论，实践下来，这样效率真的高很多。

好了，需求调研的方法论大概就这些啦，接下来我分享下产品设计阶段的方法论。

二、产品设计

产品设计阶段也就是我们出方案、画原型阶段，在这个阶段，我踩过许多坑，要注意的点比较多，下面为大家讲解下。

1、避免产品只为单人而设计

跟我们提需求的人，一般都是某个部门的某个人，这人提的需求，都是站在他的角度来出发的，他觉得系统该做成怎么样，才满足他的需要，这时候如果我们完全按照他的需求来做，可能设计出的功能只有他才能看懂，那么这个功能就只为他而设计了，当他的岗位变动或者离职了，这个功能就没多少人能理解了，这是很可怕的。所以，作为产品经理，我们做产品设计不仅是满足需求提出者的需求，还要站在系统易用性角度来设计，当这块功能发生交接时，别人很快就能上手。

2、一个功能只解决一个问题

既然产品设计要使人简单易懂，容易上手，那么在一个功能里头，就不要试着解决多个问题，而是要秉行一个功能只解决一个问题原则。比如你接到一个报表的需求，分别要统计合同管理系统里各产品的销售情况、合同的收款情况等，你不能只在一个报表里来做这个统计，而是要分开，一个报表体现各产品的销售数据，另一个报表体现合同的收款数据，这样，即使以后有对报表有权限的需求，比如要求合同收款的数据只能开给财务看，系统实现起来也比较方便。另外，秉持着一个功能只解决一个问题的原则，能使模块功能单一，很好地实现了模块之间的解耦。

3、功能与线下流程要对应

后端的产品，实际运行时都要配合线下流程的，要契合线下的场景。比如你在原有的业务流程上增加了一个环节，那么系统上线后，该环节的工作由谁来负责？或者你在原有某个环节上增加了功能，那么该环节的人要去理会这个功能吗？如果要理会，那么承担这个环节的人的职责范围就发生了变化，这些变化是否已沟通好了？总之一句话，我们的产品设计都要有对应的体系在支撑，设计的功能谁来操作、谁来运营、数据从哪里来，这些都必须考虑。

4、产品设计要符合大多数人心智

也就是你做的功能，要符合大多数人的认知。比如一个电商的订单状态，有未付款、已支付、已发货、配送中、已签收等状态，如果你也在做订单这块的产品，那么在订单状态命名上也应该大致跟这相同，而不要自己另取一个名字，因为这样不符合大多数人的认知，新的命名让人理解起来比较费尽，加大学习成本。

三、需求评审

1、如何推动你的方案

很多时候，我们是从单个部门接到需求，但这个需求牵涉到很多相关部门，比如财务、法务、商务等等，在初步产品方案出来之后，我们要拿着我们的方案去跟各部门评审，这时候我不太建议你挨个部门地谈，而是把大家叫到一起，这样更容易推动。为什么呢，因为如果有部门不同意该方案但其他部门都同意了，那么不同意该方案的部门必然会有压力，而这种压力会迫使他与大家达成共识。

2、准备多个方案

有时候，我们提的方案，不会让所有人都满意，可能会出现各种意外而流产，比如操作繁琐、技术实现不了、投入产出比小等。所以，在讨论方案的时候，我们要准备多个，主推一个，如果这个方案不行，那就推出备用方案，说明优缺点。这样做的好处一方面能体现我们产品经理的专业性，能从上百种方案中选出比较好的方案，让你更具说服力；另一方面，让人从多个方案中选择，会更容易被人接受。

四、技术评审

如何过技术评审

该阶段产品经理常常会被技术哥哥或测试姐姐怼得很惨，他们通常会以各种借口把需求怼回来，比如技术实现不了、需求不合理、方案不行等等。但是，如果前期你在接到业务方需求后并在产品设计之前，拉上技术、测试一起谈，让他们提前知道你对该需求的想法，如果有问题的话他们早就就提出来了，而不是到这个阶段再来提意见。

五、测试评审

严控测试评审

测试是对产品的质量负责，而你是对产品负责，说人话就是，产品质量不行那责任直接追究到你头上。所以，测试评审环节，我们一定要严控好，主要注意以下三点：

一定要要求测试出测试用例，并拉上技术一起参与评审。要注意的是，技术不是拉上技术经理，而是拉上负责该模块编码的技术，因为只有他们，才清楚自己的代码在实现什么功能。

测试用例里除了正常的业务测试，还要包含边界、异常等测试用例。

考虑是否要做压力测试，这对大用户量的产品来说是必不可少的环节。

六、开发跟进

交流实现方式

这个阶段也是极其重要的一环，前面虽已做过技术评审，但实际上开发可能不会按照你以为的方式来实现你的需求，这样产品上可能会存在其他坑，以后要做业务扩展也可能会被开发怼回来说现技术架构不支持等等。所以，在原型交付给技术后，一定要了解技术哥哥的想法，了解他们是怎么实现的，这样即使产品上线后出现什么问题也比较好排查。

七、产品上线

1、产品验收

在产品上线前一般都会先上到灰度/测试环境，这个时候，建议产品经理都要去验收下，以便及早发现问题，而不是等到上线了才验收，这时候发现问题也晚了。

2、产品宣导

产品上线后一定要通知需求方以及涉及到的业务部门，必要时要进行宣导，方式有很多种，邮件、会议等等，并且让他们做好运营的准备。