Tipping Point

A collection of 2 posts
扩张

CS183C笔记 - 再谈Scale的速度

在这篇文章 [https://www.ming.rocks/cuo-wu-fan-si-5-rong-zi-de-jie-dian/] 中,我曾经提到过我们之前在Scale过程中反思的错误。Paul Grahm则反复强调“Do things that don't scale” [http://paulgraham.com/ds.html]。 Reid在谈到Blitzscaling的时候,也反复强调,需要先找到Product-Market-Fit ,再考虑Scale的事情。这个对于LinkedIn这种慢公司,以及NextDoor这种慢方向(第一年只创建了100多个邻居关系),都是Critical的。 第二点是Hiring Slowly。AirBnb花了9个月找到第一个员工,NextDoor则花了6个月,Instagram被收购的时候只有11人。Eric Schmidt、Reid Hoffman、John Lilly等等所有的人都在强调寻找最优秀的人才。 第三点是Capital Efficient。Ann Miura Ko就非常提倡这一点。此外,对于慢公司NextDoor而言,Nir
2 min read
错误

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

讲2个故事。 第一个故事 我们在2014年中下旬刚准备加速增长的时候,我们当时花了大量的时间思考和尝试所谓的“Practice”训练器的功能。当时筹划的一些功能包括: * 和弦转换训练 * 爬格子训练 * 扫弦训练 当时和弦转换的训练想参照UberChords的方法通过麦克风识别来解决,并且根据用户的演奏情况自适应的调整训练的节奏;爬格子则想参照类似Yousician 的方法是别并且自适应训练内容;扫弦则同样想通过类似Beat Detection的方法来识别。这是一套很伟大的想法,也许可以改变人们进行音乐训练的游戏规则。 一切都sounds great,我们是一个技术性的团队,然而我们在对技术方案进行评估的时候,发现开发时间可能会比预估的长很多。 这个时候我们做的决策是: 增加社区,提升用户的活跃度 但是其实这里有2个很致命的错误: 1. 我们在评估要做什么的时候,选择了What we can do,而不是What we must do。所有人在选择的时候都倾向于先做B+的事情 [http://blog.ming.rocks/how-to-operate
5 min read