如果你想成为一位不称职的产品经理，那么请立马发布你所有的功用吧。马上将你手头上所有酷炫的功用向全世界展现吧。你独一要做的就是：尽可能的快，尽可能多的发布。由于在用户第一次使用产品时，如果不能看到全部的功用，我们将有会有可能得到这些用户。虽然有些功用用户其实并不在意，用户却会很乐意从额外的功用中筛选出他们认为有价值的功用。

假设你有志向成为一名优秀的产品经理，一些功用可以放一放。在产品初次发布时，包含足够多的功用点确实有举足轻重的作用，然而接下来的版本发布中，延迟部分非核心功用的发布，也有它合理的缘由：

1. 用户并不能一次性处理和熟悉太多的功用。对于全新的产品，极其容易出现功用点过多，用户不能关注产品中最核心功用的情况。过多的非核心功用，反而会让用户把留意力从产品的核心功用转移开。用户被那些不重要的功用所吸引，忽略了产品真正的附加价值。需求知道，每添加一个新的功用点，都必须提供一定的时间让用户顺应和熟悉。 

2. 产品初期，更少的功用点能让你无机会抓住更多的价值。一些“一鸣惊人”的产品在初次发布时就发布了所有最佳的功用点，导致在接下来的产品迭代过程中却不能提供持续的升级和改进。在许多情况中，通过分阶段叠加版天性够得到一定范围的处理。假如所有最有价值的功用都在一个版本中发布，那么希望通过价格的提升和模块的扩展为公司带来更多的产品附加值的想法，具有不小的挑战性。反之，只实现最核心功用的1.0版本，曾经足够证明产品的价值和得到用户的接受。这将为你构建更好、更合理的产品规划铺平道路，从用户身上获得更多的价值，并更容易锁定潜在用户群。随着产品的发展，初期“纤细”的产品，为后期功用的添加和价格的提升提供更多灵活性。

3. 功用分阶段实现，则产品可以依据市场反馈快速反应并以此为依据调整新功用。在产品管理中，有一条定律—明天你知道的一定比你昨天做过的多得多（you always know more tomorrow than you did yesterday）。这就好比在前期产品发布前你觉得重要的一大堆功用，在发布后也许就变得不是很必要了。在前期保留部分功用，还能从用户反馈中得到好处。一旦用户开始使用和接触你的产品，他们不单单会提供产品现有功用的反馈意见，更为重要的是反馈你目前没有的功用。之前你认为很重要的功用，你会发现其实用户并不觉得重要。各种你完全不会料想的“奇思妙想”也会源源不断的从你的用户那里得到。基于真实场景下的用户反馈，协助你指明了产品的发展方向和修正你的产品规划。同时，你可以将更多的精力放在更有价值的功用上，而不是浪费在一堆毫无价值的功用上。

随着产品经理对产品功用的扩展，一个对产品未来功用的合理预期能够为产品的发展打下扎实的基础。然而，产品管理是一场马拉松，并不是百米冲刺。产品经理更需求着眼于大局的发展和长期的胜利。绝对于一次性发布产品所有具有潜在价值的功用，产品经理在初次发布时应该是只提供核心功用，以尽快的速度让产品面向市场。

保留部分功用吧！只要这样，产品经理才能更好的建立令人服气的产品规划，在发展中保持领先的地位，在市场变化前做好一切预备。

PS：对于用户而言，他们使用的并不是产品，而是一种问题的处理方案。那么什么是核心需求（我本人喜欢使用“基础需求”这个说法）？就是采用产品减法，当任何一个功用的减少都不足以让你的产品协助用户处理问题的时候，产品所具有的功用就是最基础和不可或缺的功用，也就是核心功用。任何一个产品，其实是应该协助用户以一种更高效率、更方便的方法去处理他们的问题。当产品曾经不能提供这种最本质的功用的时候，回头看看最后的产品和最后的意图，也许能够重新找回和找到方向。其实，除了功用需求我们缓一缓外，我们也需求学会和bug和平相处。不是每个bug都需求立即处理，将不是很严重的bug放一放，不要因此不停地打断开发人员的开发节拍，那样反而会适得其反。最后也许是丢了西瓜，捡了芝麻。