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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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