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

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

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

Тестовое задание:

Расскажи, как бы ты проверял гипотезу:
«У людей с детьми, которые вовлечены в процесс воспитания и ухода за ребёнком, есть потребность находить сказки для чтения, чтобы уложить их спать».

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

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

Составление Lean Canvas Model

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

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

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

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

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

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

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

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

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

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

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

Генерация гипотез через JTBD

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

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

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

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

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

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

Генерация гипотез через User Story

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

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

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

Гипотезы (HADI-циклы)

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

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

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

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

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

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

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

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

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

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

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

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

В заключение

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

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

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

9393
86 комментариев

Со всем уважением к вам, хочу высказать ряд замечаний.

Ваше решение это набор клише и технологий, без смысла, без последовательности, без понимания и целесообразности.

1. Прежде чем решать решать проблему, нужно понять её суть и сформулировать.

Вам дано:
"«У людей с детьми, которые вовлечены в процесс воспитания и ухода за ребёнком, есть потребность находить сказки для чтения, чтобы уложить их спать»."

В чём цель?? В чём цель клиента?? У клиента же ведь есть потребность. Или ребёнок должен быстрее уснуть. Или удовольствие ребёнка, то есть повышение качества поиска сказок. Или иные вещи. На проблематику нужно смотреть с точки зрения клиента. Это первое. Вот с чего нужно начиать.

Какой смысл начиать с Lean Canvas, когда вы ничего не знаете?? Лин кана используется для моделирования бизнеса. Что вы моделируете и формулируете, когда у вас ничего нет??

2. Если рассматривать ваши гипотезы по JTBD, то в некоторой степени их можно оценить как приближение к решению. Но я не увидел выхода на решение проблемы.

"Родители не высыпаются и бывают разбитыми на следующий день,
если ребенок долго не мог уснуть или спал беспокойно."
Это вообще что?? Это какая-то чушь. Как и остальное написанное.

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

3. После того как вы сформулировали проблему, которую нужно достичь, нужно сформировать метрики, по которым в эту самую проблему будете контролировать и оценивать. У вас этого нет. Смысл в том, что по итогам этого вы можете выйти на объем аудитории и рынка, что в итоге решает вопрос целесообразности создания приложения в принципе. И ваши качественные исследования не решают данный вопрос.
Количественно можно оценить число родителей.
Число детей определённых возрастов. Их можно и нужно сегментировать. Это не было сделано.

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

4. После того, как вы сформулировали метрики, по которым нужно проконтролировать проблему, которая выльется в анализ рынка, нужно сформулировать как вы это будете делать. Этого тоже нет.

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

Ваше качественное исследование, это просто сваливание в кучу различных вопросов. Бессмысленное и нецелесообразное.

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

То что сделано - бессмысленная чушь.

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

34
Ответить

Спасибо за уделенное время и развернутый комментарий. Мне нравятся дискуссии, в части пунктов согласен, в другой - нет:

1. Для понимания, у вас есть запущенные проекты, которые стабильно приносят доход? У меня только неудачный опыт. Почему я не должен им делиться, я в интернете вообще не много тестовых нашел для продактов, а особенно с решением. Мне не стыдно показывать свой труд. Пусть люди включают критическое мышление и фильтруют некачественный материал. Ваш аргумент про то, что нужно выкладывать качественные материал я не принимаю, я не кандидатскую диссертацию пишу. Честно признаюсь, что моя первая реакция была такая, что вы зануда и теоретик, меня прям реально бомбануло, перечитывал комментарии 3 дня)). После понял, что есть доля правды в ваших словах.

2. Я согласен, что с точки зрения структуры и логики есть ошибки в задании, винить мне не кого. Кто-то написал ниже, что к формулировке задания есть вопросы: первая часть про то, что нужно показать логику проверки гипотезы ок, а вот вторая, про прототип и экономику не логична. А если проблема не подтвердится, что тогда прототипировать и считать? Из-за этого я начал фантазировать и делать весь путь, хотя в реальности, возможно, я бы давно остановился. Но эти вопросы руководству я не задал. Отсюда и ваши выводы, что мало понимания, целесообразности и так далее.

3. Что касается Lean Canvas. Я его поместил в начало, чтобы человек как раз мог посмотреть на одном листе все то, что я делал до этого. Заполнить его из головы нереально, согласен, это уже финальный штрих. Но у меня все задание - гипотетическая ситуация, у меня нет фактов. Но я его заполнил только тогда, все все остальные пункты сделал.

Структура расходов:

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

Ключевые метрики:

