互联网小团队创业启示录

 　　武汉北大青鸟光谷校区：校区新闻-互联网小团队创业启示录

       关于互联网上创业，要找到一个切入点，顺势而为。

　　找个你真正熟悉了解信任的人搭伙建团队。创业是个艰难的过程，才认识1 2 天的人哪怕相谈甚欢，也更好先花足够长的时间先加深了解，建立信任。一个人创业是个孤独的过程，2个人无论在精神，技能，分工上往往有更好的效果

　　找到一个好的产品切入点：

　　1.你的产品是为谁服务的, 可以一句话清晰描述的明确用户群(所有上网用户不是答案，对于一个早期产品，更好找到一群需要的核心用户，试图满足越多的用户，往往你的产品会越复杂，越不能让所有人满意)

　　2.可以一句话说清楚的，产品核心需求和核心功能，如果这两点不能在两句话说清楚，就不是一个好的切入点。另外不要把你自己的假定和需求当作用户的需求

　　选择切入点的时候不要over fancy,

　　不是一定要做没人做过的东西，借鉴已有的应用和模式做增量创新或整合式创新其实也是一条好的路，起码是验证过的用户需求和商业模式，只要你做出好的区隔点。做新的需求的话，更好确定这个需求一年内有明显的量，再远的话，更好能找到一个一年内有的一个中间过渡需求点。

　　在开始之前，还要想清楚

　　如何推广和接触你定义的核心用户，有没有低成本用户和流量获取渠道，根据产品不同，可能是好的用户传播机制，seo,sns网站，api合作，用户数据库群发，论坛，下载站，网吧，网址站，捆绑，预置，网盟，appstore朋友帮忙等等。尽量利用各种开放平台。如果没有早期的低成本的用户获取或推广渠道，那除非你的产品可以早期赚钱，否则就不要做。

　　早期的赚钱方法

　　早期的赚钱方法不等与产品的终商业模式。早点赚钱的重要性：

　　1.你永远没法预测拿到下一笔钱要多久，收入可以让团队活下去，并且在投资人面前获得主动权

　　2.任何推广都是有成本的，哪怕是"免费"的，如过每个用户获取可以带来收入，那可以把发展速度提高好几倍

　　早期的赚钱方法务求简单，可以是网盟，卖流量，卖用户，卖道具，特定服务收费，电子商务，以不需要复杂商务运营为宜

　　只有以下情况你可以开始不考虑收入：1.产品有非常便宜的用户获取成本 2.产品有非常便宜的用户运营成本 3.产品有巨大的潜在用户数

　　如果一个项目既没有早期赚钱的方法，又不符合上述条件，那这个项目就不适合小团队白手起家创业，

　　启动产品开发

　　基本原则：用快的速度开发出核心功能，尽快发布，尽快获得用户测试反馈，尽快改进(或放弃)

　　像微软那样，用12个月做出一个精品或庞然大物是不适合互联网，尤其是小团队。团队的个阶段是摸索方向，强调的是低成本，快速。你一开始的所有计划其实只是对用户和市场的假定而已，小团队的钱和资源也都有限，必须先快速的找个办法验证方向

　　所以产品的个版本的目的是验证用户需求和反馈，而不是做一个完美无缺功能丰富的版本。版应该集中于开发出核心功能和核心需求，用户花70%时间的功能，放弃非核心需求。比如下载器，下载速度是核心需求，杀毒，登录，社交可能就是外围需求。

　　个版本尽量定义为 2-4 个人可以在2-4个月内开发出来，可以给几百上千个用户用。如果预期超过这个时间和资源，就削减外围功能和简化设计，保证在钱和资源，时间用完前，即使次探索方向错误，还能做数次探索。无论多复杂的互联网产品，我还没有见过不能消减到这个开发周期内作出初始版的。

　　1.尽量使用现成的代码框架，模版，开源项目，api，使用现成的工具，哪怕不是符合需要，工程背景的创业者往往喜欢开发自有架构和技术，长期来说这个是竞争优势，但这个可以等验证了用户需求，有了用户量在重构

　　2.只要满足用户需求，版可以用尽量简单的解决方案，比如部分后台和算法，可用先静态页面，人工干预的方法解决

　　3.专注 80%的精力放在核心功能上，一次只做一个方向，一个核心需求的探索，核心要做到比较完美，除非失败，再做下个方向探索，绝不同时做两个方向。

　　4.快速，稳定永远是要求，不管是网站还是软件，基本做到这两点是发布的前提，功能可以削减，有问题的功能可以先不开放

　　5.产品要有明显，方便的用户反馈接口，重视用户反馈

　　6.外围功能，尤其是网站，要做到一旦提出，可在数天内实施验证，如果超过，可以考虑不做在版，保证核心需求

　　7.严格进度，日毕日清，如遇严重问题瓶颈，不要拖延或过分纠缠，尽早解决或调整计划，或者迅速放弃

　　8.找到所有相似，相关，上下游产品，充分研究学习

　　9.想清楚你要验证的用户行为和数据是什么，做好数据跟踪分析模块。盲目的数据收集没有意义，发布前要有明确的发布目标和验证目标

　　10.界面简洁，确保核心功能在界面的主要位置，用户可立即找到，一键访问无歧义。这比美观风格更重要

       11.版在不严重影响进度的情况下，尽量为将来考虑可升级的架构，如果矛盾，参考条