У Apple и Android есть любопытное различие в том, как компании подходят к бета-версиям мобильных приложений.

Если ты хочешь запустить бету своего приложения на iOS, у Apple есть специальное приложение TestFlight, через которое пользователи могут установить твою бету. Чтобы участвовать в бете, пользователи должны быть замотивированы, ибо процесс не самый дружелюбный.

Для разработчиков же TestFlight просто идеален. Ты можешь управлять своей бетой как хочешь, можешь остановить её в любой момент, а можешь просто перестать выпускать обновления и через 90 дней бета сама закончится.

Чтобы перейти с беты на продакшен, пользователи просто переустанавливают приложение с App Store. При этом, все их локальные данные сохраняются.

У Google бета публикуется сразу в Google Play Store. Если приложения ещё нет в продакшене, то по умолчанию пользователи, сами того не подозревая, ставят бету. Это очень легко, никакого гемора с установкой. Разработчикам это тоже весьма удобно.

Сложности начинаются, когда ты хочешь перевести пользователей с беты на продакшен. Чтобы выйти из беты, пользователи должны самостоятельно зайти в Play Store, выйти из беты, удалить приложение и установить его заново. Все их данные при этом теряются, если приложение не делает копию, которую можно восстановить из облака.

Если приложение можно использовать без создания аккаунта, то у тебя нет никакой возможности связаться с бета пользователями. Даже если ты закончил бету в Google Play Console, пользователи всё равно "остаются в бете" хотя и используют приложение из продакшена. Любые рейтинги и ревью от бета пользователей идут только разработчику и не публикуются в Play Store, что является главным недостатком не-выхода пользователей из беты.

Обобщая эту особенность:

— Google сделал так, чтобы бету было легко начать, а чтобы закончить они, похоже, особо не думали и сделали процесс очень сложным и непонятным.

— Apple же сделал запуск чуть более геморным, но зато сделал невероятно удобным управление и окончание беты.

Ту же особенность мы заметили при отправке приложения в прод. Google сразу аппрувнул наше приложение, но через пару дней прислал три предупреждения с угрозами удалить приложение в течение 7 дней. Apple пое.ал нам мозг чуть больше недели, зато после аппрувала всё идёт супер гладко.

Пройдя через этот процесс, я стал ещё большим фанатом Apple и в очередной раз разочаровался в Google.

@ilyabezdelev_blog #продактменеджмент #стартап #мобильнаяразработка

CPO обсуждает требования по телефону:
— Нет. Нет. Нет. Да! Нет. Нет. — кладет трубку.
— CPO, а почему ты один раз все–таки сказал "да"?
— Спросили, хорошо ли слышно.

Объяснял ребенку домашку по информатике. Делили байты на 8, умножали мегабайты на 1024, определяли тип входных данных в системе типа «черный ящик», решали кроссворд с компьютерными терминами…

Я все задания для 6 класса сделал правильно в уме. Есть ещё порох в пороховницах!

А на днях 3 часа бился над олимпиадной задачей по математике… Потом обсуждал её с другими родителями. Никто не смог решить. Снова открыл в себе азарт к решению математических задач.

А ещё писали сочинение по литературе. У меня трояк по литре, но, думаю, что сейчас легко бы получил пятерку. Было реально интересно читать Гомера, сказ о Петре и Февронии Муромских и стихи Жуковского. Так затягивает.

Почитал учебник истории за 6 класс. Блин, ну почему в 6 классе это было неинтересно, а сейчас на это нет времени?

Жду когда начнут делать вычисления в двоичной и шестнадцатеричной системе. И логические операторы в двоичной системе. Я любил это делать, хорошо стимулирует, как арифметика в уме.

ПОДНИМАЕМ КАЧЕСТВО ПИСЬМА В КОМАНДЕ

(Перепост из чата продактов, где я отвечал на вопрос о том, что делать, если сотрудники делают так, что ничего непонятно)

