Специалисты «Яндекса», Facebook, Prisma рассказали о проектах учеников школы «Мобилизация» 2016 года выпуска

Перспективы приложений для бега, рецептов и почты в виде карточек.

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

После курса лекций участники «Мобилизации» объединились в группы по 4-6 человек, чтобы создать с нуля работающий прототип мобильного приложения и представить его на финальной презентации. На совместную работу над приложением было отведено пять недель. Успешный проект должен был отвечать сразу нескольким критериям, в том числе эффективно решать проблему пользователя.

​Круто, что ребята прошли весь процесс создания продукта: нашли проблему у пользователей, изучили весь пользовательский сценарий от заказа до получения посылки. Судя по всему, использовали и качественные методы исследований — проводили интервью, изучали вручную контент писем, и количественные: делали опросы и работали с аналитикой «Яндекс.Почты». Получившийся продукт решает реальную проблему пользователя, это очень здорово.

Метрики успеха продукта понятные, но их слишком много — они и про использование, и про качество сразу. Я бы ограничилась одной-двумя ключевыми метриками, причём привязывала бы их к большому продукту «Почты» — как карточки должны влиять на KPI «Почты» в целом.

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

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

Перед тем, как делать что-то классное, надо включить голову и корпоративное мышление (да-да, тут вам не стартап на дому). Ответьте на несколько вопросов:

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

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

А как iTunes решает эту проблему? Было сказано про поиск через ключевые слова в App Store. К сожалению, это не так. 60% поисков это уже брендовый поиск, 30% самые популярные ключевики, и только потом музыка для бега.

Как человек, который бегал полжизни, и не только от хулиганов, но ещё и профессионально, могу сказать: если бег серьезный, он вообще без музыки. Даже если вы просто бегаете по вечерам, анализ темпа за 60 секунд — странный прием, ведь есть светофоры или передышки, а ещё иногда люди делают ускорение (можно ли предсказать его с помощью радио?).

Понравилась реализация: управление и простота. Её бы внутрь обычного приложения в режим бега.

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

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

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

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

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

Я бы посоветовал им потратить месяц на то, чтобы, используя подручные средства (группа в Facebook, Google Docs или ручная работа), попытаться добиться максимального результата в рамках своей цели (помочь максимальному количеству инвалидов). В процессе они увидели бы, что ограничивает их, что не дает помочь в 10 раз большему количеству людей — автоматизация, недостаток волонтеров или, возможно, другие факторы. И уже только после этого, приоритезировав найденные узкие места, думать над решениями.

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

Для анализа данных мало, презентация милая, но про бизнес практически ничего не сказано.

Сильные стороны:

• Доставка еды из магазина, формирование привычной корзины заказа для регулярного потребления (но эта гипотеза ещё не проверена).
• Выбраны удачные сегменты аудитории (например, мамы с детьми) и под них проработаны сценарии использования. Как я понимаю, именно они будут ядром ЦА — им удобна доставка дома, они готовят для семьи и мужа, но устали готовить примерно одно и то же. Однако не хватает данных статистики по запросам для анализа (кто ищет рецепты и почему, какие есть паттерны).

Слабые стороны:

• Мало показана первая сессия и то, как будет решена проблема большого выбора и длинного хвоста предпочтений пользователей. Всё это снижает конверсии.
• Экономика: даже при среднем чеке 1000—3000 рублей и 10% комиссии за еду, 10—30 рублей с заказа — очень мало. Чтобы зарабатывать 1 млн рублей, нам нужно 33,3 тысяч —100 тысяч заказов в месяц. Если 10% из тех, кто выбрал рецепт, делает заказ, получаем 330 тысяч—1 миллион выбранных рецептов и людей. Это не приговор, но нужно хакать Customer Journey Map и упрощать первую сессию, не откладывая кнопку «Заказать» далеко в интерфейсе, однако, судя по роадмэпу, это вопрос отложен на потом.

• Основной вопрос: почему будет не 1,1 повторный заказ еды, и почему ретеншена даже в 30% на второй месяц (будет скорее всего сильно меньше) хватит для значимого числа повторных заказов.

• Тема с экономикой и доставкой пока плохо проработана. Неочевидно, почему ключевая метрика С2 (конверсия во вторую покупку) будет больше 50-60%.

#Интерфейсы