AI-продукт — це не просто чат: 4 помилки, які коштували Валерію Ясакову часу й грошей
Валерій Ясаков працює з машинним навчанням із 2012 року, а останні півтора року розвиває продукти, де AI лежить в основі. Сьогодні в його портфелі чотири продукти у складних з точки зору регуляторики сферах — healthcare та insurtech.
На зустрічі Валерій розповів не про те, як «успішно впровадити AI», а про власні помилки: де можна втратити місяці роботи, чому красивий AI-прототип ще нічого не означає і що насправді створює цінність продукту.
Прототип, який «працює», може бути готовий лише на 15%
Одна з головних пасток — побачити, як модель отримує дані, відпрацьовує промпт і видає хороший результат, а потім вирішити, що залишилося лише написати код.
Саме в цю пастку Валерій потрапляв тричі з чотирьох.
«Насправді на цьому етапі все працює на 15% максимум, а то й менше».
Після такого прототипу починається розробка, хоча до повноцінного продукту ще дуже далеко. У випадку Валерія це також призвело до проблем із юніт-економікою. На розрахунки пішло чотири місяці, які можна було заощадити, якби економіку порахували на старті.
Команді довелося скоротити функціонал і залишити лише те, що справді було потрібне користувачам. У результаті продукт став значно простішим — і саме це дало йому шанс вижити.
AI не створює цінність сам по собі
Ще одна помилка — будувати продукт навколо самого AI.
Наприклад, команда створила чат для жінок 45+, який мав допомагати їм розуміти зміни в організмі. Але швидко стало зрозуміло: сам чат не дає достатньої цінності. Люди вже звикли ставити запитання Google або ChatGPT.
Підхід змінили. Замість «чату заради чату» продукт почав збирати дані з пристроїв, отримувати інформацію про сон та активність, враховувати настрій користувачки, аналізувати все це й формувати зрозумілий звіт.
AI у такій моделі вже не є самим продуктом. Він допомагає перетворити зібрані дані на корисний для людини результат.
«Він ніколи не створює, він може щось тільки покращити або масштабувати».
Тому перед впровадженням AI Валерій радить поставити просте питання: чи справді цю роботу потрібно автоматизувати?
Якщо завдання може виконати людина за $5 — можливо, автоматизація поки не потрібна. Коли ж одного-двох людей уже недостатньо, тоді з'являється сенс шукати автоматизацію та AI-рішення.
AI-пайплайн — це окремий продукт
У звичайному SaaS легко сприймати нову функцію як ще одну фічу. З AI це може бути небезпечно.
Особливо у healthcare та страхуванні, де результат моделі потребує додаткових перевірок, захисту, контролю та врахування регуляторних ризиків.
Тому кожен AI-пайплайн Валерій радить розглядати майже як окремий продукт: рахувати його розробку, інфраструктуру, якість результату та вартість використання.
Окрема проблема — токени. Користувачі взаємодіють із моделлю по-різному, тому витрати неможливо просто закласти як фіксовану собівартість.
«Вам треба юніт-економіку до того порахувати, щоб зрозуміти, чи має сенс у цьому, чи не має».
Власна модель може зменшити залежність від вартості запитів, але й вона не є безкоштовною. Потрібні інфраструктура, дані та ресурси для навчання.
У своєму продукті для страхових компаній команда Валерія змогла отримати доступ до сотень тисяч деперсоналізованих медичних історичних кейсів. На них навчили власну модель, що дозволило зменшити залежність від зовнішніх моделей.
Перевіряти потрібно не тільки продукт, а й ринок
Навіть хороший продукт може не мати сенсу, якщо його дорого продавати.
В одному з кейсів співвідношення Customer Acquisition Cost до LTV у команди становило 1,4. За орієнтир Валерій називає показник близько 3 або вище.
Замість того щоб просто продовжувати інвестувати в розробку, команда змінила підхід до перевірки гіпотез.
Спочатку — простий прототип і перевірка, чи взагалі працює ідея. Потім — інтерфейс, за яким частину роботи виконує людина вручну. Це дозволяє перевірити попит і зрозуміти, де саме початкова гіпотеза була неправильною.
Якщо результат позитивний, команда переходить до MVP для обмеженого кола клієнтів. При цьому людина залишається в контурі та перевіряє результат моделі.
Лише після цього можна думати про масштабування.
CustDev починається з правильних людей
За словами Валерія, команда зазвичай починає з 10–15 глибинних інтерв'ю. На їх основі формуються гіпотези для кількісного дослідження.
Але перед CustDev команда робить ще й desk research. Іноді цього вже достатньо, щоб зрозуміти: від певної ідеї краще відмовитися.
Для складних ніш важливо говорити саме з людьми, які приймають рішення. Наприклад, у страховому бізнесі користувачем системи може бути оператор, але купувати продукт буде його керівник.
Саме тому команда залучає радників із відповідної сфери. Один із таких радників Валерія — американка з досвідом роботи HR-директоркою у великих компаніях. Вона допомагає з контактами, розумінням ринку та проведенням глибинних інтерв'ю.
Людина в контурі поки що залишається необхідною
AI помиляється. Питання не в тому, чи станеться помилка, а в тому, коли.
Найкращий результат, якого команда Валерія досягала за своїми еталонами, становив 92%, а реальний показник — близько 89%.
Тому в продуктах, де помилка може мати серйозні наслідки, остаточне рішення залишається за людиною.
У консультативних продуктах користувачу прямо пояснюють, що інформацію надавала модель. У страхових рішеннях оператор отримує результат AI, перевіряє його і як професіонал відповідає за фінальне рішення.
Такий підхід дозволяє контролювати ризики, особливо в регульованих сферах.
Найцінніші речі — дані та Delivery
На думку Валерія, сам продукт із часом матиме все менше цінності, особливо якщо його легко повторити за допомогою AI.
Натомість конкурентною перевагою стають дані, до яких складно отримати доступ.
«Той, хто володіє даними, до яких важко дотягнутися, він робить класні продукти».
Це добре видно на прикладі страхування. Якщо компанія має доступ до великого масиву реальних кейсів, може навчити на них власну модель і побудувати навколо цього продукт. Конкуренту буде недостатньо просто скопіювати інтерфейс — йому доведеться пройти весь шлях до отримання таких самих даних.
Друга складова — Delivery. Навіть сильний продукт нічого не вартий, якщо його погано доставляють клієнту.
Валерій наводить власний приклад: раніше його студія мала велику команду, багато клієнтів та великі проєкти. Після перебудови залишилося лише чотири людини, але команда може інтегрувати кілька систем і випустити продукт приблизно за півтора тижня.
Загалом після перебудови процесів команду вдалося скоротити вдвічі, а швидкість роботи — збільшити втричі.
AI не замінює досвід
Валерій не вважає, що AI просто замінить розробників. На його думку, він змінює вимоги до їхньої роботи.
«Мені джуніор з AI не потрібен, він не зрозуміє, що AI робить неправильно».
Модель може генерувати код на рівні junior-розробника, але для перевірки цього коду потрібен досвід. Особливо важлива архітектура: якщо рішення неправильно спроєктоване на цьому рівні, хорошим кодом проблему вже не виправити.
Тому цінність спеціаліста поступово зміщується від простої здатності написати код до розуміння продукту, архітектури, бізнес-контексту та вміння перевіряти результат AI.
Головний висновок
Досвід Валерія Ясакова з чотирма AI-продуктами зводиться до досить простої послідовності: не закохуватися в технологію, перевіряти попит до дорогої розробки, рахувати економіку заздалегідь, працювати з реальними даними й не забувати про якісний Delivery.
«Зробили, працює, класно — тепер проаналізувати, чи це потрібно ринку, а вже після того тільки намагатися це реалізувати реальним кодом».
Саме такий підхід дозволяє не просто створити AI-функцію, а зрозуміти, чи варто взагалі будувати навколо неї бізнес.