Парадокс прогалин у функціях: чому найзапитуваніші функції не завжди варто будувати

Пастка аналізу прогалин

Аналіз прогалин розповідає вам, чого не вистачає. Він не розповідає вам, що важливо.

Більшість продуктових команд дізнаються про це на власному досвіді. Вони проводять конкурентний аналіз прогалин, знаходять список функцій, які мають конкуренти, але не вони, а потім сприймають цей список як дорожню карту продукту. Інженерам ставлять завдання. Квартали виділяються. Функції випускаються. А потім повертаються дані про використання, і ніхто не користується ними.

Функція, яку найбільше просять користувачі, часто є функцією, якою вони будуть користуватися найменше. Це і є пастка аналізу прогалин — і вона ловить команди, які сприймають аналіз прогалин як результат, а не як вхідні дані.

Основна проблема в тому, що аналіз прогалин виявляє видимість, а не цінність. Користувачі скаржаться на відсутні функції, тому що відсутні функції помітні. Прогалина — це конкретна, артикульована проблема. "У вашому продукті немає X" — це речення, яке може сказати будь-який користувач. Що користувачі не можуть легко артикулювати — це чи X насправді змінить те, як вони використовують продукт, чи вони заплатять більше за нього або чи перейдуть до іншого постачальника без нього.

Коли ви будуєте дорожню карту продукту безпосередньо з аналізу прогалин, ви оптимізуєте для того, що найгучніше, а не для того, що найцінніше. Ці два поняття рідко збігаються.

Чому популярні запити на функції можуть вводити в оману

Розуміння того, чому запити на функції вводять в оману, вимагає розуміння трьох структурних проблем у тому, як генерується зворотний зв'язок.

Проблема голосної меншості. Користувачі, які надсилають запити на функції, голосують за елементи дорожньої карти та голосно скаржаться в тікетах підтримки, становлять крихітну частку вашої бази користувачів — і систематично нерепрезентативну. Вони, як правило, є досвідченими користувачами, ранніми прихильниками або граничними користувачами, чиї робочі процеси відрізняються від середніх. Коли п'ять відсотків користувачів кричать про функцію, ви не знаєте, чи скористаються нею інші дев'яносто п'ять відсотків, чи проігнорують.

Мовчання більшості легко сприймається як згода. Це не так. Більшість користувачів не надсилають запитів на функції. Вони адаптують свій робочий процес, знаходять обхідне рішення або тихо відходять. Відсутність гучних скарг на функцію не означає, що користувачам байдуже — а наявність гучних запитів не означає, що функція широко важлива.

Бажано мати проти готовності платити. Користувачі систематично перебільшують, наскільки сильно вони хочуть функції, за які не потрібно платити. Коли опитування запитує "чи знайшли б ви цю функцію цінною?", майже всі відповідають "так". Функції безкоштовні для бажання. Суттєве питання не в тому, чи хочуть користувачі функцію — а в тому, чи заплатять вони більше за неї, чи її відсутність змушує їх розглядати альтернативи і чи прискорить її наявність їхнє рішення купити.

Існує велика категорія функцій, які користувачі справді хочуть, із задоволенням використовуватимуть, якщо ви їх реалізуєте, але не заплатять за них ні цента більше і не підуть без них. Це функції "приємно мати". Їх розробка споживає ті самі інженерні потужності, що й розробка функцій, які суттєво покращують утримання та розширення.

Копіювання конкурентів руйнує диференціацію. Найнебезпечніша форма заповнення прогалин — будувати функції просто тому, що конкурент має їх. Ця логіка — "вони мають це, користувачі просять, тому ми повинні будувати" — здається розумною, але призводить до гомогенізації продукту. Коли кожен продукт у категорії має однакові функції, рішення про покупку зводяться до ціни. Ви перетворили диференційований продукт на товар.

Конкуренти іноді мають функції, яких немає у вас, тому що вони будували для іншого ринку, робили різні архітектурні компроміси або пріоритизували інший ICP. Функція, яка має сенс для їхнього продукту, не обов'язково має сенс для вашого. Коли ви копіюєте без розуміння причин, ви успадковуєте функцію без стратегічного контексту, що її виправдовував.

Чотири типи прогалин у функціях

Не всі прогалини рівні. Ставлення до них як до однорідного списку — це те, де більшість продуктових команд помиляються. Існують чотири різних типи прогалин, кожен з яких вимагає різної відповіді.

Базові прогалини — це функції, які вашому продукту дійсно потрібні, щоб його сприймали серйозно в категорії. Вони не є диференціаторами — жоден користувач не оберет ваш продукт через них. Але їх відсутність є активно дискваліфікуючою. Експорт у CSV, базовий доступ через API, SSO для enterprise — це базові прогалини в більшості SaaS-категорій. Коли ви знаходите таку, будуйте її, оскільки її відсутність є блокером.

