Нужны ли ML-продакты?

Сегодня хочу поделиться своей историей о становлении ML-продактом.

🤓Когда я начал работать на новой должности, честно скажу, было непонятно практически всё. Начиная с понятия того, что такое датасет и зачем он нужен, и заканчивая циклом и процессами T2M фичей.

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

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

Эврика!
1. Я осознал важность своей должности, когда заказчики начали задавать вопросы членам команды, на которые ни один тех специалист не мог дать точного ответа. Вопросы касались статуса проекта, текущих бизнес-задач, необходимых взаимодействий, роадмапа и так далее. Эту роль выполняет менеджер продукта. Без него разработчики, имея зарплату в +7000 долларов в месяц, будут тратить время на организационные процессы, а не на написание кода.

2. Помню наши доски с исследованиями. Когда я пришел, они были пусты, и не было предложений по развитию продукта, только задачи по совершенствованию моделей и созданию новых. А как же расширение точек входа, совершенствование функционала и взаимодействия для улучшения UX пользователей? Вот зачем появился ML-продакт: он будет, преодолевая трудности, приносить задачи команде технического продукта. Конечно, могут возникать сомнения в значимости задачи. Но представьте, когда вы принесете исследование, основанное на данных, вопросов сразу не останется.

Вот для чего нужен ML-продакт. Это шестеренка, которая приводит в движение все остальные, запуская мощный и сложный "двигатель" – продуктовую ML-команду.

#Вопросы на собеседованиях на позицию ML Product Manager

Привет, друзья!

Сегодня запускаем новую рубрику, где будем делиться самыми интересными и полезными вопросами, которые вы можете получить на собеседованиях на позицию ML Product Manager. 💡

Вот первый вопрос на разогрев:

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

Как бы вы решили эту задачу? Поделитесь своими мыслями в комментариях! Сегодня вечером мы опубликуем наш вариант ответа. Не пропустите! 🔔

Ваши ответы очень важны для нас, давайте учиться друг у друга! 👇

______________
Подписывайтесь: "Как приручить ИИ"

#Правильный ответ

На самом деле, как и любой вопрос на собеседовании, этот имеет несколько возможных вариантов ответа:

1. Анализ текущих данных

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

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

2. Сбор обратной связи от пользователей

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

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

3. АБ-тест с минимальными улучшениями

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

- Плюс: Это честный АБ-тест, который даст понимание, влияет ли время загрузки на поведение пользователей.
- Минус: Всё же требует ресурсов разработки, чего изначально хотелось избежать.

4. Ухудшающий АБ-тест

Часто забывают про такой важный и относительно простой метод как ухудшающий АБ. Давайте одной группе пользователей оставим сайт без изменений, а другой — замедлим загрузку, и посмотрим, как это повлияет на их поведение.

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

Какой метод вам кажется наиболее эффективным? Делитесь мнениями в комментариях!
__________
Подписывайтесь: "Как приручить ИИ"