Маркетинговые, продуктовые, бизнесовые. Вы же знаете, что такое Nord star mertic и дерево метрик? Можно вынесли одну метрику, этого будет достаточно, а далее в сделать дерево и не указывать все в канве. Опять же, трата времени.

Риски:

Аналогичная ситуация. Про PEST не знал, спасибо, изучаю. Вы не согласны, что главный риск стартапа - отсутствие потребности, или решение не той проблемы, или решение проблемы не тем способом? Или то, что экономика не будет сходиться? У меня B2C приложение, сказки для детей, какие политические и социальные риски? Важна логика, помните, я же не реальный бизнес запускаю. Я в сети нашел неплохой, как мне кажется, слайд с рисками, пользуюсь - http://joxi.ru/p27jx1vCnOalYm

Экономика:

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

4. Гипотезы по JTBD

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

5. Метрики, по которым можно проконтролировать проблему

Я не понял, о чем вы пишите. Что за метрики проблемы, уточните.

6. Сегментация аудитории и вопросы для интервью

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

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

Согласен, можно доработать. Но не так, как предлагаете: ФТ и НФТ требования мне не нужны здесь, как и бизнес-требования, архитектура и так далее. Я сделал анализ до уровня скачек, дохода, и минимальной функциональности типо наличия картинок, текстовых вариантов. Опять же, нужно показать логику, я не делать проект. Я на 100% принимаю аргумент, что сделано очень много, а с вашим подходом я вообще по итогам тестового должен уйти с работы и запустить бизнес)))

8. Прототип

Требования я минимальные описал. Прототип кликабельный, там есть логика в онбординге, все подряд экраны листать не нужно. А онбординг и авторизация связана с обновлением на iOS на прошивку 14.5. Это уже детали. Опять же, я показал минимальный функционал, у меня нет цели делать все экраны. У меня на задание ушло 4-5 часов на 2 дня, можно было ужаться, но и я это время зря не провел. Не понимаю, что вам еще нужно)

P.S

Еще раз спасибо за обратную связь, она ценная. Кто-то узнал для себя новое, кто-то как душнила начал язвить, вы дали качественную ОС, но которую я покритиковал. Я для себя сделал выводы, и тестовое переделаю с учетом комментариев и сравню две версии. У вас ответ реально тянет на статью, может, выложите с учетом ваших комментариев фактуру, а не только тезисы?)

5
Ответить

Тянет на отдельную статью. Корректнее было бы ответить там.

1
Ответить

Комментарий недоступен

1
Ответить

8. MVP комментировать бессмысленно. С учетом отсутствия требований, это просто сделанное от балды решение. Больше половины показаны какие-то сервисные окна, типо регистрации и прочего.

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

По канве можно сказать, что она в целом на уровне мусора. Приведу несколько замечаний для примера.
"Структура расходов
1. ФОТ
2. Налоги
3. Оплата за оцифровку и озвучку сказок (если делаем с нуля)"
Нет организационных расходов, расходов на сервера и техническую поддержку приложения, нет еще кучи всего. Да банально, даже расходов на маркетинг нет.

Риски:
Просто полная чушь.
"Потребительские сегменты и их размер Детей рожали и будут рожать, проблем с доступом к аудитории не вижу " Это вообще что?? Вы это пишите в рисках.

Для анализа рисков, есть например такая вещь как PEST. Загуглите что это такое.

"Ключевые метрики
1. Активация из триала в подписку
2. Retention
3. LTV "

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

10. Если под Profit имеется ввиду Чистый доход, то он рассчитывается следующим образом:
Net Profit = Gross Profit − TOE − IE − Tax

То, что написали вы не имеет смысла. Как можно из Revenue (Выручки) вычесть Gross Profit (Валовую прибыль) и получить чистый доход я не понимаю. Формула ошибочна. Вот формулы для расчёта показателей:
https://www.audit-it.ru/articles/finance/a106/868238.html

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

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

С уважением.

30
Ответить

Здесь ещё проблема в том, что продакт в принципе это все не должен делать.

Ответить

Объем работы поражает, но по моему опыту, пока кто-то делает такое огромное тестовое задание, другому уже приходит оффер, потому что он в одном емэйле показывает свой подход / мысли.

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

Но в любом случае думаю, что получился невероятно полезный материал для начинающих продактов. Даже я, если честно, никогда не задумывался о том, что Lean Canvas можно сделать в таком формате (сам его + бизнес-модель Остервальдера делал в Figma, но здесь в разы быстрее можно получить по сути то же самое).

Очень круто, спасибо за статью!

27
Ответить