Кого нанимать первым для запуска IT-продукта?

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

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

Не начинайте со штатного расписания «как у взрослых»

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

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

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

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

Сценарий 1: есть спрос, но некому собрать работающую версию

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

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

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

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

Сценарий 2: технически всё возможно, но неясно, за что заплатят

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

Это не обязательно «продажник на холодные звонки». На раннем этапе важнее услышать язык клиента: как он называет проблему, что уже пробовал, почему откладывает решение, кто принимает решение о деньгах. Человек может называться product manager, бизнес-девелопер или основатель с такой привычкой — название вторично.

Хороший признак: после десяти разговоров команда меняет не рекламный слоган, а сам продуктовый фокус. Возможно, выясняется, что клиенту важен не отчёт, а согласование исключений. Или не интеграция «со всем», а надёжный обмен с одной учётной системой. Именно так отделяют вежливый интерес от реального спроса — об этом есть отдельный разбор: кто действительно готов платить за идею.

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

Сценарий 3: первые клиенты есть, а основатель тонет в операционке

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

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

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

Кого не стоит нанимать первым

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

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

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

Как проверить кандидата без красивых общих слов

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

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

Короткий чек-лист перед первым наймом

• Сформулируйте одну главную неопределённость на ближайшие два-три месяца.
• Опишите результат, который новый человек должен помочь получить, а не только список обязанностей.
• Проверьте, нельзя ли сначала закрыть задачу временно: консультацией, подрядчиком, личным участием основателя.
• Дайте кандидату практическую задачу из реального контекста.
• Заранее решите, кто будет принимать решения и давать обратную связь в первые недели.

Связанные вопросы

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

Можно ли начать с подрядчика? Можно, если границы первой задачи ясны. Подрядчик особенно полезен для точечного навыка, который пока не нужен на постоянной основе.

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

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

Как не перегрузить первого разработчика? Не отдавать ему стратегию вместо требований. Сначала договоритесь о первом полезном сценарии и о том, что войдёт в MVP, а что сознательно останется за рамками.

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