转型到互联网领域，会充满对未知的恐惧和想像，会希望有一只梦幻团队。
我在“在行”上有个项目是“传统行业如何转型互联网”，一直无人问津，最近破了处，并从中了解到：
- 传统行业的成功者对互联网领域觊觎已久；
- 对市场有大量一厢情愿；
- 非常重视之前缺少的技术环节。
有野心是好事。身为一个创业者，绝对不能没有“野心”，因为这是你与一般人唯一的分别。如果你连强大的企图心都没有，那就绝对不适合创业。但误区也是客观存在，不得不指出来。
很多年以前我也写过程序，认识一些技术大牛，大家根本不在乎小白们会不会用，只在乎其他人觉得我的东西屌不屌，追求的是用最少的代码，用最屌的方法，把这个功能写出来，至于功能本身能不能帮别人解决问题，我一点也不在乎，因为那是产品经理的责任。我的大脑要用在更有意义的地方，像是去研究更新、更屌的技术。
如果创始人不懂技术，又一味追求技术负责人的技艺高超，很容易找到一些“纯粹”的工程师。而问题是，大多数用户根本不知道技术是什么，对他们来说这个东西也一点都不重要。Paul Graham写了几十年的程序后，提出一项真知灼见：“不要开发聪明的东西，而要开发人们想要的东西。”
过去十年，技术发展十分迅速，大量公开的代码和工具可以帮助设计出强大的程序。如此一来，现在大家都可以设计出聪明的东西，但却不易聚焦于开发人们想要的东西。但现在是一个以产品为中心的世界，也就是拚命为用户打造最好的产品，他们并不关心是不是用C语言写的，只在乎速度快不快，而且希望界面操作合乎直觉，清楚明了。
若要打造最好的产品，必须了解使用者是谁。经常关注和满足使用者的需求，这一点至为重要，为什么？因为人们的品味和流行事物都瞬息万变，竞争激烈，除非用心了解使用者的改变、成长和发展方向，否则不可能创造出跟上他们脚步的产品。此外，如果没有把这种DNA植入公司里，则很难融入公司每个人每天在做的事里头。
有的人会疑惑——到底是应该先有内容，再有平台；或是应该先有平台、 再找内容。这就好比该先把生产线设备都准备好，再接订单；还是先接到订单，再来搞定这些设备。其实答案是很简单的——没有哪个公司，会在不知道自己要生产什么产品前，就大兴土木盖工厂。也没有哪个客户，会在不知道你葫芦里面卖的是什么膏药前，就把宝贵的订单下给你。所以，重点是先找到那个能够帮客户解决问题的产品，而且最好是个痛点，那么订单和生产线，都只是时间的问题罢了。
也就是说，建立平台要在杀手应用之后。如果不是打车达不到、拒载这些迫切的问题，打车应用也不会迅速窜红；如果不是在上网的交互体验上有所突破，iPhone也不会在市场上热卖。而平台化，都是之后的事情。所以，平台大梦虽好，但没有杀手应用带来的第一批用户都是白搭。
为了创造杀手应用，你必须想出好的产品功能，快速开发，与小部分的用户一起测试，搜集数据。接着，要是有个新功能提高了一项关键指标（例如人们使用的频率、时间或花费增加），你就将此功能提供给所有用户。如果产品某功能改良后效果不佳，则必须调整或删除，很简单。
数据不会说谎，在此过程中没有太多出错的空间，除非你不擅长：
- 想出可供测试的产品改良方法；
- 厘清如何评估产品改良的成效；
- 判定手中产品功能的相关数据会让核心指标提高或降低。
转型到互联网领域，会充满对未知的恐惧和想像，会希望有一只梦幻团队。在理想世界里，你在早期阶段真的雇用到了这些人，但在现实中恐怕办不到。我们只能先看看理想的团队结构，以确认前进的方向无误，这时候最好先深入研究谁能提供下列三个关键问题的答案：
- 你正在开发什么产品？
- 该产品是否解决真正的问题？
- 我们在为谁（目标用户）解决问题？
尚未打磨出符合市场需求的产品前，团队里专门负责产品的人不太可能超过一位（理想情况下，还会有一位出色的设计师）。只有等到产品上轨道，才需要扩大产品团队的规模。打车类的产品相对复杂：由乘客和司机组成，两个应用必须同时运作，才能到达产品符合市场需求的阶段，所以需要的开发量比较大。如果应用不复杂，只需要一位产品经理就好，最好把钱花在聘请工程师，全心为公司开发更好的技术。会遭遇的瓶颈通常不是产品功能的点子不足，而是如何快速让用户使用所有的产品功能。
在开发过程中，通常还会突然冒出其他问题：
- 这个应用看起来如何？
- 这个应用使用起来如何？
- ……
负责回答这些问题的是设计团队（通常隶属于产品团队的一部分）。也许你只有聘请一位兼职设计师的预算，但为了提供杀手级产品，你必须与设计师更密切合作——理想情况下，如果负担得起应该选择全职设计师。
所有产品人员其实都是在回答开发“什么”的问题，有的团队划分产品经理、设计师、用户体验专员等，对早期团队既无聊又没意义。实际上，应该团队齐心协力，密切合作。每个人的专长的确不同，但到头来，大家都是应用的使用者，而且许多领域会重叠，应该鼓励所有人注重整个产品经验，而非单一的部分。
所以一般来说，团队成员会包括：创始人人引领产品愿景和管理；理想上，另一位创始人是工程师，有天使资金后，应该至少再招另一位工程师（或两位）加入。你可能无法聘请一位出色的全职设计师，但至少每周要能交流一次，此时大概也无法聘请一位全职的QA人员。实际上，确认应用运作无碍的重任，落在仅有一人的产品部门上。
综上所述，团队成员共为五、六人。如果应用较为复杂，需要建立一个较大的团队。需要全职设计师、iOS工程师、安卓工程师、几位后端工程师、几位外包人员以支援开发，最后再找来一位QA，这样团队成员约为十到十二人。
人有了，一般来说会采用敏捷开发的模式进行具体工作。所谓敏捷开发，是指在一段固定的短时间内，提供有价值的功能或改良，一般持续一或两周，目标是从头开始，提供某个有价值的东西（一个特定功能）让用户使用。为什么它很普及？因为每两周就可以为用户提供新功能或改良，代表每两周用户能测试新功能，让你评估是否要留下这个功能。自然地结合了使用者对产品改良后的回馈，和你原先规划要他们测试的新产品功能。
敏捷团队的定义，是指一群人完全独立自主，采用、执行、测试、配置一个产品功能，最后让用户使用。这个概念相当棒，如果团队规模小，运作成效会很好。这里很重要的一点是，团队成员应该在同一个地方，尤其是只有产品/设计/开发等少数成员的小团队。原因如下：
我们先从理想情况开始，如上所述，组织（目前小规模）产品开发团队的真正目标，是让他们有能力快速推出应用的新版本，这件事仰赖有效沟通，过程并不容易。为了能经常“推出新功能”，就要持续改善代码，等用户使用后提供反馈，再看看应用是否因此变得更好，你必须在每个可能的层面上追求效率。也就是说，要让整个产品／设计／开发／品控团队都在同一个地点，随时待命。如果其中一位或多位成员在远地工作，只会让沟通效果不佳，少了大家在同一个房间面对面沟通的机会，也无法随时私下交流。目前你的团队规模还太小，尚无法各自为政。但如果你的应用在之后以疯狂的速度成长，沟通绝对仍是关键，因此你现在所建立的沟通文化，未来将得到丰厚的成果。
把应用开发出来只是万里长征第一步，更重要的是如何让用户来用。基本上没有经验的人的答案千篇一律：“我们会用尽各种方法推广。”这和什么都没说一样。每个创业者都非常努力在推广他们的应用，但最终真能在市场上获得海量活跃用户的屈指可数。所以非常努力去推广，是基本的工作，但不是一种致胜策略。
没有用户，心目中想达成的远景再美好也是白搭，所以除了有愿景，还有要务实、按部就班的市场策略。首先是思考竞品是谁？如果说什么是最大的竞品，我会说是游戏产业，这不是玩笑，只因为一款应用上市在这个红海中的红海最先决的条件就是被找到，找不到的应用没有价值，当游戏把各种应用市场的榜单占满时，你连最基础冒头的机会都没有了。再举个例子，假设你制作了一款闹钟，想的可能是放在生活类别，但详细观察当你将闹钟放在生活品味这个类别后，会发现什么房屋出租、二维码之类都在此类，而这些都是你所谓的竞争对手。那么在曝光这个角度上，竞争对手并不是类似功能的产品，而是放在同个类别、能占据用户手机时间的应用都是你的竞品。
要想一上来就对所有用户产生网络效应，在大的公司恐怕也没办法做到。但如果先针对几千人、几万人的小群体，而后渐渐扩展，则是小团队做得到的，也是绝大多数成功公司最初使用的策略。Facebook从校园开始流行、知乎从互联网/媒体圈开始发展，都是一个道理。问题只是说，哪个小圈子最能从你的第一版产品得到价值，而累积这些用户后，又能够延展到哪里去。
如何获取用户？很多人一定会立刻想到社交媒体。社交媒体是穷人的原子弹，但要提醒的是，玩社群是非常花精力和金钱的，叫原子弹是因为人与人的互动具备散播性，而当切中角度，后续发酵将超乎预期，所以产品上线前，先问问自己各类媒体的发布与运作是否都准备好了。
另外，作为创业者，生存就是一切，所以当产品上线后要根据市场反馈情况，在最快的时间修正完成，只要市场喜欢什么就做什么，抛开一切原则，迎接市场才是。
最后，如果你做的是需要在短时间内大量用户来沉淀的产品时，就没办法等待社群慢慢的发酵，只能用用广告大量、精准的取得用户。这也是一门深奥的技巧，且背后需要耗费大量的预算，如果没有学费可以缴的话，建议先在大公司的类似部门先工作几年再出来创业，或者找到一个能把这块搞定的合伙人。
很多时候，往往我们开发多时的产品因为市场的不领情而胶着不前，而自己认为不可能火的小产品却可能在市场大放光明，那么当你的产品在互联网这个红海中的红海中被打捞起来之后，下一步就要思考这个应用对于用户而言，到底将有怎样的帮助，如果没有实实在在的根基，并不是产品优化或者产品格局够大市场就会接受的。想清楚了，成败在天，无愧于心。
作者：孙志超，小米科技投资部，MIUI生态负责人，微信公众号：weixinsunzhichao
本文由 @孙志超 原创发布于。未经许可，禁止转载。
题图来自 unsplash