Мне нравится, как эта проблема решается в культуре Амазона. Все продуктовые предложения пишутся в документах (прозой) и проходят несколько раундов ревью, каждый раз поднимаясь на один уровень выше по иерархии.

Предложение создать новый продукт будет читаться:

1) сначала коллегами-продактами, менеджерами разработчиков и разрабами-сеньорами - <=L6

2) затем руководителем продактов (5-10 человек в подчинении) и руководителем менеджеров разработки (30 чел) - L7

3) директорами продукта (20-30 чел) и разработки (100 чел) - L8

4) VP (500-1000 чел) - L10

5) SVP (много тыщ людей) - L11

5) потенциально CEO подразделения

Предложение создать новую большую фичу пойдет до уровня директоров (3). Мелкую фичу - до уровня руководителей (2).

На каждом этапе качество (=ясность и обоснованность) документа поднимается. Пока люди не будут удовлетворены качеством, док не идёт на уровень выше и буксует. Никто не хочет показывать говно своих подчиненных вышестоящему руководству, ну и, собственно, подчиненные тоже не хотят. На каждом этапе есть шанс заработать поинты к репутации и риск эти поинты потерять.

Но!

Это работает, когда у всех общее понимание стандартов и есть желание черкать в документе красной ручкой (доки печатаются на бумаге) и душнить по поводу ясности.

Я как-то был свидетелем, как SVP в AWS швырнул недочитанный документ (слава богу, не мой) на стол, вздохнул и устроил получасовый высер о том, почему команде должно было быть стыдно показывать этот документ. В комнате было около 15 человек уровня VP, Director, Sr. Manager и Principal (L7+). Все сидели, потупив глаза. Критика была жесткая, но справедливая.

Он прояснил свой стандарт качества как "документ на уровне, когда его можно взять и передать команде разработчиков, у которой вообще нет никакого контекста, и они смогут это запилить, задавая минимум вопросов". Стандарт, конечно же, нереалистичный, но стремясь его достигнуть, получаем намного более продуманный и обоснованный документ.

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

Подытоживая, в Амазоне качество артефактов достигается системно через процесс и культуру, в основе которой лежит конструктивная критика "душнила 80-го уровня".

Когда людей отправляют дорабатывать сделанное, они быстро учатся.

Когда стандарт культуры — "и так сойдет", то они и пишут, как дети домашку в школе — самый минимум, лишь бы сдать.

@ilyabezdelev_blog #продактменеджмент #культура

Высокие стандарты — это всегда больно, причём, чем больше ты им сопротивляешься, тем больнее. Всё как в массаже и психотерапии — чем больше сопротивляешься процессу, тем больше шанс, что не вытерпишь боль и сдашься.

Не каждый может и хочет играть в игру высоких стандартов.

Для соблюдения стандартов, нужна сильная внутренняя мотивация ("и так сойдет" не сойдет), а для того, чтобы их пушить, нужна маниакальная убеждённость, что это правильно или личность с оттенком психопатии. Тот, кто требует должен в первую очередь предъявлять высокие стандарты к себе.

Я говорю про стандарты, которые всем ясны, но которые при этом постоянно повышаются по заданной траектории. Самодурство в стиле "я - чёрный ящик, угадай что я хочу по моим высерам" — это не стандарт.

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

Если вы защищаете продуктовые предложения без фидбека от минимум 5 человек или пушите код в прод без глубокого code review, вы играете в игру на понижение стандартов или в лучшем случае сохранения статус-кво.

Повторюсь, что не каждый может и хочет играть в игру высоких стандартов. У кого-то не хватает компетенций, у кого-то желания, у кого-то способностей, у кого-то мета-навыка "учиться по прямой и косвенной обратной связи".

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

Но и нет (на мой взгляд) ничего более деморализующего, чем работа в среде, где у всех стандарты значительно ниже твоих. (Перед этим стоит пройти тест на перфекционистическую токсичность: 1) твои стандарты должны быть в первую очередь к себе, а не к другим и 2) идут ли твои стандарты в разрез с нуждами бизнеса?)

