Привет, меня зовут Андрей Король. Я разрабатываю и управляю продуктами более 7 лет, сейчас занимаю позицию VP of Product в компании Yola, веду лекции на курсе ProductMan.
В прошлой статье мы говорили о подходах, которые помогают проверить ценность идеи и дальнейший спрос на продукт. Сегодня посмотрим, какие фичи нужны продукту, и как они могут убить планы о масштабировании.
Проверка ценности фичи в готовом продукте
Как узнать, нужна ли новая фича в уже существующем продукте? В свое время Яндекс хотели сделать бота, который будет помогать пользователям в поиске. Компания не стала создавать AI, а посадила на другом конце чата реального человека. Оператор имитировал общение бота с пользователями и анализировал самые частые запросы. В итоге Яндекс так и не запустили бот, но эти запросы использовали в разработке похожего продукта — Алиса.
Поэтому чтобы проверить ценность фичи, не бросайтесь создавать AI, а посадите человека, который будет общаться с пользователями.
Много фичей = довольные пользователи?
Часто продакт-менеджеры стремятся сделать как можно больше фичей, но давайте сначала выясним, хорошо это или плохо. Предположим, есть новый продукт: мы провели CustDev и поняли, что есть три фичи, решающих проблему клиента. В итоге, получили Release 1.0, который хорошо приняли пользователи.
Дальше работаем над Release 1.5 и «допиливаем» еще пару фичей, которые не успели добавить в первую версию. Начинаем получать фидбек от пользователей, узнаем, какие фичи им еще нужны и тоже добавляем их в сервис.
Продукт развивается, мы выпускаем следующий Release 2.0. Приходят инвесторы и хотят видеть в продукте новые функции, которые есть у конкурентов, но пока нет у нас. В Release 3.0 воплощаем их пожелания и создаем еще больше фичей, забывая при этом о статистике, которая показывает, что 75% функций люди не используют.
Как помочь пользователям оставаться в продукте
Как быть, если кажется, что задача продакта в том и состоит — «пилить» новые фичи? Что делать, если возникает страх, что продакт не приносит пользы компании, если выпустит Release 4.0 без новых функций?
Помнить о балансе. Чем больше фичей, тем сложнее интерфейс: появляется масса call-to-action — кнопок-ссылок, дропдаун-меню и прочего мусора, с которым приходится разбираться пользователям. Если человек давно в нашем продукте, ему будет легче освоиться, но для новичков позитивный опыт использования будет снижаться, а Activation Rate упадет.
Получается, что в попытке угодить всем и делая фичи под каждого человека, мы только усложняем наш интерфейс и теряем пользователей. Чтобы исправить ситуацию, нужно убрать лишние и оставить только те, которыми люди активно пользуются. Но чаще всего продакты пытаются сохранить все функции, потому что жаль денег и времени на тестирование и запуск. А потом в какой-то момент приходит конкурент с пятью фичами, зато ключевыми — и вытесняет вас с с рынка.
Последствия введения большого количества фичей хорошо демонстрирует пример MS Word и Google Doc. У MS Word есть масса функций, о которых большинство пользователей даже не подозревает и которыми никогда не пользуется. Google Doc «взял» первую панель Word-а, реплицировал эти функции в онлайн-варианте — и предложил пользователям удобный и понятный сервис. В данном случае юзабилити и доступность (Google Doc можно пользоваться бесплатно) стали немаловажным аспектом истории успеха продукта.
Как фичи могут убить планы о масштабировании
Фичи должны быть востребованы всем рынком, а не только одним клиентом. Представьте, что есть небольшой, но перспективный В2В-продукт, который покупает некая корпорация и просит сделать для нее специализированные функции. Из-за страха потерять клиента компания начинает трансформировать продукт, создавая всё новые и новые фичи под этого заказчика. Затем появляется еще один крупный клиент, который выдвигает свои требования.
В итоге функции продукта «заточены» под двух больших клиентов, а продуктовая компания трансформируется в аутсорс, который обслуживает этих двух клиентов. Продукт становится нишевым, и инвесторы не будут вкладываться в такую компанию. Фичи, сделанные под интересы двух конкретных компаний, «убили» масштабируемость.
Чтобы фича не убила планы о масштабировании, нужно понимать совпадает ли она с продуктовым видением и будет ли востребована другими клиентами, на которых мы нацелены в перспективе.
Если на эти два вопроса ответили «нет», то не стоит делать такую фичу, по крайней мере, в самом начале. Когда немного подрастете, можно разделять эти условия и создавать «коробочное» решение, которое подходит всем, например, как это делает Terrasoft. Дальше можно создать компанию, которая кастомизирует готовые продукты под отдельных клиентов, занимается их поддержкой, совместимостью и прочими функциями.
Главное, о чем нужно помнить — хорошим продукт делает не количество фичей, а их ценность для пользователей.
Оболочка сервиса должна быть интуитивно понятной, без лишних кнопок. Всегда учитывайте для кого и зачем вы создаете ту или иную фичу, и собирайте фидбек, чтобы сохранить и привлекать новых клиентов. А о том, как отслеживать поведение пользователей в продукте, мы поговорим в следующей статье.