Прототип против продукта: как понять, что приложение, созданное с ИИ, действительно готово

Несколько недель назад знакомая мне основательница собрала приложение для записи к психотерапевтам. На всё ушло четыре дня и ИИ-конструктор приложений. Оно делает ровно то, что ей нужно: терапевты видят свой календарь, клиенты записываются на приёмы, подтверждения уходят по электронной почте. Оно работает.

Уже две недели она на него смотрит и так и не запустила.

Когда я спросил почему, она ответила: «Оно работает, но… не ощущается готовым».

Я спросил, что бы она поменяла. Она сказала: «Не знаю. В этом-то и проблема».

Это самый трудный момент в работе с ИИ-конструктором приложений. Штука функциональна, но между «функционально» и «мне было бы спокойно просить реальных людей этим пользоваться» лежит разрыв. Понять этот разрыв — и определить, на какой его стороне вы на самом деле находитесь, — и есть разница между тем, чтобы запуститься, и тем, чтобы навсегда застрять в фазе сомневающегося голоса в голове.

Что на самом деле значит «готово»

Вот различие, которое имеет значение: прототип — это то, чем вы пользуетесь, чтобы проверить идею. Продукт — это то, чем вы пользуетесь, чтобы решить проблему.

Приложение для записи к психотерапевтам — это прототип. Оно доказывает, что концепция работает. Терапевт мог бы им пользоваться. Но есть семнадцать мелочей, из-за которых оно ощущается сыроватым:

Письма-подтверждения голые. Ни логотипа, ни фирменного оформления, шаблонный текст.
При отмене не уходят уведомления. Клиенты просто не приходят.
Нет списка ожидания, если у терапевта всё расписано.
В форме регистрации не спрашивают о специализации терапевта, так что фильтровать по профилю практики невозможно.
Нет письма-напоминания за 24 часа до приёма.

Ничто из этого приложение не ломает. Но из-за всего этого реальный терапевт думает: «Это похоже на то, что собрали на выходных, а не на то, за что с меня берут деньги».

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

Три вопроса, отделяющие прототип от продукта

Вот в чём сложность: вы не можете знать всё, чего не хватает. Ваш ИИ-конструктор тоже этого не знает. Поэтому нужны три быстрых вопроса, чтобы понять, на какой стороне черты вы находитесь.

1. Стали бы вы решать этим свою собственную проблему?

Этот вопрос честный, потому что вам придётся реально жить со своим продуктом.

Если вы — основатель того приложения для записи к психотерапевтам, стали бы вы записываться через него на свои собственные сеансы терапии? Не «могли бы», а реально стали бы пользоваться им вместо переписки по почте или общего документа Google Doc?

Если ответ «нет» — вы не готовы. Вы точно знаете, что не так, — вы чувствуете это каждый раз, когда открываете приложение. Если ответ «да» — вы ближе.

Та основательница, о которой я говорю, сама прошла регистрацию терапевта. Она застряла на форме (та просила слишком много информации, прежде чем дать записаться). Она увидела письмо-подтверждение и подумала, что оно выглядит любительски. Она начала думать, как её терапевт получит это письмо и не уйдёт ли оно в спам.

Она не пользовалась собственным продуктом так, как это делал бы платящий клиент. Когда она это сделала, то нашла десяток вещей, которые надо исправить.

2. Показывали ли вы это троим людям, кроме себя?

Разговаривать с потенциальными пользователями сложнее, чем строить, и большинство основателей это пропускают, потому что хотят удивить людей на запуске. Это ошибка.

Вам не нужна фокус-группа. Вам нужны три человека, похожие на того, кого вы считаете своим клиентом. Для приложения для терапевтов это трое настоящих психотерапевтов.

Вот что вы ищете: где они путаются? Где они колеблются? О чём спрашивают? Не «что они думают об этом?» (люди слишком добры). Попросите их реально сделать действие — записаться на приём, отправить письмо-подтверждение, что-нибудь отменить.

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

Это информация о продукте. Из спецификации вы бы такого не угадали.

3. Что сломалось бы, если бы вы отдали это десяти реальным пользователям?

