Вывод из довода
Возьмем условную историю одного факапа.
- Сервис XYZ стартовал в 2013 году. С каждым годом увеличивал выручку. Прибыль вкладывали в развитие. Стал лидером сегмента в России. Команда превысила 100 человек.
- В начале 2016-го прибыль стала оставаться после реинвестирования. Идём на шопинг — решили в XYZ — и купили проект ABC за 20 млн. рублей.
- Что-то-пошло-не-так и проект ABC заморозили. Талантов перевели в XYZ. Там же добавили функциональность. Убыток зафиксировали.
Как это принято в технологических стартапах, команда сделала ретроспективу и покаялась.
- “Мы очень поверхностно изучили проект ABC перед покупкой.”
- “Мы не продумали бизнес-модель ABC с учетом специфики своего бизнеса.”
- “Мы не провели аудит кода и не оценили, сколько ресурсов нужно на правильный менеджмент по ABC.”
Разумеется, по щелчку мыши выводы трансформируются в задачи. Когда в следующий раз будем тратить 20 млн. рублей, то следует:
- Глубоко изучить проект перед покупкой.
- Детально продумать модель бизнеса с учётом специфики продукта.
- Провести аудит кода и оценить сколько ресурсов нужно на правильный менеджмент.
— Что здесь сейчас хуже всего?
— Проект XYZ зафиксировал убыток в размере 20 млн. рублей.
Понятно. А сейчас будем искать разрывы между тем, что ЯКОБЫ известно и тем, что СТАЛО известно.
- Можно интегрировать проект ABC в XYZ как дополнительную функциональность для наших клиентов → ABC невозможно интегрировать в XYZ (функционал каннибализует, клиентская база не совпадает, механика продаж различается).
- Основатель XYZ сможет подключаться к управленческой деятельности ABC → Основатель XYZ полностью погружен в материнский проект и физически не может подключаться к проекту ABC.
- Пришло время покупать других игроков → Время покупать других игроков не пришло.
Если расположить проблемы на логической оси, то получится так:
- Время покупать других игроков не пришло потому что…
- ABC невозможно интегрировать в XYZ потому что…
- Основатель XYZ полностью погружен в материнский проект и физически не может подключаться к проекту ABC.
Возвращаемся к антикризисному плану команды XYZ.
Чтобы у основателя появилось время для нового проекта нужно ... ТА-ДАМ! …
- Глубоко изучить проект перед покупкой.
- Детально продумать модель бизнеса с учётом специфики продукта.
- Провести аудит кода и оценить сколько ресурсов нужно на правильный менеджмент.
Как бы мягче сказать, здесь вывод не следует из довода.
В логике команды XYZ системная ошибка. Они перепутали проверку на входе (Due Diligence) и операционное управление (Execution).
Страхует ли план “на будущее” от наступания на те-же-самые-грабли под названием “Проект падает, а разгребать некому”?
Можно потратить любое количество времени ДО покупки ресурса и это не имеет отношения к тому, что происходит В ПРОЦЕССЕ реализации проекта. План “лучше изучить код в следующий раз” никак не решает проблему “у основателя 24 часа в сутках, и все они заняты”.
Сколько ни читай медицинскую карту пациента перед операцией, если у хирурга во время операции заняты руки — пациент умрет.
Есть простой критерий для определения качества вывода.
Правильный вывод — не стенания по прошлому. Правильный вывод — не зарубки на будущее. Правильный вывод — руководство для настоящего.
Текущий план XYZ — рассказ о прошлом и будущем. Он предполагает, что КОГДА в СЛЕДУЮЩИЙ РАЗ соберемся покупать проект, то ПРЕДВАРИТЕЛЬНО:
- Изучим проект по Марианскую впадину.
- Продумаем модель бизнеса до последнего байта.
- Разберем и соберем код трижды (а заодно и управленческие ресурсы оценим).
Предполагается, что при помощи этого плана XYZ со второй попытки станет мультипродуктовой компанией. Потом. Когда пожелает распределить следующие 20 млн. Однако, действовать можно уже сейчас.