Привет, меня зовут Галя Ширанкова, я продуктовый юнит-лид в Авито. Отвечаю за несколько команд и занимаюсь мессенджером Авито — вместе с командой мы создаём новые возможности для быстрой покупки и продажи в чатах. Также я ментор для продактов и тех, кто только хочет зайти в эту профессию.

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

Я работала во многих больших компаниях – Ланит, Т1, МТС, ВК. Про свой опыт и развитие в больших корпорациях пишу в канале «Полтора продакта». Подписывайтесь, чтобы не терять новые кейсы.

Содержание:

• Что не так с мелкими инициативами

• Как в Авито принимаются решения по большим и важным инициативам

• Как сформировать свою ставку

• Запустили LLM-based ассистента, который обрабатывает 13% вопросов покупателей в мессенджере Авито

• Проверка базовой гипотезы

• Трекшен-модель

• Работа с рисками

• Итоги: 4 необходимых условия до запуска рисковой инициативы

Что не так с мелкими инициативами

В работе передо мной стоят две большие задачи:

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

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

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

• нанести большой вред;

• получить негативный фидбэк от пользователей, причём в любых количествах. Я регулярно встречаю кейсы, когда продукты не выкатываются в прод, потому что они получили 10–15 обращений в поддержку на сегменте в несколько миллионов человек;

• согласовывать со всеми. Если продакты работают в больших компаниях, им становится очень «страшно», потому что их инициативы могут внести изменения в PnL других команд и негативно повлиять на их метрики.

В общем, «нас накажут», всё очень страшно. Тем не менее это очень плохой путь, потому что при таком подходе:

Бизнес не растёт. У нас есть бэклог из 100500 осторожных гипотез, каждая из которых значимо на бизнес не повлияет.

Ресурсы тратятся без понятного результата. Довольно сложно прокрасить A/B-тесты при маленьких изменениях, поэтому компания не может подсчитать, сколько ценности она получила за счёт работы такой команды.

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

Представьте себе резюме продакта, который пишет примерно следующее:

Я запустил пятьдесят фичей. Я не знаю, как они повлияли на бизнес, потому что ничего не смог замерить. Могу и у вас в компании такое повторить!

Согласитесь, нет жгучего желания взять его на работу?

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

• выбирать действительно большие кейсы, над которыми стоит работать, чтобы качественно продвинуть бизнес вперёд;

• валидировать такие идеи и понимать потенциал гипотез;

• митигировать риски, потому что большие продукты, о которых я говорю, — всегда рисковые;

• и, наконец, запускать продукты, которые растят бизнес.

Как в Авито принимаются решения по большим и важным инициативам 

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

Под «гипотезой» мы обычно понимаем решение какой-то маленькой проблемы и какую-то конкретную фичу — хотя сама по себе эта фича может не принести никакого роста.

Если гипотезы собрать в большие бакеты, имеющие ожидаемый эффект, который можно замерить, то с этим становится возможно работать. Такими бакетами могут стать «ставки». 

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

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

Основные характеристиками ставки:

1. Оценённый эффект в бизнес-метриках, потому что, если мы хотим двигать бизнес, нам нужны именно бизнес-метрики. Чаще всего это — выручка (revenue), но бывают и другие кейсы. Например, если говорим про продукты в ранних стадиях жизненного цикла, это может быть, например, доля рынка, ежедневные активные пользователи (DAU) или возвращаемость пользователей (retention).

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

3. Риски: нам должны быть понятны риски этой ставки, и ожидаемый эффект должен их перекрывать.

Чтобы приоритизировать ставки, можно использовать показатель выручки на одного сотрудника (Revenue per FTE). Он показывает, сколько выручки получает компания в расчёте на одного сотрудника. Revenue per FTE помогает оценить производительность труда и эффективность использования персонала: чем выше показатель, тем больше дохода приносит каждый сотрудник.

