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