Коли один продукт стає двома: як розділити ваш застосунок на ШІ, не починаючи спочатку
Ваш застосунок на ШІ почався як один продукт. Потім ви зрозуміли, що це таємно два. Ось як чисто розділити застосунок на ШІ — не покидаючи того, що ви вже випустили.
Ви почали з однієї ідеї. Ви описали її своєму конструктору застосунків на ШІ, подивилися, як він генерує екрани, відредагували шорсткі краї й випустили щось справжнє. Люди почали ним користуватися. А потім, спершу повільно, у зворотному зв’язку проявився патерн: половина ваших користувачів хотіла одного, інша половина — іншого. Вони не билися за ту саму функцію. Вони просили два різні продукти.
Це момент, коли багато засновників панікують і починають другий проєкт із нуля. Не варто. Є чистіший спосіб розділити застосунок на ШІ, коли ваш один продукт виявляється двома, — і він зазвичай зберігає більшість того, що ви вже зібрали. Цей допис — про те, як розпізнати розділ, коли його робити і яких трьох форм він зазвичай набуває.
Як ви дізнаєтеся, що у вас два продукти
Сигнал майже ніколи не виглядає як запит на функцію. Він виглядає як тертя.
У застосунку для продуктивності, який я спостерігав у цьому процесі, була чітка історія. Він продавався як «особистий планувальник». Користувачі почали з’являтися двох гатунків. Одна група використовувала його, щоб планувати власний тиждень, і ставилася до нього як до приватного записника. Інша група вела невеликі команди й хотіла призначати завдання іншим людям. Обидві були достатньо задоволені, щоб продовжувати користуватися тим самим продуктом, але кожен реліз тішив одну групу й дратував іншу. Команда думала, що в них проблема пріоритизації функцій. Насправді в них була проблема бренду. У них був особистий застосунок і командний застосунок, що ділили одну кодову базу, одну головну сторінку й одну сторінку цін.
Ви зрозумієте, що перетнули цю лінію, коли одне з цього почне бути правдою:
- Вашому лендінгу доводиться ховати свій справжній пітч за узагальненою мовою, бо дві аудиторії не повірять тим самим словам.
- Кожна нова функція має застереження «але для іншого типу користувача це має працювати інакше».
- Ваші відповіді підтримки починають розгалужуватися: «якщо ви використовуєте це для себе…» проти «якщо ви керуєте командою…».
- Нетривіальна кількість користувачів тримає два окремі акаунти, щоб розділяти два режими.
Якщо ви бачите два чи більше з цього, у вас не проблема функцій. У вас розділ продукту, що чекає на свою мить.
Три форми розділу
Вам не треба обирати форму першого ж дня. Зазвичай можна спробувати найлегшу спершу й ескалювати. Але корисно знати меню, перш ніж описувати це своєму конструктору на ШІ, бо слова, які ви використовуєте, формуватимуть те, що згенерується.
Форма 1: Один застосунок, двоє дверей
Найлегша версія. Ви тримаєте одну кодову базу. Ви додаєте запитання при першому запуску — «Ви тут для себе чи для команди?» — і використовуєте відповідь, щоб показати інший набір сторінок та іншу навігацію. Те саме сховище даних. Той самий вхід. Те саме білінгування. Просто інша поверхня.
Більшість конструкторів застосунків на ШІ добре справляються з цим, якщо описати це як «застосунок із двома режимами». На що варто зважати — це що два режими не мають ділити екрани з умовними показ-і-сховай усюди. Це зрештою виглядає як один захаращений застосунок, що вдає двома. Скажіть конструктору, що двоє дверей окремі — різні головні сторінки, різні сторінки налаштувань, різні порожні стани. Кілька екранів, що справді перетинаються (налаштування акаунта, білінгування), можна ділити.
Коли це працює: коли дві аудиторії хочуть іншого обрамлення, але тих самих базових об’єктів. Приклад планувальник-проти-команди підходить сюди. Те, що ви плануєте, усе ще завдання; змінюються лише правила навколо призначення, поширення й сповіщень.
Коли це не працює: коли дві аудиторії очікують цілком різних об’єктів. «Клієнтський портал» та «внутрішній адмінський інструмент» майже не перетинаються, навіть якщо виглядають так, ніби про той самий бізнес.
Форма 2: Два застосунки, один бекенд
Середня форма. Ви розділяєте передню частину продукту на два окремі застосунки — два URL, два лендінги, два процеси онбордингу, дві таблиці цін, — але обидва читають з тієї самої бази даних під сподом. Клієнт може мати акаунт в обох. Адмін може бачити дані з обох.
Саме це ми нещодавно зробили в компанії, що веде цей блог. У нас був один застосунок, що намагався обслуговувати дві аудиторії: інженерів, що оцінюють нашу агентну платформу, і будівників, що користуються нашим конструктором застосунків на ШІ. Той самий бекенд, та сама автентифікація, та сама база даних — але фронтенд відростив дві голови, а меседжинг був заплутаний. Ми розділили його на два фронтенд-застосунки, по одному на кожну аудиторію. Бекенд лишився точно таким самим.
Ця форма — правильна відповідь, коли:
- Дві аудиторії купують з різних причин.
- Їх збентежив би чи відштовхнув би маркетинговий текст іншої аудиторії.
- Дані, що їх турбують, здебільшого тієї самої форми, але обрамлені інакше.
- Ви не хочете підтримувати дві бази даних чи два білінгові налаштування.
Скажіть своєму конструктору на ШІ, що ви хочете «другий фронтенд-застосунок, що ділить наявний API». Більшість сучасних конструкторів на ШІ можуть зробити каркас сестринського проєкту й спрямувати його на ваш наявний бекенд. Пастка, якої треба уникати: копіювати-вставити компоненти першого застосунку дослівно й потім вічно редагувати обидві копії. Попросіть конструктор винести спільні частини (екрани автентифікації, поширені віджети форм) у маленьку бібліотеку, якою користуються обидва застосунки. Ви заощадите собі місяці дубльованих виправлень потім.
Форма 3: Два застосунки, два бекенди
Найважчий розділ. У вас справді два продукти. Вони не діляться даними, не діляться користувачами й не мають ділити дорожню карту. Правильний хід — повністю їх розділити: окремі кодові бази, окремі бази даних, окремі домени.
Це правильний хід рідше, ніж люди думають. Він спокусливий, бо здається чистим. Реальність у тому, що два цілком окремі застосунки означають по два всього, що треба тримати робочим — два конвеєри деплою, два чергування на дзвінку, дві платіжні інтеграції, два набори довідки. Не тягніться до цієї форми, якщо продукти справді не перетинаються. Хороший тест: якщо користувач продукту A ніколи не був би користувачем продукту B, вам, імовірно, справді потрібна Форма 3. Якщо більшість ваших користувачів могла б правдоподібно хотіти обох, вам майже напевно потрібна Форма 2.
Коли ви робите це з конструктором на ШІ, найлегший хід — скопіювати наявний проєкт як відправну точку для другого, а потім попросити конструктор прибрати функції, що не належать, і додати ті, що належать. Не починайте другий проєкт із порожнього полотна. Ви вже багато чого навчилися, будуючи перший, і конструктор на ШІ підхопить цей контекст, якщо ви йому дасте.
Що зробити, перш ніж щось розділяти
Перш ніж описувати розділ своєму конструктору на ШІ, зробіть три маленькі речі. Вони варті більше, ніж звучать.
По-перше, напишіть нову головну сторінку для кожного боку. По два абзаци кожна. Пітч, аудиторія, одна річ, яку ви хочете, щоб вони зробили. Якщо ви не можете написати дві різні головні сторінки, у вас насправді ще немає двох продуктів — у вас просто два сегменти одного продукту, і це варто розв’язати меседжингом, а не архітектурою.
По-друге, перелічіть, які екрани спільні, а які ні. Будьте чесні. «Вхід спільний. Онбординг інший. Дашборд інший. Налаштування здебільшого спільні. Білінгування спільне». Цей список стає брифом, який ви передаєте конструктору на ШІ. Він заощаджує багато туди-сюди.
По-третє, вирішіть, що однакове під сподом. Ті самі користувачі? Ті самі дані? Ті самі платежі? Кожне «так» тягне вас до Форми 1 чи 2. Кожне «ні» тягне вас до Форми 3. Правильної відповіді немає — лише відповідь, що відповідає тому, як ваш продукт насправді працює.
Що змінюється після розділу
Дві речі стають легшими, а одна — важчою.
Маркетинг стає легшим. Кожен застосунок отримує власний чіткий пітч. Кожен лендінг може звертатися до однієї аудиторії без вивертів. Ваш показник конверсії зазвичай зростає принаймні на одному боці, іноді на обох.
Онбординг стає легшим. Користувач уперше потрапляє на сторінку, що про нього, а не на сторінку, що намагається бути про всіх.
Що стає важчим — це тримати спільні частини синхронізованими. Якщо ви виправляєте баг у процесі входу, ви хочете, щоб його виправили в обох застосунках. Якщо ви міняєте, як виглядає екран білінгування, ви хочете, щоб обидва застосунки це відобразили. Дисципліна, яка вам потрібна — і це правда, чи то ви вайб-кодите з конструктором на ШІ, чи то будуєте з командою людей-розробників, — це тримати спільні частини справді спільними. Не дублюйте. Не форкайте. Або винесіть спільний екран у маленьку бібліотеку, якою користуються обидва застосунки, або прийміть, що у вас два справді окремі застосунки, і володійте цим.
Маленьке запитання наостанок
Якби ви прогнали пітч свого поточного застосунку повз п’ятьох незнайомців, і кожен описав би його інакше — але у два чіткі кошики, — ви, ймовірно, вже живете з розділом. Єдине запитання — чи ви продовжуєте платити податок одного заплутаного продукту, чи робите роботу бути чесним щодо того, що ви — два.
Вам не треба вирішувати сьогодні. Але наступного разу, коли ваш конструктор застосунків на ШІ запитає «що мені будувати далі?», зважте, що найкорисніша відповідь може бути не новою функцією. Вона може бути новими вхідними дверима.
Якщо це відгукнулося, вам також може сподобатися наша попередня стаття про побудову для своєї команди проти побудови для клієнтів — той самий гатунок рішення, на крок раніше в житті вашого продукту.