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

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

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

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

• Составление Lean Canvas Model
• Генерация гипотез через JTBD
• Генерация гипотез через User Story
• Гипотез через циклы HADI
• Шаблон для качественного исследования
• Расчет unit-экономика
• Конкурентный анализ
• Сбор требований к MVP
• Прототипирование
• Шаблон для решенческого интервью

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

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

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

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

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

Начал заполнение с сегментов клиентов, выделил, как мне показалось, 5 крупных сегментов, которые могу пересекаться друг с другом:

• Читают бумажные книги со сказками
• Читают электронные книги со сказками
• Включают сказки в аудио- и видео- приложениях (Youtube, Boom, Яндекс музыка)
• Включают сказки в приложениях с аудиокнигами или приложениях конкурентов
• Не читаю и не включают сказки совсем, предпочитают разговаривать с детьми и петь песни самостоятельно

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

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

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

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

Ссылка на вкладку с гипотезами здесь.
Про JTBD подробно и интересно есть на сайте Тильды.

JTBD (jobs to be done) - методология, которая помогает генерировать гипотезы или определять проблемы пользователей с точки зрения той работы, которую хочет сделать пользователь, "нанимая" наш продукт на работу. Поищите в интернете статьи или видео по тому, как работать с данным инструментом.

Три общих проблемы родителей, которые укладывают детей, сгененрировал с помощью этого инструмента. Возможно, я пользуюсь им неправильно и не расписываю "работы" пользователей со всех сторон, но в целом это помогает более детально посмотреть на проблемы. Так, например, для трех проблем я выделил 3 контекста, в которых находятся родители, Big Job (основная задача, которую хотят решить пользователи), Small Job (второстепенная задача), конкуренты и альтернативы, а также ценность, которую мы дадим каждому сегменту людей с помощью нашего решения.

Например, гипотеза:

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

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

Ссылка на вкладку с гипотезами здесь.
Достаточно интересно и подробно про инструмент читайте здесь.

Опять же, не претендую на истину, но в этом блоке для каждого сегмента аудитории я предположил, какие могут быть модели поведения, тип личности и их проблемы (гипотезы). Собственно с этого я и начал определение сегментов для продукта, а потом все перенес в Lean Canvas.

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

Ссылка на таблицу с гипотезами здесь.

Есть огромное количество способов формирования бэклога и приоритезации гипотез (ICE, RICE, Кано и тд). Опять же, не будут отнимать ваше время и лить воду. Загуглите, если интересно про это почитать. Я же поклонник того, что любое предположение нужно подтвердить или опровергнуть. Для этого классно подходят HADI-циклы:

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

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

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

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

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

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

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

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

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

Ох, сколько же вопросов к этой теме. Я сам выходец из маркетинга, умею в достаточно точные прогнозы размещений для веба и мобильных приложений. При этом медиапланирование не равно 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

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

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

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

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

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

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

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

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

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