Использовать показатель выручки на одного сотрудника полезно как на старте новой ставки для ответа на вопрос: «А точно ли это лучшее, на что сейчас нужно тратить ресурсы?», так и при принятии решения о продолжении работы над ставкой. 

Замечу, что для приоритизации ставок не нужен метод RICE (Reach, Impact, Confidence, Effort). На старте не так важен показатель уверенности в оценках — confidence, так у всех ставок он по умолчанию будет минимальный. При этом нам важно эффективно вложить ресурс и принести им наибольший вклад в бизнес-метрики. 

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

Для стратегического планирования в Авито мы используем крупные ставки уровня стратегии. Если говорить про портфель мессенджера Авито, чаще всего у нас их три вида:

Кстати, прекрасную статью про продуктовый портфель писал Денис Дудоров: «Что такое продуктовый портфель и какие боли продакта он закрывает».

Как сформировать свою ставку 

Кратко опишу 7 способов, а на одном сфокусируюсь подробно и покажу кейс внедрения из практики.

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

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

3. Решить большую пользовательскую проблему. Вы все наверняка собираете «голос клиента»: через опросы NPS/CSAT, запросы в техподдержку, отзывы в приложениях и так далее. В больших компаниях обычно есть ещё значимый поток запросов от стейкхолдеров и обратной связи от соседних команд.

По отдельности это так называемый длинный хвост — если решать проблемы по одной, вы не увидите влияние на бизнес. В таком случае предлагается каждый такой запрос привязать к большой верхнеуровневой проблеме, которую пользователь не смог решить по JTBD (jobs to be done), и сформировать 7-10 самых болезненных job story. Например, Job-story может звучать так:

Теперь поговорим про ставки, которые можно формировать в только зрелых продуктах. 

4. Заняться решением проблем конкретного сегмента. Проверьте, есть ли у вас сегмент, который не удовлетворён больше всего. Это и может стать отправной точкой для создания нового продукта. 

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

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

5. Изменить модель монетизации. Подумайте:

• что создаёт ценность в вашем продукте;

• как часто продукт нужен;

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

6. Спуститься или подняться по CJM. Ваш продукт существует как часть большого пути пользователя в продукте — он что-то делает до и после использования вашего сервиса или приложения. Здесь можно:

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

• сформулировать гипотезы их автоматизации.

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

7. Сократить неоптимальный шаг CJM. А вот об этом давайте поподробнее.

Запустили LLM-based ассистента, который обрабатывает 13% вопросов покупателей в мессенджере Авито

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

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

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

Ассистент — как раз тот самый канонический большой и рисковый кейс: у нас огромное количество чатов, и здесь, очевидно, большой масштаб. 

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

Проверка базовой гипотезы

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

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

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

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

В рамках теста покупатели получали ответ на эти вопросы с формулировкой «Продавец сказал, что…». 

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

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

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

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

Для проверки автоответов по информации из объявления мы добавили ещё несколько популярных вопросов. Теперь отвечали не только по параметрам объявления, но также анализировали текст из карточки и добавляли это в ответ ассистента. 

Например, если пользователь спрашивал, какой размер у этой вещи, а в описании объявления было указано, что «юбка или шорты маломерят» — мы сообщали покупателю размер и эту информацию тоже. Такой тест также прокрасил сделки. 

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

Трекшен-модель

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

Процесс подготовки такой модели довольно сложен, поэтому не буду останавливаться на этом в статье. Если интересна тема, подробнее я писала про это в Телеграфе: «Считаем деньги от внедрения LLM: traction model Avito Assistant»

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

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

Трекшен-модель держится на двух понятиях:

1. Аутпут-метрика — должна вырасти на выходе. Как раз та самая бизнес-метрика, ради которой ставка затевается.

2. Инпут-метрика — та, над которой мы будем работать в ожидании, что аутпут-метрика вырастет.

