Многие разработчики рано или поздно задумываются о том, чтобы стать основателями стартапа, потому что на первый взгляд создание компании кажется продолжением привычной работы: найти проблему, придумать решение и реализовать его. Поэтому переход может выглядеть обманчиво знакомым. Однако навыки, которые делают человека отличным инженером — техническая экспертиза, точность и умение создавать надёжные системы, — сами по себе не дают навыков продаж, расстановки приоритетов, лидерства и понимания рынка, необходимых для построения успешной компании.
Почему написание кода и создание продукта — не одно и то же
Инженерная работа в первую очередь связана с созданием решений, тогда как построение продукта требует доказать, что проблема действительно достаточно важна и люди готовы использовать решение или платить за него.
Разработчики привыкли мыслить с точки зрения реализации. Получив достаточно понятную задачу, они оценивают архитектуру, технологии, производительность, надёжность, сопровождаемость и технические компромиссы. Прогресс при этом часто можно измерить количеством работающей функциональности.
Основатели имеют дело с другим типом неопределённости. Главный вопрос может заключаться не в том, как что-то создать, а в том, стоит ли это вообще создавать.
Технически впечатляющий продукт может провалиться, потому что клиенты не считают проблему достаточно важной, существующие альтернативы уже удовлетворяют их потребности, целевой рынок слишком мал, привлечение пользователей обходится слишком дорого или люди просто не понимают, зачем им менять привычный способ работы.
Для технических основателей это создаёт непривычную ситуацию. Написание очередной функции ощущается как продуктивная работа, потому что результат виден сразу. Интервью с потенциальными клиентами, проверка позиционирования, изменение цен или отказ от первоначальной гипотезы могут казаться менее конкретными задачами, хотя именно они иногда имеют большее значение для выживания компании.
Поэтому задача основателя заключается не в максимизации количества созданного программного обеспечения. Его цель — найти воспроизводимый способ создавать ценность для клиентов и превращать её в устойчивый бизнес.
Что на самом деле меняется в ежедневных приоритетах
Стать основателем означает перейти от ответственности за техническую систему к ответственности за всю систему, которая превращает проблему клиента в устойчивый бизнес.
Особенно хорошо этот переход заметен по тому, как меняется распределение времени:
- От реализации к расстановке приоритетов. Вместо вопроса о том, как создать каждую запрошенную функцию, вы всё чаще решаете, какие проблемы действительно заслуживают времени разработчиков, а какие следует проигнорировать.
- От кода к клиентам. Разговоры с пользователями, потенциальными покупателями, партнёрами и клиентами, отказавшимися от сделки, становятся одним из основных источников информации о том, что компании следует создавать дальше.
- От технического качества к бизнес-результатам. Хорошая архитектура остаётся важной, но активация пользователей, удержание, выручка, конверсия, стоимость привлечения клиентов и их удовлетворённость всё сильнее определяют успех продукта.
- От личной производительности к эффективности команды. По мере роста компании ваш вклад всё меньше зависит от количества лично написанного кода и всё больше — от способности других людей принимать правильные решения и эффективно работать.
- От решения определённых задач к управлению неопределённостью. Основателям постоянно приходится принимать решения при недостатке данных — о рынке, найме, ценах, позиционировании, привлечении инвестиций и направлении развития продукта.
Для многих разработчиков-основателей такой переход поначалу создаёт ощущение снижения продуктивности. День программирования оставляет после себя видимые коммиты. День, потраченный на интервью с кандидатами, разговоры с клиентами, проверку финансовых предположений и переговоры с партнёрами, может не оставить ничего столь же осязаемого.
Однако влияние этих действий на компанию может быть значительно выше.
Новые навыки, которым основателей не учили на инженерных факультетах
Самой сложной частью перехода к роли основателя часто становится освоение коммерческих и управленческих навыков, которых техническая работа раньше позволяла избегать.
Один из важнейших примеров — продажи. Основателям на ранней стадии приходится убеждать клиентов попробовать ещё не полностью готовый продукт, талантливых специалистов — присоединиться к рискованной компании, партнёров — сотрудничать, а иногда и инвесторов — вложить деньги в новую возможность.
Работа с клиентскими потребностями — ещё один отдельный навык. Спросить пользователей, какие функции они хотят получить, относительно легко, но ответы часто вводят в заблуждение. Основателю необходимо понимать реальное поведение клиентов, находить дорогостоящие или болезненные проблемы, выяснять, как люди решают их сейчас, и отличать реальную готовность купить продукт от простой вежливой заинтересованности.
Позиционирование и коммуникация также имеют огромное значение. Даже технически сложный и качественный продукт будет иметь ограниченную ценность, если потенциальные клиенты не могут быстро понять, что он делает, для кого предназначен и почему лучше существующей альтернативы.
По мере роста компании всё важнее становится финансовая грамотность. Основателю необходимо понимать выручку, маржинальность, денежный поток, финансовый запас, стоимость найма, экономику ценообразования и влияние различных сценариев роста на жизнеспособность бизнеса.
Но самым серьёзным переходом может стать лидерство. Инженерные проблемы обычно поддаются логике и экспериментам. Люди привносят мотивацию, разногласия, эмоции, стимулы, разные стили общения и личные амбиции. Управление этими факторами требует совершенно другого набора инструментов.
Освоение новых навыков не требует отказываться от инженерного мышления. Необходимо лишь расширить его на области, где исходные данные менее структурированы, а результаты сложнее прогнозировать.
Как совершить переход и не потерять техническое преимущество
Цель заключается не в том, чтобы перестать быть техническим специалистом, а в том, чтобы использовать техническую экспертизу как преимущество и постепенно направлять своё время на задачи с наибольшим влиянием на компанию.
Практический переход можно разбить на четыре этапа:
- Оставайтесь близко к продукту, но перестаньте оценивать себя количеством написанного кода. Продолжайте понимать архитектуру и участвовать в ключевых технических решениях, но оценивайте собственный вклад по результатам компании, а не по числу коммитов.
- Регулярно выделяйте время на разговоры с клиентами. Относитесь к изучению потребностей и продажам с той же дисциплиной, с которой раньше подходили к разработке. Постоянный контакт с реальными пользователями помогает не принимать продуктовые решения исключительно на основе внутренних предположений.
- Делегируйте реализацию раньше, чем техническое мышление. По мере роста команды передавайте другим инженерам всё больше ответственности за код, сохраняя способность оценивать технические компромиссы, задавать правильные вопросы и замечать ненужную сложность.
- Осознанно развивайте компетенции за пределами разработки. Осваивайте продажи, финансы, найм, переговоры, маркетинг и управление на практике, не дожидаясь момента, когда отсутствие этих навыков превратится в кризис.
Сохранение технической грамотности может оставаться серьёзным преимуществом основателя. Она позволяет понимать ограничения разработки, оценивать технических кандидатов, эффективно общаться с инженерами и отличать задачи, которые действительно требуют нескольких месяцев работы, от тех, сложность которых преувеличена.
Опасность заключается не в том, чтобы оставаться техническим специалистом. Опасность — продолжать вести себя как главный индивидуальный исполнитель компании в тот момент, когда бизнесу уже нужен основатель.
Типичные ошибки разработчиков, ставших основателями
Разработчики-основатели часто сталкиваются с проблемами не из-за недостатка технических способностей, а потому, что продолжают применять инженерные привычки там, где необходимы проверка рынка, коммуникация или управленческие решения.
Одна из самых распространённых ошибок — слишком много создавать до начала общения с клиентами. Месяцы могут уйти на архитектуру, инфраструктуру, панели управления, настройки, интеграции и обработку редких сценариев ещё до того, как кто-либо подтвердил реальный спрос на основную ценность продукта.
С этим тесно связано чрезмерное усложнение разработки. Инженеры естественным образом стремятся создавать масштабируемые, поддерживаемые и технически чистые системы. Однако стартапу на ранней стадии часто сначала необходимо понять, заслуживает ли продукт масштабирования, и только потом вкладываться в инфраструктуру для гипотетического будущего спроса.
Ещё одна ошибка — избегание продаж. Некоторые технические основатели предполагают, что достаточно хороший продукт распространится сам. Иногда так действительно происходит, но большинству продуктов необходима дистрибуция. Кто-то должен находить потенциальных клиентов, объяснять ценность предложения, работать с возражениями и непосредственно продавать.
Найм создаёт ещё одну ловушку. Разработчики могут оценивать технических кандидатов преимущественно по профессиональным знаниям, недооценивая коммуникацию, самостоятельность, адаптивность и способность работать в условиях неопределённости. Первые сотрудники влияют на компанию гораздо сильнее, чем предполагает их непосредственная должность.
Разработчик-основатель также может слишком долго оставаться узким местом компании. Если каждое техническое решение, проверка кода, развёртывание, клиентская проблема и продуктовое решение требуют его одобрения, компания не сможет масштабироваться быстрее, чем позволяет внимание одного человека.
Но, пожалуй, самая глубокая ошибка — воспринимать неопределённость как повод продолжать разработку. В инженерии дополнительная работа обычно приближает систему к завершению. В стартапе дополнительный код необязательно приближает компанию к соответствию продукта рынку.
Иногда правильным следующим шагом действительно будет новый коммит. А иногда — десять разговоров с клиентами.
Признаки того, что вы действительно начали мыслить как основатель
Вы начинаете мыслить как основатель, когда вместо вопроса «Что мне создать?» по умолчанию задаёте другой: «Какое главное ограничение сейчас мешает этой компании добиться успеха?»
Иногда это ограничение действительно техническое. Продукт может быть ненадёжным, медленным, небезопасным или не иметь функции, которая действительно необходима клиентам. В таком случае написание кода может быть именно тем, на что основателю следует потратить время.
Но ограничением может оказаться и дистрибуция. Или позиционирование. Или онбординг. Или ценообразование. Или найм. Или удержание клиентов. Или нехватка денег.
Мышление основателя означает готовность работать над той проблемой, которая оказывает наибольшее влияние на компанию, даже если она находится далеко за пределами вашей основной компетенции.
Вы также начинаете спокойнее относиться к выпуску несовершенных решений, когда их задача — помочь чему-то научиться. Вместо оптимизации каждого компонента перед запуском вы начинаете различать решения, которые дорого и сложно отменить, и решения, которые можно скорректировать после получения обратной связи от реальных пользователей.
В подходящих ситуациях интуицию начинают дополнять метрики. Вы смотрите не только на то, говорят ли пользователи, что им нравится продукт, но и на то, начинают ли они им пользоваться, возвращаются ли, платят ли, расширяют ли использование и рекомендуют ли его другим.
Меняется и отношение к технической работе. Можно по-прежнему серьёзно относиться к качеству разработки, не превращая техническое совершенство в главную цель компании. Вы учитесь принимать разумный технический долг, когда важна скорость, и столь же уверенно замедлять разработку, когда этого действительно требуют надёжность или безопасность.
И самое главное — вы перестаёте определять собственный вклад количеством лично выполненных задач. Разработчик создаёт рычаг за счёт программного обеспечения. Основатель создаёт его за счёт программного обеспечения, людей, капитала, дистрибуции, процессов и решений.
Таким образом, переход от разработчика к основателю связан не столько с отказом от инженерной работы, сколько с расширением масштаба системы, за которую вы отвечаете. Код остаётся одним из ваших инструментов, а техническая экспертиза может оставаться серьёзным конкурентным преимуществом. Но после того как вы становитесь основателем, главной системой, которую вы строите, становится сама компания.