@ilyabezdelev_blog #софтскиллы

По моим наблюдениям самая несчастная функция в Амазоне — это UX. В прод попадает половина от того, что они предложили, а половина от половины, которая всё же попала, искажена по разного рода объективным техническим причинам (невозможность имплементации в существующем фреймворке, дороговизна, сроки и т.п.).

Я в детстве (в 11 классе) хотел быть дизайнером. Хорошо, что не стал. Спился бы.

Далеко за примером ходить не надо. Возьмем страницу 404.

Ну можно же было хотя бы отцентровать изображение вертикально?

Вчера встретился с ребятами из чатика питерских продактов. Остались интересные ощущения.

Понимаю, что выборка не репрезентативная, но как будто то, что в России делают продакт менеджеры — это меньше половины того, что РМ делает в западном бигтехе. Особенно, в том, что касается разработки продукта и его развития.

У меня осталось впечатление, что разработка — это внутренняя сервисная организация, которая делает то, что написал продакт в неком подобии ТЗ. Продакт не является частью команды разработки.

В общем, у меня в голове сейчас каша. Я пытаюсь увязать в кучу то, что я услышал за пивом в баре.

Я бы хотел пообщаться с несколькими продактами, кто работает в крупных компаниях (Т-Банк, Сбер, Яндекс, Авито и другие) и несколькими из компаний поменьше. Интересно пообщаться с людьми, кто видит процесс целиком, то есть синиор/директор/СРО, кто поднялся с низов и всё видел.

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

Если вы подходите по критериям и вам интересно ответить на несколько вопросов, напишите мне на @ilyabezdelev и сделаем созвон на 30 минут.

Я бы хотел пообщаться примерно с 5 людьми из каждой группы: бигтех, средний бизнес и менеджеры разработки/техдиры.

Если есть знакомые, кто соответствует критериям, киньте им. Мне это сейчас прямо сильно надо.

Спасибо! 🙏

Разработчики любят шаблоны, чтобы не повторять один и тот же код.

Например, на этом сайте аренды автомобилей вместо того, чтобы три раза кодить похожие поля в форме, они написали код один раз. Условно, есть функция показатьОпции() с параметрами название, стоимость и картинка.

Но единицы измерения при этом hardcoded (кто-нибудь подскажет как это на русском слэнге?), то есть сама функция лепит "штуки" независимо от содержимого опции. Поэтому водители измеряются в штуках. Добавят домашних животных, они тоже будут "штуками".

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

Но шаблоны имеют и ограничения, как в этом примере. Теперь, чтобы изменить водителей со "штук" на "людей", нужно поменять шаблон и сделать дополнительный параметр единицаИзмерения. При этом важно не сломать уже существующие страницы, поэтому нужно или 1) поменять код во всех местах, вызывающих шаблон, чтобы бустер и детское кресло корректно отображались в штуках, или 2) шаблон должен по умолчанию выводить штуки, если единицы измерения не указаны.

Первый вариант более "чистый", а второй — более быстрый и обладает свойством "обратной совместимости", то есть изменения в функции не поломают существующий функционал.

Где здесь продакт менеджмент?

В хорошо продуманных требованиях можно было бы заранее указать, что единицы измерения могут отличаться.

@ilyabezdelev_blog #техническийпродактменеджмент

FEATURE TOGGLES

Feature toggling, также называемый feature flagging — это механизм включения/выключения фич в продукте через простую конфигурацию. Например, у нас есть новая фича, которую мы тестируем с бета пользователями. На стороне серверной конфигурации мы прописываем у кого должен быть доступ и фича включается у отдельных юзеров.

Обычно это выглядит так:

1) На клиенте (в приложении, вебаппе, или даже API) есть кусок кода, к которому мы хотим ограничить доступ. Этот код обнесён простым if, который делает запрос к сервису feature toggling в формате "есть у пользователя userId доступ к фиче featureId"? Если сервис говорит, что доступ надо дать, показываем фичу. Если нет — соответственно, не показываем.

