Быть или не быть фиче в продукте? Чтобы не превратиться в фабрику по производству фичей, в любой компании стоит задаваться вопросом: «А стоит ли добавлять эту новую фичу в продукт?» на регулярной основе. Есть, конечно, ноу-брейнеры, но чаще всего выделяют следующие причины внедрения нового функционала: 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)? • Какой тип пользователей продолжает активно пользоваться функцией? • Как мне ограничить доступ к функции только для этих пользователей? • Какова стратегия масштабного привлечения пользователей для этой функции? • Как данная функция способствует удержанию, активности или монетизации основного продукта? Хороший вариант для систематической проверки себя на вопрос: «А не говно ли мы делаем?».