😁 Первые недели маркетолог нихрена не делает - это хороший маркетолог? Первые 2 недели в новой компании я вообще не маркетолог, я - врач изучающий медкарту пациента. Я открываю всё, что есть: рекламные кабинеты, воронки, отчеты, CRM, продажи, прошлые гипотезы, подрядчиков, цифры за последние месяцы. Мне нужно понять, что здесь вообще происходит: • Не «какой у нас CPL», а почему он такой. • Не «какая конверсия в продажу», а что происходит с человеком между заявкой и оплатой. • Не «этот канал работает», а за счет чего он работает и можно ли это повторить. Смотрю, что компания уже пробовала. Что давало результат. Что перестали делать, хотя оно работало. Куда уходит бюджет. Где воронка начинает сыпаться. Какие цифры вообще считают - и (мое любимое) можно ли им вообще доверять. И отдельно сверяю показатели с рынком. Иногда оказывается, что с маркетингом все в порядке, а деньги теряются на продажах или дырявой СRM. Иногда, что компания льет огромный бюджет в канал, который никогда не окупится. А иногда, что у компании давно уже все есть для успешного роста, просто оно существует кусками, а не складывается в единую систему. Поэтому я не люблю начинать с вопроса: «что делать?». Сначала ценнее другой: «что происходит с бизнесом прямо сейчас?». Вопрос к вам - через сколько дней после найма маркетолога ждете результат?)

Технология, продукт и компания это разные вещи, хотя я не сразу это поняла. У нас долго был некрасивый фронтенд, и меня это совершенно не беспокоило, потому что за ним была вся сложная часть: CRM, инструменты аутрича, AI-сервисы и куча процессов, которые сначала нужно было просто заставить работать. Я была одержима именно этим, и на интерфейс сил почти не оставалось. Технология работала, продуктом это стало уже позже. Сейчас мы упёрлись в следующий уровень, и он оказался тяжелее обоих предыдущих, потому что здесь уже почти не про код и не про интерфейс. Клиент должен получать обещанное сегодня, а не «в среднем за квартал». Клиентов становится не три, а двадцать пять, и старые способы держать всё под контролем просто перестают работать. Качество не должно зависеть от одного конкретного человека, значит нужны процессы. А ещё нужны плейбуки под конкретных людей и ситуации, потому что одному клиенту важна одна формулировка в письме, а другому совершенно другая. И это не решается тем, что вы наняли ещё разработчиков, мне кажется, именно здесь и видно, кто по-настоящему построил компанию, а кто просто хорошо сделал продукт. В новую категорию зайдут десятки компаний, а лидерами станут единицы, и разница между ними и остальными почти никогда не в технологии, потому что на старте она у всех примерно одинаковая. Не знаю, окажемся ли мы среди лидеров, но точно понимаю, где сейчас основная работа: год назад мы учились делать технологию, потом учились превращать её в продукт, а сейчас учимся строить компанию. И кажется, что третий уровень по-настоящему никогда не заканчивается. А вы на каком уровне? Напишите в комментарии👇🏼