Диференціаційні прогалини — це ті, якими варто захоплюватись. Це можливості, які хочуть користувачі, які конкуренти не надали добре та які ваша команда могла б побудувати з справжнім конкурентним ровом. Диференціаційна прогалина — це кандидат для великої продуктової ставки. Але вони вимагають ретельної оцінки: розмір ринку прогалини, здійсненність вашої реалізації та чи можете ви побудувати версію, яка є захищено кращою.

Прогалини-пастки — найнебезпечніша категорія, тому що їх легко сплутати з диференціаційними прогалинами. Патерн виглядає так: користувачі гучно і часто просять функцію, ви будуєте її, прийняття мінімальне, і функція тихо депрекується через два роки. Dark mode, мобільні додатки в робочих процесах, де домінує десктоп, та кастомні інтеграції для рідко використовуваних інструментів — усе це слідує цьому патерну.

Стратегічні упущення — прогалини, що існують, тому що конкуренти свідомо вирішили не будувати щось. Вони позиціонувалися для конкретного ICP і навмисно залишили суміжні випадки використання незакритими. Перш ніж припускати, що загальна прогалина є можливістю, запитайте себе, чому чотири конкуренти, схоже, прийняли однакове рішення не заповнювати її.

Як відрізнити одне від одного

Фреймворк для розрізнення типів прогалин покладається на три рівні доказів.

Дані відгуків: частота скарг проти тригера переходу. Відмінність між "користувачі згадують це" і "користувачі наводять це як причину, через яку вони пішли або ледь не пішли" — це найважливіший фільтр у пріоритизації прогалин. Прогалина функції, яка з'являється в десяти відсотках відгуків як скарга, але в нулі відсотків як заявлена причина переходу — це, мабуть, прогалина-пастка або стратегічне упущення. Прогалина, яка регулярно з'являється в контексті "я розглядав перехід через це" — справжня проблема, яку варто вирішувати.

Під час проведення аналізу матриці функцій розділіть згадки функцій на два кошики: фонові скарги і мова тригерів переходу. Список тригерів переходу — ваша реальна черга пріоритетів. Список фонових скарг — ваш беклог.

Замінники використання. Перш ніж будувати, знайдіть замінники того, наскільки активно користувачі реально використовуватимуть функцію. Якщо у вашому продукті є будь-яка функціональність, що наближається до запитуваної, подивіться на показники використання. Якщо є обхідне рішення, виміряйте, скільки людей його застосувало. Якщо конкуренти мають функцію, подивіться, чи говорять користувачі про її використання чи просто про її наявність. Користувачі, які пишуть "зрештою ми не надто використовували X" у відгуках, говорять вам, що це прогалина-пастка.

Сигнали готовності платити. Найчистіший тест — ціновий. Коли ви описуєте функцію користувачам, вони реагують "це було б чудово" чи "я заплатив би більше за це"? Чи зупиняються угоди через її відсутність? Чи з'являється прогалина в розмовах про розширення? Готовність платити — це не стягнення за функцію — це замінник того, скільки прогалина реально коштує користувачам у термінах цінності.

Кейси: три прогалини, які не варто було заповнювати

Ці патерни з'являються в SaaS-компаніях досить часто, щоб розглядати їх як архетипи.

Мобільний додаток, яким ніхто не користувався. Інструмент для управління проєктами отримував постійні запити на нативний мобільний додаток. Запити були гучними, голосування — рясними, команда виділила квартал на розробку. Після запуску аналітика показала, що середній активний користувач відкривав мобільний додаток 1,2 рази на місяць. Продукт був інструментом десктопного робочого процесу — користувачі просили мобільний додаток, тому що хотіли його абстрактно, а не тому що мали реальний мобільний сценарій використання. Три місяці розробки дали функцію з майже нульовим прийняттям.

Dark mode і тримісячний відступ. Інструмент для colaboration з документами відклав три місяці розробки функцій, щоб реалізувати dark mode після того, як він став найбільш запитуваним елементом на їхній публічній дорожній карті. Дані після запуску показали, що dark mode мав сильне початкове прийняття — сорок відсотків користувачів спробували його в перший тиждень — але утримання режиму було поганим, більшість користувачів поверталися протягом місяця. Функція не мала вимірюваного впливу на відтік, не мала вимірюваного впливу на дохід від розширення та створила рівно одну хвилю позитивних згадок у соціальних мережах. Витрати на упущену можливість — квартал дорожньої карти, витрачений на театр гігієни замість стратегічних можливостей.

