Запит на функцію, який варто справді побудувати (і як його розпізнати)

Ви вмієте казати «ні» поганим запитам на функції. Ви навчилися відрізняти розповзання обсягу від ключових функцій. Ви захищаєте межі свого продукту.

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

Які три?

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

Сигнали, що важать

Сигнал 1: Неспровокована повторюваність

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

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

Рахуйте запити, перш ніж будувати. Не ті, що від найгучнішого клієнта чи вашого найбільшого замовника, — рахуйте неспровоковану повторюваність. Два-три незалежні користувачі, що просять те саме, — набагато сильніший сигнал, ніж один важливий клієнт, що просить п’ять речей.

Сигнал 2: Обхідний шлях має значення

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

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

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

Звертайте увагу, які запити є блокерами. Хтось каже «я не можу цим користуватися, доки ви не зробите X» проти когось, хто каже «було б чудово, якби у вас було X». Ця різниця — золото.

Сигнал 3: Функція пов’язується з бізнес-моделлю

Деякі функції відкривають цілком нові способи заробляти. «Виставляти рахунки моїм клієнтам» відкриває бізнес-модель, де ви берете плату за виставлення рахунків. «Експорт у Salesforce» відкриває дохід від інтеграцій. «Білий лейбл для реселерів» відкриває партнерський канал.

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

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

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

Сигнал 4: Прохання про допомогу

Якщо користувач просить вас щось побудувати, це запит. Якщо користувач питає, чи могли б ви щось побудувати, і пропонує допомогти це тестувати, це інше.

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

Люди, що просто запитують, — це люди, які сподіваються, що ви чарівно збудуєте те, що вони уявляють. Іноді ви збудуєте. Часто — ні.

Будуйте спершу з тестувальниками. Усе інше другорядне.

Спокуса побудувати престижну функцію

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

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

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

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

Як насправді вирішувати

Коли у вас є пачка запитів на функції, що всі проходять тест «чи це в обсязі?», ранжуйте їх за:

Скільки користувачів попросили (незалежно)? Більше — краще.
Це блокер чи «приємно мати»? Блокери терміновіші.
Чи можуть ваші користувачі обійти це сьогодні? Якщо ні, це важливіше.
Чи допоможе хтось це тестувати? Якщо так, будуйте це першим.
Чи виявить це новий ринок? Якщо, можливо, — це бонус, а не причина.

Потім будуйте в такому порядку. Не в порядку «звучить вражаюче». Не в порядку вашого найбільшого клієнта. У порядку справжнього сигналу від людей, що користуються вашим застосунком.

Функція, яку ви не будуватимете (поки)

У вас будуть запити, що не пройдуть відбір. Не вдавайте, що ви колись їх побудуєте. Скажіть користувачу: «Ми цього зараз не будуємо. Ось чому. Ось що ми будуємо. Ось альтернатива, що може вам підійти».

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

І іноді, щойно ви сказали «ні», користувач знаходить обхідний шлях, чи інший інструмент, чи розв’язує проблему інакше. Це нормально. Ви не можете бути всім для всіх.

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