Что делать, если все заинтересованные стороны по-своему правы Одна из сложных ситуаций в работе менеджера продуктов: когда в обсуждении вариантов решения каждый стейкхолдер приводит свои веские аргументы, конфликтующие друг с другом, — но нужно договориться. ➡️ Отдел продаж хочет добавить интеграцию с конкретной системой, потому что без нее крупный клиент не подпишет контракт. ➡️ Команда разработки говорит, что интеграция потребует серьезных изменений в архитектуре и создаст новую статью расходов на поддержку. ➡️ Менеджер продукта уже провел исследование среди действующих клиентов и считает, что ресурсы стоит вложить в другую проблему, которая касается большого сегмента пользователей. ➡️ CEO напоминает, что выход в сегмент, из которого пришел крупный заказчик, — одна из стратегических целей года. Решение предстоит принять, учитывая все аргументы, интересы и последствия. Что особенно важно при этом не упустить — рассмотрим ниже на примере. 1️⃣ Сначала разберитесь, что именно стоит за позицией участника Допустим, менеджер по продажам хочет закрыть сделку, чтобы выполнить KPI и закрыть свои личные финансовые нужды. В разработке треть команды уходит в отпуск, и ресурсов на быстрый запуск интеграции просто нет. Команда продукта уже прошла часть пути для повышения LTV действующих клиентов и не хочет бросать, пока есть возможность вовремя добавить востребованную функцию. А CEO делает на новый сегмент большую ставку из-за его платежеспособности — и надеется за счет этого вывести компанию на самоокупаемость, потому что привлекать инвестиции стало сложнее. 2️⃣ Сведите аргументы к общим критериям Когда каждая сторона защищает свою ценность, нужно привести аргументы к одному знаменателю — стоимости: 🔵 Каковы минимальные требования конкретного клиента и сколько ресурсов потребуется на разработку? 🔵 Какие технические последствия и статьи расходов создаст? 🔵 Какой коммерческий эффект ожидаем? 🔵 Можно ли использовать решение для других клиентов и какой объем рынка им можно охватить?  Тогда становится понятно, между какими величинами стоит выбор. 3️⃣ Проверьте цену отказа от каждого варианта Если не делаем интеграцию, то: 🟦 сохраняем архитектуру; 🟦 экономим ресурс и можем завершить разработку функции для действующих пользователей, от которой ожидаем прироста LTV на 2%; 🟦 рискуем потерять крупного клиента; 🟦 откладываем выход в новый сегмент на 3–4 месяца и теряем возможность получить критически важные Х миллионов, а это означает необходимость срочно искать инвесторов или сокращать издержки. Так становятся ясны возможные последствия не только активных действий, но и бездействия. 4️⃣ Распишите все возможные варианты и последствия Чтобы понять, какой вариант решения действительно будет оптимальным, полезно создать канву для дальнейшего обсуждения:  🔵 исходный контекст и данные; 🔵 варианты решения и их стоимость; 🔵 возможные последствия и риски по каждому варианту, в том числе в денежном выражении; 🔵 необходимые для проверки вопросы.  Это позволяет сделать логику выбора ясной для всех участников. 5️⃣ Найдите способ проверить самое дорогое неизвестное Недостаток каких данных может привести к самой дорогой ошибке в выборе решения? В нашем случае это может быть вопрос о клиенте: действительно ли для заключения сделки нужна полноценная интеграция или основную потребность можно закрыть минимальной версией или даже ручной обработкой данных?  Может быть вопрос о рынке: нужна ли интеграция с этим сервисом еще кому-то из стратегически важного сегмента?  Или технический вопрос: сколько реально будет стоить решение и можно ли сделать его проще и дешевле? На этом этапе важно понять, какой сценарий может сделать решение ошибочным, и найти самый дешевый способ это проверить. 6️⃣ Зафиксируйте, какой вариант выбрали и чем будете жертвовать, если компромисс невозможен Предположим, вы выбрали делать частичную интеграцию для одного клиента с ручными процессами на начальном этапе. Потому что стратегическая ценность клиента очевидна, но другим представителям целевого сегмента интеграция с конкретным сервисом может не понадобиться.  Если стоимость такой разработки все равно высока, нужно понять, с какой инициативы будет переброшен ресурс, который пойдет на интеграцию. А также зафиксировать, в каком случае возможен пересмотр решения. Проделав все шаги, вы получите не только матрицу оценки вариантов и рисков, но и план принятия решений для дальнейших инициатив. Если через месяц отдел продаж снова предложит сделать полноценную интеграцию, не придется заново все обсуждать: понятно, какое решение приняли, на каких основаниях и что должно измениться, чтобы его пересмотреть. @productsense

Как AI-агенты трансформируют компанию? Недавно на воркшопе обсуждали следующий этап работы с AI в компаниях: переход от отдельных чат-ботов к агентам, встроенным в бизнес-процессы компании. Ключевой поинт - Corporate Brain. AI получает доступ к Slack, Jira, созвонам, документам, продуктовой аналитике и репозиториям и связывает разрозненный контекст в единую картину: обсуждение → решение → задача → изменение в продукте → влияние на метрики. На практике такой агент может за несколько минут разобрать backlog и найти связанные задачи и прошлые решения, собрать индивидуальный onboarding-план, сопоставить Jira с ClickHouse, GA, Amplitude и пользовательскими логами, проанализировать PR и коммиты, найти потенциальные проблемы в UX и подготовить гипотезы для команды. Но важный вывод воркшопа: ускорение отдельного сотрудника еще не означает ускорение компании. В одном из примеров AI значительно повысил скорость разработки, но очередь QA выросла с 15 до 55 задач, количество багов увеличилось в 4 раза, а rework - в 6. Поэтому измерять нужно не объем сгенерированного кода или количество AI-запросов, а конечный бизнес-результат. При этом агент нужен не везде. Если задачу надежнее решает обычная автоматизация, API или workflow, усложнять систему агентом нет смысла. Агент особенно полезен там, где нужно работать с большим контекстом, принимать неоднозначные решения, выбирать инструменты и корректировать следующие действия. Главная сложность тоже не в самой LLM. В production быстро появляются вопросы качества данных, доступов, legacy-интеграций, безопасности, стоимости, логирования и контроля действий. Поэтому рабочая схема выглядит примерно так: Goal → Context → Tools → Actions → Verification → Guardrails → Human escalation. И внедрять это лучше постепенно: найти первые реальные кейсы и мотивированных early adopters, измерить эффект и только потом масштабировать. Главная метрика здесь - не токены и не количество пользователей AI, а Cost per Successful Outcome: сколько компании стоит один действительно полезный результат. AI-трансформация - это не "заставить всех дрочить ChatGPT". Это перестроить конкретные бизнес-процессы вокруг новой возможности AI понимать корпоративный контекст, работать с инструментами и выполнять часть работы самостоятельно, но под контролем человека. https://youtu.be/vR_enpahg8M

