Чи може нетехнічний засновник побудувати стартап?

Нетехнічний засновник може побудувати стартап, але не шляхом навчання програмуванню. Шлях проходить через технічну відповідальність: призначення людини, яка несе відповідальність за архітектуру, інженерні рішення та технічний найм. Цією людиною може бути технічний співзасновник, CTO-партнер стартапу або, на самому початку, засновник, який проводить достатньо досліджень для обґрунтованих рішень. Top Netics виступав таким технічним партнером у сферах ШІ, блокчейну, фінтеху та комп'ютерного зору, запустивши більше ніж двадцять венчурів у семи країнах.

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

Що насправді означає «нетехнічний засновник»?

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

Це розмежування має практичне значення. Візьмімо двох засновників на seed-етапі: обидва будують фінтех-продукти, жоден не має інженерного досвіду. Один провів шість місяців на курсах програмування, а потім найняв агенцію для створення продукту. Інший залучив CTO-партнера стартапу до першої розмови про розробку, який встановив архітектуру та оцінив перший інженерний найм. Рік потому перший засновник перебудовує все з нуля, оскільки архітектура не підтримує продукт, який йому справді потрібно побудувати. Другий перебуває в розмові щодо серії A, де технічний консультант не знайшов нічого несподіваного у кодовій базі. Однакова відправна точка. Одне структурне рішення різне.

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

Технічні рішення, які нетехнічний засновник не може безпечно ухвалювати самостійно

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

Архітектура

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

Власна розробка vs. готові рішення

Кожен продукт будується з комбінації речей, які ви розробляєте самостійно, та тих, які інтегруєте. Межа між ними виглядає як технічне рішення, але це бізнес-рішення з довгим хвостом: воно визначає вашу залежність від вендорів, позицію ІВ, площу аудиту у регульованій галузі та цінність acqui-hire, якщо це колись стане актуальним. Помилитися тут не просто неефективно. Це створює прив'язку до вендора, вихід з якої є дорогим.

Технічний найм

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

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

Технічні знання vs. технічне судження: чому різниця має значення

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

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

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

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

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

Коли технічне лідерство має увійти до структури вашої команди засновників

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

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

До залучення будь-якого розробника або агенції

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

Коли ви проєктуєте продукт

Продуктові рішення та архітектурні рішення не є окремими. Набір функцій, який ви проєктуєте, визначає модель даних. Модель даних формує архітектуру. Архітектура визначає інфраструктуру. Залучення кваліфікованого технічного лідерства на етапі проєктування продукту, а не після, запобігає перебудові, яка поглинає runway, потрібний для зростання.

До інвесторських розмов про ваш технічний фундамент

Якщо інвестор збирається проводити технічний due diligence вашого стартапу, а будь-який інституційний інвестор на seed або вище це зробить, ви хочете, щоб кваліфікована людина переглянула вашу архітектуру, кодову базу та структуру команди до того, як ця розмова відбудеться. Не як підготовку до розмови. Як постійну умову вашої структури засновників.

Що таке CTO-партнер стартапу?

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

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

Чи потрібен вам технічний співзасновник?

Не завжди, але вам потрібна еквівалентна відповідальність звідкись. Технічний співзасновник тримає частку на рівні співзасновника та повноваження над технологіями вашої компанії з першого рішення. Якщо ви його не залучите, ця відповідальність має надходити від CTO-партнера стартапу, штатного CTO після того, як компанія зможе його підтримати, або, на самому початку, від засновника, який проводить достатньо досліджень для обґрунтованих рішень.

На практиці частка технічного співзасновника становить десь від 15 до 50 відсотків, залежно від того, наскільки рано він приєднується та яку частину технічного напрямку компанії він має контролювати з самого початку.

Airbnb є добре задокументованим прикладом цієї структури. Браян Чески та Джо Геббія, обидва навчалися промисловому дизайну в RISD, не мали інженерного досвіду. Натан Блечарзик приєднався місяці потому як співзасновник та технічний лід, інженер з Гарварду, який отримав реальну частку співзасновника, а не відносини найманого працівника. Засновники не стали інженерами. Вони залучили того, хто вже був ним, і надали йому повноваження співзасновника над технологіями. Це необхідний шлях для закриття прогалини відповідальності. Це спосіб її закрити.

Чи варто найняти CTO замість технічного співзасновника?

Правильна модель залежить від вашого етапу. Технічний співзасновник є правильною структурою до того, як існує архітектура, коли вам потрібен хтось із повноваженнями засновника з першого рішення. CTO-партнер стартапу є правильною структурою, коли вам потрібна реальна відповідальність без повної зайнятості. Штатний CTO є правильним наймом після того, як ваша команда та фінансування можуть підтримати постійного керівника.

Штатний CTO у США зазвичай коштує понад $150 000 на рік без урахування частки. CTO-партнер стартапу або технічний співзасновник, який бере частку замість зарплати, часто є більш реалістичною структурою для компанії, яка ще не отримала фінансування. Найпоширеніша помилка: чекати, поки компанія зможе підтримати штатний найм, перш ніж закрити прогалину відповідальності. На той момент архітектурні рішення вже ухвалено тим, хто будував першу версію.

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

Як валідувати ідею стартапу до пошуку технічного лідерства?

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

