这篇文章酝酿了一段时间，起因是在新公司接到了几个特殊的需求，而这个需求也是没人做过或尝试过的，这就需要我从零开始，一点点的来摸索前进。

带着这项任务，前前后后做了大概6版的原型，修改了至少5版的PRD，但依然不够完美。

索性是在3月底，快到截至时间过了评审，确定了初版的规则和样式。

又过了大概半个月，通过和客户对接，对比同类型的产品，我发现当前的规则设计，切入方向有偏差——也就是说第一期设计，没有抓到最核心的痛点，只能解决企业一部分的问题。因此，只能将需求整理起来，准备二期的规划。

回顾这一个月，颇有感触，结合自己这一年的产品经验，也做了不下10个大功能，有的比较成功，有的也是相当失败。

今天就来讨论讨论产品是越做越复杂，还是越做越简单？

一、你所能抉择的很少？还是你可以负责整个模块？

出道刚做产品时，基本上都是老板需求，不得不说：成功率确实低的可怜，基本上起不到实际的效果，但往往又无能为力。

每次和领导们讨论的时候，也是讨论一大堆需求，然后一下子全部上线，产品做的很臃肿，用户根本不会买账。

到了中期，老板逐步会将一些他所不擅长的功能交付给我，让我尝试一种新的思路来解决需求，但整体效果也不是很好。

因为我所了解这个方向的知识很浅薄，设计的功能也是以“借鉴”为主，产品没有重点和核心，没有自家公司的思想，结果也是可想而知。

到了后期，当我对一个模块的建立有了“大致”的规划，基本的方向摸清楚了，可以和老板建议如何实现某项功能。

这时老板在看到前期的成果后，愿意放手一部分，让你设计，并给你提出他的想法。这时候的产品是越做越有人使用，可以呈现稳定的增长，但产品还是复杂，没用的功能占据很多。

现在，每个模块的功能都需要我第一时间确立，产品的核心功能以及原则、预期效果都由自己来负责，深深感受到了产品该怎么做。

尤其是在开发资源过度紧张，可调用资源稀缺，如何才能突出自己负责的模块功能，符合公司的战略，是每个PM需要考虑的问题，这样才能保证产品的稳定运行。

二、越快速，越有机会！越了解，越有深度

当设计一个新功能的时候，我曾犯过一个大多数PM都会做的错事——把功能想的太复杂。因为根本原因不是在于该实现多少个小功能，而是没有确定最合适的使用场景，所以出现了“想的挺好，但就是没人使用”的尴尬场面。

这时，我就要根据产品评审讨论的情况，调整自己的思考方式，并去回访调查用户的使用习惯，继续完善原型，这也就是近期修改6版原型的原因。

随着我对这个场景了解的更深，也逐渐能确定下几个必要的功能，知道做哪些可以满足用户的基本需求，确定一条完整的用户路径，几个相关的基本功能，这时一个周期的需求基本确定，接着将在这期间考虑到的相关功能整合起来，作为二期的规划。

往往“事不遂人愿”，功能做的再明确，依然有用户不会买账。

这时就到了要是否坚持“目标”的阶段，我们要明确功能上线后的结果，因为这决定功能的预期接受度，我们要确定哪些的反馈为不良，哪些的数据为正常，这才能保证我们是否要坚持初衷，确定这个产品这样做是正确的，也是可行的。

接着，我们通过快速迭代的方式，获取一部分资源，获得一部分正反馈，让功能使用数据能够稳定增长，这就代表着你做的是对的。

也许有更好的方法，但目前来说，这个方法是合适的。

三、到底是越做越复杂？还是越做越简单？

如果现在让我来说：功能还是“简单”为好。因为加功能合理即可，减功能则需要魄力。

从根本上来理解就是：产品初期的实现可能很复杂，因为不够了解；随着深入，你所能把控的越来越多，做产品也相对简单。

简单是让自己找到“MVP”，最简化可行产品。

怎么做到最简化？

必须要了解基础的用户。

举个例子来说：之前负责在某个旧功能的基础上，做了一个更大的功能，这个新功能上线后的效果很不错，而旧功能的数据依然没有起色，而且很影响整体规划。

但你就是干不掉它——因为你无法对“干掉它”的风险负责，因为你不能轻易干掉用户。

现在很多产品就是这样：有些功能在前期的目的是一个样，但在后期改变，而又不能一竿子把老用户打掉，所以就产生了“尾大不掉”的现象。

在创业公司中，版本的迭代十分频繁，每个版本都有无穷尽的新需求等着你来排期。每天看到用户在群中反馈各样问题，有时觉得压力还挺大：因为一旦你不满足，可能失去的是一家优质的客户。这种失落感，我想每个PM都不愿意接受。