Это самый трудный вопрос, потому что он требует по-настоящему подумать о пограничных случаях.

Для приложения для терапевтов:

Что произойдёт, если клиент попытается записаться на два приёма одновременно? (Приложение это не проверяет.)
Что произойдёт, если терапевт отменит приём? Получают ли клиенты автоматическое уведомление? (Нет.)
Что, если адрес почты клиента указан неверно? Есть ли способ это исправить, не начиная заново? (Нет.)
Что, если терапевт заболел и ему нужно закрыть календарь на неделю? (Ему пришлось бы вручную удалять каждый приём.)

Это не баги. Приложение не падает. Но это «бумажные порезы». С десятью реальными пользователями и реальными пограничными случаями вы наткнётесь на все из них в первую же неделю.

Продукт справляется с пограничными случаями. Не со всеми — кое-что может подождать. Но те, что случаются в первые две недели с реальными пользователями, должны работать.

Как решить: тест из трёх слоёв

Используйте его, чтобы понять, где вы находитесь:

Слой 1: основной сценарий — Работает ли «счастливый путь»? Может ли пользователь сделать то главное, ради чего создано ваше приложение?

Для приложения для записи к терапевтам: да. Человек может зарегистрироваться, записаться на приём, получить подтверждение. Это работает.

Слой 2: пограничные случаи из реального использования — Вы показали это трём настоящим пользователям. Натолкнулись ли они на что-то, чего вы не предусмотрели? Запутались ли где-нибудь?

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

Слой 3: вылизанность и профессионализм — Ощущается ли, что вам не всё равно? Или ощущается, что вы собрали это на скорую руку?

Для приложения для записи к терапевтам: ощущается, что на скорую руку. Письма-подтверждения голые. Нет фирменного оформления. Нет сообщения об ошибке, если что-то идёт не так, — поэтому, если что-то ломается, пользователь понятия не имеет, что случилось.

Вот эвристика:

Работают все три слоя? Вы — продукт. Запускайте.
Слои 1 и 2, но не 3? Вы готовы на 80%. Потратьте день на вылизывание.
Работает слой 1, а слои 2 и 3 — нет? Вы — прототип. Пока не запускайте.
Слой 1 не надёжен? Вы не готовы. Продолжайте строить.

Приложение для терапевтов застряло на границе между слоем 1 и слоем 2. Основной сценарий работал, но настоящие терапевты находили недостающие части. Так что у основательницы был выбор: потратить ещё неделю с ИИ-конструктором на добавление функций, которые терапевтам реально нужны, или запуститься с тем, что есть, и добавить их позже.

(Она их добавила. Это заняло три дня. Теперь это продукт.)

То, что делает это трудным

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

Строить — это разговор с вашим ИИ-инструментом. У вас есть идея, вы её описываете, инструмент её воплощает. Есть обратная связь, которая занимает минуты. Запуск — другое дело. Вы нажимаете «опубликовать», и если что-то не так, об этом узнают реальные люди. Переиграть нельзя.

Поэтому мы находим причины не запускаться. «Недостаточно вылизано». «Надо добавить ещё одну функцию». «А что, если шрифты не те?» И шесть недель спустя вы всё ещё сидите над чем-то, что работает, но не ощущается готовым, и вы убедили себя, что дело в шрифтах.

Дело не в шрифтах.

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

Чек-лист готовности к запуску

Используйте его. Он короткий и честный.

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

Если можете поставить галочки во всех пяти пунктах — вы готовы. Запускайте.

Если не можете — не запускайте. Но будьте конкретны насчёт того, почему. «Не ощущается готовым» — это не причина. «Настоящим терапевтам нужны правила доступности, а я их пока не построил» — это причина. Это можно сделать. Это можно исправить. В этом и разница между тем, чтобы застрять, и тем, чтобы быть на пути.

Основательница приложения для терапевтов запустила его вчера. У неё уже есть первый платящий клиент. Продукт не идеален, но он реален, и её клиент уже подсказывает ей, что строить дальше. Вот когда понимаешь, что готов: не когда приложение идеально, а когда ты готов узнать, что на самом деле значит «идеально» для тех, кто им пользуется.