Коли запросити другу людину допомагати підтримувати ваш застосунок на ШІ

Більшість застосунків на ШІ починаються наодинці. У певний момент однієї людини замало. Ось як розпізнати цей момент, кого запросити першим і як передати шматок, не віддаючи всього.

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

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

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

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

Ознаки, що час

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

  • Ви кажете «ні» змінам, які хотіли б зробити. Не тому, що це погані ідеї, — тому, що у вас немає годин. Ви почали приватний список «речей, які я зробив би, якби мав час», і він усе довшає.
  • Те саме запитання користувачів виринає знову й знову. Ви відповіли «як експортувати мої дані?» вісім разів за два тижні. Це сторінка довідки, але у вас немає часу її написати, тож ви відповідаєте вручну.
  • Ви уникаєте застосунку. Якийсь конкретний його кут відчувається важким. Може, адмінський розділ, може, екран оплати — щось, де кожна зміна відчувається як хірургія. Ви даєте багам там старіти довше, ніж варто.
  • Одна помилка зашкодила б. У вашого застосунку тепер справжні користувачі зі справжніми даними. Один поганий деплой у втомлений вівторок увечері міг би втратити чиюсь роботу. У вас немає другої пари очей.
  • Ви — вузьке місце для зростання. Троє потенційних клієнтів попросили невелику зміну, перш ніж зареєструватися. Два місяці тому ви зібрали б це того ж вечора. Тепер ви навіть не можете відповісти три дні.

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

Кого запросити першим

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

Шукайте приблизно в такому порядку:

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

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

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

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

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

Який шматок їй передати

Помилка — передати їй увесь застосунок. Увесь застосунок у вас у голові. Ви знаєте, які частини крихкі, які частини ви так і не зовсім завершили, яку частину користувач колись мало не зламав. Вона — ні.

Передайте їй шматок. Справжній, з краями:

  • Головну сторінку й маркетингові сторінки. Низький ризик, висока видимість. Вона може ітерувати текст, секції, скриншоти, відгуки. Якщо вона щось зламає, ви помітите за годину, і жоден користувач не втратить дані.
  • Центр довідки. Якщо ви постійно відповідаєте на ті самі запитання, це той шматок. Вона пише відповіді; ви переглядаєте перші кілька, доки не довірятимете голосу; потім вона публікує.
  • Одна конкретна функція, орієнтована на користувача. Може, це процес експорту, чи система коментарів, чи сповіщення. Щось із чіткою межею, де баг у ній не кладе весь застосунок.
  • Адмінські інструменти, якими ви користуєтеся самі. Напрочуд хороший стартовий шматок. Вона може покращити інструменти, якими ви користуєтеся, не торкаючись нічого, що бачать клієнти. Ви відчуваєте покращення щодня, що будує довіру.

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

Чого не робити першого дня

Короткий список, здебільшого зі спостережень, як інші роблять це погано:

  • Не давайте їй доступ до вашої живої бази даних. Більшість конструкторів застосунків на ШІ дають змогу зробити staging-копію вашого застосунку. Почніть її там. День, коли вона вперше випустить щось у продакшен, має бути маленькою церемонією, а не випадковістю.
  • Не звалюйте все їй на коліна. «Ось документ Notion з 87 речами, обери будь-яку». Це приголомшливо, і вона кине. Оберіть перші три речі разом. Завершіть їх. Потім оберіть наступні три.
  • Не очікуйте, що вона читатиме ваші думки. Ви живете з цим застосунком місяцями. У вас скорочення для всього. Запишіть п’ять речей про те, як працює застосунок і як ви ухвалюєте рішення щодо нього. Передайте їй це. Це займе у вас дев’яносто хвилин і заощадить вам тижні.
  • Не зникайте. Ви потрібні їй на перші кілька тижнів. Задайте справжній ритм — швидкий дзвінок раз на тиждень, асинхронні повідомлення між ними. За місяць ви, ймовірно, зможете перейти на раз на два тижні. Не раніше.

Як це насправді відчувається потім

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

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

Якщо ви сидите з довгим списком «речей, які я зробив би, якби мав час», можливо, варто витратити годину сьогодні, обмірковуючи, ким могла б бути та перша людина і який шматок вашого застосунку на ШІ ви б їй передали.

Це зазвичай менший стрибок, ніж здається.