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

Как было раньше: я определяла потребности пользователя, затем приходила к команде разработки с готовой задачей и дизайн-макетами. А после забирала работающий продукт, чтобы отдать его в A/B-тест.

В ML все работает иначе. Команда включается уже на этапе исследования, погружается в бизнес-цели и техническую постановку задачи. Именно исследования занимают львиную долю времени дата-сайентистов, и только после них начинается разработка.

Ну, или не начинается. Или разработка начинается, но совсем не той идеи, которая была вначале.

Я Саша Пургина, руковожу развитием продуктов на основе данных в Lamoda Tech. В этой статье я расскажу на примере Lamoda, почему разработка ML-продуктов — это сложность и риск. И приведу примеры ошибок, когда хороший продакт в команде может увеличить шансы на успех, имея определенные знания и навыки.

Серебряной пули не ждите, но пара интересных мыслей должна найтись!

А если без продакта?

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

В некоторых ML-командах о продакте даже не задумываются. Все равно при постановке задачи придется сразу обсуждать ее с тимлидом или со всей командой. Тогда зачем нужна дополнительная прослойка в виде менеджера? Его роль в таких ситуациях обычно берет на себя тимлид или технический руководитель. 

В этом есть свои плюсы: 

• гипотезы формулируются сразу на понятном команде языке, 

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

Команда счастлива! Но есть и минусы: 

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

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

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

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

Если не распределить правильно зоны ответственности в команде, то что-нибудь важное обязательно забудется. И от этого резко увеличивается риск потерять деньги и время, так и не получив эффект от продукта. 

Ошибки в работе с ML-продуктами и как продакт может уменьшать их количество

В моем опыте есть ряд случаев, когда идея «не взлетала». Причем модель работала и делала ровно то, о чем ее просили, но принести пользу бизнесу так и не смогла. Были ситуации и другого характера: проект застревал на этапе исследования, данных не хватало или выкатка модели в прод оказывалась невозможной. 

На каждом из этих этапов хороший продакт может помочь ML-команде довести дело до конца. Или как минимум объяснить неудачу стейкхолдерам и сделать из нее верные выводы. Разберу на примерах из истории Lamoda Tech.

На этапе дискавери

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

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

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

Что мы сделали не так? Нужно было предсказывать не тех, кто не вернется, а недавно активных пользователей, которые задумываются об уходе. Их еще можно сохранить, предложив что-то полезное. 

Как продакт может помочь разработать нужное решение?

• Рассказать бизнес-инсайты. Больше контекста — лучше! На старте и далее очень важно погружать команду во все детали проблемы и вариантов ее решения, обсудить, что с точки зрения процессов, бизнеса, пользователя будет происходить после реализации решения и на какие целевые метрики мы хотим повлиять. Продакт может погружать в контекст сам или свести команду с представителями бизнеса и помогать настроить регулярный, открытый диалог.

• Переформулировать бизнес-запрос и продуктовую гипотезу в формат постановки ML-задачи. Между запросом бизнеса «нам нужно всё автоматизировать/оптимизировать/персонализировать» до конкретных ML-продуктов — пропасть, которую требуется всесторонне продуктово проработать. Уточнить, из каких данных формируется датасет, какие модели можно использовать для решения задачи, как ML-метрики будут связаны с продуктовыми и бизнес-метриками. 

• Оценить имеющиеся данные. Если данных нет, то продакт может поставить задачу на их сбор или разметку асессорами, а если данные есть и бизнес-ценность подтверждена, то подключить команду для более детального погружения.

Приоритизация бэклога

Когда пользователь не находит товар в нужном размере на Lamoda, он может подписаться на его появление в наличии. Бывает, что товар через пару дней появляется на складе, и тогда имеет смысл его ждать. А бывает, что больше не появляется никогда, — если коллекцию раскупили и пополнения не будет. 

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

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

В ML-командах всегда есть риск, что потраченные время и силы не приведут к желаемому эффекту. И это нормально. Задача продакта на этапе приоритизации — оценивать и объяснять эти риски для стейкхолдеров и балансировать бэклог так, чтобы в результате команда приносила бизнесу пользу. 

Как выстраивает процесс хороший продакт:

1. Регулярно поставляет приоритизированный продуктовый бэклог для работы команды. Чем выше скилл и больше глубина понимания ML, тем заметнее разница в предлагаемых продактом гипотезах. 

