错误反思4 － 技术类团队最容易犯的错误

讲2个故事。

第一个故事

我们在2014年中下旬刚准备加速增长的时候，我们当时花了大量的时间思考和尝试所谓的“Practice”训练器的功能。当时筹划的一些功能包括：

• 和弦转换训练
• 爬格子训练
• 扫弦训练

当时和弦转换的训练想参照UberChords的方法通过麦克风识别来解决，并且根据用户的演奏情况自适应的调整训练的节奏；爬格子则想参照类似Yousician的方法是别并且自适应训练内容；扫弦则同样想通过类似Beat Detection的方法来识别。这是一套很伟大的想法，也许可以改变人们进行音乐训练的游戏规则。

一切都sounds great，我们是一个技术性的团队，然而我们在对技术方案进行评估的时候，发现开发时间可能会比预估的长很多。

这个时候我们做的决策是：

增加社区，提升用户的活跃度

但是其实这里有2个很致命的错误：

1. 我们在评估要做什么的时候，选择了What we can do，而不是What we must do。所有人在选择的时候都倾向于先做B+的事情，它永远无法导致A+的结果。社区是我们知道How to do的事情，我们在当时做判断的时候这是一部分原因之一。

2. 至于What we must do，当时我们的用户构成和用户反馈来看，绝大部份用户都是新手。这意味着对于新手教学训练的需求会远远大于所谓的交流的需求。虽然交流可以增加所谓的DAU，也会有更好看的数据，但是从product-market fit的角度上来说，提升新手的友好程度的意义会更大于社区交流的意义。更何况，社区会依赖于后续的强运营，这会分散本来就紧缺的Startup的资源。

但是的确，我们没有办法等待3-6个月的开发来解决这些技术问题。这时候，结合What we must do和我们当时的开发速度，最好的方法是用非技术的方法解决新手训练和教学的问题（比如用视频跟弹的方式）。事实上，由于定位不够清晰，我们的新手练习过了近半年才推出，而Competetor却抓住了这个点找到了一个非常好的Tipping Point。

第二个故事

之前我们在做国际市场的时候，习惯使用Email作为用户反馈的渠道，因为国外用户对Email是有强烈的使用习惯以及以来的；换到国内市场之后，我们使用过一段时间Email，也切换过一段时间的美恰，在设计课程练习功能的时候也有当面的访谈和录音备份。

但回想起来，我们团队的PM&Founder在跟进用户反馈时，远远没有国外用户跟进的及时；此外，事实上，我们并没有主动出击，访谈那些潜在的用户；其三，对于仅有用户的访谈和录音我们也没有跟进处理研究。

在CS183B中，Emmett Shear提到的内容中，有3点很重要：

1. 早期，需要主动出击去寻找用户并且访谈，千万不要等着用户来
2. 访谈用户的优先级为：用竞争对手产品的用户 > 不用相关产品的用户 > 我们的用户
3. 迂回和旁敲侧击，是做好用户调查的关键

我们在至少第1点和第2点上都做的不好。国际市场的产品基本上也是等着已有用户的反馈，并且我们极少主动出击。回想起来，在国际市场的成功应该主要取决于2个原因（都和产品技巧无关）：

1. 2012年，移动市场出于一个上升行业
2. 挠自己的痒（37 Signal关于Getting Real里面的名言），我们最早只是在解决自己的痛点而已（所以即便不做用户调查，我们也很清楚的知道产品的第一阶段应该怎么做）

回想起来，之所以我们的产品在后期遇到瓶颈，和我们的产品已经很好的满足了自己的需求有很大的关系。这个时候我们并不知道应该朝哪个方向发力，但是在没有接受太多外界信息的基础上本着直觉在做决策，这也是导致团队有相当长一段时间停滞不前的主要原因。所以：

在早期的product－market fit的时候，Scratch your own itch是一个很好的办法。随着产品的发展，自己很难完整的构成自己产品的用户画像。这个时候为了下一个Tipping Point的增长，必须要充分了解我们的用户，产品的定义也会出现一些转型。用户调查的意义会逐渐增大。

在Reid Hoffman的CS183C中，提到的Blitzscaling把Startup的成长分成了几个不同的阶段，但我还没有看完，回头听一听他对用户调查需要在什么阶段怎么执行的方法论，在回头来补充。