Мой опыт выполнения тестового задания на менеджера продукта

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

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


                    Мой опыт выполнения тестового задания на менеджера продукта           0

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

  • Гипотеза (можно формулировать по SMART)
  • Действие (у меня это то, как я буду проверять их — все через глубинные интервью)
  • Метрики (что будет результатом проверки) — у меня это везде таблица с агрегированными данными по каждому сегменту
  • Выводы (собственно, то, что будем делать дальше, если гипотеза подтвердится или не подтвердится)

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

Качественные исследования (User research)

После того, как сгенерированы и приоритезированы гипотезы (в моем случае нет), создан Lean Canvas, самое время проверить, а правильно ли я определил сегменты аудитории и их проблемы. Для этого проводят проблемные интервью или user research. Не будем разводить демагогию на счет Custdev, но такие исследования я так не называю, т.к. это не интервью, а целый подход к созданию продуктов. На этот счет есть хорошая статья на GoPractice.

В задании я сделал шаблон проблемного интервью / интервью JTBD, ссылка здесь. За время работы и на своих проектах я провел около 50 интервью. Не знаю, много это или мало, но этого хватило, чтобы начать уверенно проводить такие исследования, четко формулировать мысли, выстраивать доверительные отношения с собеседниками и копать в самую суть.

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

  • Установите эмоциональный контакт (расскажите, чем занимаетесь, для чего пригласили человека, сделайте комплимент или расскажите свой пример из жизни). Чтобы выглядеть на равных, можете сделать какую-нибудь ошибку, чтобы человек понял, что все нормально и можно вести себя естественно. В среднем, интервью у меня занимали около 1-1,5 часов, но один раз я настолько разговорил человека, что встреча была 2,5 часа. Было утомительно, но безумно интересно, это высший пилотаж.
  • Проводите интервью с партнером. Исследование — это не допрос, а живая беседа. Не нужно строго идти по сценарию и вопросам, а углубляйтесь каждый раз, когда есть за что зацепиться. Партнер нужен для того, чтобы фиксировать ответы пользователя, подсказывать или задавать доп. вопросы, а после вдвоем удобнее анализировать результаты, т.к. вы можете по разному интерпретировать результаты. Best practice — запись интервью для последующего анализа, но обязательно спросите на это разрешение у интервьюируемого.
  • Обязательно переходите на эмоциональный уровень, именно там кроется истинная мотивация пользователей. Говорить об эмоциях тяжело, люди могут не понимать вопросов, но если научитесь, выйдете на новый уровень. На этот счет есть классная запись Ивана Замесина в Яндексе.

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

Расчет Unit-экономики

Ссылка на расчет экономики продукта здесь.

Ох, сколько же вопросов к этой теме. Я сам выходец из маркетинга, умею в достаточно точные прогнозы размещений для веба и мобильных приложений. При этом медиапланирование не равно unit-экономике. Для меня на данный момент точка роста — это умение считать LTV пользователей и PnL продукта.

У меня шаблон разделен на динамичные и статичные значения. Статичные значения (CPI, CR в онбординг, CR в trial и transaction rate (конверсия из триала в подписку) я взял по бенчмаркам или прикинул на основе опыта. В файле есть таблица с комментариями по этим метрикам.

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

  1. CPI (cost per install) — стоимость установки. У нас новый продукт, у которого нет органических установок. Поэтому я считал экономику для iOS версии и без учета виральности внутри продукта. Взял бенчмарк в 30 рублей, ссылка в файле.
  2. UA (user acquisition) — количество привлеченных пользователей, изменяемая величина. Взял для примера 500 человек, можно больше.
  3. Acquisition cost (стоимость привлечение) — произведение цены за установку на количество пользователей (установок)
  4. CR (onboarding) — конверсия из установку в авторизацию внутри приложения. Взял 80%.
  5. CR (trail) — конверсия из бесплатной версии в пробный период, взял 2% как бенчмарк.
  6. TR (transaction rate) — конверсия из триала в оплату, взял как бенчмарк на уровне 25%.
  7. C1 — сквозная конверсия из установки в оплату. Считается как произведение конверсии в онбординг, конверсии в триал и конверсии в оплату. У меня это в базовом сценарии 0,4%.
  8. CAC (cusotmer acquisition cost) — стоимость платящего пользователя. Считается как C1 * CPI. В моем случае один платящий пользователь стоит 7500 рублей.
  9. Subcription — стоимость подписки, после конкурентного анализа решил заложить 2990 рублей за годовую подписку. Для упрощения считал LTV в размере одного платежа за годовую подписку.
  10. COGS (Cost of Goods Sold) — себестоимость продукции. У меня это 30% — комиссия Apple за платежи внутри приложения.
  11. AMPPU (avarage margin per payment user) — средняя маржа с платящего пользователя (стоимость подписки — комиссия Apple)
  12. APRU (average revenue per user) — средний доход с одного пользователя. Считается как произведение AMPPU на C1. Отношение LTV с CAC мы можем уже посчитать как отношение APRU (доход с пользователя) к CPI (стоимости установки, пользователя). В нашем случае это 28% — убыток.
  13. Далее идут Renevue, Gross Profit, Profit — расчеты можете посмотреть по формулам.

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

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

Конкурентный анализ

Ссылка здесь.

В зависимости от ваших целей глубина и параметры конкурентного анализа могут отличаться. В моем случае я изучил приложения конкурентов со сказками, посмотрел на кол-во установок и средний доход через Sensor Tower (не наглядно). Посмотрел на основной функционал и модели монетизации. Для сравнения посмотрел, что происходит у приложений с аудиокнигами.

По этим данным можно сделать вывод, что у приложений со сказками не очень большое количество скачиваний, а доход не превышает $5000 в месяц. В купе с юнит-экономикой уже можно сделать предварительные выводы о том, что к идее стоит относиться очень аккуратно. Емкости у приложений нет, аудитория в приложениях аудиокниг в разы больше, а там представлены как раз текстовые и аудиоформаты сказок. Также эта таблица помогла мне понять, как я могу отстроиться от приложений конкурентов и какие функции заложить на этапе MVP.

Сбор требований к MVP

Ссылка на файл здесь.

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

  • Название продукта
  • Ценностное предложение
  • Сегменты пользователей
  • Наше предложение
  • Объем рынка
  • Функции внутри приложения
  • Каналы сбыта
  • Ключевые метрики
  • Критерий успешности запуска MVP

Прототипирование

Я не часто работаю в фигме, но знания имеются и их достаточно, чтобы за 4-5 часов собрать из компонентов неплохой кликабельный прототип.

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

Решенческие интервью

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

В решенческих интервью достаточно только обозначить цель респонденту, и задавать на каждому этапе / экране три вопроса:

  • Что видите?
  • Что понятно / не понятно?
  • Что делаете дальше?

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

В заключение

На тестовое задание я потратил около 7-8 часов (растянул на 2 дня). В целом, я доволен собой и тем, что у меня получилось на выходе. Из простого задания в два абзаца у меня получилось 11 листов в Google Таблицах. Как написал ранее, меня пригласили на интервью, финальное решение будет принято в декабре. Вне зависимости от результата я получит удовольствие от проделанной работы, еще раз структурировал подход и знания к тестированию гипотез.

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

Добавляйтесь в друзья в Facebook, будем дружить.

Источник: портал vc.ru

Добавить комментарий