2) На стороне сервиса Feature Toggling есть конфигурация, в которой для каждой featureId прописаны критерии доступа. На самом базовом уровне мы можем прописать идентификаторы пользователей, у которых есть доступ. Или идентификатор компании, чьи пользователи имеют доступ (в сегменте B2B). Или условия вроде "если аккаунт был создан до июля 2024 года && пользователь находится в такой-то стране" для более сложных сценариев. Или "внутренний пользователь из отдела Х" — в таком случае сервис может даже коммуникировать с другими системами внутри компании, чтобы определить уровень доступа.

3) Есть также значение по умолчанию. Если вдруг нет доступа к сервису feature toggling, то клиентский код должен знать, что делать дальше. Если ответа нет, значит доступа нет. Ну или наоборот есть в случаях, когда мы хотим удалить фичу.

4) Когда мы выкатываем не новую фичу, а меняем старую, то метрики из приложения должны учитывать значения toggle, чтобы можно было анализировать разницу между новым и старым. Feature toggling — это база для A/B тестирования. FT может распределять пользователей по группам в том числе и рандомно, а "A/B тестирование" заключается в анализе результатов между группами.

Feature Toggling — незаменимый механизм для высокой скорости разработки.

Работа над фичами может занимать недели и даже месяцы. Если разработчики работают над фичей в отдельной ветке (branch), то их копия кода устаревает, её нужно постоянно синхронизировать с работой других разработчиков, возникают конфликты в коде и т.п. Это ад даже в команде из 3-4 человек, а в команде, где над кодовой базой работают 10+ человек, это будет прям совсем неэффективно.

Поэтому важно делать небольшие изменения в коде и регулярно пушить их в основную ветку (main), которая сразу же идёт в продакшен.

ЧТО??? ТЕСТИРУЕМ КОД В ПРОДАКШЕНЕ???

Конечно. Именно так.

Но тут нам на помощь приходят feature toggles!

На ранних этапах, когда всё очень криво, даём доступ только для команды, потом расширяем до внутренних пользователей, потом начинаем добавлять рисковых бета-юзеров, а потом уже одним переключением рубильника "выкатываем" в прод фичу, код которой уже и так давно в проде.

Где тут продакт менеджмент?

Понимая, что такое feature toggling, РМы должны настаивать на использовании этого механизма для более раннего доступа к фичам. Создать такой механизм не так сложно или можно использовать платный сервис типа LaunchDarkly.

Если к вам приходят разработчики и говорят, что хотят сделать FT, их нужно обнять и купить им за такое дело овсяный латте, а не хлопать глазками с вопросом "чтобы что? скока бабла это принесёт?"

@ilyabezdelev_blog #техническийпродактменеджмент

Прикол. Походу у Басты на артворке песни стоит реклама. Такого в Спотифай я ещё не видел. Нативненько!

Ну или где-то в сети происходит подмена изображения. Это было на телефоне жены, сам я ещё не смотрел откуда ноги растут.

В ближайшее время тут будет несколько постов с рекомендациями других продуктовых каналов. Меня добавили в группу, состоящую из 80 человек с каналами про продакт менеджмент с >1к подписчиков. Многие значительно больше моего. Есть интересные, притом, что я о них никогда раньше не слышал.

В старых добрых традициях кросс-промоушена будут коллабы с ребятами. Я говно рекомендовать не буду. В любом случае, прежде, чем соглашаться почитаю, что они пишут.

Предупреждаю, потому что это будет новый тип постов и может возникнуть реакция а-ля "это чё?" В отсутствие агрессивных рекомендательных алгоритмов авторы каналов продвигаются по старинке, через обмен вниманием аудитории.

Два самых частых вопроса, которые мне задают — почему я вернулся из США в Россию и как продакту прокачать технические навыки.

Увидев сколько существует продуктовых каналов, возникла мысль занишеваться и чуть больше сфокусироваться на техническом продакт менеджменте (темы последних постов).

