MVP продукта в корпорациях: как внедрить фичу и не растерять пользователей

При создании новой фичи всегда есть риск что-то упустить. Чтобы минимизировать потери, перед выводом нового функционала в продакшен создают MVP — минимально жизнеспособный продукт. Благодаря ему можно проверить, понравятся ли изменения пользователям. Как выглядит процесс проработки MVP продукта в крупных компаниях рассказывают руководитель отдела продуктовой разработки Юрий Кочарян и руководитель группы продуктов для авторов Вера Советкина из Дзена. 

Как устроена работа в продуктовой команде в Дзене

Вера Советкина

Руководитель группы продуктов для авторов Дзена

Мы работаем по принципу SCRUM.

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

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

Как возникают идеи новых продуктовых фич

Идеи фич обычно появляются из нескольких источников: 

• из общения с аудиторией продукта с помощью исследований;
• из аналитики продуктовых метрик;
• из анализа рынка и конкурентного анализа;
• из обращений в поддержку.

А ещё запросы и идеи могут поступать от коллег: например, команда разработки предложила ввести возможность делать подборки в каналах авторов.

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

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

Как новые фичи проходят верификацию для MVP

Доводим фичу до разработки

Для этого нужно пройти несколько этапов.

1. Продуктовый анализ, который заканчивается процессом продуктового ревью. 

Его результатом становится артефакт в виде User Story, где, в частности, есть ответы на следующие важные вопросы:

• есть ли вообще проблема?
• что это за проблема?
• чья это проблема, продакта или пользователей, какого объёма аудитории?
• почему её нужно решать?
• на какие метрики это повлияет?
• как сильно это повлияет на метрики?
• спустя какое время мы ждём положительный эффект?

2. UX, side-by-side исследования и т. д. Порой после них вносятся существенные корректировки в предлагаемые интерфейсы. В исследования отдаются как уже готовые макеты дизайна, так и мокапы и варфреймы (wireframe).

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

После этого фичи отправляются на тестирование, это отдельный большой процесс.

Проводим тестирование

Юрий Кочарян

Руководитель отдела продуктовой разработки Дзена

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

Если изменения небольшие, то можно провести A/B-тестирование, посмотреть на метрики и сразу реализовать фичу в продакшене.

С помощью А/В мы также можем довольно быстро на большом объёме пользователей понять, что идёт не так не только в продукте, но и в технической реализации, например, найти баги. Некоторые ошибки сложно заметить на тестировании до релиза. Но мы можем протестировать фичу на A/B и уже на следующий день понять, что у нас не так, отключить её и вернуть в доработку.

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

Иногда мы проводим тестирование прототипов на пользователях. Можем даже спросить у коллег в офисе, нравится ли им нововведение.

Если метрики после А/В-тестирования растут, то мы раскатываем фичу в продукт.

Проверяем метрики в экспериментах

Вера Советкина

Руководитель группы продуктов для авторов Дзена

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

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

Например, в процессе создания роликов на старте мы тестировали три гипотезы:

1. Если пользователь остановился на просмотре роликов, то при следующем заходе они снова откроются автоматически. 
2. Предлагали пользователям на Android, которые чаще остальных смотрят ролики, установить отдельную иконку для них на своём девайсе, чтобы они сразу переходили в ролики. 
3. Предлагали пользователю настроить открытие роликов в приложении в первую очередь.

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

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

А вот как дизайнеры учили смотреть ролики Дзена

Какие фичи мы внедряли и как

Юрий Кочарян

Руководитель отдела продуктовой разработки Дзена

Мы ускоряли загрузку сайта на dzen.ru. Это важная метрика, потому что там загружаются и поиск «Яндекса», и Дзен. Чтобы ускорить сервис, мы делали загрузку страницы двумя чанками — кусками страницы. Сначала мы отдаём пользователю чанк с поиском, потом отдаём второй чанк со страницей. Это позволяет отдавать строку поиска буквально за миллисекунды.

А вот в части Дзена сложная машинерия: нужно учитывать рекомендации для юзера. Это занимает сотни миллисекунд, поэтому мы отдаём его чуть позже. И так как пользователь уже начал получать контент и взаимодействовать со страницей, ожидание для него становится менее тягостным.

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

Вера Советкина

Руководитель группы продуктов для авторов Дзена

Скорость загрузки мы увеличиваем не просто так. Мы хотим, чтобы пользователям быстрее отдавался интерфейс, UI–элементы, чтобы он быстрее мог с ним начать взаимодействовать, что-то поискать. Тем самым мы решаем количество вхождений в поиск и уменьшаем количество отказов пользования сервисом.

Такие фичи пользователь не осознаёт. По ним нельзя провести кастдев и спросить, понравилось это людям или нет. По таким фичам мы отслеживаем микс продуктовых и технических метрик. Часть из этих фич не нужно тестировать в А/В, потому что не надо доказывать, что высокая скорость загрузки это хорошо. Это оценка по здравому смыслу.

Бывает, что техническое решение не даёт ощутимого прироста в моменте, но может влиять на продукт спустя время.Люди привыкли, что все приложения работают нативно, ничего не лагает. Если мы сделаем более плавный скролл, то это, скорее всего, не повлияет на метрику прямо сейчас. Но зато у пользователей накопится знание, что Дзен — качественный быстрый продукт.

Юрий КочарянРуководитель отдела продуктовой разработки Дзена

Как мы работали с негативным фидбэком

Вера Советкина

Руководитель группы продуктов для авторов Дзена

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

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

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

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

Как на этапе MVP продукта мы понимали, что именно нужно дорабатывать

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

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

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

Юрий Кочарян

Руководитель отдела продуктовой разработки Дзена

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

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

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

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

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

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