Producto Samurai - producto

Фича киллер Когда вы в последний раз убирали какой-то функционал из своего продукта? Подразумевая рост, все обычно предлагают, что добавить в продукт, но редко кто вспоминает о том, что улучшение продукта может крыться в том, чтобы его упростить. Некоторые фичи, несмотря на то, что мы проводили хорошее дискавери, все еще могут ухудшать продуктовый опыт и не найти фита с пользователем. Возможно, в вашей продуктовой стратегии зрелого продукта не достает именно этого: что из него стоит убрать. Если этого не сделать, может возникнуть feature bloat — ситуация, когда продукт становится чрезмерно сложным из-за добавления слишком большого количества ненужных функций. Почему случается Feature Bloat? *️⃣ Ревью в корпорациях: система ориентирована на фичепроизводство и оценивание продуктовых команд по новым запускам — мотивация делать больше нового всегда превалирует; *️⃣ Конкуренция на рынке: на красном рынке есть соблазн добавить какую-то фичу, которая есть у конкурентов, чтобы не отстать в гонке, что ведет к потере уникальности; *️⃣ Давление и сопротивление стейкхолдеров: все преследуют свои цели. Новую фичу можно продать, рассказать про нее в рекламной кампании, а вот идею отказаться от какой-то фичи или выпилить ее продать очень сложно; *️⃣ Внутренняя борьба: мы привязываемся к своим идеям и нам сложно признать, что наше гениальное решение не сработало. А еще есть sunk cost fallacy: ресурсы уже затрачены, нам жаль собственных усилий. Здесь напомню свой пост про метрики выживания, которые подстрахуют в этом кейсе. Чем плох Feature Bloat? *️⃣ Ухудшается пользовательский опыт. Срабатывает барьер когнитивной перегрузки, так как пользователь сталкивается с большим количеством выборов, что ведет к раздражению; *️⃣ Падает производительность. Каждая новая фича может ухудшить перфоманс, так как растет время загрузки, потребление ресурсов — продукт чаще лагает; *️⃣ Размывается ценность продукта. Перегрузка функциями удлиняет время пользователя до целевого действия, затрудняет онбординг и путь к aha-моменту, и момент активации может вовсе не наступить; *️⃣ Падает удержание. Если продукт все же дал пользователю ценность, но ему сложно пользоваться продуктом, то он перестанет в него возвращаться; *️⃣ Падает выручка. Когда пользователи перестают возвращаться или оттекают, не успев активироваться, мы получаем падение выручки. Именно поэтому важно вовремя понимать, что фичу пора убивать. Проводите аудит фич в вашем продукте как сторонний эксперт, чтобы выделить красные флаги: ➖ Фичей никто не пользуется. Проанализируйте данные, чтобы понять, насколько пользователи вовлечены в использование продукта (соотношение DAU/MAU) и как часто они возвращаются в фичу (retention). Сделайте обратный АБ тест: ухудшит ли удаление фичи основные метрики вашего продукта или даже улучшит? ➖ Фича не нравится пользователям. Соберите обратную связь о функциональности от ваших пользователей: почитайте отзывы, изучите результаты CSAT, обращения в поддержку, проведите день интервью, где сможете спросить об опыте использования. Негативный фидбек может быть сигналом не только для выпиливания, но и для доработки фичи. ➖ Фичей пользуется не ваш сегмент. Даже если по пунктам выше все супер, не стоит забывать, что у продукта есть целевой сегмент, и фича может быть не актуальна именно для них, а пользователей, которых привлекла эта фича, вы не хотите удерживать. ➖ Поддержка фичи обходится вам слишком дорого. Рассчитайте, во сколько вам обходятся саппорт, багфиксы, техдолг по фиче: несмотря на все, что уже инвестировано в фичу, всегда можно остановиться. В идеале, нужно выстроить в команде и компании: 1️⃣ открытость к дискуссии о выпиливании функционала: быть честными в том, что работает, а что нет, вместе обсуждать влияние своей работы и признавать неуспешность некоторых запусков; 2️⃣ четкий процесс убирания фич из продукта: определять, как вы будете оценивать необходимость удаления и его результаты и коммуницировать выпил на пользователей. Ставьте 🔥, если замечаете feature bloat в своих продуктах. Был ли у вас опыт удаления функционала?