Встреча технического сооснователя перед обсуждением долей в стартапе

Почему эта встреча важна

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

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

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

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

Эти темы звучат просто. Это не так. Они заставляют основателей менять фантазии на конкретику, а в этом и состоит смысл.

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

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

Что принести в комнату

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

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

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

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

Принесите и черновик cap table, даже если он кажется слишком ранним. В нем должны быть текущая доля, любые советники или ранние участники, пул опционов, который, как вы ожидаете, понадобится, и доли, которые вы хотите сохранить для будущих наймов или инвесторов. Пока не нужен spreadsheet на уровне юриста. Достаточно грубого, но понятного варианта.

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

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

Начните с обещаний клиентам

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

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

Разделите обещания на две группы. Первая — это твердые обязательства: подписанный объем работ, оплаченные пилоты, даты в письменном виде и функции, которыми закрывали сделку. Вторая — это разговоры с надеждой: грубые предположения о roadmap, идеи, упомянутые на discovery-звонках, или вещи, сказанные просто чтобы не потерять интерес. Эти группы не должны весить одинаково.

Некоторые обещания звучат мелко, но тянут за собой месяцы работы инженеров. Кастомные отчеты, audit logs, SSO, offline mode, мобильные приложения или глубокие интеграции могут полностью изменить план разработки. Если один из основателей уже продавал что-то из этого, отметьте это отдельно. Это влияет на команду, сроки и на то, достаточно ли одного технического основателя.

Короткий чек-лист помогает:

• Какие обещания уже записаны и связаны с деньгами?
• Какие из них требуют новой архитектуры, а не просто полировки?
• Какие из них рано запускают работу по безопасности, compliance или поддержке?
• Какие из них сдвигают сроки с недель на месяцы?

Представьте, что стартап сказал своему первому клиенту: «К концу квартала у вас будут role-based access, approval flows и полноценная admin dashboard». Это не размытое видение продукта. Это обещание по поставке, в которое уже заложены команда и scope.

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

Поставьте цели по cap table простыми словами

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

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

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

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

Цели по контролю требуют той же честности. Если кто-то хочет сохранить board control как можно дольше, скажите об этом прямо. Если план — быстро привлечь деньги и нанять сильную команду, этот контроль обычно будет уменьшаться. Эти идеи могут сосуществовать, но только если оба основателя видят компромисс.

Стадия тоже важна. Небольшой сервисный бизнес, bootstrapped SaaS-продукт и стартап с венчурным финансированием не дают одинаковый cap table. Основатели часто спорят о процентах, даже не договорившись, какой именно компании они строят. Это неправильно.

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

Поговорите о стиле работы до названий ролей

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

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

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

Коротко и ясно обозначьте практические вещи:

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

Конфликт заслуживает прямого языка. Некоторые спорят в комнате и двигаются дальше. Другие замолкают, а потом неделями ходят с раздражением. Обсудите это заранее. Решите и то, что делать при срыве сроков. Вы пересматриваете scope, просите помощи или вместе меняете обещание?

Потом определите роль в часах, а не по ощущениям. «Full-time» для одного человека может означать 50 часов в неделю, а для другого — 30 сфокусированных часов. «Part-time» может хватить для архитектуры и найма, но не хватить для delivery. «Advisory» обычно означает ограниченный доступ, ограниченную долю и отсутствие ежедневной ответственности.

Помогает простой тест: опишите ближайшие 90 дней в календарных терминах. Кто доступен по будням, кто участвует в звонках с клиентами, кто пишет спецификации, кто проверяет код и кто отвечает за production-проблемы? Если один человек ждет партнера, а другой планирует быть лишь occasional helper, название роли это не исправит.

Проведите встречу пошагово

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

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

1. Сначала запишите объем продукта. Назовите первый тип клиента, первый ожидаемый результат и ограничения первого релиза. Если идея все еще слишком широкая, сузьте ее сейчас.
2. Перейдите к ролям и времени. Решите, кто отвечает за продуктовые решения, кто строит продукт, кто разговаривает с пользователями и кто занимается наймом или привлечением денег. Говорите прямо о часах. «Full-time» и «по вечерам и выходным» — это не одно и то же.
3. Обсуждайте цели по доле только после того, как работа станет понятной. Скажите, сколько места вы хотите оставить для будущих наймов, советников и инвесторов. Если один основатель хочет контроль, а другой — гибкость, скажите это заранее, а не спорьте потом о процентах.
4. Закончите открытыми рисками и следующими решениями. Составьте список того, что все еще кажется неясным, кто проверит каждый пункт и когда будет следующая встреча. Дата следующего разговора важна, потому что нерешенные вопросы быстро превращаются в раздражение.

