Как проверять гипотезы
Два месяца назад мы с менти запустили эксперимент, который не достиг тех результатов, на которые мы надеялись.
Во многих командах такой исход превращается в разбор полётов с поиском и наказанием виноватых. Энергия и время уходят на суд вместо обсуждения следующих шагов. В своё время я тоже проводил ретроспективы, которые превращались в судебные заседания. И это был неверный подход.
В этот раз мы поступили иначе. Важно признать, не все гипотезы подтверждаются. И чем быстрее и дешевле мы их проверяем, тем быстрее находим правильное направление для развития бизнеса. Но гипотезы нужно уметь формулировать. Когда запускаешь эксперимент, важно обозначить: мы проверяем гипотезу X, критерий успеха — Y, бюджет и срок — Z.
Кроме того, важно фиксировать и итог, и выводы. Формулировка «не сработало» — плохой итог, из которого сложно извлечь пользу. Гораздо ценнее фиксировать конкретный вывод. Например: «найм сейлза без понятного позиционирования продукта и сопровождения со стороны человека со стратегическим мышлением не даёт результата в продаже B2B-услуг». Такой вывод становится основой для новых гипотез.
Команда, которая умеет спокойно фиксировать неудачные эксперименты, не тратит время впустую и рационально относится к неудачам. Пока другие устраивают разборки, они фиксируют выводы и запускают следующую гипотезу.
И да, иногда проверка гипотез может стоить дорого. Но иногда ещё дороже стоит её непроверка.
Два месяца назад мы с менти запустили эксперимент, который не достиг тех результатов, на которые мы надеялись.
Во многих командах такой исход превращается в разбор полётов с поиском и наказанием виноватых. Энергия и время уходят на суд вместо обсуждения следующих шагов. В своё время я тоже проводил ретроспективы, которые превращались в судебные заседания. И это был неверный подход.
В этот раз мы поступили иначе. Важно признать, не все гипотезы подтверждаются. И чем быстрее и дешевле мы их проверяем, тем быстрее находим правильное направление для развития бизнеса. Но гипотезы нужно уметь формулировать. Когда запускаешь эксперимент, важно обозначить: мы проверяем гипотезу X, критерий успеха — Y, бюджет и срок — Z.
Кроме того, важно фиксировать и итог, и выводы. Формулировка «не сработало» — плохой итог, из которого сложно извлечь пользу. Гораздо ценнее фиксировать конкретный вывод. Например: «найм сейлза без понятного позиционирования продукта и сопровождения со стороны человека со стратегическим мышлением не даёт результата в продаже B2B-услуг». Такой вывод становится основой для новых гипотез.
Команда, которая умеет спокойно фиксировать неудачные эксперименты, не тратит время впустую и рационально относится к неудачам. Пока другие устраивают разборки, они фиксируют выводы и запускают следующую гипотезу.
И да, иногда проверка гипотез может стоить дорого. Но иногда ещё дороже стоит её непроверка.
👍4🔥2
Маркетинговый план без ROI
Недавно разбирал маркетинговый план одной компании. Ребята делают B2B-продукт, оборот около 120 млн. в год. Маркетолог принёс документ: контент-план, SEO, конференции, email-рассылки, вебинары несколько раз в квартал. Красиво оформлено, всё расписано по месяцам.
Я сразу спросил: «Сколько это должно принести в деньга? Какой ROI?» Пауза. «Ну, мы планируем вырасти по трафику на 30%, увеличить количество заявок вдвое». Хорошо. А сколько из этих заявок конвертируется в контракты? Ещё пауза. Какой средний чек? Молчание.
В таком формате это не маркетинговый план. Это список активностей. Иногда маркетинг живёт в своей системе координат, где главная единица измерения — лиды. Написали статью — пришло 15 заявок, значит, статья сработала. Провели вебинар — зарегистрировались 200 человек, значит, вебинар удался. Но никто не смотрит дальше: из этих 15 заявок сколько стали клиентами? С какой маржой? Окупила ли статья время редактора и команды?
У меня был клиент — небольшая компания. Они исправно вели блог, публиковали две статьи в неделю и делали это два года. Трафик на блог был приличный. Когда мы начали разбираться, выяснилось, что за два года ровно два клиента пришли из блога. Суммарно — на 600 тысяч рублей. А только на написание статей ушло около 1,5 млн: зарплата контент-менеджера плюс редактор на аутсорсе.
Канал работал в минус, но никто этого не считал, потому что трафик рос и «значит, всё правильно».
Чтобы маркетинговый план стал финансовым инструментом, нужно протянуть метрику от каждой активности до денег. Выглядит это так: берёте канал — например, конференцию. Стоимость участия — 150 тысяч рублей, плюс три дня работы сейлза и маркетолога. Итого вложили условно 200 тысяч.
Исторически с похожих конференций приходило 5–7 тёплых контактов, из которых закрывалось 1–2 сделки. Средний чек — 800 тысяч рублей, маржа — 40%. Значит, ожидаемая отдача — где-то 320–640 тысяч рублей маржи. Экономика сходится — едем. Если конференция новая и истории нет, ставите минимальный прогноз, делаете один раз, смотрите результат, а потом решаете.
То же самое с контентом. Статья стоит 20 тысяч рублей и время команды. Какой процент читателей таких материалов исторически оставляет заявку? Какой процент заявок переходит в контракт? Сколько нужно таких статей, чтобы получить один контракт?
Если ответов нет — это первое, что нужно посчитать и исправить. Маркетолог привык отчитываться охватами, руководитель привык этому радоваться, и оба живут в комфортной иллюзии, что «работаем, растём». Но когда приходит время резать бюджет или наоборот масштабироваться, никто не может ответить на вопрос, во что вложить деньги.
Переформатировать план несложно. Нужно добавить три колонки к каждой активности: сколько стоит, сколько ожидаем получить контрактов, сколько это должно принести маржи.
Первые два-три цикла цифры будут кривыми, и это нормально. Вы просто не привыкли считать. Зато через квартал у вас появятся реальные данные, и вы наконец увидите, какие каналы развивают бизнес, а какие просто создают иллюзию деятельности.
Маркетинговый план без привязки к деньгам это булшит.
Недавно разбирал маркетинговый план одной компании. Ребята делают B2B-продукт, оборот около 120 млн. в год. Маркетолог принёс документ: контент-план, SEO, конференции, email-рассылки, вебинары несколько раз в квартал. Красиво оформлено, всё расписано по месяцам.
Я сразу спросил: «Сколько это должно принести в деньга? Какой ROI?» Пауза. «Ну, мы планируем вырасти по трафику на 30%, увеличить количество заявок вдвое». Хорошо. А сколько из этих заявок конвертируется в контракты? Ещё пауза. Какой средний чек? Молчание.
В таком формате это не маркетинговый план. Это список активностей. Иногда маркетинг живёт в своей системе координат, где главная единица измерения — лиды. Написали статью — пришло 15 заявок, значит, статья сработала. Провели вебинар — зарегистрировались 200 человек, значит, вебинар удался. Но никто не смотрит дальше: из этих 15 заявок сколько стали клиентами? С какой маржой? Окупила ли статья время редактора и команды?
У меня был клиент — небольшая компания. Они исправно вели блог, публиковали две статьи в неделю и делали это два года. Трафик на блог был приличный. Когда мы начали разбираться, выяснилось, что за два года ровно два клиента пришли из блога. Суммарно — на 600 тысяч рублей. А только на написание статей ушло около 1,5 млн: зарплата контент-менеджера плюс редактор на аутсорсе.
Канал работал в минус, но никто этого не считал, потому что трафик рос и «значит, всё правильно».
Чтобы маркетинговый план стал финансовым инструментом, нужно протянуть метрику от каждой активности до денег. Выглядит это так: берёте канал — например, конференцию. Стоимость участия — 150 тысяч рублей, плюс три дня работы сейлза и маркетолога. Итого вложили условно 200 тысяч.
Исторически с похожих конференций приходило 5–7 тёплых контактов, из которых закрывалось 1–2 сделки. Средний чек — 800 тысяч рублей, маржа — 40%. Значит, ожидаемая отдача — где-то 320–640 тысяч рублей маржи. Экономика сходится — едем. Если конференция новая и истории нет, ставите минимальный прогноз, делаете один раз, смотрите результат, а потом решаете.
То же самое с контентом. Статья стоит 20 тысяч рублей и время команды. Какой процент читателей таких материалов исторически оставляет заявку? Какой процент заявок переходит в контракт? Сколько нужно таких статей, чтобы получить один контракт?
Если ответов нет — это первое, что нужно посчитать и исправить. Маркетолог привык отчитываться охватами, руководитель привык этому радоваться, и оба живут в комфортной иллюзии, что «работаем, растём». Но когда приходит время резать бюджет или наоборот масштабироваться, никто не может ответить на вопрос, во что вложить деньги.
Переформатировать план несложно. Нужно добавить три колонки к каждой активности: сколько стоит, сколько ожидаем получить контрактов, сколько это должно принести маржи.
Первые два-три цикла цифры будут кривыми, и это нормально. Вы просто не привыкли считать. Зато через квартал у вас появятся реальные данные, и вы наконец увидите, какие каналы развивают бизнес, а какие просто создают иллюзию деятельности.
Маркетинговый план без привязки к деньгам это булшит.
33🔥4
Как ИИ разбирает мои встречи и хранит важное
Полтора года назад я оказался в неприятной ситуации. Сижу после созвона и пытаюсь вспомнить, кто, кому и что обещал. Встреча закончилась всего два часа назад, но я весь день был рассеянным и почти ничего не зафиксировал. Переспрашивать о договорённостях было бы странновато.
Тогда я решил сделать так, чтобы ничего не забывалось, а вся информация о моих встречах сохранялась дословно. И выстроил систему из ИИ-агентов. Первая версия была собрана на n8n, но позже я полностью переписал её с нуля с помощью вайб-кодинга. Расскажу, как она устроена.
Каждая встреча заранее запланирована в календаре и проходит в Телемосте с использованием встроенной транскрибации. После встречи на почту приходит .txt-файл. Иногда в нём встречаются неточности, но агенту этого достаточно, чтобы извлечь весь контекст разговора.
По триггеру агент получает файл и извлекает из него контекст, задачи и договорённости. Промпт настроен так, чтобы учитывать только то, что прозвучало явно. Никаких интерпретаций, предположений или догадок. Только точные договорённости и задачи без лишней информации. Вся магия в промпте и LLM, которая его обрабатывает. Я использую Claude Sonnet 4.6.
После того как агент обработает транскрипт, мне в Telegram приходит саммари. К нему прикладываются исходный транскрипт и список задач и договорённостей в формате Markdown. Такой формат удобно читать самому и при необходимости снова отдать LLM. Материалы я могу сразу переслать человеку, с которым у нас была встреча.
Агент все сохраняет в Obsidian. Каждая встреча превращается в отдельную заметку с набором метаданных. Заметки раскладываются по папкам «год → месяц», поэтому в истории встреч легко ориентироваться.
Название заметки формируется на основе события в календаре. Оттуда же подтягиваются участники, дата, время, проект и другие метаданные. Они записывается в свойства заметки.
Участники встречи тоже оформляются как отдельные заметки, поэтому Obsidian постепенно обрастает перелинковкой. Достаточно открыть заметку человека, чтобы увидеть все встречи с его участием, а из заметки встречи можно перейти к информации о любом участнике.
Но это только начало. Дальше в работу вступают другие агенты: один помогает находить идеи для новых постов, извлекая их из заметок, другие ставят задачи и следят за их выполнением. Но это уже тема для следующего поста.
Кстати, если вы хотите собрать похожую систему у себя, я могу поделиться своими наработками.
Полтора года назад я оказался в неприятной ситуации. Сижу после созвона и пытаюсь вспомнить, кто, кому и что обещал. Встреча закончилась всего два часа назад, но я весь день был рассеянным и почти ничего не зафиксировал. Переспрашивать о договорённостях было бы странновато.
Тогда я решил сделать так, чтобы ничего не забывалось, а вся информация о моих встречах сохранялась дословно. И выстроил систему из ИИ-агентов. Первая версия была собрана на n8n, но позже я полностью переписал её с нуля с помощью вайб-кодинга. Расскажу, как она устроена.
Каждая встреча заранее запланирована в календаре и проходит в Телемосте с использованием встроенной транскрибации. После встречи на почту приходит .txt-файл. Иногда в нём встречаются неточности, но агенту этого достаточно, чтобы извлечь весь контекст разговора.
По триггеру агент получает файл и извлекает из него контекст, задачи и договорённости. Промпт настроен так, чтобы учитывать только то, что прозвучало явно. Никаких интерпретаций, предположений или догадок. Только точные договорённости и задачи без лишней информации. Вся магия в промпте и LLM, которая его обрабатывает. Я использую Claude Sonnet 4.6.
После того как агент обработает транскрипт, мне в Telegram приходит саммари. К нему прикладываются исходный транскрипт и список задач и договорённостей в формате Markdown. Такой формат удобно читать самому и при необходимости снова отдать LLM. Материалы я могу сразу переслать человеку, с которым у нас была встреча.
Агент все сохраняет в Obsidian. Каждая встреча превращается в отдельную заметку с набором метаданных. Заметки раскладываются по папкам «год → месяц», поэтому в истории встреч легко ориентироваться.
Название заметки формируется на основе события в календаре. Оттуда же подтягиваются участники, дата, время, проект и другие метаданные. Они записывается в свойства заметки.
Участники встречи тоже оформляются как отдельные заметки, поэтому Obsidian постепенно обрастает перелинковкой. Достаточно открыть заметку человека, чтобы увидеть все встречи с его участием, а из заметки встречи можно перейти к информации о любом участнике.
Но это только начало. Дальше в работу вступают другие агенты: один помогает находить идеи для новых постов, извлекая их из заметок, другие ставят задачи и следят за их выполнением. Но это уже тема для следующего поста.
Кстати, если вы хотите собрать похожую систему у себя, я могу поделиться своими наработками.
👍7
С 27 по 29 августа мой приятель Ваня Ярославцев из Alto проводит конференцию AI Growth Days (ex-AGDays).
Я уже выступал на этой конференции со своим докладом, а теперь Ваня позвал меня в программный комитет. Это означает, что вы можете прислать мне свой доклад про AI. Темы для выступлений можно посмотреть на сайте. В этом году основная — искусственный интеллект для роста бизнеса.
В программе три дня пользы и общения:
🔴 27 августа: pre-party конференции — знакомимся и настраиваемся на продуктивную пятницу.
🔴 28 августа: официальная программа — более 20 спикеров и два зала. «Бизнес» — про рост продаж и эффективности для заказчиков, «Профи» — про развитие производства и разработки для IT-компаний и агентств. Вечером — after-party с уральским размахом.
🔴 29 августа и в выходные: экскурсия по стрит-арту Екатеринбурга и digital-баня.
AI Growth Days — самое значимое событие про искусственный интеллект на Урале в этом году, и совсем скоро здесь соберётся 200+ участников.
Следить за анонсами: @agdays
Купить билеты и посмотреть программу: agday.ru
Я уже выступал на этой конференции со своим докладом, а теперь Ваня позвал меня в программный комитет. Это означает, что вы можете прислать мне свой доклад про AI. Темы для выступлений можно посмотреть на сайте. В этом году основная — искусственный интеллект для роста бизнеса.
В программе три дня пользы и общения:
AI Growth Days — самое значимое событие про искусственный интеллект на Урале в этом году, и совсем скоро здесь соберётся 200+ участников.
Следить за анонсами: @agdays
Купить билеты и посмотреть программу: agday.ru
Please open Telegram to view this post
VIEW IN TELEGRAM
❤2🔥1
Клиенты платят не за то, что ты думаешь
Есть один момент, который я наблюдаю у фаундеров. Они строят продукт вокруг гипотезы, которая кажется им настолько очевидной, что проверять её даже не имеет смысла. Кажется, что это само собой разумеется.
Год назад я консультировал основателя продукта в корпоративном сегменте. Он был уверен, что главная боль его клиентов — безопасность данных. Весь сайт про это. Презентация про это. Онбординг выстроен так, что о безопасности говорится буквально на каждом экране.
Потом по моей рекомендации он провёл двадцать глубинных интервью без наводящих вопросов. И безопасность не всплыла ни разу. Зато большинство клиентов в разных формулировках говорили об одном и том же. Именно это и оказалось основной причиной, по которой они покупают его продукт.
Такая подмена реальности происходит потому, что основатели влюблены в проблему, которую решали, когда придумывали продукт. Или в проблему, о которой где-то читали.
А когда он понял, что основная боль клиентов совсем в другом, убрал ненужные фразы с сайта и переписал презентационные и рекламные материалы. Сделал акцент на том, что действительно важно клиенту, и стал продавать именно то, за что его выбирали. Обороты и доходы компании начали существенно расти.
Вот такая история у меня для вас сегодня.
Есть один момент, который я наблюдаю у фаундеров. Они строят продукт вокруг гипотезы, которая кажется им настолько очевидной, что проверять её даже не имеет смысла. Кажется, что это само собой разумеется.
Год назад я консультировал основателя продукта в корпоративном сегменте. Он был уверен, что главная боль его клиентов — безопасность данных. Весь сайт про это. Презентация про это. Онбординг выстроен так, что о безопасности говорится буквально на каждом экране.
Потом по моей рекомендации он провёл двадцать глубинных интервью без наводящих вопросов. И безопасность не всплыла ни разу. Зато большинство клиентов в разных формулировках говорили об одном и том же. Именно это и оказалось основной причиной, по которой они покупают его продукт.
Такая подмена реальности происходит потому, что основатели влюблены в проблему, которую решали, когда придумывали продукт. Или в проблему, о которой где-то читали.
А когда он понял, что основная боль клиентов совсем в другом, убрал ненужные фразы с сайта и переписал презентационные и рекламные материалы. Сделал акцент на том, что действительно важно клиенту, и стал продавать именно то, за что его выбирали. Обороты и доходы компании начали существенно расти.
Вот такая история у меня для вас сегодня.
❤4👍2
Регламенты не внедряются сами
Разбирали с командой клиента ситуацию. Руководители написали регламент постановки задач с примерами и шаблонами. Менеджеры пробежались глазами по документу, кивнули и продолжили ставить задачи по-старому.
Почему?
Потому что старый способ по-прежнему проще и привычнее. «По-старому» почти всегда побеждает «по-новому», если за новым подходом не стоит ничего, кроме ещё одного документа в корпоративной Wiki.
Проблема большинства регламентов не в том, что они плохо написаны. Проблема в том, что компании внедряют документы, но не внедряют новое поведение.
Недостаточно написать хороший регламент и сказать: «Теперь работаем так». Нужно сделать новый способ работы понятным, обязательным и контролируемым.
Что для этого можно сделать?
Сначала соберите обратную связь у тех, кто будет работать по регламенту, до того как документ станет финальным. Не просто спросите: «Что думаете?», а попросите конкретные замечания: что здесь может не сработать, где возникнут сложности и как можно улучшить.
Это полезно сразу по нескольким причинам. Сотрудники начинают воспринимать регламент не только как очередное правило, спущенное сверху, а как процесс, в создании которого они участвовали. Именно исполнители часто замечают ограничения, которые не видны руководителю. А иногда обсуждение показывает, что проблема вообще в разном понимании самого процесса.
Обязательно установите дедлайн на ознакомление. Например: «до пятницы, 18:00».
Если до этого момента комментариев нет, считаем, что замечаний к документу у сотрудника тоже нет. После этого аргумент «я не согласен» уже не работает.
Но одного ознакомления всё равно недостаточно. Нужно заранее определить дату, с которой новый порядок становится обязательным, и убрать возможность продолжать работать по-старому.
Если задача должна ставиться по новому шаблону, то в другом формате она просто не принимается в работу. Иначе, если новый процесс можно без последствий игнорировать, его будут игнорировать.
Назначьте ответственного, который будет следить за применением регламента в работе. При этом не обязательно резко вводить изменения во всей компании. Возьмите один проект или небольшую команду и попробуйте новый подход там. Пусть они поработают по регламенту несколько недель. Соберите статистику и посмотрите, что изменилось: стало ли меньше ошибок и потерянного времени.
Тогда у вас появится реальный пример. Остальным гораздо проще «продать» то, что уже работает у коллег, чем то, что просто написано в Wiki. Особенно если новый регламент показал измеримый результат.
Регламент это всего лишь артефакт. А изменение поведения сотрудников — проект со сроками, ответственными, контрольными точками и метриками. Если относиться к внедрению регламента как к публикации документа, он будет пылиться в Wiki. Если относиться к нему как к проекту по изменению поведения, то люди начнут работать по-новому.
Разбирали с командой клиента ситуацию. Руководители написали регламент постановки задач с примерами и шаблонами. Менеджеры пробежались глазами по документу, кивнули и продолжили ставить задачи по-старому.
Почему?
Потому что старый способ по-прежнему проще и привычнее. «По-старому» почти всегда побеждает «по-новому», если за новым подходом не стоит ничего, кроме ещё одного документа в корпоративной Wiki.
Проблема большинства регламентов не в том, что они плохо написаны. Проблема в том, что компании внедряют документы, но не внедряют новое поведение.
Недостаточно написать хороший регламент и сказать: «Теперь работаем так». Нужно сделать новый способ работы понятным, обязательным и контролируемым.
Что для этого можно сделать?
Сначала соберите обратную связь у тех, кто будет работать по регламенту, до того как документ станет финальным. Не просто спросите: «Что думаете?», а попросите конкретные замечания: что здесь может не сработать, где возникнут сложности и как можно улучшить.
Это полезно сразу по нескольким причинам. Сотрудники начинают воспринимать регламент не только как очередное правило, спущенное сверху, а как процесс, в создании которого они участвовали. Именно исполнители часто замечают ограничения, которые не видны руководителю. А иногда обсуждение показывает, что проблема вообще в разном понимании самого процесса.
Обязательно установите дедлайн на ознакомление. Например: «до пятницы, 18:00».
Если до этого момента комментариев нет, считаем, что замечаний к документу у сотрудника тоже нет. После этого аргумент «я не согласен» уже не работает.
Но одного ознакомления всё равно недостаточно. Нужно заранее определить дату, с которой новый порядок становится обязательным, и убрать возможность продолжать работать по-старому.
Если задача должна ставиться по новому шаблону, то в другом формате она просто не принимается в работу. Иначе, если новый процесс можно без последствий игнорировать, его будут игнорировать.
Назначьте ответственного, который будет следить за применением регламента в работе. При этом не обязательно резко вводить изменения во всей компании. Возьмите один проект или небольшую команду и попробуйте новый подход там. Пусть они поработают по регламенту несколько недель. Соберите статистику и посмотрите, что изменилось: стало ли меньше ошибок и потерянного времени.
Тогда у вас появится реальный пример. Остальным гораздо проще «продать» то, что уже работает у коллег, чем то, что просто написано в Wiki. Особенно если новый регламент показал измеримый результат.
Регламент это всего лишь артефакт. А изменение поведения сотрудников — проект со сроками, ответственными, контрольными точками и метриками. Если относиться к внедрению регламента как к публикации документа, он будет пылиться в Wiki. Если относиться к нему как к проекту по изменению поведения, то люди начнут работать по-новому.
👍3❤1
О вайб-кодинге и вреде автоматизации
У меня два стартапа. И периодически меня начинает заносить в автоматизацию. Личные кабинеты, интеграции, агенты.
В эпоху вайб-кодинга, кажется, что многое можно сделать довольно быстро. И моя инженерная составляющая за это «цепляется». Все чаще приходится останавливать себя и задавать вопрос: «Это действительно нужно сейчас?»
В одном из проектов мы разрабатываем корпоративное решение для доступа к международным сервисам. Кстати, если у вас с этим есть проблемы, напишите мне. Так вот. Пару дней назад обсуждали личный кабинет для клиентов, где они смогут управлять подпиской и решать типовые вопросы.
Но клиентов пока немного. Все операции можно делать вручную. И это одна из типичных ошибок — автоматизировать процесс потому, что это можно сделать. В результате время и внимание команды уходят не на продажи, проверку гипотез и вывод продукта на рынок, а на создание инфраструктуры для масштаба, которого пока нет.
Помню показательный кейс. Для международной компании мы несколько месяцев разрабатывали автоматизацию с бюджетом в несколько миллионов. В итоге оказалось, что этой функциональностью пользуются всего два человека. Реально два человека!
Мы были исполнителями, поэтому вопрос о необходимости разработки был на стороне клиента. Но этот кейс мне хорошо запомнился.
Благодаря кодовым агентам стоимость создания автоматизаций резко снизилась, но вырос риск делать автоматизацию ради автоматизации. Потому что технический вопрос «можем ли мы это автоматизировать?» сегодня чаще получает ответ «да».
Нам кажется, что вайб-кодинг работает быстро и за пару часов мы можем автоматизировать что угодно. Но это не так. Даже небольшая автоматизация забирает десятки часов. Как минимум на отладку.
Когда соблазн автоматизировать велик, важно задать вопрос: «Зачем нам автоматизировать это именно сейчас?» Ведь ручной процесс не всегда недостаток, а иногда даже преимущество. Это говорит человек, который большую часть своей жизни занимался автоматизацией.
Ранняя автоматизация может «зацементировать» процесс, который еще можно оптимизировать. Только когда ручная работа начинает регулярно приводить к ошибкам или мешать обслуживать растущее количество клиентов, появляется причина автоматизировать. Но прежде стоит понять: сколько это будет стоить и окупится ли?
Поэтому сейчас я стараюсь придерживаться простого принципа: сначала делаем руками, понимаем, где можно улучшить, считаем экономику и только после этого автоматизируем.
Вижу, что многие с помощью вайб-кодинга бросились автоматизировать всё подряд. Это действительно экономит ресурсы или вы иногда тоже ловите себя на желании автоматизировать просто потому, что теперь это стало легко?
У меня два стартапа. И периодически меня начинает заносить в автоматизацию. Личные кабинеты, интеграции, агенты.
В эпоху вайб-кодинга, кажется, что многое можно сделать довольно быстро. И моя инженерная составляющая за это «цепляется». Все чаще приходится останавливать себя и задавать вопрос: «Это действительно нужно сейчас?»
В одном из проектов мы разрабатываем корпоративное решение для доступа к международным сервисам. Кстати, если у вас с этим есть проблемы, напишите мне. Так вот. Пару дней назад обсуждали личный кабинет для клиентов, где они смогут управлять подпиской и решать типовые вопросы.
Но клиентов пока немного. Все операции можно делать вручную. И это одна из типичных ошибок — автоматизировать процесс потому, что это можно сделать. В результате время и внимание команды уходят не на продажи, проверку гипотез и вывод продукта на рынок, а на создание инфраструктуры для масштаба, которого пока нет.
Помню показательный кейс. Для международной компании мы несколько месяцев разрабатывали автоматизацию с бюджетом в несколько миллионов. В итоге оказалось, что этой функциональностью пользуются всего два человека. Реально два человека!
Мы были исполнителями, поэтому вопрос о необходимости разработки был на стороне клиента. Но этот кейс мне хорошо запомнился.
Благодаря кодовым агентам стоимость создания автоматизаций резко снизилась, но вырос риск делать автоматизацию ради автоматизации. Потому что технический вопрос «можем ли мы это автоматизировать?» сегодня чаще получает ответ «да».
Нам кажется, что вайб-кодинг работает быстро и за пару часов мы можем автоматизировать что угодно. Но это не так. Даже небольшая автоматизация забирает десятки часов. Как минимум на отладку.
Когда соблазн автоматизировать велик, важно задать вопрос: «Зачем нам автоматизировать это именно сейчас?» Ведь ручной процесс не всегда недостаток, а иногда даже преимущество. Это говорит человек, который большую часть своей жизни занимался автоматизацией.
Ранняя автоматизация может «зацементировать» процесс, который еще можно оптимизировать. Только когда ручная работа начинает регулярно приводить к ошибкам или мешать обслуживать растущее количество клиентов, появляется причина автоматизировать. Но прежде стоит понять: сколько это будет стоить и окупится ли?
Поэтому сейчас я стараюсь придерживаться простого принципа: сначала делаем руками, понимаем, где можно улучшить, считаем экономику и только после этого автоматизируем.
Вижу, что многие с помощью вайб-кодинга бросились автоматизировать всё подряд. Это действительно экономит ресурсы или вы иногда тоже ловите себя на желании автоматизировать просто потому, что теперь это стало легко?
Год назад я уже пытался с помощью нейронок перенести свой личный сайт с Webflow на статический стек HTML/CSS/JS, чтобы не зависеть от платформы.
Тогда ничего не получилось. Внешний вид сайта нейронка еще более-менее переносила, но на анимациях и поведении сайта все ломалось. Добиться идентичной копии я не смог.
Прошел примерно год. Вчера я дал Claude Code ссылку на сайт и промпт: «перенеси сайт с Webflow на статический стек, самостоятельно протестируй и добейся того, чтобы отображение, анимации и поведение сайта были максимально идентичными на всех устройствах».
В совокупности Claude проработал около шести часов. Сам переносил сайт, запускал проверки, находил расхождения и исправлял их. В итоге получилась полная копия оригинала. Я больше не привязан к Webflow и могу спокойно отменить подписку за $25 в месяц.
То, во что я тогда уперся и что так и не смог нормально решить за 10 часов, сейчас получилось сделать практически одним промптом. Далее я попросил внести еще несколько улучшений. В итоге сайт стал на 62% легче и вдвое быстрее, при этом полностью сохранив внешний вид, поведение и SEO.
Вот что получилось в итоге: https://www.naumenko.tech
Тогда ничего не получилось. Внешний вид сайта нейронка еще более-менее переносила, но на анимациях и поведении сайта все ломалось. Добиться идентичной копии я не смог.
Прошел примерно год. Вчера я дал Claude Code ссылку на сайт и промпт: «перенеси сайт с Webflow на статический стек, самостоятельно протестируй и добейся того, чтобы отображение, анимации и поведение сайта были максимально идентичными на всех устройствах».
В совокупности Claude проработал около шести часов. Сам переносил сайт, запускал проверки, находил расхождения и исправлял их. В итоге получилась полная копия оригинала. Я больше не привязан к Webflow и могу спокойно отменить подписку за $25 в месяц.
То, во что я тогда уперся и что так и не смог нормально решить за 10 часов, сейчас получилось сделать практически одним промптом. Далее я попросил внести еще несколько улучшений. В итоге сайт стал на 62% легче и вдвое быстрее, при этом полностью сохранив внешний вид, поведение и SEO.
Вот что получилось в итоге: https://www.naumenko.tech
www.naumenko.tech
Александр Науменко — ментор для IT-агентств и цифровых продуктов
Ментор для IT-предпринимателей. Помогаю расти стабильно, не теряя управляемость и деньги. 20 лет опыта, 500 млн ₽ оборот, 120 человек.
🔥5👍4
После AI Growth Days
В воскресенье ночью наконец добрался домой и начал переваривать всё, что произошло за эти несколько дней на крутейшей конференции AI Growth Days.
Конференция получилась невероятно насыщенной! Сильные доклады, много новых идей и той энергии, ради которой хочется приезжать на такие мероприятия.
Новым опытом для меня стало участие в программном комитете. Было интересно оказаться немного по другую сторону конференции и поучаствовать в том, какой она в итоге получилась.
Огромное спасибо Ване, Максу и всей команде Alto за организацию. За таким событием стоит колоссальный объём работы, большая часть которой обычно остаётся за кадром. И спасибо всем, кто приехал, выступал, обсуждал, знакомился и делился своим опытом. Именно люди создают такую запоминающуюся атмосферу!
Вокруг ИИ формируется сильное сообщество. Особенно радует, что разговоры идут уже не только о технологиях, но и о решении бизнес-задач и конкретных цифрах. Ещё год назад это были эксперименты, а теперь уже реальные кейсы и измеримые результаты.
Такие мероприятия позволяют увидеть целостную картину и понять, насколько ты идёшь в ногу с быстро меняющимся IT-миром. Я ехал с уверенностью, что достаточно глубоко разбираюсь в теме ИИ, но в итоге почерпнул несколько важных инсайтов в направлениях, на которые раньше даже не смотрел.
Всем рекомендую посещать конференции — общаться, заводить новые знакомства и выстраивать партнёрства. Кажется, впереди нас ждёт сложное, но очень интересное время.
В воскресенье ночью наконец добрался домой и начал переваривать всё, что произошло за эти несколько дней на крутейшей конференции AI Growth Days.
Конференция получилась невероятно насыщенной! Сильные доклады, много новых идей и той энергии, ради которой хочется приезжать на такие мероприятия.
Новым опытом для меня стало участие в программном комитете. Было интересно оказаться немного по другую сторону конференции и поучаствовать в том, какой она в итоге получилась.
Огромное спасибо Ване, Максу и всей команде Alto за организацию. За таким событием стоит колоссальный объём работы, большая часть которой обычно остаётся за кадром. И спасибо всем, кто приехал, выступал, обсуждал, знакомился и делился своим опытом. Именно люди создают такую запоминающуюся атмосферу!
Вокруг ИИ формируется сильное сообщество. Особенно радует, что разговоры идут уже не только о технологиях, но и о решении бизнес-задач и конкретных цифрах. Ещё год назад это были эксперименты, а теперь уже реальные кейсы и измеримые результаты.
Такие мероприятия позволяют увидеть целостную картину и понять, насколько ты идёшь в ногу с быстро меняющимся IT-миром. Я ехал с уверенностью, что достаточно глубоко разбираюсь в теме ИИ, но в итоге почерпнул несколько важных инсайтов в направлениях, на которые раньше даже не смотрел.
Всем рекомендую посещать конференции — общаться, заводить новые знакомства и выстраивать партнёрства. Кажется, впереди нас ждёт сложное, но очень интересное время.
❤7
Хорошая стратегия помещается на лист А4
Давно не было про стратегию.
Если вы спросите сотрудников, в чем заключается стратегия вашей компании, то, скорее всего, получите несколько разных ответов. Или молчание. Если же они могут более-менее одинаково ее пересказать, то вы уже сильно впереди большинства компаний.
Проблема в том, что во многих бизнесах стратегию не может нормально сформулировать даже собственник. Потому что ему никто толком не объяснял, что стратегия вообще собой представляет и как ее создавать.
В какой-то момент компания решает, что ей нужна стратегия. А раз нужна стратегия, значит, нужна стратегическая сессия. Так вроде принято, да и умные ребята об этом пишут.
Фаундер собирает ключевых сотрудников, увозит их куда-нибудь за город или просто освобождает команду от работы на день-два. Иногда приглашает фасилитатора. Все активно участвуют, обсуждают, спорят, клеят стикеры. Доска постепенно заполняется идеями. А в конце появляется список задач, разбитый по приоритетам, направлениям и кварталам.
Все расходятся с ощущением хорошо проделанной работы. Только есть одна проблема. Это не стратегия. Это список задач.
Через год проходит вторая сессия, и она уже буксует. Все очевидное обсудили в прошлый раз. Основные процессы поправили, часть проблем закрыли.
И тогда начинают появляться задачи другого уровня: «Получить десять крупных клиентов. Вырасти в два раза. Стать лидером рынка. Из мышей превратиться в ежиков». Класс! А как? Вот здесь обычно и обнаруживается, что цели у компании есть, задачи есть, планы есть, а стратегии нет.
Стратегия отвечает на вопрос: за счет чего именно мы собираемся выиграть? И вот тут начинается самое сложное.
Чтобы сформулировать стратегию, недостаточно собрать умных людей в одной комнате. Нужно понимать рынок, его конъюнктуру, клиентов, конкурентов, изменения в отрасли и ограничения самой компании.
И главное, нужно сделать несколько принципиальных выборов.
1. На каком рынке мы вообще хотим работать и почему?
2. Какого клиента хотим привлекать, а от какого готовы отказаться?
3. На чём собираемся строить своё преимущество?
4. Что компания принципиально не будет делать, даже если на этом можно заработать?
5. Куда мы направим ограниченные деньги, время и людей?
Вот это уже стратегические вопросы. И именно здесь роль фаундера критична.
Но не потому, что команда глупее. Просто каждый руководитель смотрит на бизнес через призму своей зоны ответственности. Продажи видят продажи. Маркетинг видит маркетинг. Производство думает о производстве. Финансы смотрят на экономику.
А стратегия требует посмотреть на компанию целиком и сделать выбор между несколькими возможными будущими.
Команда может и должна помогать: приносить данные, спорить, подсвечивать риски, проверять гипотезы, предлагать варианты. Но полностью делегировать ей стратегический выбор нельзя. Именно собственник должен решить, в какую игру играет компания, на что она делает ставку и от чего сознательно отказывается.
А уже после этого можно собирать стратегическую сессию и обсуждать, как эту стратегию реализовать.
И если стратегический выбор действительно сделан, сама стратегия обычно не требует пятидесяти слайдов. Чаще всего она помещается на лист А4.
Давно не было про стратегию.
Если вы спросите сотрудников, в чем заключается стратегия вашей компании, то, скорее всего, получите несколько разных ответов. Или молчание. Если же они могут более-менее одинаково ее пересказать, то вы уже сильно впереди большинства компаний.
Проблема в том, что во многих бизнесах стратегию не может нормально сформулировать даже собственник. Потому что ему никто толком не объяснял, что стратегия вообще собой представляет и как ее создавать.
В какой-то момент компания решает, что ей нужна стратегия. А раз нужна стратегия, значит, нужна стратегическая сессия. Так вроде принято, да и умные ребята об этом пишут.
Фаундер собирает ключевых сотрудников, увозит их куда-нибудь за город или просто освобождает команду от работы на день-два. Иногда приглашает фасилитатора. Все активно участвуют, обсуждают, спорят, клеят стикеры. Доска постепенно заполняется идеями. А в конце появляется список задач, разбитый по приоритетам, направлениям и кварталам.
Все расходятся с ощущением хорошо проделанной работы. Только есть одна проблема. Это не стратегия. Это список задач.
Через год проходит вторая сессия, и она уже буксует. Все очевидное обсудили в прошлый раз. Основные процессы поправили, часть проблем закрыли.
И тогда начинают появляться задачи другого уровня: «Получить десять крупных клиентов. Вырасти в два раза. Стать лидером рынка. Из мышей превратиться в ежиков». Класс! А как? Вот здесь обычно и обнаруживается, что цели у компании есть, задачи есть, планы есть, а стратегии нет.
Стратегия отвечает на вопрос: за счет чего именно мы собираемся выиграть? И вот тут начинается самое сложное.
Чтобы сформулировать стратегию, недостаточно собрать умных людей в одной комнате. Нужно понимать рынок, его конъюнктуру, клиентов, конкурентов, изменения в отрасли и ограничения самой компании.
И главное, нужно сделать несколько принципиальных выборов.
1. На каком рынке мы вообще хотим работать и почему?
2. Какого клиента хотим привлекать, а от какого готовы отказаться?
3. На чём собираемся строить своё преимущество?
4. Что компания принципиально не будет делать, даже если на этом можно заработать?
5. Куда мы направим ограниченные деньги, время и людей?
Вот это уже стратегические вопросы. И именно здесь роль фаундера критична.
Но не потому, что команда глупее. Просто каждый руководитель смотрит на бизнес через призму своей зоны ответственности. Продажи видят продажи. Маркетинг видит маркетинг. Производство думает о производстве. Финансы смотрят на экономику.
А стратегия требует посмотреть на компанию целиком и сделать выбор между несколькими возможными будущими.
Команда может и должна помогать: приносить данные, спорить, подсвечивать риски, проверять гипотезы, предлагать варианты. Но полностью делегировать ей стратегический выбор нельзя. Именно собственник должен решить, в какую игру играет компания, на что она делает ставку и от чего сознательно отказывается.
А уже после этого можно собирать стратегическую сессию и обсуждать, как эту стратегию реализовать.
И если стратегический выбор действительно сделан, сама стратегия обычно не требует пятидесяти слайдов. Чаще всего она помещается на лист А4.
👍3🔥2