SSO як блокер зростання. SMB-орієнтований аналітичний інструмент побудував enterprise SSO, тому що він продовжував з'являтися в enterprise-розмовах про продажі. Функція зайняла вісім тижнів на побудову та тестування. Після запуску команда виявила, що їхній ICP — команди від п'яти до п'ятнадцяти осіб — майже ніколи не використовував SSO-сумісних провайдерів ідентифікації. Функцію запитували enterprise-клієнти, які все одно ніколи не конвертувалися б. Тим часом вісім тижнів могли піти на покращення онбордингу, який, за даними утримання, був реальним драйвером відтоку.

Правильний спосіб використання аналізу прогалин

Аналіз прогалин — це розвідка, а не інструкції. Результат аналізу прогалин має бути списком гіпотез для дослідження, а не чергою функцій для виконання.

Правильний процес виглядає так: проведіть аналіз прогалин, щоб виявити, чого не вистачає у вашому продукті та у ваших конкурентів, а потім профільтруйте кожну виявлену прогалину через три лінзи перш ніж вона наблизиться до дорожньої карти.

Фільтр бачення продукту. Чи закриття цієї прогалини рухає вас до продукту, який ви будуєте, чи воно рухає вас убік у можливості, які суміжні, але не основні? Прогалини, що виходять за межі вашого бачення продукту, майже завжди є прогалинами-пастками для вашого ICP, навіть якщо вони є справжніми можливостями для конкурента з іншим баченням.

Фільтр ICP. Чи реально використовуватиме ваш ідеальний клієнт цю функцію у своєму основному робочому процесі, чи він використовуватиме її час від часу, теоретично або зовсім ні? Пропустіть кожну прогалину через опис реального дня вашого ICP. Якщо функція не з'являється в цьому дні частіше ніж раз на тиждень, за замовчуванням ставтесь до неї як до низькопріоритетної.

Фільтр конкурентних даних як вхідних даних. Конкурентні дані, які ви подаєте в рішення щодо дорожньої карти, мають надходити з кількох сигналів — настрої відгуків, мова тригерів переходу, дані win/loss — а не лише з переліків функцій. Прогалина, яка з'являється в списках функцій, але не в даних тригерів переходу або інтерв'ю win/loss — це тривожний сигнал.

Аналіз прогалин показує вам форму конкурентного ландшафту. Він не розповідає, які частини цього ландшафту варті заселення.

Коли прогалина ВАРТА того, щоб будувати

Сигнали, що відрізняють справжню можливість від пастки, достатньо послідовні, щоб використовувати їх як чеклист.

Прогалину варто будувати, коли відсутність є заявленим тригером переходу в даних win/loss — не просто згаданою скаргою, а реальною причиною, через яку користувачі пішли або ледь не пішли від конкурента. Коли вона з'являється одночасно у кількох конкурентів, що свідчить про те, що вся категорія не спромоглася вирішити реальну проблему користувача. Коли сигнали готовності платити присутні в розмовах про продажі — не гіпотетично, а в реальному контексті угод. Коли ваш ICP має активний, частий робочий процес, який функція покращила б. Коли ви можете побудувати захисну реалізацію, що накопичує цінність з часом.

Коли всі п'ять цих сигналів присутні, ви дивитесь на диференціаційну прогалину, варту інвестицій. Коли можете знайти два або три — можливо, дивитесь на базову прогалину для досягнення паритету. Коли знаходите один або менше — зупиніться і запитайте, чи не раціоналізуєте рішення, вже прийняте з інших причин.

Аналіз прогалин як один із багатьох вхідних даних

Команди, що найкраще використовують аналіз прогалин, ставляться до нього як до одного джерела даних у стеку аналітики — а не як до стратегії самої по собі. Дані відгуків, інтерв'ю win/loss, аналітика використання, цінові експерименти та розмови з клієнтами — все це сприяє повній картині.

Проводьте конкурентний аналіз для виявлення прогалин. Фільтруйте їх через наведений вище фреймворк. Будуйте ті, що проходять усі тести. Дозвольте решті інформувати ваше позиціонування, маркетинг та розуміння того, чому клієнти обирають вас — не дозволяючи їм захоплювати вашу дорожню карту.

Compttr виявляє аналіз прогалин як частину кожного конкурентного звіту — показуючи, на що скаржаться користувачі у відгуках G2, Capterra та Trustpilot ваших конкурентів, організовано за темами та частотою скарг. Використовуйте його, щоб знайти прогалини, варті дослідження, а потім застосуйте фреймворк фільтрації, щоб вирішити, які заслуговують вашого інженерного часу.

Запустіть конкурентний аналіз з Compttr і отримайте необхідну аналітику прогалин для цього рішення приблизно за 60 секунд.