Оценка мелких задач убивает ваше время Типовая ситуация: клиент постоянно присылает небольшие задачи и переживает, сколько времени займёт каждая. Команда начинает оценивать каждую задачу отдельно, согласовывать, потом объяснять, почему не попали в оценку. По факту оценка иногда занимает больше времени, чем сама работа. С маленькими задачами точность вообще плохо работает. Чтобы нормально оценить некоторые из них, задачу надо почти сделать. А если оценивать «на глаз», погрешность по каждой отдельной задаче будет большой. В итоге коммуникация с клиентом превращается не в работу, а в бесконечный цикл согласования бюджета и времени для мелких задач. Что с этим делать: отказаться от точной оценки мелких задач. Учитываем мелкие задачи постфактум. Сделали задачу, зафиксировали, сколько реально ушло. Чтобы клиент на это согласился, нужно немного изменить процесс: 1) Оценка остаётся, но она становится очень примерной: маленькая, средняя, большая задача. Менеджер проекта это может сделать без похода к разработчику. Клиент и Агентство соглашаются, что это грубая оценка. 2) Договориться о месячном лимите. Обычно поток таких задач укладывается в 10-20 часов в месяц. 3) При явном выходе задачи за лимиты или не попадании в оценку - заранее говорим об этом с клиентом. Большие, сложные и непонятные задачи нужно выносить отдельно и нормально оценивать. А поток маленьких задач лучше продавать почти оптом: грубо обозначать размер, следить за лимитом, заранее предупреждать о выходе за ожидания и оплачивать по фактически потраченным ресурсам. Пост помог подготовить резидент Галеры Михаил Сенсеев 🔵

Ваши бизнес-процессы всегда будут ломаться, и с этим ничего нельзя сделать 🔵Процессы — это то, как вы делаете повторяющиеся вещи: как передаёте клиента из продаж в производство, как исполняете обязательства, как держите свои стандарты. И вся эта конструкция нахер разваливается каждый раз, когда команда утраивается. Работало на 10 - отвалилось на 30. Работало на 30 - сломалось на 90. Это прям управленческое правило, и с ним, к сожалению, НИЧЕГО не сделать. Просто принимаем, плачем и переделываем процессы заново. В позитивном сценарии у вас к этому моменту уже есть наёмные руководители. Тогда всей этой свистопляской управляют они, а вы смотрите со стороны, как они всё разгребают)) Без руководителей это всё прилетит вам. А так вообще регламенты, чек-листы, оргструктуры и куча других скучных штук, которые душные дяди рисуют в учебниках по менеджменту, это реалии предпринимательства. Первые регламенты появляются ещё людях на десяти, дальше их становится больше и пишут их уже руководители. Но сама привычка и культура создавать процессы должна в компании завестись, и отвечают за неё тоже руководители. Как понять, что бизнес-процессы налажены: 🔵Заходите в чат, а там больше нет сообщений ''мы же это уже обсуждали'' 🔵Вас не дёргают одними и теми же тупыми вопросами 🔵Одна и та же услуга для всех клиентов делается одинаково (как в макдаке: куда ни приедешь, чизбургер везде примерно один и тот же) 🔵Новичок погружается за 2-3 недели вместо 3-4 месяцев: пришёл, прочитал обучалки, сделал по чек-листу, готов работать 🔵И главное, вы перестали тушить одни и те же пожары по кругу А если вы сейчас растёте, заложите время на переписывание процессов. Оно всё равно случится. Вопрос только, по плану или в аварийном режиме, когда всё уже горит...

