Пастка розповзання обсягу: як казати «ні» функціям, що звучать добре, але такими не є

Ви випустили застосунок. Користувачі прийшли. І тепер ваша скринька повна запитів на функції, які всі звучать як хороші ідеї.

«А можна додати експорт в Excel?» Розумно. «А чи можуть рахунки надсилатися автоматично?» Має сенс. «А можна інтеграцію зі Stripe?» Ось де живуть справжні гроші. «А можна додати мобільний застосунок?» Усі про це просять. «А можна зробити це під білим лейблом для наших власних клієнтів?» О, тут уже бізнес-модель.

Кожен запит окремо звучить розумно. Разом вони звучать так, ніби ви будуєте п’ять різних продуктів.

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

Як розповзання обсягу вбиває робочий застосунок

Ось що відбувається. Ви кажете «так» першим трьом запитам, бо вони здаються розумними. Ви просите свій конструктор на ШІ їх додати. Це займає два тижні замість одного, бо кожна нова функція впирається в наявний код. Тепер у вас застосунок, що робить п’ять речей, три з них добре, а дві — стерпно.

Потім приходить четвертий запит: «А можна різні рівні доступу?» Раптом вам треба переосмислити, хто що бачить на кожному екрані. Це не функція, це зміна архітектури. Ви просите свій конструктор на ШІ це зробити. Воно зачіпає все. Два тижні стають трьома. Застосунок стає повільнішим, бо ви додали логіку до кожного вигляду.

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

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

Каркас для ухвалення рішень

Вам потрібен фільтр. Кожен запит на функцію проходить через три запитання:

Запитання 1: Чи місце цьому в цьому застосунку, чи це інший застосунок?

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

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

Вам надходитимуть запити на кшталт «інтегруйте з нашою CRM». Насправді це означає «станьте власною CRM». Це інший застосунок. Інтегруватися з CRM можна пізніше. Не можна додати функції на цілу CRM, не ставши CRM.

Запитання 2: Чи розв’язує це проблему більшості ваших користувачів, чи лише цього одного?

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

Якщо у вас двадцять користувачів і один просить щось, перевірте: інші дев’ятнадцять теж цього чекають, чи цій людині просто спало це на думку? Можна запитати прямо: «А ви до мене думали запитати ще когось, чи їм це теж потрібно?» Зазвичай відповідь — ні.

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

Запитання 3: Скільки це коштує і яка ціна для первісної ідеї?

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

Запитайте конкретно: «Якщо я побудую це, чого я не побудую?» Якщо відповідь — «нічого, у нас нескінченно часу», ви не чесні із собою. У нас його немає. Час скінченний.

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

Реальний приклад: форма прийому

Хтось зробив просту форму прийому клієнтів. Клієнти її заповнюють, коуч переглядає, вони домовляються про зустріч. Ось і весь застосунок.

Запит один: «А можна позначати термінові заявки?» Так, це варіація головного процесу. Будуйте.

Запит два: «А можна експортувати заявки в Excel для моїх записів?» Це функція документообігу. Це не справа застосунку. Заявки живуть у застосунку. Якщо їм потрібен Excel, можна скопіювати-вставити. Але добре, експорт може мати сенс як зручність. Будуйте.

Запит три: «А можуть заявки автоматично створювати події в календарі?» Тепер ви займаєтеся записом. Застосунок був для прийому, а не для запису. Якщо комусь потрібне і те, і те, йому, ймовірно, потрібна справжня система запису, а не милиця, що приклеює одне до іншого. Ввічливо відмовте.

Запит чотири: «А можуть коучі надсилати нагадування про заявки через SMS?» Тепер ви — комунікаційна система. Ні.

До третього запиту ви досягли межі. Застосунок — це прийом. Усе інше — інший застосунок. Можна інтегруватися з тими застосунками пізніше. Не можна їх додати, не ставши ними.

Як казати «ні»

Найважче — власне це сказати. Ви не хочете розчаровувати користувачів.

Будьте чесні: «Це чудова ідея, але це інший продукт, ніж той, що ми тут будуємо. Ми будуємо [ваша одна справа]. Якщо ми спробуємо робити запис, чи рахунки, чи CRM, ми будемо стерпними в усьому й чудовими ні в чому».

Часто клієнт зрозуміє. Він запитав, бо ідея спала йому на думку, а не тому, що випробовує вас.

Іноді він наполягатиме. «Але мені потрібне і те, і те». Ось тоді ви рекомендуєте: користуйтеся справжнім застосунком для запису. Користуйтеся справжнім застосунком для рахунків. Користуйтеся справжньою CRM. А потім користуйтеся цим застосунком для того, що він робить добре. Це чесна відповідь.

Спокуса бути всім

Найважча частина побудови маленького продукту — казати «ні». «Ні» відчувається як гроші, лишені на столі. А раптом той клієнт справді заплатив би за обидва? А раптом та функція зробила б вас удесятеро більшими?

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

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

Кажіть «ні». Захищайте ядро. Зробіть це — і ви побудуєте щось, чим люди справді хочуть користуватися.