Stitch Fix є задокументованим прикладом. Катріна Лейк, яка вивчала економіку, а не інженерію, валідувала ідею за допомогою SurveyMonkey, щоб зібрати стильові вподобання клієнтів, потім особисто підібрала та відправила перші замовлення вручну, стягуючи плату за стиль до того, як існувала будь-яка реальна платформа. Спочатку прийшла валідація. Технологія прийшла лише після того, як ідея вже довела свою комерційну спроможність.

Як будувати MVP, не вміючи програмувати?

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

Чи можна побудувати першу версію за допомогою no-code інструментів?

Іноді так, і це варто назвати прямо. Цільова сторінка на Carrd або Webflow, список реєстрацій в Airtable, робочий процес, автоматизований за допомогою Zapier, посилання на оплату через Stripe: все це може валідувати попит без написання будь-якого коду, і реальний бізнес починався саме так.

Цей підхід іноді називають MVP «Чарівника країни Оз»: щось, що виглядає автоматизованим, поки людина виконує роботу за лаштунками. Засновник Zappos фотографував взуття у місцевих магазинах і купував та відправляв його вручну, коли надходили замовлення, до того, як існувала будь-яка система обліку запасів. Засновники DoorDash самостійно доставляли їжу протягом першого року. Groupon починався як блог на WordPress зі знижками, написаними вручну.

Обмеження проявляється на переході до масштабу, а не відразу. No-code MVP тестує, чи хтось хоче продукт. Він не дає архітектуру, на якій бізнес може масштабуватися. Коли стартап залучає реальну технічну відповідальність, технічний співзасновник або CTO-партнер часто не може взяти те, що існує, тому перебудовує це, оскільки no-code версія ніколи не будувалася для витримки у масштабі. Це не відмова від no-code підходу. Це відмова очікувати, що він виконає другу роботу, для якої не будувався: ту саму прогалину, розглянуту в нашій статті про те, чому працююча технологія не є автоматично комерційною.

Як оцінити технічного співзасновника або CTO-партнера стартапу, якщо ви не можете оцінити код?

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

П'ять речей, які нетехнічний засновник може оцінити без технічних знань:

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

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

Чи запитують вони про ваші комерційні обмеження щодо пропозиції технічного напрямку? Технічний співзасновник, який рекомендує архітектуру без розуміння вашого етапу, команди та позиції щодо фінансування, оптимізує не ту змінну. Правильне технічне рішення на seed-етапі не те саме, що правильне технічне рішення на серії B.

Чи називають вони режими відмови, а не лише можливості? Ті, хто будував у реальних умовах, знають, що йде не так. Кандидати, які лише описують, що вміли їхні попередні продукти, не були присутні, коли речі не працювали.

Чи можуть вони описати, що вони не братимуть на себе? Технічний співзасновник, який стверджує, що займеться всім, не називаючи того, що виходить за межі його сфери, недостатньо ретельно обміркував роль. Реальна відповідальність потребує чіткої межі.

Один практичний підхід до прийняття зобов'язань: спочатку проведіть платне місячне залучення, а не підписуйте угоду про співзасновництво на основі кількох розмов. Реальне залучення з реальними рішеннями дає більше сигналу, ніж будь-який процес співбесіди.

Як нетехнічні засновники залучають фінансування без CTO?

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

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

Коли варто наймати розробників або будувати інженерну команду?

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

Як інвестори оцінюють технічний ризик у нетехнічних командах засновників

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

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

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

Увага: Коли інвестори запитують «чи ви технічний?», вони зазвичай ставлять проксі-питання. Основне питання: «Чи зробите ви дорогі технічні помилки, що знецінять наші інвестиції?» Відповідайте безпосередньо на це питання.

Шлях нетехнічного засновника від ідеї до масштабу

Шлях від ідеї до масштабованої компанії проходить через шість етапів: ідея, валідація, пошук технічного лідерства, побудова MVP, залучення фінансування та масштабування. Технічна відповідальність має існувати до третього етапу, незалежно від того, чи вона надходить від власних досліджень засновника, технічного співзасновника або CTO-партнера стартапу, а не після надходження фінансування і не лише після того, як продукт вже існує.

Ось що означає прогалина відповідальності на кожному етапі:

Етап 1: Ідея. Засновник визначає проблему та ринок. Технічна відповідальність ще не потрібна. Потрібне комерційне судження.

Етап 2: Валідація. Тестуйте ринковий попит без коду. Прогалина відповідальності тут не має значення. Має значення комерційне питання. Спершу закрийте комерційний кейс.

Етап 3: Знайдіть технічне лідерство. Це точка прийняття рішень. До того, як існує архітектура. До залучення першого розробника. До специфікації продукту. Прогалина відповідальності закривається тут або накопичується у всьому, що йде за цим.

Етап 4: Побудуйте MVP. Технічний співзасновник або CTO-партнер стартапу ухвалює архітектурне рішення та окреслює обсяг розробки. Засновник ухвалює продуктові та комерційні рішення. Обидва напрямки тепер охоплені.

Етап 5: Залучіть фінансування. Технічний співзасновник або CTO-партнер представляє технічний кейс. Засновник представляє комерційний кейс. Структура відповідальності є тим, що оцінюють інвестори, а не особистою здатністю засновника до програмування.

Етап 6: Масштабування. Технічна відповідальність зростає до повноцінної інженерної функції. Перші інженери найняті під чітку архітектуру під кваліфікованим технічним лідерством.

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

Висновок

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