AI убирает одну работу и тут же создаёт другую Сегодня обсуждали с коллегами любопытный парадокс. AI резко снизил порог входа во множество задач. Люди начали делать то, за что раньше даже не брались: разбирать финансы, копаться в своём здоровье, собирать мобильные приложения, автоматизировать процессы, работать с данными и документами. Раньше для этого надо было долго учиться, читать инструкции и набивать руку, а теперь можно быстро получить объяснение, пример, прототип и даже какое-то рабочее решение. Вот только доступность задачи ничего не говорит о глубине её решения. Современный AI часто напоминает университетского профессора, который прекрасно знает теорию, убедительно объясняет материал и щёлкает учебные примеры. Как только знания надо применить в реальной среде: с ограничениями, архитектурой, производительностью, исключениями и контекстом - начинаются проблемы. Модель легко напишет огромный объём текста, обработает массив данных самым неэффективным способом и предложит архитектуру, которая выглядит убедительно, но плохо живёт на практике. Скажем, большой набор данных разумнее один раз превратить в реляционную базу и дальше получать ответы короткими запросами на SQL или Python. Вместо этого ИИ раз за разом прогоняет через контекст тысячи строк, сжигая время и токены. Забавно, что длинные рассуждения и многократная обработка данных - ровно то, на чём зарабатывают поставщики LLM. Но интереснее другое следствие. AI породил огромный объём прототипов, полуготовых решений и новых инициатив, и люди начали встраивать их в бизнес-процессы, не всегда понимая архитектуру, программирование, безопасность и экономику продукта. Всё это теперь нужно проверять, исправлять, интегрировать, защищать и доводить до промышленного уровня. Дальше начинается цепная реакция. Юристы с помощью AI находят в договорах больше несоответствий, и другая сторона получает документ ещё сложнее, на проверку которого уходит ещё больше времени. Предприниматели быстрее собирают прототипы, но потом им нужны разработчики, архитекторы и консультанты, чтобы превратить это в надёжную систему. Компании видят новые возможности и тут же упираются в новые вопросы: где будет реальная экономия, как изменятся процессы, какие появятся риски и кто на самом деле получит прирост производительности. Пока что я вижу, что новой работы ИИ создаёт не меньше, чем убирает и её будет много. @maxvotek | linkedin | substack

Новое применение Claude Подождите! Не проматывайте на следующий канал. В этом посте не будет ни слова про вайб кодинг, который уже всем порядком надоел 😁 Я хочу вам рассказать про новый подход к разработке внутренних систем для оффлайн процессов. Кто когда-нибудь сталкивался с задачей создания системы, которой ежедневно будут пользоваться десятки людей с разными ролями, в разных локациях, с разным контекстом, тот знает насколько сложно продумать все сценарии и ограничить MVP теми функциям, без которых не обойтись. Именно такая задача стояла перед моей командой — система управления стоком мотоциклов для сети из десятков магазинов дилеров-партнеров, которая позволит оцифровать путь от добавления мотоцикла в продажу до его выдачи покупателю. Стадия развития продукта такая, что никакой автоматизации и синхронизации стоков с партнерами нет. У многих из них нет вообще никакой системы для управления своими стоками. Вместо того, чтобы проектировать сложную систему ролей и прав доступа, мы решили сделать 3 ключевых роли, переключиться на интерфейс которых может любой авторизованный пользователь системы. Грубо говоря это тот, кто управляет стоком всех магазинов, тот кто отвечает за актуальность стока определенного магазина или сети магазинов и тот, кто находится в магазине и отвечает за выдачу товара клиенту. В MVP заложили те действия, которые, как мы думаем, должен делать каждый из них. И главное. На каждое действие в системе добавили логи: какой пользователь, что сделал, с каким юнитом, когда и под какой ролью. И доступ админа, который может в удобном интерфейсе отфильтровать логи по всем параметрам и выгрузить их в CSV. Дальше начинается самое интересное, то что теперь доступно любому с подпиской на Claude Cowork. Нахожу в логах какую-то аномалию, например, продавец удалил юнит из системы вместо того, чтобы отметить его как выданный клиенту. Или менеджер стока удалил юнит и через минуту создал такой же с небольшими отличиями. Прошу Claude сделать анализ всех таких кейсов и получаю идеи для доработок — добавить обязательный выбор причины удаления и предупредить, что при продаже нужно использовать другую функцию. И добавить возможность редактировать определенные параметры у юнитов в доступном стоке для нужной роли. Наверное, к этим выводам мы бы пришли сами. После долгих разговоров с операционной командой, наблюдений за их работой и анализа метрик. Но с Claude это стало возможным после двух недель с момента внедрения системы, когда накопилось достаточно логов для анализа. Бонусом стало добавление интерфейса для анализа логов по юниту, который менеджеры операционной команды используют для «расследования» ошибок своих подчиненных и точеного проведения воспитательной работы 😁 Единственный минус — в этом месяце я дважды достиг лимита токенов, что стоило компании $400. Но, уверен, что польза от таких расходов инвестиций будет намного выше. Ведь каждое улучшение системы, сделанное по наводке AI, улучшает эффективность всего продукта и напрямую влияет на бизнес метрики! #lifehacks #aifuture #claude #salmon

