🔒Открыть пост
и посмотреть медиа
и посмотреть медиа
Быть или не быть фиче в продукте?
Чтобы не превратиться в фабрику по производству фичей, в любой компании стоит задаваться вопросом: «А стоит ли добавлять эту новую фичу в продукт?» на регулярной основе. Есть, конечно, ноу-брейнеры, но чаще всего выделяют следующие причины внедрения нового функционала:
1. Функция действительно работает: несмотря на увеличение сложности продукта, результаты A/B-тестирования показывают рост основных показателей (лучший вариант).
2. Упрощение продукта: результаты тестирования нейтральные, но данная функция уменьшает сложность продукта.
3. Стратегическая ценность: результаты тестирования либо нейтральные, либо неудовлетворительные, но нам необходимо её запустить для будущего проекта, который, по нашим ожиданиям, принесет положительные результаты.
4. Помощь целевой аудитории: Результаты тестирования нейтральные или плохие, однако функция улучшает продукт для определенного сегмента пользователей, которых мы приоритетно рассматриваем.
5. Улучшенный дизайн: Функция не слишком сложна, тест показал нейтральные результаты, но, по нашему мнению, это шаг вперед в плане дизайна/пользовательского интерфейса.
6. Основано на нашем опыте: Тестирование функции по каким-то причинам невозможно, но нам эта функция нравится.
7. Мы дали слово: Функция соответствует запросу клиента или администратора, с которым мы согласовались.
8. Выполнение обязательных требований: Результаты тестирования нейтральные или плохие, но функция делает наш продукт более безопасным, соответствующим стандартам, локализованным и т. д., что соответствует нашей стратегии в этой области.
Но значит ли это, что любая внедренная фича должна жить в продукте вечно? Нет. Самое сложное, но иногда и самое важное — уметь отрезать ненужное. Как понять, что фичу нужно вырезать? Мне очень нравится подход Feature/Product Fit (по аналогии с Product/Market fit). Его основная цель — подтвердить, что функциональность привносит ценность в продукте и комплиментарна одному из трех направлений измерения успеха продукта: retention, monetization и/или engagement. На самом деле, этот подход помогает и с определением необходимости новой фичи на старте, но основной фокус на оценку по результатам накопленных данных. Сводится фреймворк к двум формам чек-листов.
Для поиска Feature/Product Fit:
• Что данные говорят об использовании этой функции?
• Что пользователи говорят о данной функции?
• Как я могу использовать основной продукт для стимулирования использования этой функции?
• Как я могу использовать уведомления для стимулирования использования этой функции?
• Какие стимулы я могу предложить для стимулирования использования этой функции?
• Как я могу привлекать людей для распространения и применения этой функции?
Для подтверждения Feature/Product Fit:
• Показывает ли функция устойчивость к использованию (retention)?
• Какой тип пользователей продолжает активно пользоваться функцией?
• Как мне ограничить доступ к функции только для этих пользователей?
• Какова стратегия масштабного привлечения пользователей для этой функции?
• Как данная функция способствует удержанию, активности или монетизации основного продукта?
Хороший вариант для систематической проверки себя на вопрос: «А не говно ли мы делаем?».