Как Slack нашёл product-market fit

Разбор лекции Николая Андрюхина от 16 сентября 2026 года из библиотеки стримов Guide DAO.

Николай Андрюхин отвечает за data-продукты и монетизацию в Avito, работает также в hh.ru и больше шести лет занимается продуктами на стыке AdTech, AI и Big Data. На одном из еженедельных стримов курса «Продакт-менеджер» он разобрал историю Slack.

Кажется, что такие продукты появляются просто: умный человек решает, что корпоративная почта устарела, и садится делать рабочий мессенджер. Slack вырос иначе, из неудачи. Игровая студия закрыла убыточную игру, и самым ценным, что у неё осталось, оказался чат, который команда собрала для себя. Николай разбирает, какие решения превратили этот чат в продукт с миллионами пользователей.

В 2012 году компания Tiny Speck делала многопользовательскую игру Glitch. Над ней несколько лет работала команда примерно из 45 человек. Игра приносила деньги, но не окупала затраты, и в ноябре 2012 года её решили закрыть. Ни код игры, ни игровой мир никому не были нужны.

Зато остался внутренний инструмент. Люди работали из разных городов и стран и по нескольку раз в день обсуждали код, дизайн и работу с игроками. Переписка расползалась по почте и чатам отдельных команд, уведомления GitHub видели только разработчики, а новичок собирал контекст по кусочкам. Чтобы с этим справиться, команда постепенно собрала свой инструмент: туда попадали сообщения, файлы и уведомления других систем, и всё находилось поиском. Николай приводит слова одного из основателей: за три года на общую корпоративную почту ушло около 50 писем.

Романтизировать эту историю Николай не советует. Команда не изучала рынок, она решала свою задачу. Одна команда легко могла построить систему под свои странные привычки, так что доказательством рынка это ещё не было. Но инструмент, который годами оттачивали на ежедневной работе, уже гораздо сильнее идеи на салфетке.

Внешне ранний Slack был похож на хороший групповой чат с каналами и личными сообщениями. Это понятная точка входа: объяснять, что такое групповой чат, никому не нужно. Но команда быстро поняла, что настоящий продукт лежит глубже.

Slack объединил разговоры с данными из других сервисов. Уведомление из GitHub или файл из Dropbox можно было обсудить, а потом найти и сам файл, и разговор о нём. Команда получала общую цифровую память, как называет это Николай. Новичок открывал канал и видел прошлый контекст, а через год можно было вернуться к файлу и понять, что по нему решили, почему и кто принимал решение.

Чат помогал начать пользоваться Slack, а ценность поиска, файлов и интеграций открывалась со временем. Отсюда выросла амбиция: сделать Slack местом, где встречаются рабочие разговоры, внутренние инструменты и уведомления внешних сервисов. Но пока это была логика одной команды.

Следующий шаг был сложнее: отдать продукт людям, которые не обязаны были любить его с полуслова. К марту 2013 года команда сама работала в новой версии Slack, а в мае начала уговаривать знакомые компании поставить его и дать фидбек. Так набралось от шести до десяти компаний. Николаю нравится этот подход: без платного маркетинга, только ранние пользователи, которые действительно перенесут в Slack часть работы.

Среди первых тестировщиков были сервис для управления арендой Cozy и музыкальный сервис Rdio. В Rdio Slack сначала пользовалась небольшая группа фронтенд-разработчиков, потом вся инженерная команда, а затем вся компания, около 120 человек. Тут продукт начал разваливаться. Когда каналов много, новичок не понимает, куда заходить, а старожил не может найти последнее обсуждение. По словам Николая, то же сейчас видно в Mattermost, на который многие российские IT-компании перешли после ухода Slack. Команда добавила к каналам описание и число участников. Мелочь, но без неё продукт не стал бы понятным для больших команд.

Проблему никто не придумал на воркшопе, подчёркивает Николай: Slack отдали компании другого размера и посмотрели, где люди теряются. Размер команды стал новой нагрузкой на продукт, причём не на серверы, а на понимание. Дальше команда повторяла цикл: подключала группы крупнее, наблюдала, исправляла и только потом расширяла тестирование.

В августе 2013 года Slack объявил превью-релиз и сознательно не назвал его бетой. Николай объясняет это так: услышав «бета», люди считали бы баги нормой, а команде нужно было, чтобы о них сообщали. В первый день доступ запросили около 8 тысяч человек, через две недели заявок было уже 15 тысяч. Можно было открыть регистрацию для всех и показывать зелёные графики. Вместо этого заявки разбили на партии. Команда смотрела, начали ли люди общаться, читала обращения в поддержку, меняла онбординг и только потом звала следующую партию. Так продолжалось полгода, до публичного запуска.

Для стартапа это вечность, но Slack был командным продуктом. Мало, чтобы один человек разобрался в интерфейсе: ему нужно позвать коллег, убедить их перейти и дождаться, пока общение в Slack прорастёт из одного отдела во всю компанию.

Поддержка тем временем работала почти как исследовательская команда: жалобы из Twitter и тикеты попадали в отдельные каналы в Slack, а повторяющиеся темы быстро уходили разработчикам. Слушали при этом не всех подряд. Если застревала команда, которая, по мнению создателей, должна была пользоваться продуктом успешно, её проблема поднималась в приоритете. Slack прислушивался к своей целевой аудитории, а не чинил подряд корнер-кейсы.

