经常听到做产品要快、要卡位、快鱼吃慢鱼，可真的要做到快，并非易事
感受需求变化要快
用户的需求是在不断演化的，也会有突发的、阶跃的需求，要能及时感知需求的变化、以及新的需求
怎么做到呢？一方面是要离用户近，经常听他们抱怨、想要的改进，听他们说最近圈子里开始流行的新东西，听他们说他们的客户的抱怨与新鲜事，总会有坐在办公室里意想不到的收获
另一方面就是要对数据与信息保持敏感，运营监测的数据有哪些和历史数量些微的不匹配，政府开始对政策的变动吹风，最近微博上关于某个话题的讨论开始变多，等等。这些可能都意味着一些变化要发生、或已经发生
比如对于打车软件，最近是不是打车的人变少了？是不是因为最近拼车的人变多了？如果确实捕捉到了拼车有开始成为趋势的苗头，及时在这一点上做好准备、甚至是将重心向其迁移，就不至于在未来的竞争中处于被动
more
内部决策要快
如果公司内部有复杂的Report Line，要反复开会讨论，每个人都要撇清风险，有关系、没关系的人都要签字决策才能通过，等决策出来，黄花菜都凉了
因而，越是大公司越强调所谓的扁平化，重要的部门、业务干脆独立出来，直接向CEO汇报，当年微信的孵化便是如此。华为更是强调让听得到炮声的人做决策
原型设计要快
需求明确、决策通过，产品经理就要能快速设计原型，最好在这个阶段就能抓个典型用户过来验证，避免因为图快而走弯路，后期再改成本可就高了
开发迭代要快
这里的开发不仅指写代码，所有从原型至产品的环节都可涵盖其中，包括界面设计、字符串本地化、甚至是法务部门更新用户许可协议等
不过，软件开发依然是核心，一个很重要的点就是，现有的代码框架要足够好、足够灵活，这样能有好的扩展性，很容易得接入新功能。这就需要长久的积累，不是突击加班就能搞定的
测试验证要快
自动化测试总是要的吧，不然频繁的版本递交会让质量保证团队疲于奔命。据说，淘宝网站的发布计划在非常时期频繁到秒，这对测试就是非常大的挑战
反之，如果上线上个有漏洞的版本，被用户或竞争对手发现，进而大肆宣传，对产品的品牌形象、用户之间的口碑影响可就大了
上线运维要快
比如Apple的AppStore，有奇葩的审批制度，提交的时候就要很小心了，如果被打回来修改，耽误的时间就很多了。尤其是产品上线需要多个步骤、要在多个渠道上线，就要有相应的流程，有条不紊，避免在紧张中犯低级错误
运维部门在新功能上线后就要密切关注其影响，比如正面的是不是在线用户数量变多了、在线时长变长了，或者反面的这一时间的卸载量是不是不正常得增加、用户的抱怨突然多起来、等等。到产品稳定运行之前，这样的关注要非常密切
应变要快
我们并不能总是对未来的事情有充分的预判，事情也并不问题按之前的预期发展，出现意料之外的情况，要能启动相应的预案，或者临时起义来应对
比如，对于跨国公司来讲，如果对手已经突然发起攻击，这边因为时差的原因决策者还在睡觉，那可真是没开打就落后一大截。再比如，突然就爆发了Open SSL的漏洞，产品就要在第一时间打补丁，并通过市场宣传来稳定用户，如果能把坏事变成好事就更好了（比如给Open SSL捐点钱）
小结
快，不只是突然爆发、不只是随机应变，更是平时积累沉淀的检验。扎扎实实做好基本功，才能以不变应万变