Most Products Fail!
是的，大多数的产品都会死掉，一个黑暗的事实。就如很多人认为现在团队协作工具出来这么多，很不看好风车一样。但是就如风车诞生的初衷一样，我们希望风车能够帮助创业团队更好的成长，更快地发布更好的产品，很欣慰现在风车真的帮助到了不少产品团队，让我能更有动力去改进产品和提供更好的服务。之所以我相信风车能真正帮到用户发布更好的产品，是因为我坚信对于一个创业团队来说，采用正确的做事方式和合适的工具能大大降低失败几率。
一个产品的成功，也许需要天时地利人和，但是要做到不失败相对就容易的多了。我想分享一些我们做事的方式，希望能帮助到你。这里没有互联网思维，这里没有成功学，有的只是真正的工作实践心得，甚至有些也许都是很笨的，但是希望这些分享能给你带来一点点的启发，并且还能付诸于实践。
上图是对 Scrum 敏捷方法不同角色的职责的很好诠释，即使是对于不采用 Scrum 的团队来说，我们也应该这样去做产品。做正确的事情，正确的做事情，并且快速的做事情，这样一个团队，最佳情况就是总是能在正确的时间用正确的方法做正确的事，非常完美。对于这个系列的计划，我希望能涵盖产品的整个生命线。本文开篇，主要介绍如何做产品远景和形态探索，后面的文章会涉及如何做用户角色分析，如何做用户故事、如何做计划评估、如果做迭代计划、如何协作执行、如何做回顾测试、如何做用户访谈等。
Great Product starts with Vision
正如我在「你是否关注过消费者心理？」 所写，优秀的市场营销者，会先去传递产品的使命，然后才是与使命匹配的具体需求实现。对外如此，对内同样需要如此，不然团队事情会做的很茫然。为什么我们要做这个功能，为什么我们不做那个功能？为什么我们现在需要做这个，而不是那个？回忆一下，曾经你有没有问过自己这些问题，为什么会问这些问题。究其原因，其实是产品的使命和远景缺乏透明，或者不够简单和清晰，最终导致了执行层面的混乱。用句最近流行的话来讲，『你不要用战术的勤奋来掩盖战略的懒惰』，不要去逃避寻找远景这个答案。只有有了产品远景，后面的路才能走得顺，不然相信我，出来混，迟早是要还的。
那么，应该如何才能定出一个好的产品远景呢？作为一个创业者，我们时常被要求用一句话来描述清楚产品，远景也应该如此。经典的 30 秒电梯游说就非常适合用来做产品远景测试，
<b>For</b> (target customer)
<b>Who</b> (statement of the need or opportunity)
<b>The</b> (product name) <b>is a</b> (product category)
<b>That</b> (key benefit, compelling reason to buy)
<b>Unlike</b> (primary competitive alternative)
<b>Our product</b> (statement of primary differentiation)
具体来说，就是产品做给谁、解决什么需求，产品是什么、核心价值是啥，跟竞争对手相比区别主要在哪。简单的 30 秒，但是这个定义过程需要做很多功课，非常耗时，但是如果能一口气讲清楚并且还能让人两眼发光，那么你就有了一个简单清晰而且还令人振奋的产品远景，也就有了一个好的开始。现在坐下来，好好思考一下，针对你的产品去填上那些括号里的内容，就像我对风车的远景定义。
<b>For</b> 创业团队
<b>Who</b> 想更好的成长
<b>The</b> 风车 <b>是一个</b> 团队协作工具
<b>That</b> 以任务管理为基础，提供简洁纯净的工作空间，帮助团队节省大量时间和资源去做真正要做的事
<b>Unlike</b> Jira、Basecamp、Trello、Email 和 Excel
<b>Our product</b> 专注于任务进度掌控和高效执行，信息合理有效地组织起来，真正做到简单、轻量和高效的平衡。
转换成中文习惯就是『风车是一款以任务管理为基础，提供简洁纯净的工作空间的团队协作工具，让创业团队能节省大量的时间和资源做真正重要的事情，更好的成长。不像 Jira、Basecamp、Trello、Email 或 Excel，风车更专注于任务的进度掌控和高效执行，信息合理有效地组织起来，真正做到简单、轻量和高效的平衡』。
当有了这个远景以后，我们就应该围绕着这个远景去定义产品形态，设计出一个用户想用、用户知道怎么用并且可以做出来的产品。这个过程，需要整个团队一起参与和努力，更需要相互信任和尊重，以远景为中心，多从用户的角度出发和思考，慢慢聚拢收窄需求，最终的的目标是寻找到最小可行产品，用最小成本去做测试，看看我们是不是在正确的方向上。
MVP 的确定，绝对不是一蹴而就，而是需要一段时间的反复探索、试错和纠正，有时甚至需要原型的辅助测试。所以，在探索的过程中，我们需要不同时刻带不同的帽子。
- 学会带最终用户的帽子。忘掉自己的知识背景，去思考如果自己是最终用户，会希望是什么样子的，尽可能的抛掉主观因素。
- 学会带用户支持的帽子。去聆听用户的声音，他遇到了什么问题，他希望看到什么结果。即使是他要一辆更快的马车，对于我们来说也是知道他的问题是嫌弃速度不够快。
- 学会带产品经理的帽子。用户声音中存在着很多噪音，用户也并不清楚自己需要什么，所以我们需要从众多的用户反馈和建议中挖掘出用户的真正潜在需求并给出可行解决方案。
产品形态的定义过程，是一个从具象到抽象，再从抽象回到具象的过程。这个过程，依赖于对问题的深刻理解，也借助于用户行为测试和数据分析。 实际项目中，总会有很纠结的时候，听上去这个客户提的意见有道理，那个客户提的也有道理，我们该如何做决策？这个时候就需要依托于我们在前面定义的远景，通过做用户角色分析，来让我们专注在最重要的事情上。这将在本系列文章（II）里面介绍。
在（I）的最后，再次重申，无论你的设计团队技术团队运营团队销售团队有多强，如果一开始设计出的不是一个用户想用且会用的产品，那么最终产品还是会走向失败。所以，从现在开始透明化你的产品远景，让团队每个成员都清楚知道前进的目标，这，真的很重要。
读到这里，你有什么想法吗，欢迎大家留言讨论，谢谢!
PS：本文发表于我的个人博客。我每周会在博客分享技术、创业、团队协作和项目管理上的思考，欢迎订阅。
