我恨秋天和冬天。喵们和我都容易在这个季节生病。另外尤其讨厌的一点是，无论早上起床，还是晚上回家，以及洗澡——穿衣脱衣的过程都要花上比夏天多很多的时间。
其实说到这个，想想看会让自己厌恶烦躁的倒也远不止穿衣脱衣的事。总结下来，只要当下产生了做某种事情的需要，却不可以立刻进入做那件事的状态，就会很难受，甚至是恼怒。例如晚上打算学点东西，但这之前必须吃饭洗澡，这个“中间”的状态就很讨厌…而吃饭之后，又必须首先花时间把碗刷掉才能洗澡，这也很讨厌…总之从计划到实施，这当中涉及的中间状态越多，越讨厌。中间状态对于目标的完成永远是一种阻挠，这让我觉得目标与现实之间有着无比强大的摩擦力；什么时候才可以平滑的好像牛油一样呢。
这些听上去像是无病呻吟的废话，其实你仔细琢磨琢磨，不是没道理。你为什么不生气，为什么不愤怒，为什么不着急，为什么任凭目标以外的事物干扰自己的前行，而不去想想那些事物是否真的像吃饭睡觉这类刚需一样无法改变？话说，如果你和我一样对这些事情较为敏感，那么其实我们所在的行业，我们平日所做的事情，正为我们提供着一系列的机会，让我们可以创造一些在生活当中帮助人们减少这类摩擦力的东西。可是话说回来，如果只有我们自己在意，只有我们自己能感受到负面体验给人带来的沮丧，那这一切的意义到底在哪里？我只知道闲话可以到此为止了。看正文。
“新创产品的目标，是找到一个奇妙的点。在这里，最小化的形态与可行性可以完美的结合，让人们乐于使用。经过一段时间，你听取用户的意见建议，对产品进行改进，并逐渐提高‘可行性’的标准，使竞争对手逐渐无法跟上你的步伐。” – John Radoff
如果你正着手打造自己的创业项目，那么通常会希望产品能尽快被用户接受，并带来实际的回报。这意味着你要以最小形态来发布产品，并确保用户乐于为之付费。接下来，你可以基于用户的更多需求和期望来设计和开发新的功能，而不是根据你自己的想象替用户决定哪些是他们想要的。
本文中，我将根据自己的实际经验为各位介绍一下怎样以真正最小的形态发布产品，并通过不断倾听用户的声音来使你的产品逐渐成熟起来。
怎样确定第一版的必备功能
我们可以以很小的形态作为起点，但你仍然需要规划清楚哪些功能是产品所必需的，哪些功能可以为用户带来价值并使他们乐于付费。建议你考虑以下两个主要的问题：
你的目标用户是谁？
你的产品可以帮他们解决怎样的问题？
对于我们自己的产品来说(Perch)，目标市场是那些设计代理公司及自由设计师。具体来说，我们的产品是一款CMS(内容管理系统，例如Wordpress、Drupal、Joomla等)，不过我们没有意图将它打造成某种傻瓜式的建站工具。我们的目标用户就是那些我们曾经合作过的人：小型设计代理公司和拥有HTML、CSS代码能力的自由设计师。他们需要的不是复杂的建站系统，而是能够帮他们管理作品内容的工具。我们的CMS同样会面向那些有能力开发小型站点的人，不过我们并没想成为Drupal的竞争对手。所以归纳起来，我们的目标用户就是那些有一定前端开发技能的，需要建立小型站点的独立设计师或设计代理公司。
我们很了解这个群体，而且他们也了解我们。我总是建议，如果你要打造一款新产品，那么所面向的最好是你自己已经树立起名声和口碑的那部分市场；这会让你的产品更容易传播，因为人们已经对你有所了解和信任。
我们希望这个产品能解决两个主要的问题。第一，它的部署方式要足够的快速和简单；一个小型站点不该需要用户花费几天的时间来创建页面模板。第二，我们希望提供一种足够纯净的代码方案，在HTML、CSS和JavaScript中没有任何不必要的东西出现，以便设计师们可以100%控制CMS的代码输出。
以上就是我们的产品所要面对的用户群体以及所要解决的主要问题。接下来，我们产生了大量的功能概念设想，但是我们始终把目标用户和核心价值记在心里，所以反过来又无情的砍掉了很多想法，直到我们觉得剩下的功能可以支撑起一个最小形态的产品。最初版本的Perch花了我们四周的时间去设计和开发——当时我们还在帮客户做着其他项目。然后我们又用了差不多相同的时间去搭建推广网站以及用来发布产品的必要基础。
充满自信地发布产品
一切就绪之后，你要充满自信的将产品发布出去。也许你有一份包含大量功能设想的清单，希望把他们都做到产品当中，但是用户不知道这些。没关系，只要你的目标用户有困难需要解决，而你敏锐的识别到了这些问题，并在产品中提供了解决方案，那么它就应该可以卖的动。快速发布最小化产品的方式有一个重要的好处，就是你可以在投入大量资源设计开发更多功能之前对产品的核心价值进行验证。
在“最小化”和“可行”之间找到平衡点，倾听用户的声音，验证你的想法，持续改进。
不要因为你给用户带来了仅包含很少功能的产品而道歉，只管去推广好了，注意要准确的将产品的功能范围及专注解决的问题告诉潜在用户。假设人们已经购买并开始使用你的产品，那么你很快就会收到新功能需求的反馈建议，而且其中有些建议很可能会让你感到惊讶——虽然用户提出的需求当中会有一些是你已经设想过的，但就我个人的经验来说，他们所提到的一些需求会是你从来没有想到过的。
我们并没有听到过哪些用户觉得我们的最小化产品是缺斤短两缺乏诚意的，因为我们在推出产品并进行宣传的时候就已经明确的让市场知道了我们的特色，我们的营销策略与产品自身是保持一致的。而且我们发现，最初的那些用户会因为我们在改进产品的过程中倾听了他们的意见而感到非常开心；如今我们有很多忠实用户已经使用Perch创建了大量的站点，他们当中的多数都是最早的那部分用户。
本文一开始就提到过关于尽快让用户接受产品、为之付费的目标。人们总是会不遗余力的告诉你应该免费提供怎样的功能，而那些愿意为你的产品掏钱的用户所带来的反馈和诉求则更加有价值。付费的过程改变了用户与产品及产品团队的关系，用户变成了消费者和客户，他们会觉得有责任提出自己期望的功能与服务。
做那些能够为最多的用户带来最大不同的事情
一旦你成功发布了包含最少量功能的最小化产品，并且很快从用户当中得到了功能需求方面的反馈，那么这真心不坏。不过有时这类反馈会让你觉得铺天盖地。你该从何处入手来增加这些新功能？怎样向一部分用户解释为什么他们热忱的期望无法得到满足？
为功能方案进行优先级排序，对多数用户有价值的、能解决普遍性问题的功能更加优先。
我们一直对用户保持透明，对能够使绝大多数用户获益的那些功能方案进行优先级规划。我们会将用户在论坛、邮件、Twitter或当面交流当中提出的功能需求整理起来，另外还会研究用户在实际当中是怎样使用我们的产品的，以发现那些有可能的“隐藏功能需求”。有时我们会观察到用户以非常复杂的方式试图完成一些我们的产品无法做到的事情；如果我们逐渐看到越来越多的用户在这样做，那么我们会认为这可能是个需求点。这类可以帮到多数人的功能点会拥有最高的优先级。而且我们总是发现，一旦我们确认采纳一个需求量最大的功能方案，很快就会有另一个人气最高的需求爬到优先级的顶端。
定义用例
要向产品中增加功能，你需要为其定义某种普遍适用的用例。你不能像给客户制作定制化功能那样做产品，功能必须面向足够多的用户解决某种足够普遍的问题，这样的功能才值得投入成本去进行设计和开发。当广大用户希望我们的产品增加某种功能时，我们会向他们提出请求，让他们帮我们解释这种功能的实际用例。我们想要了解他们需要解决的具有普遍性的问题，而不是他们自己遇到的某种特定问题。
我们发现，在与用户就某个特定的用例进行沟通和探索时——在论坛里，有类似需求的用户也会逐渐加入讨论——慢慢的，这类原来只有很小范围的需求和用例就会变得具有足够的普遍性，值得我们去进一步思考。
有时，某个用户提出的一点功能需求虽然具有很强的特殊性，但不会破坏产品的核心用例，而且开发起来相当简单，那么我们也乐于在下一个版本中增加这样的小功能，并让这些有需求的用户知道。做属于自己的产品时，有一个很棒的地方，就是你可以决定让一些用户感到愉悦，做一些非常规的事情来为他们提供帮助。
我们在打造产品的过程中与用户进行了良好的沟通，并很好的听取了他们的建议，不过要记住，这部分用户很可能只是很小的一部分。看看客服系统当中的数据，有多少用户是主动来寻求支持和交流的。对我们来说，这部分用户占到总数的25%，也就是说，我们听到的声音只来自于全部用户的25%，而另外75%的沉默用户可以说是在比较开心的用着我们的产品——至少没有不开心到觉得有必要寻求客服帮助或是提出功能需求。
将这部分理想用户牢记在心，这对你来说也是很有帮助的。我们有时会在人们付费购买我们的产品之前告诉他们，我们并不能确认这款产品对他们来说是真正合适的，但他们仍然会购买。然而接下来他们就会抱怨各种问题，例如系统没有自带主题模板，或是他们必须自己写HTML代码等等。虽然这不是好事，但你也要记得，他们并不是你的理想用户，你的产品并不是针对他们进行设计开发的。所以，要抗拒你内心当中为非目标用户增加各种功能的欲望。
然而有时，你的核心用户群当中发出的一些噪音也会让你误以为大部分的目标用户需要某种特定的功能。你可以对此加以判断，如果这类功能会使产品走向新的方向，或是改变重要的功能流程，那么建议你向数量更多的沉默用户征询意见。我们发现，当我们在自己的博客、播客和Twitter当中宣布某些有可能增加的新功能时，很多我们从未见过和交流过的用户会浮出水面提出自己的看法。如果你的统计数据或销售数据可以根据用户进行细分，那么你应该可以识别出那些非常活跃但很少表达自己观点的用户，并与他们进行沟通。喜爱你产品的用户会很乐于看到你向他们征求反馈意见。
微博是用于收集用户简短回馈的绝佳平台。
当你向用户征求反馈意见时，要提出一些具体的问题，而不是问他们怎样看你的产品。如果你正在规划一次重大的改版，那么试着提前向用户解释改版的原因，并让他们设想在使用新版本的时候有可能产生怎样的问题。
保护你的核心用例
充分理解你的核心用例，也就是你的产品所要解决的最首要的问题——这对于后续功能的决策是至关重要的。我们的产品距离初次发布已经四年了，尽管它已经进化到第二个大版本，各方面功能比起刚刚发布时的最小形态来说也完备了很多，但用户使用它的基本方式并没有发生变化。
如果某个新功能会使基本用例变得复杂，那么除非有很好的理由，否则不要添加它。有时你需要告诉用户，他们想要的功能并不适合这个产品，并且你要意识到，部分用户可能因此而选择其他产品。你没法让所有人都开心，你最核心的目标用户也不会希望你试图让产品满足所有人。
新功能对我们销售业绩的推动并不大
我花了很长时间才了解到，增加新功能的做法并没有对我们的产品销售起到非常大的推动作用。这些年来，我们在Perch当中增加了一些很大的、呼声很高的功能，其中有一些的开发时间甚至和当初我们做整个产品所花费的相仿。然而，这些新功能的上线并没有在我们的销售报表上添加漂亮的尖峰，曲线仍然是平稳增长的，而且没有明确的迹象表明哪一个增长期是由于某个特定的功能上线而导致的。
这并不是说增加新功能不是重要的事情。现有用户乐于看到新功能的上线，他们会把这看作产品的活跃标志，并且会因为产品正在向他们需要的方向进化而感到开心。然而，就我的经验来说，你很难寄希望于通过新功能来吸引新用户。要让更多的用户了解并使用你的产品，聚焦于在营销方面的工作有时比单纯的开发新功能要更加有效。