Такой порядок делает разговор спокойнее. Вы не спорите о ценности в вакууме. Вы сопоставляете долю с реальной работой, реальным риском и реальными планами.

Иногда здесь помогает внешний специалист. Startup advisor или fractional CTO может заметить пробелы в scope, устройстве команды или допущениях по cap table еще до того, как они превратятся в плохую сделку.

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

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

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

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

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

Павел затем переводит сроки на простой язык. Он может выпустить core product за шесть недель, если они оставят первый релиз узким. Он не сможет одновременно выпустить core product, кастомные функции для трех покупателей и admin tools уровня production без помощи. Если Нине нужно все это, им понадобится бюджет на contract engineer и место в cap table для раннего найма.

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

Они меняют план. Нина перестает предлагать кастомные доработки до того, как Павел утвердит scope. Павел обещает давать примерные оценки в течение дня, а не исчезать в двухнедельном цикле планирования. Они оставляют часть cap table открытой для первого технического найма и договариваются о vesting, чтобы никто не закрепил большую долю после короткого периода работы.

Только после этого проценты начинают иметь смысл. Финальная сделка получается честнее, потому что отражает реальную работу, реальные обещания и реальную цену выхода на версию 1.

Ошибки, которые искажают сделку

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

Труд очень быстро недооценивают, когда продукт — всего лишь эскиз. Экран входа и dashboard могут звучать как что-то простое. На самом деле работа может включать data models, billing, admin tools, error tracking, deployment, backups и дежурную поддержку. Если никто не называет эту работу, разработчик выглядит «дорогим» или «медленным», хотя на самом деле он просто считает весь объем задач.

Part-time помощь — еще один источник плохих сделок. Человек, который подключается на пять часов в неделю, не принимает тот же риск, что и тот, кто отвечает за delivery, найм, ночные сбои и решения по безопасности. Совет, знакомства и code review важны, но это не то же самое, что полная основательская нагрузка.

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

Хуже всего искажает сделку математика будущей оценки. «Если мы станем компанией на $50 million, это разделение покажется честным» — это фантазия, прикинутая под логику. Ранняя доля должна отражать текущий риск, текущую ответственность и следующий объем работы. Если выручка идет медленнее, чем ожидалось, спросите, кто все еще делает тяжелую работу каждую неделю.

Простой пример все проясняет. Один основатель говорит: «Нам просто нужен MVP за шесть недель». Технический основатель знает, что этому обещанию еще нужны auth, audit logs, облачная настройка, уведомления, исправления ошибок и поддержка клиентов. Это не маленькая разработка. Многие споры о доле начинаются с ошибок в scope, которые никто не назвал простыми словами.

Быстрая проверка перед разговором о доле

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

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

Пятиминутный тест

Используйте этот короткий чек до того, как кто-то вслух назовет процент.

• Оба основателя могут в одном предложении назвать главное обещание клиенту почти одними и теми же словами.
• На ближайшие 6–12 месяцев есть понятные ответственные за продукт, продажи и поддержку, найм, delivery и техническую работу.
• Время участия определено явно. Full-time, part-time, только вечерами и дата, когда это меняется, — все это имеет значение.
• Права на принятие решений записаны. Кто-то отвечает за финальное решение по scope продукта, архитектуре, бюджету и найму.
• План по cap table включает будущий dilution, пул опционов, если он нужен, и первые наймы, которые позже изменят структуру владения.

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

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

Эта проверка не требует долгого воркшопа. Двадцать сосредоточенных минут могут сэкономить месяцы раздражения. Если два основателя продолжают говорить мимо друг друга, нейтральный специалист поможет заставить их говорить конкретно. Oleg Sotnikov из oleg.is занимается таким CTO-level advisory для стартапов, особенно когда scope, архитектура и ожидания основателей еще размыты.

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

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

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

Хорошо работает короткий формат:

• что мы уже согласовали
• в чем мы пока не согласны
• какие данные или решения помогут закрыть каждый открытый вопрос
• когда мы встретимся снова

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