Привіт, мене звуть Андрій Король. Я розробляю та керую продуктами більше 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. Далі можна створити компанію, яка кастомізує готові продукти під окремих клієнтів, займається їхньою підтримкою, сумісністю та іншими функціями.
Головне, про що потрібно пам’ятати — добрим продукт робить не кількість фічів, а їхня цінність для користувачів.
Оболонка сервісу має бути інтуїтивно зрозумілою, без зайвих кнопок. Завжди враховуйте, для кого і навіщо ви створюєте ту чи іншу фічу, та збирайте фідбек, щоб зберегти та залучати нових клієнтів. А про те, як відстежувати поведінку користувачів у продукті, ми поговоримо у наступній статті.