По ходу команда нашла число, которое объясняло продукт лучше регистраций и красивых отзывов. До 2000 сообщений команда ещё пробует Slack, а из прошедших этот порог 93% продолжали им пользоваться. Регистрация в командном продукте почти ничего не значит. По данным, которые приводит Николай, больше 90% людей, создавших новую команду, не приглашали ни одного коллегу и так и не начинали работать в сервисе. Поэтому Slack сравнивал команды, которые остались, с теми, кто ушёл, и искал момент, после которого поведение меняется. Сегодня такой рубеж назвали бы порогом активации.

Число превратилось в практическую задачу: помочь целевой команде дойти до опыта, после которого Slack начнёт удерживать её сам. Онбординг должен был быстрее приводить приглашённого коллегу, интеграции раньше приносить полезные уведомления, подсказки помогать завести первые каналы. Оптимизировали уже движение всего коллектива к новой привычке.

Для маленького стартапа Николай выводит отсюда правило: такая метрика редко лежит на поверхности, её находят в поведении тех, кто остался. Slack не придумывал 2000 сообщений заранее. Команда увидела в данных границу и начала отстраиваться от неё.

Первой аудиторией Slack стали технические команды компаний среднего размера: создатели сами были такой командой, а разработчики уже привыкли к чатам и интеграциям. Но способ покупки, по словам Николая, оказался важнее формального портрета аудитории. Slack не продавал большую трансформацию генеральному директору. Руководитель отдела мог сам создать пространство, позвать коллег и начать работать без закупок и тендеров, а бесплатный тариф снижал риски.

Ценность возникала коллективно: одному пользователю Slack почти ничего не давал, а команда сразу получала разговоры, историю переписки и поиск. Чем больше процессов попадало внутрь, тем дороже было возвращаться к старой схеме. Рост шёл изнутри компании, от одной группы разработчиков к соседней и дальше ко всему подразделению, как это было в Rdio. Такой рост называют product-led growth: новых пользователей приводит сам продукт, и тяжёлая машина корпоративных продаж на старте не нужна.

Когда Slack дошёл до крупных предприятий, появились проверки безопасности, юридические согласования и полноценные продажи. Но там уже были сотрудники, которые работали в Slack на прошлых местах и могли его защищать. У такого роста есть ограничение: первые пользователи должны уметь сами запустить продукт и показать его ценность коллегам.

Публичный запуск прошёл 12 февраля 2014 года, и дальше скорость стала, по выражению Николая, пугающей. К августу у Slack было больше 120 тысяч ежедневных пользователей. К началу 2019 года ежедневных пользователей стало больше 10 млн, организаций больше 600 тысяч, платящих клиентов больше 88 тысяч, а выручка за финансовый год составила около $400 млн.

Внутри продукт сильно менялся. Для крупных компаний пришлось строить администрирование, безопасность и корпоративные продажи. Продукт всё чаще выбирали одни люди, а договор подписывали другие. Slack, который выигрывал простотой, обрастал возможностями, как это бывает со всеми крупными продуктами. Николай вспоминает Битрикс24, который тоже начинался простым. К 2020 году в шапке Slack было больше 12 кликабельных элементов и два поиска. Функции годами добавляли разные продуктовые команды, полезные возможности оказались спрятаны в разных местах, и пользоваться ими было совсем не интуитивно.

В 2020 году компания публично признала проблему. Вместо того чтобы двигать и перекрашивать кнопки небольшими A/B-тестами, команда собрала грубые прототипы и позвала в общий канал около 100 пользователей обсуждать новый интерфейс по ходу работы. Рост не закончил продуктовую работу. Он заставил Slack заново учиться у пользователей.

Присмотритесь к тому, что команда уже сделала для себя. Инструмент, которым люди пользуются каждый день, сильнее идеи на салфетке, но рынок он докажет только на чужих командах.

Разделите точку входа и ценность. Если функция, которая приводит людей, и функция, которая их удерживает, разные, онбординг должен вести от первой ко второй.

Расширяйте тест ступенями. Отдайте продукт группе крупнее вашей, пускайте новых пользователей партиями и между партиями меняйте онбординг по обращениям в поддержку. Первыми разбирайте проблемы своей целевой аудитории.

Ищите порог ценности в данных. Сравните тех, кто остался, с теми, кто ушёл, и перестройте онбординг так, чтобы новые пользователи доходили до порога быстрее.

Проверьте, может ли первый пользователь запустить продукт сам, без консультантов и месяцев настройки. Иначе рост изнутри компании не сработает.

Когда продукт разрастётся, возвращайтесь к пользователям с грубыми прототипами.

Идеализировать кейс Slack Николай не призывает, а в B2C-продукте и вопросы будут другими. Главный его совет простой: пробовать. Благодаря вайбкодингу и доступному AI то, что раньше требовало огромных команд и ресурсов, сейчас можно собрать и проверить за несколько вечеров. Поэтому стоит создавать, тестировать, ошибаться и искать свой product-market fit, маленький или большой, но свой.