Прототип проти продукту: як зрозуміти, що ваш застосунок на ШІ справді готовий

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

Вона дивиться на нього два тижні й не запустила.

Коли я запитав чому, вона сказала: «Він працює, але… він не відчувається готовим».

Я запитав, що б вона змінила. Вона сказала: «Я не знаю. У цьому й проблема».

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

Що насправді означає «готово»

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

Застосунок для запису терапевтів — прототип. Він доводить, що концепція працює. Терапевт міг би ним користуватися. Але є сімнадцять дрібниць, що роблять його сируватим:

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

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

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

Три запитання, що відділяють прототип від продукту

Ось важка частина: ви не можете знати все, чого бракує. Ваш конструктор на ШІ теж не може. Тож вам потрібні три швидкі запитання, щоб зрозуміти, на якому боці лінії ви.

1. Чи скористалися б ви цим, щоб розв’язати власну проблему?

Це запитання чесне, бо вам доводиться справді жити з власним продуктом.

Якщо ви засновниця того застосунку для запису терапевтів, чи скористалися б ви ним, щоб записатися на власні сеанси терапії? Не «чи могли б», а чи справді скористалися б ним замість листування чи спільного Google Doc?

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

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

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

2. Чи показували ви це трьом людям, що не є вами?

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

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

Ось що ви шукаєте: де вони бентежаться? Де вагаються? Про що питають? Не «що вони про це думають?» (люди надто люб’язні). Попросіть їх справді зробити річ — записатися на прийом, надіслати лист-підтвердження, щось скасувати.

Коли засновниця показала свій застосунок для терапевтів трьом терапевтам, двоє з них запитали: «А можу я задати правила, коли я доступна? Наприклад, я приймаю нових клієнтів лише в четвер і не записую двох одразу до 14:00». У застосунку був календар, але не правила. Вона збудувала прототип для того, як вона думала, що працює запис, а не для того, як насправді працюють терапевти.

Це продуктова інформація. Ви не могли б це вгадати зі специфікації.

3. Що зламалося б, якби ви дали це десятьом справжнім користувачам?

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

Для застосунку для терапевтів:

Що станеться, якщо клієнт спробує записатися на два прийоми в той самий час? (Застосунок не перевіряє.)
Що станеться, якщо терапевт скасує прийом? Чи отримають клієнти сповіщення автоматично? (Ні.)
А якщо адреса e-mail клієнта неправильна? Чи є спосіб виправити її, не починаючи спочатку? (Ні.)
А якщо терапевт захворіє й має закрити свій календар на тиждень? (Їй довелося б вручну видаляти кожен прийом.)

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

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

Як вирішити: тришаровий тест

Скористайтеся ним, щоб зрозуміти, де ви.

Шар 1: Основний потік — Чи працює щасливий шлях? Чи може користувач зробити головну річ, для якої спроєктовано ваш застосунок?

Для запису терапевтів: так. Хтось може зареєструватися, записатися на прийом, отримати підтвердження. Це працює.

Шар 2: Крайні випадки з реального користування — Ви показали це трьом справжнім користувачам. Чи впоролися вони в щось, для чого ви не будували? Чи десь заплуталися?

Для запису терапевтів: так. Три терапевти хотіли доступності на основі правил. Один заплутався, бо лист-підтвердження виглядав надто узагальнено. Один спробував масово видалити прийоми й не зміг.

Шар 3: Шліфування й професійність — Чи відчувається, що вам не байдуже? Чи відчувається, що ви зліпили це нашвидкуруч?

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

Ось евристика:

Усі три шари працюють? Ви продукт. Випускайте.
Шари 1 і 2, не 3? Ви на 80% готові. Витратьте день на шліфування.
Шар 1 працює, шари 2 і 3 ні? Ви прототип. Поки не випускайте.
Шар 1 нетвердий? Ви не готові. Продовжуйте будувати.

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

(Вона їх додала. Це зайняло три дні. Тепер це продукт.)

Те, що робить це важким

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

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

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

Це не шрифти.

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

Чекліст готовності до запуску

Скористайтеся ним. Він короткий і чесний.

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

Якщо ви можете поставити галочки в усіх п’яти, ви готові. Запускайте.

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

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