Какая работа остаётся фаундеру, когда AI забирает всё больше задач В лекции о самоулучшающихся компаниях и как такую построить YC Partner Том Бломфилд отдельно рассказывает, какая роль остаётся человеку, когда AI становится всё умнее и может делать всё больше работы. Вот тезисы из выступления и ответ на вопрос: • AI теперь не просто про продуктивность. Он про то, чтобы держать весь контекст компании (переписки, данные о продажах, правила, код, инструкции и проч.) «на готове» и использовать их при принятии решений. • Так в компании информация перестаёт передаваться по иерархии (от начальника к исполнителю через менеджеров и наоборот), и это всё меняет — сотрудников нужно меньше, мидл-менеджмент не нужен, появляются новые роли (подробнее есть в лекции). • Том настаивает, что AI может делать работу сам и принимать решения сам. Пример: AI настроен регулярно анализировать воронку, вот он увидел в ней слабое место. Сам поресерчил и придумал, как это улучшить, сам запилил фичу, сам сделал A/B-тест, сам оценил результат, сам залил в финальный продукт. • И это те самые AI-loops, которые помогают сделать самоулучшающуюся компанию. • В такой схеме ценными становятся skills, «навыки» — описанные процессы, как бизнес делает что-то. Не софт, написанный под эти сценарии, а именно описание навыка, как этот процесс правильно выполнять. • И когда модель становится умнее → она просто переписывает код заново, а навык остаётся тем же (и эти навыки пока пишете именно вы, фаундеры). Софт эфемерен, навыки — фундамент. • У компании есть «мозг», который хранит все переписки, все скиллы, все данные — а люди сидят «вокруг», там, где нужно взаимодействовать с реальным миром. Люди — там, куда модели ещё не могут добраться. • Например, публичные выступления, этические вопросы, или моменты, где ставки слишком высоки или присутствуют эмоции. Что-то вроде разговора о расставании кофаундеров — то есть там, где нужно быть человеком, чтобы такое решить. • А ещё и продажи. Продажи следующие ≈20 лет по-прежнему будут строиться вокруг общения людей. • Заканчивает выступление Том вопросом: «Если бы вы запускали ваш бизнес сегодня, стали бы вы её делать в форме самоулучшающейся?». И сам на него отвечает намёком: «Вы только начинаете, у вас нет оправданий, чтобы строить как-то по-другому» Какие мысли? @y_everyday — рефлексируем об акселератор, создавший 100+ стартапов-единорогов

Перечитывал старые посты и этот решил апнуть и, заодно дополнить. Сейчас, уже с позиции предпринимателя, считающего свои кровные, вкладываемые в компанию, могу добавить: иногда то, что вам кажется обязательным, вовсе таковым не является, а ресурсы на это тратятся. Например, не так давно команда просила договориться с одним из преподавателей о доступе слушателей к записям живых занятий, потому что потенциальные студенты часто спрашивают. Прежде чем идти к уважаемому человеку с предложением, я, дабы не быть голословным, запросил у команды статистику по слушателям - кто просил, чего просил, сколько, на подведение которой потребовалось бы некоторое время. В итоге, когда дошел к преподавателю ,выяснил, что с записью он разумеется полностью согласен, изначально предполагал, что она будет, и ничего обосновывать не надо. Вывод я сделал - не стоит делать мозги команде не ради дела, а из своего невроза :) Остается вопрос «как же вовремя эти две ситуации различить?». Вот тут очень помогает команда. Из полей такие вещи неплохо видно и прислушиваться и не улетать в космос очень полезно.