Я не нашёл ни одного нишевого канала про технический РМ, может не так ищу?

Эта ниша выглядит свободной. Лучше быть единственным в нише, чем одним из сотни каналов на переполненном пространстве. Меня самого естественным образом всегда несёт в техническую часть.

Плюс-минус контент канала попробую сделать таким:

— 50% посты связанные с технической частью, работой с разработкой, хардскиллами.
— 30% в общем про продакт менеджмент, преимущественно из моего опыта в американском бигтехе. Рубрика "а как там у пиндосов?"
— 20% сочинения на свободные темы, делающие мой канал моим. Когда-нибудь отвечу на вопрос, который мне последнее время задают чаще всего...
— Бонус: Скоро возобновлю подкаст с интервью. В себя до конца приду после переезда, куплю звуковые панели и начну искать гостей.

В связи с этим возникла мысль также и переименовать канал в "Технический продакт менеджмент с Ильёй Безделевым".

Как вам такое название?

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

Приветствую фидбек. Можно в комменты, можно в личку @ilyabezdelev.

Послушал интервью с Марком Цукербергом на подкасте Acquired. Куча интересных инсайтов, очень рекомендую.

Поделюсь мета-инсайтом о технологических компаниях.

На таймкоде 21:52 Марк говорит, что когда он приехал в Кремниевую Долину, он увидел топовые компании того времени вроде eBay и Yahoo, которые называли себя технологическими стартапами, но по факту таковыми не являлись.

СЕО не технарь. В совете директоров нет технарей. В менеджменте только один чувак, разбирающийся в технической части — head of engineering. Если это — твоя команда, у тебя не технологическая компания.

Поэтому в Мете (признана в РФ экстремистской организацией) управленческая команда — это главы продуктовых подразделений, которые пришли наверх из технических должностей.

Это влияет на то, как ты принимаешь решения и на культуру. Мы смогли разработать все эти платформы [он имеет ввиду низкоуровневые вещи — платформы управления дата центрами, AI модели], потому что мы инвестировали в фундаментальные технологии, на которых построены наши продукты. Это позволяет нам быть организацией с культурой, которая постоянно учится.

Мета начала работать над AI моделями в 2012, поэтому она смогла выпустить Llama сейчас, почти сразу после GPT. Они создали и заопенсорсили Open Compute Project, что позволило стандартизировать оборудование для дата центров, от чего выиграла вся индустрия, но в том числе и сама Мета.

От себя добавлю, что я 100% согласен. Компания со структурой, в которой есть "бизнес", который является "заказчиком" внутренней функции разработки, не способна мыслить как Гугл, Амазон или Мета. Мышление платформами требует другого подхода к бизнесу и долгосрочным инвестициям в то, что не приносит деньги сразу. В то, где ROI возможно будет виден только через 10+ лет, а может и не материализоваться вовсе несмотря на вложенные миллиарды долларов.

Интервью супер, позже поделюсь другими инсайтами, которые я отметил закладками в Metacast, когда слушал.

@ilyabezdelev_blog #подкасты #культура

Классное интервью с Андреем Стыскиным, который был главой Яндекс Поиска, а теперь — директор в Амазоне (плюс-минус 100-150 человек в подчинении).

Он так рассказывает про культуру Амазона, что я обливаюсь ностальгическими слезами и хочу обратно. Его опыт соответствует моему, все по делу говорит. I approve.

На момент интервью он отработал в Амазоне 5 месяцев и у него очень свежий взгляд на вещи. Он ещё в стадии, когда он всё сравнивает с предыдущим опытом в Яндексе. Для меня это офигенное окно в культуру Яндекса и вообще российскую корп культуру в сравнении с той, которую я понимаю очень хорошо.

Слушаю и тащусь.

Ещё один классный подкаст — интервью с Борисом Зарьковым, основателем ресторанов The White Rabbit Family. Из его ресторанов я несколько раз был в Горыныче. Там классные бутеры, пицца и сервис.

