Много новых фичей — хорошо или плохо? Советы начинающим продактам

27 мая 2022

  • Автор: Андрей Король

  • Сложность: нормально

  • Время: 4 мин

Привет, меня зовут Андрей Король. Я разрабатываю и управляю продуктами более 7 лет, сейчас занимаю позицию VP of Product в компании Yola, веду лекции на курсе ProductMan

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

Проверка ценности фичи в готовом продукте

Как узнать, нужна ли новая фича в уже существующем продукте? В свое время Яндекс хотели сделать бота, который будет помогать пользователям в поиске. Компания не стала создавать AI, а посадила на другом конце чата реального человека. Оператор имитировал общение бота с пользователями и анализировал самые частые запросы. В итоге Яндекс так и не запустили бот, но эти запросы использовали в разработке похожего продукта — Алиса.     

Поэтому чтобы проверить ценность фичи, не бросайтесь создавать AI, а посадите человека, который будет общаться с пользователями.

Много фичей = довольные пользователи?

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

Дальше работаем над Release 1.5 и «допиливаем» еще пару фичей, которые не успели добавить в первую версию. Начинаем получать фидбек от пользователей, узнаем, какие фичи им еще нужны и тоже добавляем их в сервис. 

фичи 1

Продукт развивается, мы выпускаем следующий Release 2.0. Приходят инвесторы и хотят видеть в продукте новые функции, которые есть у конкурентов, но пока нет у нас. В Release 3.0 воплощаем их пожелания и создаем еще больше фичей, забывая при этом о статистике, которая показывает, что 75% функций люди не используют.  

Как помочь пользователям оставаться в продукте 

Как быть, если кажется, что задача продакта в том и состоит — «пилить» новые фичи? Что делать, если возникает страх, что продакт не приносит пользы компании, если выпустит Release 4.0 без новых функций?  

Помнить о балансе. Чем больше фичей, тем сложнее интерфейс: появляется масса call-to-action — кнопок-ссылок, дропдаун-меню и прочего мусора, с которым приходится разбираться пользователям. Если человек давно в нашем продукте, ему будет легче освоиться, но для новичков позитивный опыт использования будет снижаться, а Activation Rate упадет. 

фичи 2

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

фичи 3

Последствия введения большого количества фичей хорошо демонстрирует пример MS Word и Google Doc. У MS Word есть масса функций, о которых большинство пользователей даже не подозревает и которыми никогда не пользуется. Google Doc «взял» первую панель Word-а, реплицировал эти функции в онлайн-варианте — и предложил пользователям удобный и понятный сервис. В данном случае юзабилити и доступность (Google Doc можно пользоваться бесплатно) стали немаловажным аспектом истории успеха продукта.       

Как фичи могут убить планы о масштабировании

Фичи должны быть востребованы всем рынком, а не только одним клиентом. Представьте, что есть небольшой, но перспективный В2В-продукт, который покупает некая корпорация и просит сделать для нее специализированные функции. Из-за страха потерять клиента компания начинает трансформировать продукт, создавая всё новые и новые фичи под этого заказчика. Затем появляется еще один крупный клиент, который выдвигает свои требования. 

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

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

Если на эти два вопроса ответили «нет», то не стоит делать такую фичу, по крайней мере, в самом начале. Когда немного подрастете, можно разделять эти условия и создавать «коробочное» решение, которое подходит всем, например, как это делает Terrasoft. Дальше можно создать компанию, которая кастомизирует готовые продукты под отдельных клиентов, занимается их поддержкой, совместимостью и прочими функциями. 

Главное, о чем нужно помнить — хорошим продукт делает не количество фичей, а их ценность для пользователей. 

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

ProductMan

Андрей Король

Андрей управлял продуктами и проектами в разных сферах: MedTech, EdTech, FinTech, GameDev, Med Hardware, фитнес и развитие комьюнити. Сертифицированный Project Manager Professional (by PMI) с 2012 года. Получил образование в Product School by Zeo University and Google, участвовал в TechCrunch. Работал как Chief Product Officer в BiniBambini, сейчас VP of Product в компании Yola, и спикер курса ProductMan