2. Проводит оценку экономики и рисков ML-проекта. Даже без неопределенности, с которой часто связаны ML-проекты, сложно строить прогнозы об эффектах тех или иных фичей. В ML-проектах эта сложность возрастает в несколько раз, и в части Confidence из методологии RICE приходится закладывать дополнительные факторы и риски.

3. Балансирует бэклог между исследовательскими, продуктовыми и техническими задачами. Продуктовые фичи можно оценивать по RICE, на техдолг/развитие тоже принято выделять фиксированные проценты. А вот с исследовательскими задачами все не так однозначно. Если оценивать все идеи в бэклоге просто по RICE, то важные для будущего развития исследовательские задачи с непонятным эффектом никогда не пройдут в квартал. Продакту нужно найти баланс и всегда иметь сбалансированный портфель продуктов и задач: одни понятные и нужны для получения эффектов в краткосрочной перспективе, другие — сперва могут быть более туманны в части реализации, но с высоким потенциальным влиянием на будущее бизнеса.

Разработка и запуск в прод

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

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

Нехватка мощности помешала нам запустить A/B-тест в срок и потребовала серьезных архитектурных доработок.

Поэтому на этапе разработки и запуска в прод продакт должен:

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

• Делать выбор среди нескольких вариантов решения и отслеживать сроки исследований. Да, исследования занимают большую часть работы. И важно итеративно подходить к ML-задаче и не бросать эксперименты, если ваше решение действительно нужно пользователям. Но когда-то ведь уже пора остановиться, да? Продакт должен видеть эту грань и доносить свое видение команде.

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

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

Работа с командой и процессами — отдельная задача 

В Lamoda Tech мы внедрили комфортный процесс обмена знаниями между дата-сайентистами. Регулярно проводятся общие для всех команд демо, митапы, брейнштормы, результирующие за квартал встречи. 

Тимлиды ML-команд способствуют обмену инсайтами, найденными в данных: интересные для каталога закономерности могут быть в итоге полезны и для рекомендаций, и для поиска, и для гибкого ценообразования. А благодаря общим подходам мы проводим исследования быстрее и сравниваем более качественные идеи реализаций. 

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

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

Польза продакта в цифрах

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

Если продакт поможет дополнительно докатить до продакшена хотя бы 1-2 прибыльных ML-продукта за год и осчастливить тем самым миллионы пользователей более удобным функционалом, то вложения в +1 сотрудника с избытком окупятся для компании. Цель продакта в Lamoda Tech — заботиться о счастье пользователей и помогать строить растущий, прибыльный бизнес.

Так какой же он, идеальный продакт в ML-команде?

Ожидания от менеджера, работающего с ML-командой, включают все классические требования к продакту. Кроме этого, важно: 

1. Понимать и следить за развитием технологий, которые лежат в основе ML-продуктов. Помогать команде выбирать оптимальные решения с точки зрения стоимости внедрения, сроков реализации, рисков и потенциального эффекта.

2. Уметь управлять неопределенностью результата и ожиданиями стейкхолдеров. Объяснять вероятностный характер результатов ML и понимать, на каком этапе пора принимать решение о сворачивании проекта.

3. Знать ML-метрики своих продуктов и критерии, по которым можно оценить приемлемый уровень точности и полноты прогнозов модели. Например, при рекомендации размера важнее давать точные прогнозы, тогда как при рекомендации сопутствующих товаров может быть полезнее обеспечивать максимальное покрытие.

4. Объяснять принципы работы моделей для пользователей и стейкхолдеров (где это возможно и необходимо). 

5. Масштабировать функции ML: расширять покрытие продукта алгоритмами и обеспечивать сбор дополнительных наборов данных для повышения качества моделей. 

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

В случае если с вами работает такой продакт или это вы и есть — я вас поздравляю! 

Если пока нужных компетенций не хватает, здесь, безусловно, важна поддержка дата-сайентистов: спрашивайте, предлагайте помощь, погружайтесь в технические детали и в особенности процессов. Мне на первых порах очень помогли дата-сайентисты из команд рекомендаций и поиска в Lamoda Tech: объяснили детали алгоритмов, нюансы процессов и подсказали, где им нужна продуктовая помощь в первую очередь.

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

Желаю вам собрать команду профессионалов, в которой каждый может положиться на каждого, и регулярно достигать крутых бизнес-результатов вместе!