«Какой ИИ - с жиру бесятся, тут бы выжить» Такую реакцию часто вижу в глазах людей из реального сектора, когда рассказываю про нашу работу. Производство, розница, офлайн услуги. Расскажу в ответ на это историю. У нас есть клиент - дистрибьютор напитков, занимается оптовыми поставками пива в региональные магазины. Пол-ярда оборот, хорошо растут. Только есть нюанс - работают на приграничной территории. И они захотели делать умную сверку заказов: чтобы когда торговые представители оформляю 50 ящиков темного в магазин «Продукты у тети Тани», происходила автоматическая проверка - правильный ли заказ? Может, магазин обычно светлое заказывает, а тут ошиблись? Или выбрали 500 ящиков вместо 50 по ошибке. Или наоборот не учли, что жара будет и летом больше обычного берут. Понятно, что там много факторов, нужна история заказов, нужна предиктивная аналитика и все это берется из разных учетных систем, где люди допускают ошибки. Только вот сложность проекта оказалась не в мат.моделировании спроса, а в том, что заказчик работает на территории под обстрелом. И у них регулярные отключения интернета, а то и электричества в целом. В итоге, сервер недоступен, работы стоят. И тут самое интересно. Несмотря на отсутствие электричества, проект не сворачивают. Не говорят «нам бы выжить», понимая, что нужно развиваться и что ошибки в заказах стоят дорого. Автоматизация становится не вишенкой на торте, как бывает в гос.корпорациях, а реальной потребностью. В итоге, мы продолжаем налаживать систему, работая в промежутках, когда есть интернет и электричество.

HR в штат, рекрутёр на фрилансе или агентство — как не прогадать. 🔵 Периодически спрашивают, стоит ли уже брать HR в штат, или можно закрывать вопрос фрилансером или агентством. Рассказываю, как сама к этому подхожу) Фрилансер-рекрутёр: в среднем 30-40 тысяч за закрытие позиции. По деньгам самое выгодное, но минус тот же, что у любого фрилансера - контроль весь на вас. У нас реально был случай: человек взял деньги и забыл про нас 🙃 HR-агентство дороже, но зато есть структура: не подошёл рекрутёр - его заменят, есть регламенты. В среднем 80-100 тысяч. Из личного опыта скажу, мы работали с кучей агентств, и почти каждый раз это головная боль - процессы у них едут просто космическим образом. HR generalist в штат - это уже не только рекрутинг, а ещё корпоративная культура, орг.вопросы, отпуска, больничные, корпоративы. Особенно полезно, если команда уже от 20 человек. В среднем 100-120 тысяч. Как понять, что вам вообще нужно? Смотрите на объём: если нужно закрывать стабильно от трёх позиций в месяц, а команда подросла до 20+ человек, выгоднее взять человека в штат. Он знает продукт, хорошо продает вакансию кандидатам, и вы не боретесь каждый раз с тем, что рекрутёр перегрузился или уволился.

И вот что важно: рынок сейчас сильно изменился по сравнению с тем, что было ещё пару лет назад. Откликов стало намного больше, поэтому простые линейные позиции (не руководящие) хорошо закрываются через анкету: размещаете вакансию, настраиваете автоответ анкетой с квалифицирующими вопросами, а сами отбираете кандидатов с помощью Клода. У нас так закрылось около пяти позиций своими силами. Честно говоря, работает отлично)

В общем: мало позиций и редко - берите фрилансера или агентство. Стабильный поток от 3-х позиций в месяц и растущая команда от 20 человек - свой HR.

Как оценку места под магазин ужали с трёх недель до одного клика В 2009 году, чтобы понять, стоит ли открывать магазин в конкретном районе, сотрудники «Ленты» шли туда пешком. Исследование так и называлось, City Walk, прогулка по городу. Четыре дня в полях плюс две недели на отчёт, все конкуренты и зоны доступности заносились руками в PowerPoint. Сегодня прогноз товарооборота новой точки приходит по клику на карте. Между этими двумя состояниями 15 лет, собственный геопортал на ArcGIS и ML-модель на градиентном бустинге, которую команда принципиально решила делать in-house. Разберёмся, как из хождения ногами выросла модель, работающая с точностью до 90%.

