Технический сооснователь или консультант для первого продукта

Почему этот выбор кажется сложным

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

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

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

Обратная ошибка тоже бывает. Некоторые основатели уже понимают, что им нужно: клиентский портал, процесс бронирования, простое мобильное приложение или внутренний инструмент с понятным ТЗ. В таком случае сложность в исполнении. Консультант часто подходит лучше, потому что у работы есть границы, сроки и понятный финиш.

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

Люди еще и смешивают риск продукта с риском найма. Они думают: «Если дам долю, этому человеку будет не все равно» или «Если заплачу консультанту, проект будет безопаснее». Ни то ни другое не обязательно правда. Доля не исправляет размытый продукт, а оплачиваемый контракт не создает общего взгляда на продукт.

Неправильная схема быстро рождает напряжение. Сооснователь может ожидать широкого влияния там, где вам нужна только реализация. Консультант может ждать фиксированный объем работ, а вам на самом деле нужны недели исследований, изменений и сложных продуктовых решений.

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

Вы выбираете не только человека. Вы выбираете и тип проблемы, которая у вас сейчас есть.

Как выглядит высокая неопределенность

Высокая неопределенность означает, что описание продукта перестает быть верным каждую неделю. Вы не шлифуете уже известную идею. Вы все еще ищете реальную проблему, реального пользователя и самую маленькую версию продукта, за которую люди готовы платить.

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

Основной сценарий использования тоже может постоянно меняться. На одной неделе продукт выглядит как панель управления. На следующей — как inbox, форма или даже сервис с легкой админкой. Это важно, потому что рабочий процесс влияет почти на каждое решение при разработке. Если пользователям нужны согласования, журналы аудита или проверка человеком, продукт быстро меняется.

Скорее всего, вы на этом этапе, если одни и те же вещи постоянно сдвигаются. Вы переписываете описание проблемы после разговоров с клиентами. Самая важная функция меняется каждую неделю. Ценообразование все еще кажется догадкой. Вы не уверены, нужен ли продукту самостоятельный запуск, помощь продаж, или сначала ручной пилот.

Технические решения тоже становятся шаткими. Если вы не знаете, нужна ли следующей версии глубокая интеграция, сильная автоматизация, строгие права доступа или простая веб-форма, слишком рано фиксировать архитектуру. Может поменяться даже способ разработки. Легкий прототип, no-code проверка или частично ручной процесс иногда дают больше знаний, чем отполированное приложение.

Именно здесь ранние команды теряют время. Они воспринимают движущиеся гипотезы как факты, а потом переделывают все после каждого нового этапа обучения. Если каждый разговор с клиентом меняет объем работ, канал или цену, у вас еще нет стабильной задачи на реализацию. У вас все еще исследование, которое притворяется проектом по разработке.

Когда подходит технический сооснователь

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

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

Консультанты обычно лучше всего работают, когда задача уже имеет устойчивую форму. Сооснователь больше подходит, когда форма все время меняется. Если вы ждете несколько разворотов до первой версии, совместная ответственность обычно — более чистая схема.

Это особенно верно, когда:

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

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

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

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

Когда основатели сравнивают сооснователя и консультанта, они часто в первую очередь смотрят на цену. Лучший вопрос — сколько неопределенности все еще скрыто внутри продукта. Если ответ «много», совместная ответственность обычно подходит лучше, чем работа по четкому объему.

Когда подходит консультант

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

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

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

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

Небольшой пример помогает. Допустим, вы ведете локальный сервисный бизнес и уже принимаете записи по телефону и в таблице. Теперь вам нужен простой клиентский портал, где клиенты смогут записываться, платить и получать напоминания. Это не легкая работа, но она понятна. Консультант может оценить ее, сделать и передать вам.

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

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

Если вам нужен более глубокий совет без потери контроля, советник в формате fractional CTO может помочь определить объем работ до начала разработки. Этот шаг часто экономит деньги, потому что команде разработки достается более четкое ТЗ и меньше сюрпризов.

Используйте простой процесс принятия решения

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

Помогает простой процесс:

1. Выпишите все открытые вопросы на одну страницу. Пишите простыми словами: кто первый пользователь, какое действие он должен завершить, какие данные нужны и что должно быть быстрым или надежным в первый день?
2. Отметьте неизвестные, которые могут изменить разработку. Тест цены обычно не переписывает весь код. А переход от «простого клиентского портала» к «многопользовательскому рабочему инструменту» — скорее всего, перепишет.
3. Опишите первую версию обычным языком. Одной страницы достаточно, если на ней написано, что могут делать пользователи, что могут делать администраторы и что можно отложить.
4. Отметьте решения, которые требуют еженедельного технического взгляда. Частые примеры — выбрать между быстрым прототипом и более надежной основой, решить, когда автоматизировать, или менять модель данных после обратной связи.
5. Сопоставьте роль с работой. Если именно неизвестные будут определять большую часть работы, подходит совместная ответственность. Если форма уже стабильна, а главная задача — реализация, наймите консультанта или небольшую команду разработки.