В интервью Зарьков говорит про текучку кадров. Когда высокая текучка, ресторан постоянно недоукомплектован, люди недообучены и сразу падает качество сервиса.

То же можно и применить на айтишные команды. Когда высокая текучка, теряются коллективные знания, доменная экспертиза, слаженные отношения в команде, что в свою очередь влияет на сроки исполнения и качество продукта.

В ресторанах текучка до 100% в год. Представьте себе полную смену команды за 12 месяцев… 🤯

В худшие годы у них была текучка 300%. Три раза сменяется состав людей 🤯 🤯 🤯

Он дрючит своих управленцев за высокую текучку и лишает их бонусов.

ДОКУМЕНТ PRFAQ В АМАЗОНЕ ч.1: 5 вопросов

Судя по комментариям под постом про интервью со Стыскиным, тема документов в Амазоне интересна.

Любой продукт в Амазоне начинается с PR/FAQ:

1) Одностраничного пресс-релиза как будто продукт уже запускается
2) 5-страничного FAQ с гипотетическими вопросами пользователей и реальными вопросами внутренних стейкхолдеров
3) Неограниченного количества приложений с данными, исследованиями, скриншотами и т.п.

Работа над PR/FAQ начинается с пяти вопросов (5 questions). Ответив на самые важные 5 вопросов, у тебя будет вся информация для написания PRFAQ. Письмо пресс-релиза становится относительно механическим процессом.

Итак, пять вопросов:

1. Who is your customer?

Кто твой пользователь/кастомер? Здесь мы описываем аватар пользователя. Не гипотетический, а основанный на исследованиях, метриках и касдеве.

2. What is the customer problem or opportunity?

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

3. What is the most important customer benefit?

Какая у пользователя будет выгода от использования того, что мы предлагаем? Как она измеряется?

4. How do you know what your customer needs or wants?

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

5. What does the experience look like?

Описываем UX (можно с прототипами и скринами), как это интегрируется в общую экосистему, стоимость и т.п. Всё, что нужно понимать о том, как это будет работать, но не уходя в сильно глубокие дебри.

Обратите внимание, что тут нет ничего про то, какая в этом выгода для нас. Это важно. Мы отталкиваемся от пользователя, а потом уже анализируем есть ли в этом экономический смысл. Мы работаем не от "как заработать бабла?" а от "какую ценность принести? бабло приложится..."

—

Ответы мы пишем полными предложениями.

Our customers are mid-level product managers who are stuck in their roles and don't know how to move forward in their careers. They typically work in companies with ~500 employees. Geographically 40% of them are concentrated on the West Coast, 30% on the East Coast and 30% are spread throughout the country. Their median income is $120k/year. There are approximately 40,000 of them in the United States. Their average age is 30, 60% of them are male, and 25% of them have children.

Я это только что придумал, чтобы показать на примере уровень детализации ответа на первый вопрос. Детали должны быть релевантными для последующих ответов. Например, если мы пишем про их семейное положение и детей, то это должно быть релевантно в следующем ответе, например в контексте нехватки времени.

Проходимся по всем пяти вопросам. Получаем документ-черновик из нескольких страниц, который станет основой для следующего шага — написания пресс-релиза.

👉🏻 Вторая часть

@ilyabezdelev_blog #продактменеджмент #бигтех #amazon

По четвертому пункту — он важен не только для того, чтобы доказать вышестоящему руководству и разработке, что это стоит делать. Это нужно в том числе для тебя самого. Чтобы ТЫ был уверен в своём предложении.

Если ты будешь уверен, ты сможешь это продать кому угодно. Если ты сам не уверен, то почему тебе должны выделить под это ресурсы?

Мне только что рассказали про прикольную практику — приглашать в середине спринта на встречу с командой (продакт + разработка + дизайн) пользователей, которым можно показать промежуточный прогресс по фиче.

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

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

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

А что так можно было?