The Inside Story of a Small Startup Acquisition (Part 2) | Rob Walling
Роб Уоллинг объясняет, почему он купил стартап HitTail, а не построил новый с нуля. Главные причины: экономия 12-18 месяцев пути до состояния «маховика» (когда бизнес начинает двигаться по инерции), наличие «хорошей основы» у кода, который работает с 2006 года, и резкое снижение рыночного риска благодаря уже платящим клиентам. Автор также противопоставляет покупку готового продукта аутсорсингу разработки и отвечает на внутренний вопрос, остаётся ли он «настоящим основателем», если не писал код v1 сам. Он формулирует свою «Теорию времени до 1.0»: 4-6 месяцев и 300-600 часов на запуск, и считает покупку HitTail выгодной сделкой при его почасовой ставке.
The Inside Story of a Small Startup Acquisition (Part 2)
Внутренняя история покупки маленького стартапа (часть 2)
Why I Bought My Next Startup (Instead of Building It)
Почему я купил свой следующий стартап (вместо того чтобы строить его)
This is part 2 in a series covering my acquisition of HitTail; part 1 went to the top of Hacker News last week and I have a slew of questions from that discussion that I will answer next week.
Это часть 2 серии о моей покупке HitTail; часть 1 попала на вершину Hacker News на прошлой неделе, и у меня накопилась куча вопросов из той дискуссии, на которые я отвечу на следующей неделе.
But first I want to address the most common question I hear when I tell someone I acquired a startup:
Но сначала я хочу ответить на самый частый вопрос, который слышу, когда говорю кому-то, что приобрёл стартап:
Why did you buy instead of building?
Почему ты купил, а не построил?
If you’re a developer you’re probably scratching your head wondering how I could pass up the chance to do the awesome green field development. A new project with no legacy baggage…this is the stuff we live for!
Если вы разработчик, вы, вероятно, чешете в затылке, недоумевая, как я мог упустить шанс заняться шикарной разработкой с нуля. Новый проект без легаси-балласта… это же то, ради чего мы живём!
But I did indeed opt to plunk down my hard earned cash instead of hunkering down for 6 months in my dev cave, and what follows are my reasons for doing so.
Но я действительно решил выложить свои кровно заработанные деньги, а не закрываться на 6 месяцев в пещере разработчика, и далее я расскажу, почему.
Reason #1: Saved 12-18 months
Причина №1: Экономия 12-18 месяцев
I have a little theory that a v1.0 should take 4-6 months from inception to launch. This includes time for marketing (which should start before you write a line of code), planning, development, launch, etc...
У меня есть маленькая теория, что v1.0 должна занимать от 4 до 6 месяцев от идеи до запуска. Сюда входит время на маркетинг (который следует начинать ещё до того, как вы напишете первую строку кода), планирование, разработку, запуск и т. д.
And if you have the luxury of working on it full-time then by all means you should get it out the door faster. Almost without exception, the sooner you get in front of real customers the better off you’ll be.
И если у вас есть роскошь работать над этим полный день, то обязательно выпускайте быстрее. Почти без исключений, чем раньше вы окажетесь перед реальными клиентами, тем лучше для вас.
But in general, this is “Rob’s Theory of Time to 1.0”: 4-6 months, 300-600 hours.
Но в целом это «Теория времени до 1.0 Роба»: 4-6 месяцев, 300-600 часов.
But there’s another time frame, and I call it the “time to flywheel.”
Но есть и другой временной интервал, который я называю «время до маховика» (time to flywheel).
A flywheel is a large, heavy wheel that requires an incredible amount of effort to get moving, but once it’s moving it can continue to do so under its own momentum for quite some time, without additional effort. The time it takes to get your business to “flywheel” will vary, but I’ve found that it’s typically 6-12 months after launch.
Маховик — это большое тяжёлое колесо, для приведения в движение которого требуется огромное усилие, но как только оно движется, оно может продолжать движение под собственной инерцией довольно долго, без дополнительных усилий. Время, необходимое, чтобы ваш бизнес вышел в режим «маховика», варьируется, но я обнаружил, что обычно это 6-12 месяцев после запуска.
“Time to flywheel” is not profitability, but an app is typically on a rapid trajectory towards profitability when it hits.
«Время до маховика» — это не прибыльность, но приложение обычно находится на быстрой траектории к прибыльности, когда оно его достигает.
It’s also after you’ve confirmed you’ve built something people need and are willing to pay money for, and have found your market (some would say product-market fit). You’ll also have some marketing channels that are bringing in new customers for less than they pay you during their time as a customer.
Это также момент, когда вы подтвердили, что построили нечто нужное людям, за что они готовы платить, и нашли свой рынок (кто-то назвал бы это product-market fit). У вас также будут какие-то маркетинговые каналы, которые привлекают новых клиентов дешевле, чем те платят вам за время, проведённое в статусе клиента.
This is the point where you have a bit more work to do in order to scale, and when smart founders who are interested in funding begin to seek it out. My typical estimate when asked how long it takes to get there is 12-18 months. Some companies can pull it off in 9, for others it takes 24 if they are ever able to achieve it.
Это та точка, где у вас остаётся ещё немного работы, чтобы масштабироваться, и когда умные основатели, заинтересованные в финансировании, начинают его искать. Моя обычная оценка, когда меня спрашивают, сколько времени уходит, чтобы туда добраться, — 12-18 месяцев. Некоторые компании могут управиться за 9, у других на это уходит 24 — если им вообще удастся достичь этой точки.
But the sweet spot is around 12-18 months.
Но оптимальный диапазон — это около 12-18 месяцев.
Getting to “flywheel” is a slog. It’s painful (and yet also exhilarating). And frankly, I’m not a patient person when it comes to growing a business.
Дойти до «маховика» — это изнурительный труд. Это больно (и при этом захватывающе). И, откровенно говоря, я не терпеливый человек, когда дело касается роста бизнеса.
Given the hourly rate at which I value my time, and the value I place on 12-18 months of effort, buying an application like HitTail is a ridiculous bargain. It may be the best deal I receive on anything I buy during the next year.
С учётом часовой ставки, по которой я оцениваю своё время, и ценности, которую я придаю 12-18 месяцам усилий, покупка приложения вроде HitTail — это смехотворно выгодная сделка. Возможно, это лучшая сделка, которую я заключу на что-либо в течение следующего года.
Reason #2: It Has “Good Bones”
Причина №2: У него «хорошая основа»
There’s something to be said for acquiring an app that’s already worked out the v1.0 kinks. HitTail has been around since 2006, and although some of the software architecture and code structure leaves something to be desired, a lot of bugs were ironed out in the early days.
Можно много сказать в пользу приобретения приложения, которое уже разобралось с проблемами v1.0. HitTail существует с 2006 года, и хотя кое-что в архитектуре ПО и структуре кода оставляет желать лучшего, многие баги были вычищены в ранние дни.
Any problems that existed when I took it over had crept in over time due to changing APIs, lack of maintenance, and failed hardware.
Любые проблемы, которые существовали, когда я его принял, появились со временем из-за изменений в API, отсутствия поддержки и отказов оборудования.
In general, the code had been purring away for 3 years without intervention, and that indicated one thing to me: this thing had good bones.
В целом, код мирно мурлыкал три года без вмешательства, и это указывало мне на одно: у этой штуки хорошая основа.
“Good bones” is an expression realtors use about a house to indicate that the major systems like plumbing and electrical are solid, but that the house may need cosmetic upgrades like new paint and flooring. It means the house is pretty solid as it stands, and that with a bit of effort it could be more attractive and more valuable.
«Хорошая основа» (good bones) — это выражение, которое риелторы используют про дом, чтобы показать, что основные системы вроде сантехники и электрики надёжны, но дому могут потребоваться косметические улучшения вроде новой краски и напольного покрытия. Это означает, что дом сам по себе довольно крепкий и что с небольшими усилиями он может стать привлекательнее и ценнее.
It’s an expression I would apply to HitTail, and one of the reasons I decided to acquire it.
Это выражение я бы применил к HitTail, и это одна из причин, по которым я решил его приобрести.
Reason #3: Dramatically Reduced Market Risk
Причина №3: Резко сниженный рыночный риск
When you set out to build and launch a product there are three types of risk: product, market and execution.
Когда вы беретесь строить и запускать продукт, существуют три типа риска: продуктовый, рыночный и исполнения.
Product risk looks at whether or not you’ll be able to build the product. These days, most web apps we see have only a small amount of product risk.
Market risk looks at whether there will be people willing to buy your product if you build it. This is the risk factor I encourage founders to look at the most, especially before they write a line of code. Market risk is the deadliest of the three because if you build something for which there is no market, it’s nearly impossible to adjust course later and fix it.
Execution risk is whether you can pull off the whole package. Can you bring everything together, build and launch the product, and get it in front of the right prospects?
Продуктовый риск — это про то, сможете ли вы построить продукт. В наши дни большинство веб-приложений, которые мы видим, имеют лишь небольшой продуктовый риск. Рыночный риск — это про то, найдутся ли люди, готовые купить ваш продукт, если вы его построите. Это тот фактор риска, на который я больше всего призываю основателей обращать внимание, особенно прежде чем они напишут первую строку кода. Рыночный риск — самый смертоносный из трёх, потому что если вы построите что-то, на что нет рынка, потом скорректировать курс и исправить это практически невозможно. Риск исполнения — это про то, сможете ли вы вытянуть весь пакет. Сможете ли вы собрать всё воедино, построить и запустить продукт и донести его до правильных потенциальных клиентов?
Given these, market risk is the one that scares me the most. Every time.
С учётом этого, рыночный риск пугает меня больше всего. Каждый раз.
I have confidence in my ability to execute, but anything I can do to reduce market risk early is a no-brainer. Buying an app with paying customers is one of the best ways to ensure you have something people will pay for.
Я уверен в своей способности исполнять, но всё, что я могу сделать, чтобы заранее снизить рыночный риск, — это очевидное решение. Покупка приложения с платящими клиентами — один из лучших способов убедиться, что у вас есть нечто, за что люди готовы платить.
Reason #4 Better than Outsourcing
Причина №4: Лучше аутсорсинга
I talk a lot about outsourcing. Last year I paid $100 or more to at least 15 contractors ranging from developers to an infographic designer. And I’m a firm believe that you must learn to outsource or hire employees if you want to grow a business.
Я много говорю об аутсорсинге. В прошлом году я заплатил 100 долларов или больше как минимум 15 подрядчикам — от разработчиков до инфографического дизайнера. И я твёрдо верю, что вы должны научиться передавать работу на аутсорс или нанимать сотрудников, если хотите растить бизнес.
But I would take a completed product over a spec every time.
Но я бы каждый раз выбрал готовый продукт вместо спецификации.
Outsourcing works, but avoiding the possibility of hiring a crappy developer, building the wrong feature set, and the enormous amount of time you need to invest to manage a development project is typically well worth the purchase price.
Аутсорсинг работает, но избегание возможности нанять плохого разработчика, построить не тот набор функций и колоссального количества времени, которое необходимо инвестировать в управление проектом разработки, обычно с лихвой стоит цены покупки.
Counter-Reason #1: “If you buy, you’re not a real founder!”
Контр-причина №1: «Если ты покупаешь, ты не настоящий основатель!»
This is from my internal monologue that attempted to talk me out of the acquisition.
Это из моего внутреннего монолога, который пытался отговорить меня от приобретения.
At one point I actually stopped to wonder what people would think of the fact that I didn’t build HitTail myself from the ground up.
В какой-то момент я действительно остановился и задумался, что подумают люди о том, что я не построил HitTail сам с нуля.
Are you a real technical founder if you don’t write every single line of code for your v1? Or at least oversee every single line of code as it’s being written by your team?
Настоящий ли ты технический основатель, если не написал каждую строку кода своей v1? Или хотя бы не контролировал каждую строку кода, пока её писала твоя команда?
I’ve built and launched apps from the ground up in the past. Am I still a real founder if I skip it this time?
Я в прошлом строил и запускал приложения с нуля. Остаюсь ли я настоящим основателем, если в этот раз пропущу этот этап?
The conclusion I came to is that it doesn’t matter.
Вывод, к которому я пришёл: это не имеет значения.
Growing HitTail into a more profitable business is the next phase of my learning (and the next test of my chops). Both personally and career-wise it’s the right decision.
Превратить HitTail в более прибыльный бизнес — это следующая фаза моего обучения (и следующая проверка моих навыков). И с личной, и с карьерной точки зрения это правильное решение.
Everything else is semantics.
Всё остальное — семантика.
Conclusion
Заключение
If you’re interested in hearing more about due diligence, which things I attacked first after the acquisition, thoughts on valuation methods, and answers to other questions from the Hacker News discussion, stick around for part 3.
Если вам интересно услышать больше про due diligence, какие вещи я атаковал в первую очередь после приобретения, мысли о методах оценки и ответы на другие вопросы из дискуссии Hacker News — оставайтесь до части 3.