Потом сделайте проверку на здравый смысл. Вам нужен человек, который будет спорить с самим продуктом, или тот, кто выполнит понятный план? Основатели часто смешивают эти роли, и именно так начинаются плохие наймы.

Возьмем полевую службу. Если вы все еще не знаете, что важнее — диспетчеризация, счета или фотоотчеты, — совместная ответственность подходит больше, потому что каждый ответ меняет и продукт, и разработку. Если вы уже знаете, что первая версия должна включать логин, биллинг, клиентский кабинет и две интеграции, работа все еще требует навыка, но ее форма уже ясна. Это гораздо ближе к работе по четкому объему.

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

Простой пример

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

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

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

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

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

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

Теперь основатель может уверенно описать задачу. Сделать календарь для стойки регистрации. Добавить правила доступности врачей. Отправлять напоминания. Отслеживать отмены. Это уже достаточно стабильно для работы по четкому объему.

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

Ошибки, которые тратят время и деньги

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

Одна частая ошибка — отдать долю ради краткосрочной реализации. Если вы уже знаете, что строить, как пользователи будут этим пользоваться и как должен выглядеть успех в ближайшие месяцы, вам может не понадобиться сооснователь. Вам может понадобиться консультант с четким объемом работ. Доля уместна тогда, когда человек будет формировать продукт, разделять риск и оставаться рядом в сложных решениях, а не просто закрывать очередь задач.

Обратная ошибка не менее дорогая. Некоторые основатели нанимают консультанта, когда ТЗ меняется каждую неделю, а потом удивляются, почему прогресс кажется хаотичным. Работа по четкому объему требует стабильных решений. Если цель все время движется, консультант либо дважды переделывает одни и те же части, либо начинает защищать объем работ вместо того, чтобы помогать думать о продукте.

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

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

Почасовая ставка создает еще один неправильный выбор. Самый дешевый человек часто обходится дороже, если ему нужно постоянное руководство, если он не замечает продуктовые проблемы или оставляет вам код, который никто не хочет поддерживать. Более опытный fractional CTO или советник может стоить дороже в час и все равно сэкономить деньги, потому что рано сократит объем, выберет более простой стек и остановит очевидные обходные пути до того, как они станут дорогими.

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

Быстрые проверки перед тем, как решиться

Плохой найм часто начинается с размытого ТЗ. Прежде чем выбирать, заставьте решение звучать простыми словами. Если вы не можете объяснить, что должна делать первая версия, для кого она и что считается «готово», вы все еще находитесь на этапе поиска.

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

Запишите ответы на эти прямые вопросы:

• Можете ли вы описать первую версию на одной странице без общих фраз?
• Возвращают ли интервью с пользователями вас к началу каждую неделю?
• Будет ли этот человек вместе с вами принимать продуктовые компромиссы или только делать то, что вы попросите?
• Можете ли вы оплатить фиксированный объем работ деньгами, не надеясь, что объем как-нибудь решится сам?
• Вам нужен долгосрочный партнер в бизнесе или краткосрочный исполнитель, который сделает работу и уйдет?

Шаблоны важнее любого отдельного ответа. Если заметка о первой версии постоянно меняется и вам нужен человек, который будет вместе с вами спорить о приоритетах, сооснователь обычно — более чистый выбор. Если продукт простой, задачи известны и у вас есть бюджет на разработку, консультант часто быстрее и менее проблемный.

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

Еще одна проверка помогает. Представьте следующие шесть месяцев. Если вы ожидаете постоянные развороты, найм под аккуратный объем работ расстроит обе стороны. Если вы ожидаете понятную разработку с понятными этапами, отдавать долю слишком дорого.

Если после этого упражнения вы все еще не определились, возьмите второе мнение до подписания. fractional CTO может проверить объем работ, протестировать ваши предположения и показать, где на самом деле сидит риск.

Что делать дальше

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

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

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

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

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

Если вам нужна внешняя оценка перед тем, как решиться, Oleg Sotnikov на oleg.is делает такую работу в формате fractional CTO и startup advisor. Он помогает стартапам и небольшим командам оценить объем работ, структуру команды и архитектуру продукта до того, как они потратят месяцы на разработку не того.

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