Думаю, вы уже поняли, зачем нам Ассистент: мы собираемся увеличить сделки на Авито — они и будут аутпут-метрикой создаваемой трекшен-модели. Фактически мы переводим чаты, в которых ответов за первый час не было, в те, где ответ за первый час был. И чтобы разобраться с инпут-метриками, нужно определить, на что конкретно будет влиять продукт. 

Мы понимали, что не можем напрямую повлиять на долю ответов продавцами за первый час. Наше влияние ограничивается тем, что в ряде кейсов мы начинаем отвечать за продавца — и это далеко не 100% кейсов, потому что для многих популярных вопросов нужно вмешательство человека. Например, для подтверждения договорённости. 

При этом если Ассистент отвечает, то он отвечает быстро, и все его ответы зачтутся за ответ в первый час.

В итоге для трекшен-модели мы выбрали долю первых сообщений покупателей с ответом Ассистента — именно на эту метрику мы можем влиять, масштабируя продукт. По сути, это классический adoption фичи, в нашем случае выраженный в отвеченных сообщениях. 

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

Дальше мы можем домножить прирост доли ответов на ту самую разницу конверсий и так получить прирост сделок. 

Ещё нам нужен понижающий коэффициент: так как мы знаем, что Ассистент будет конвертировать хуже, чем живой продавец. 

Этот коэффициент можно взять из предыдущих A/B-тестов: гипотеза решения подтверждена, и мы знаем, как ответы Ассистента конвертируют пользователя в сделку.

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

Трекшен определил развитие продукта: при такой модели Ассистент должен быть массовым продуктом. Поэтому для него мы выбрали opt-out модель, где согласие считается полученным по умолчанию, пока пользователь явно не откажется от него. 

То есть мы сначала отвечаем на вопрос, а потом спрашиваем у продавца, хочет ли он оставить Ассистента или отключить.

Работа с рисками

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

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

Очень важно не прятать самое страшное под ковёр, потому что задача адекватно принять решение — нужно идти в этот рисковый проект или нет. 

С рисками можно работать как с бэклогом: у каждого есть размер, вероятность наступления и последствия. Например, задайте себе вопрос: при наступлении риска вы сможете быстро его митигировать или это будет фатально? 

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

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

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

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

Конечно, на совет нужно нести не все риски, это абсолютно неадекватно: вы сильно увеличите time to market запуска ваших ставок, да и зачем дёргать C-level по пустякам. Поэтому чаще всего создаётся правило: как и в каком случае команда сама может принять риски и план митигации, а когда нужно собирать совет.

Как это работает у нас:

• если нет блокирующих рисков, решение может принять сама команда. Только при условии, что всё будет запускаться под A/B;

• если есть блокирующие риски в размере N миллионов рублей, то решение может принять руководитель с учётом плана митигации, с которым он согласен;

• если это большой риск, то собирается совет, который уже помогает определиться: идём мы в инициативу или нет.

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

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

Итоги: 4 необходимых условия до запуска рисковой инициативы

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

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

2. Подтверждение базовой гипотезы. Их бывает два типа: гипотезы проблемы и решения.

3. Трекшен-модель. 

4. Понятный процесс митигации и согласованный план рисков.

В общем-то, и всё. 

Благодаря такому подходу, большинство наших GEN AI проектов ROI-позитив — ещё на входе мы отрезаем инициативы, в которых либо ничего не подсчитано, либо ничего не получается. 

А тем, кто думает, что это всё только для бигтехов с их сложными процессами согласований и ритуалами, я скажу вот что:

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

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

Ну а наша ставка сыграла. Ассистент запущен в вертикали Товары и отвечает на популярные вопросы более чем в десяти категориях. Уже 13% вопросов покупателей обрабатываются автоматически, и это основная ставка юнита на следующий год. 

Желаю, чтобы и ваши ставки играли.

Расскажите в комментариях, какие у вас боли с крупными запусками?

А если хотите вместе с нами адаптироваться в мире стремительно развивающихся технологий — присоединяйтесь к командам. Свежие вакансии есть на нашем карьерном сайте.