Как понять, нужен ли вашему продукту ИИ (часть 2) В прошлый раз мы рассмотрели подробно, в каких задачах хорошо себя показывают ML, LLM, RAG и ИИ-агенты — удобная сравнительная таблица на слайде 1. Но выбор решения должен исходить из стратегических вопросов. Разберем фреймворк, который помогает точно выбрать подходящую ИИ-технологию или инструмент для вашего контекста. ❌ Частые ошибки при поиске ИИ-решения для продукта: — Выбирать модель раньше, чем продумали работу с данными: какие данные есть, хватит ли их, где они лежат, как получить к ним доступ? Этот этап занимает много времени, и если не оценить заранее его трудоемкость, можно сильно сдвинуть сроки. — Считать, что любая ИИ-функция должна отвечать мгновенно. На самом деле далеко не всегда — например, классификацию пользователей достаточно проводить раз в месяц. Работа в реальном времени резко повышает стоимость решения, поэтому такой режим стоит использовать только там, где он действительно необходим. — Надеяться на решение комплексной задачи одним инструментом. Если загрузить весь объем данных в одну модель, то результат будет в большей или меньшей степени состоять из галлюцинаций. — Запустить и забыть. Модель на проде нужно дообучать и переобучать в случае применения к другим продуктам, даже в схожих контекстах. ✅ Этапы использования ИИ в продукте 1️⃣ Четко сформулируйте бизнес-задачу, которую хотите решить с помощью ИИ. Она должна быть: — актуальна и значима для компании (автоматизация, сокращение времени); — иметь измеримые последствия (деньги, время, ресурсы). Для отслеживания прогресса сразу стоит: — определить ключевую метрику; — нарисовать схему процесса As Is → To Be. 2️⃣ Переведите бизнес-задачу в задачу для ИИ. Классический ML — К какому типу ML-задач относится ваш кейс? — Что будет являться целевой переменной, что модель должна предсказывать? — В чем бизнес-смысл этого предсказания? — На каком этапе бизнес-процесса будет использоваться модельное решение? — Какие математические метрики будут проверять качество модели? Генеративные модели — Какой тип генеративной архитектуры вы используете — LLM (GPT-подобная), diffusion, VAE, GAN или гибрид? — Что именно должна генерировать модель и по каким правилам? — В чем бизнесовая ценность этой генерации? — На каком шаге пользовательского/операционного процесса запускается генерация? — Какими метриками будете мерить качество вывода? 3️⃣ Подготовить данные. — Какие данные планируется использовать для обучения модели? Какие ключевые признаки? — На какую дату признаки должны собираться? Будут ли к этой дате известны показания по всем признакам? — Требуются ли внешние источники данных? — Требуются ли дополнительные действия для сбора данных? — Есть ли ограничения по использованию данных/моделей? — Можно ли отправлять данные за контур компании в вендорское решение? — За какой период (срок наблюдения) собираются данные? — Все ли данные уже есть в промышленных системах, или потребуется дополнительное подключение? 4️⃣ Выберите режим для модели. — Как часто будет работать модель: Batch — раз в день/неделю/месяц. Online — в момент действия пользователя. — Как часто нужно делать предсказание? — Есть ли требования к скорости ответа? 5️⃣ Продумайте внедрение в продукт. — Как модель будет интегрирована в бизнес-процессы и существующую архитектуру? — Требуется ли API или встраивание в существующие сервисы? — Нужно ли менять интерфейсы или бизнес-логику продукта? — Кто отвечает за поддержку и обновление модели после внедрения? — Как будет организована обратная связь от пользователей для улучшения качества предсказания? 6️⃣ Запланируйте регулярный мониторинг. — Какие метрики качества будут отслеживаться? — Как будет происходить мониторинг деградации модели? — Кто отвечает за реакцию на падение качества? — Как часто планируется переобучение модели? — Есть ли процесс аварийного отключения модели и возврата к ручному процессу? — Как будут учитываться требования по безопасности и хранению данных в эксплуатации? 7️⃣ Постройте систему метрик (слайд 5). В ней важно учитывать: — продуктовые метрики — от менеджера продуктов и бизнеса; — ML-метрики — от дата-сайентиста; — метрики связи продукта с ML. Только после этого имеет смысл выбирать между классическим ML, LLM, RAG или агентной архитектурой. И иногда правильным ответом окажется вовсе не генеративный ИИ. По мотивам мастер-класса «Нужен ли вашему продукту искусственный интеллект?» Михаила Войтко на ProductSense’25 💙 VK 🖤 YouTube @productsense

