Как проверять PMF и внедрять новые функции: фреймворки и методологии мировых гигантов
Как проверить жизнеспособность идеи, найти Product-Market-Fit и работать с гипотезами? На каждом проекте Фабрики Гипотез мы используем большое количество фреймворков. Решили собрать интересные и неочевидные методологии, которые могут облегчить процесс работы с продуктом.
Привет, я Андрей Краснопеев — основатель агентства стратегических исследований «Фабрика гипотез». Мы проводим глубинные интервью, анализируем конкурентов, занимаемся трендвотчингом и реализовываем стратегии развития продуктов.
Что вас ждет в этом выпуске:
- Как проверить жизнеспособность идеи
- Фреймворки внедрения новых функций
- Схемы работы с Product-Market-Fit
- Методологии работы с гипотезами и экспериментами.
Мы анонсируем дайджест только в своем Telegram-боте. Подпишись, чтобы не пропустить свежий выпуск.
Features Development
Value delivery – подход постоянного обеспечивания клиента ценностью
Успешные технические команды уделяют особое внимание частым обновлениям и не работают над внедрением больших наборов функций. Этот метод улучшает пользовательский опыт, позволяет быстро проверять гипотезы и минимизировать риски с помощью ранних отзывов.
3 этапа работы в рамках методологии Value Delivery:
1. Определение проблемы и последовательности работы с продуктом.
- Проблема клиентов – ценность продукта в решении проблемы пользователя.
- Основные предположения о клиентах (желания, потребности или поведение) и процессе разработки (операционные связи разработки с другими отделами, препятствия и необходимые ресурсы).
- Последовательность работы – приоритизация функций. Здесь помогут фреймворки RICE и MoSCoW.
Распространенная сложность на данном этапе – отсутствие единой точки зрения между разработчиками, дизайнерами и продактами.
Три разных мнения формируют 3 разных функционала MVP. Часто продакт-менеджеры стремятся увеличить объем функций, инженеры стремятся уменьшить его, чтобы обеспечить высокое качество реализации, а дизайнеры хотят прийти к идеальному пользовательскому опыту.
2. Работа с техническими рисками
- Установка способов решения технических рисков перед стартом проекта
Эта система может быть либо про время, либо про людей.В первом случае на решение экстренных задач выделено конкретное время. Например, раз в квартал. Во втором случае, это фиксированная команда, которую привлекают для "тушения пожара”.
- Разбивка проекта на спринты
Один из способов проверить, достаточно ли вы разбили работу на мелкие фрагменты, - это спросить себя: “Что произойдет, если какой-то й этап не будет выполнен или займет больше времени, чем ожидалось?”. Если это приведет к нестабильности, то нужно продолжать разбивку.
3.Установка реалистичных этапов внедрения новых функций
Работа с постоянным внедрением новых функций может быть привязана либо ко времени (может меняться объем работ), либо к объему работ (может меняться затрачиваемое на разработку время).Если с внедрением ко времени все понятно – компании в таком случае жертвуют качеством и объемом, чтобы успеть к определенной дате. То привязка к объему работ, чтобы не растягивать процесс разработки, требует четкого ответа на вопросы:
- Что нам нужно узнать в этом запуске?
- Что нужно сделать, чтобы получить ответ на первый вопрос?
При ответе на этот вопрос важно определить минимальный объем работы, который позволит проверить гипотезу.
Оценка производительности функций при помощи фреймворка TARS
TARS –это сокращение: Targeted (целевой), Adopted (принятие), Retained (удержанный) и Satisfied (удовлетворенный).
Targeted. Вся ЦА, которая потенциально может воспользоваться новой фичей.
Если разработка ведется для всей пользовательской базы, то ваша целевая аудитория по TARS может отражать целевую аудиторию всего продукта. В ином случае, сюда должны быть включены только конкретные сегементы аудитории. Базово при определении ЦА новой функции нужно понимать:
- Пример использования продукта.
- Демография пользователя.
- Уровень взаимодействия с продуктом.
- Уровень опыта работы с продуктом.
- Тип клиента (бесплатный, базовый платный, премиум).
Adopted. Доля ЦА, которая использует функцию.
Низкий уровень этого показателя говорит либо о проблемах с осведомленностью и доступностью новой фичи, либо о проблеме удобства использования. Чтобы определить долю пользователей, которые используют функцию необходимо:
- Установить измеряемое событие. Пользователи, которые завершают это событие, должны впервые ощутить ценность функции.
Примеры.
Мобильное приложение Dropbox. Когда пользователь сохраняет свой первый файл в Dropbox через мобильный телефон.
Подкасты Spotify: прослушивание одной минуты подкаста.Webflow: публикация сайта.
- Произвести рассчет. Количество пользователей, которые воспользовались функцией разделенное на количество активных целевых пользователей. Результаты должны соотноситься с историческими показателями компании и уникальными показателями каждого рынка.
Если компания не обладает средними рыночными показателями, то оценка должна зависеть от степени серьезности проблемы, которую решает функция. Для высокого уровня серьезности итоговый показатель должен быть не ниже 80%, для низкого – 30-40%.
Retained. Доля ЦА, которая остается после использования (можно пропустить на низкочастотных продуктах).
Этот показатель может подсветить, что фича не предоставляет достаточной ценности или имеет проблемы с удобством использования. Т.е указывает на необходимость дальнейших улучшений.Можно ссылаться на метрику удержания как на ежедневных активных пользователей (DAU), еженедельных активных пользователей (WAU) или ежемесячных активных пользователей (MAU).
Анализ удержания.
Кривые удержания показывают количество активных пользователей функции с течением времени.Необходимо создать диаграмму, где:
- Ось Y - это процент пользователей, которые повторно используют функцию
- Ось X - это время. (Для DAU – день, для WAU – неделя и т.д.)
Поэтому, если частота использования вашей функции еженедельна, вторая точка на графике представляет долю пользователей, которые были сохранены на второй неделе после принятия функции.Оценка показателей также зависит от степени серьезности проблемы, которую решает новая функция.
Для высокого уровня серьезности итоговый показатель удержания должен быть не ниже 50%, для низкого уровня – 10-20%.
Satisfied. Доля тех, кто доволен функцией.
Удовлетворенность важна для понимания того, как хорошо фича отвечает на потребности и ожидания пользователей, и может указывать на области, где фича может быть дополнительно оптимизирована или улучшена.Мы рекомендуем использовать Customer Effort Score (CES) для измерения удовлетворенности пользователей.Получив все необходимые данные, мы получаем 4 направления развития новой функции:
- Оптимизация. Когда наша функция приносит некоторую ценность, но есть возможности для улучшения. Возможно, потребуется улучшить пользовательский опыт, исправить некоторые ошибки или повысить производительность.
- Редизайн. Когда функция работает, но не решает нужную нам проблему пользователя.
- Откат: Обычно это происходит, если есть серьезные проблемы, которые создают плохой пользовательский опыт или негативно влияют на последующие показатели.
- Дальнейшие действия. Когда функция остается в первоначальном виде, так как либо полностью решает проблему пользователя, либо оптимизация не окупает затрачиваемые на нее ресурсы.
Получить продолжение через Telegram-бота