在《创业笔记 155：对比几家 APP 的迭代速度》里，我提到了最近一段时间，我们的产品迭代从两周变成三周。我一直隐隐觉得里面存在问题，但没细想解决方案。

同事反馈了一个困惑：感觉目前的迭代是在「削足适履」——每次凑三周的工作量出来，保障三周发布。而不是真正地从用户着手，由需求出发。

前几天在杭州，找大辉、邱岳请教目前开发节奏的问题，沟通过程中，他们提到了一些零散的观点：

  • 三周的开发周期「不可思议」，绝对会贻误战机。比如此前支付宝的一位产品跟邱岳说过类似的话：支付宝现在一年居然才发 24 个版本，问题很大；
  • 一般情况下，产品可能实验 10-20 个功能，才有机会跑出一个可以增长的点（还得看产品能力），如果一年就迭代 10-20 次，实际上几乎没成功可能；
  • Airbnb 的做法其实是不断开发，不断灰度，灰度有数据反馈，没问题才继续放大；
  • 阿里云早期每周二、四发布，目前已经是除了周五、六、日（因为周末发布，后续值班跟进人员不一定足够），其他时候都可以随时发布，回退机制做得好；
  • 抽奖助手（当然抽奖助手是纯小程序不完全一样）几乎每天都有 1 个版本以上的发布，然后根据数据调整；
  • 可以尝试拿一个功能点来跑一遍「流程」，观察里面存在的不合理障碍。观察每个迭代周期过程中是不是存在无效的「等待」时间；