Как работают Фрактальные (рекурсивные) MAS (Multi agent system) на примере создания учебных материалов / курса по построению AI First Org. За рефы взял просто топ 10 курсов tier0/1 от MIT/Standford/Accenture (big 4 или кто там консалты) + перешерстило само интернет на тему самых новых и трендовых материалов на эту тему. Создало ICP + объяснило максимально детально на несколько страниц: • для кого • что на входе должно быть • что на выходу получают люди/компании Очень классные проверки и тесты моих гипотез / RnD через кейсы. Step 2: -> рекурсивно весь этот граф/дерево с "проваливанием" в детализацию с последующей реализацией так же через фрактальные/рекурсивные подходы. То есть -> есть какая-то невнятная идея/задача/хотелка -> она потом разворачивается вот в такое "полотно"/граф, считает юнитэкономику/ делает бизнес план / gtm etc + вариации как к этому можно прийти и какие могут быть пивоты/попытки/вероятности/сканы конкурентов/пустые ниши и тд и тп.

Предпринимательство как практика формирования будущего В статье «The best way to predict the future is to create it» увидел интересный фреймворк, который описывает предпринимательство как практику future-making. Предприниматели принимают решения балансируя между двумя параметрами будущего — future potentiality и future closure. На пересечении этих векторов появляются три последовательных этапа: 1. Speculation — этап открытия будущего • Момент, когда задача увеличить количество осмысленных возможностей и сценариев. • Ключевой результат: не план, а понимание future potentiality. • Барьеры: когда команда слишком рано стремится к ясности и определенности. Будущее закрывается раньше, чем успели найти самый большой потенциал. 2. Alignment — этап согласования будущего • Момент, когда нужно переключать поиск возможностей на ограниченное количество сценариев. И синхронизировать людей, ресурсы, ожидания и ближайшие действия. Важный нюанс — это ещё не полное закрытие будущего. Но выбор направления, при сохранении гибкости и мобильности. • Ключевой результат: стратегическое видение, роудмапы и драфт бюджетов. • Барьеры: когда планы слишком преждевременные, определенные и детальные. Возникает конфликт между тактическим удобством и долгосрочными стратегическими амбициями. 3. Obligation — этап закрытия будущего • Этап жесткой приверженности в отношении определенного фокуса и курса действий. Масштабирование ресурсов и обязательств. Минимальное potentiality и максимальное closure. • Ключевой результат: path dependence через детальные планы, распределение ролей и отчетность. • Барьеры: публично взять на себя обязательства, потому что есть внешнее давление, но по факту оставаясь на этапах speculation и alignment. Какой важный вывод я бы сделал? Что люди, эффективные для этапа speculation, скорее всего саботируют obligation. Но и те, кому по душе определенность, врядли смогут увидеть новые большие возможности. В комментариях оригинал статьи и аудио-саммари.

🍾 Проблема узких мест в бизнес-процессах Ошибочные управленческие подходы ежегодно обходятся компаниям в миллионы рублей и крадут до 20% рабочего времени у руководителей. Корень проблемы — в так называемых «узких местах», возникающих из-за недостаточной ясности в коммуникациях, отсутствия четких регламентов или чрезмерной концентрации решений на отдельных людях. Как побороть эту проблему? Первый шаг — составление схемы процессов. Важно выявить, где именно происходят задержки, какие действия дублируются и какие этапы можно оптимизировать или исключить. В результате процессы становятся понятными и предсказуемыми, что снижает риск неразберихи. Второй шаг — внедрение вспомогательных инструментов: чек-листов, алгоритмов принятия решений, структурированных моделей данных. Эти средства помогают удерживать фокус на ключевых задачах и минимизировать вероятность ошибок. Итог — решения принимаются быстрее, увереннее и мотивируют команду, одновременно экономя время. Фаундер | Бизнес и Стартапы

А каким на самом деле бизнесом мы занимаемся? Знаю одного парня. У него экспедиционная компания - логистика. Находят кому надо перевезти груз, находят того, кто перевезет, сращивают, накидывают свою маржу и вот прибыль. Таких компаний на рынке много. Он уже большой. Прибыль более 10 млн чистыми в мес. Но у него средняя отсрочка платежа - полгода. Такой вот демпинговый сложный рынок. Не будешь давать отсрочку - не будешь много возить. А еще, более половины клиентов не платят потом свою отсрочку, и он выбивает свои кровные деньги через суд. Смеется, что у него крутейший Юр отдел и суды - это базовый бизнес-процесс компании. Я ему говорю. Так ты не логическая фирма. Ты банк, у которого еще и юрфирма своя есть. Фактически, его прибыль - это награда не за логистику, не за то, что они такие фа, пэпэ, лучше всех везут тару на палетах. Его прибыль - это плата за то, что он умеет управлять риском на отсрочках, понимать кому и сколько давать и потом системно судиться. Вот в чем его бизнес. А каким на самом деле бизнесом ты занимаешься? Напиши в комментах