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

  1. Предоставление тестовых данных в качестве критерия приемлемости в пользовательских историях: инженеры обычно не имеют такого большого бизнес-контекста, как PM. Менеджер проекта должен убедиться, что тестовые данные доступны в контексте пользователей, чтобы они могли быстрее познакомиться с реальными сценариями и бизнес-контекстом. Поскольку модели проходят QAed с использованием тестовых данных и измеряются коэффициенты ошибок, чтобы принять решение о непригодности для запуска, тестовые данные, выбранные PM, становятся новыми критериями приемлемости для команды. Набор данных, который можно увидеть в реальном мире, является довольно открытым, поэтому PM играет решающую роль в выборе набора приоритетных тестовых данных. Это гарантирует, что большая часть ожидаемого использования продукта на всех рынках приходится на запуск продукта. Эндрю Нг во время выступления в Stanford GSB привел несколько хороших примеров выбора правильных тестовых данных для распознавания речи и чат-ботов.
  2. Выбор функций, основанный на знаниях о племени: команды эксплуатации и поддержки обычно имеют хорошие инструкции и передовые методы работы с существующими рабочими процессами продукта. PM играет важную роль в налаживании взаимопонимания между командами операторов и техническими специалистами, собирая знания в этой области. Это помогает командам по анализу данных выбирать функции, а также собирать бизнес-контекст для обучения моделей.
  3. Уравновешивание компромисса, ориентированного на бизнес-цели: в моделях машинного обучения всегда есть ошибки, и это помогает команде понять, как расставить приоритеты между уменьшением количества ложных срабатываний и ложных срабатываний. Эти компромиссы имеют решающее значение для точной настройки модели и измерения ее эффективности по данным испытаний. Менеджеры по продукту могут помочь своей команде, расставив приоритеты между ними, исходя из бизнес-целей и экономических выгод.
  4. Разработка продуктов машинного обучения для продуманной интеграции с существующими рабочими процессами: очень важно спроектировать, как функции на основе машинного обучения интегрируются с существующими рабочими процессами и приносят пользу пользователям. Большинство функций, основанных на машинном обучении, являются усовершенствованиями существующих продуктов, поэтому вместо того, чтобы быть черным ящиком, лучшие проекты прозрачно включают новые функции, чтобы дополнить текущий рабочий процесс продукта. Дизайн продукта должен быть легким для понимания пользователем результата модели или рекомендаций, сделанных моделью. Это выходит за рамки простого интуитивно понятного дизайна в сторону прозрачного дизайна продукта. Это повысит доверие к этой функции и ускорит внедрение и более широкое использование продуктов.
  5. Изящный отказ: модели могут не справиться со всеми возможными сценариями, наблюдаемыми в реальном мире. Вот где хороший дизайн должен красиво провалиться, и важно, чтобы продукт оставался честным и заслуживающим доверия. Менеджеры по продукту должны тщательно продумать работу с такими сценариями на ранней стадии разработки продукта. Некоторые из часто встречающихся сценариев в реальном мире также становятся источником новых тестовых примеров для улучшения вашей модели.
  6. Постоянное совершенствование модели с использованием строгого процесса обратной связи с продуктом: ни одна модель после запуска не работает должным образом с реальными данными, и очень важно понимать вновь полученные данные и действовать в соответствии с ними. Менеджер проекта должен очень тщательно спланировать запуск продукта и процесс сбора производственных данных, их использования и измерения эффективности модели как посредством внутренних измерений, так и посредством обратной связи с пользователями. Быстрое обучение и быстрые действия в первые 15–30 дней после запуска так же важно, как и время, потраченное на построение модели на этапе разработки.

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