产品经理们，请把手上的一些功能放一放

sxen

如果你想成为一位不称职的产品经理，那么请立马发布你所有的功能吧。马上将你手头上所有酷炫的功能向全世界展现吧。你唯一要做的就是：尽可能的快，尽可能多的发布。因为在用户第一次使用产品时，如果不能看到全部的功能，我们将有会有可能失去这些用户。虽然有些功能用户其实并不在意，用户却会很乐意从额外的功能中筛选出他们认为有价值的功能。
$ ?! Q/ p! k) ^9 i  k
假设你有志向成为一名优秀的产品经理，一些功能可以放一放。在产品首次发布时，包含足够多的功能点确实有举足轻重的作用，然而接下来的版本发布中，延迟部分非核心功能的发布，也有它合理的原因：
& Q) d2 f9 Q+ t4 [
, v; ~" U' S" k+ V: i; j1 _+ w1. 用户并不能一次性处理和熟悉太多的功能。对于全新的产品，极其容易出现功能点过多，用户不能关注产品中最核心功能的情况。过多的非核心功能，反而会让用户把注意力从产品的核心功能转移开。用户被那些不重要的功能所吸引，忽略了产品真正的附加价值。需要知道，每增加一个新的功能点，都必须提供一定的时间让用户适应和熟悉。

* T9 j8 Q  \6 {) A) N( N7 p' |2. 产品初期，更少的功能点能让你有机会抓住更多的价值。一些“一鸣惊人”的产品在首次发布时就发布了所有最佳的功能点，导致在接下来的产品迭代过程中却不能提供持续的升级和改进。在许多情况中，通过分阶段叠加版本能够得到一定范围的解决。假如所有最有价值的功能都在一个版本中发布，那么希望通过价格的提升和模块的扩展为公司带来更多的产品附加值的想法，具有不小的挑战性。反之，只实现最核心功能的1.0版本，已经足够证明产品的价值和得到用户的接受。这将为你构建更好、更合理的产品布局铺平道路，从用户身上获得更多的价值，并更容易锁定潜在用户群。随着产品的发展，初期“纤细”的产品，为后期功能的增加和价格的提升提供更多灵活性。
" Q4 E6 U* i5 v* W4 t( X. Y
" T; g7 S0 D' v& D( N3. 功能分阶段实现，则产品可以根据市场反馈快速反应并以此为依据调整新功能。在产品管理中，有一条定律—明天你知道的一定比你昨天做过的多得多（you always know more tomorrow than you did yesterday）。这就好比在前期产品发布前你觉得重要的一大堆功能，在发布后也许就变得不是很必要了。在前期保留部分功能，还能从用户反馈中得到好处。一旦用户开始使用和接触你的产品，他们不单单会提供产品现有功能的反馈意见，更为重要的是反馈你目前没有的功能。之前你认为很重要的功能，你会发现其实用户并不觉得重要。各种你完全不会预想的“奇思妙想”也会源源不断的从你的用户那里得到。基于真实场景下的用户反馈，帮助你指明了产品的发展方向和修改你的产品布局。同时，你可以将更多的精力放在更有价值的功能上，而不是浪费在一堆毫无价值的功能上。

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

8 w# V6 ~1 L8 n2 M/ W. z! Y) I保留部分功能吧！只有这样，产品经理才能更好的建立令人信服的产品布局，在发展中保持领先的地位，在市场变化前做好一切准备。
& |6 U. F3 f1 @9 A
( \$ A: I+ F- FPS：对于用户而言，他们使用的并不是产品，而是一种问题的解决方案。那么什么是核心需求（我自己喜欢使用“基础需求”这个说法）？就是采用产品减法，当任何一个功能的减少都不足以让你的产品帮助用户解决问题的时候，产品所具有的功能就是最基础和不可或缺的功能，也就是核心功能。任何一个产品，其实是应该帮助用户以一种更高效率、更方便的方法去解决他们的问题。当产品已经不能提供这种最本质的功能的时候，回头看看最初的产品和最初的意图，也许能够重新找回和找到方向。其实，除了功能需要我们缓一缓外，我们也需要学会和bug和平相处。不是每个bug都需要立即解决，将不是很严重的bug放一放，不要因此不停地打断开发人员的开发节奏，那样反而会适得其反。最后也许是丢了西瓜，捡了芝麻。
7 Q( x9 o2 A2 m
/ `) l# q# g" s+ _2 C本文编译自苦茶，原文地址。

译文出处：互联网的一些事