Техническая сортировка портфеля стартап-когорт за 2 недели

Почему первые две недели превращаются в хаос

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

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

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

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

Небольшой пример хорошо это показывает. У стартапа A продукт пока сырой, но пользователи его любят, и команда выпускает обновления каждую неделю. Стартап B выглядит отполированным в демо, но никто не может объяснить, как именно делается работа и кто отвечает за следующий релиз. Стартап C хочет AI-функции, но данные клиентов лежат в таблицах и почте. Этим командам не стоит получать одинаковую помощь в первую очередь.

Что собрать до разговора с основателями

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

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

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

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

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

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

Задайте одну оценочную шкалу для всей когорты

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

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

Опишите значения оценок до первого разговора с основателем. Этот маленький шаг помогает избежать «дрейфа» оценок.

• 1 означает, что у команды есть ясные доказательства, стабильное исполнение и мало открытых вопросов.
• 3 означает, что картина смешанная. Какие-то доказательства есть, но пробелы могут замедлить прогресс.
• 5 означает, что у команды много неизвестного, слабые доказательства или явные блокеры.

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

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

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

Проводите на каждый стартап по 60 минут

Часа достаточно, если держать разговор в рамках и быстро проходить мимо демо. Большинство основателей могут заполнить 60 минут функциями. Хороший разбор снова и снова возвращается к риску, скорости и тому, что прямо сейчас мешает бизнесу.

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

• 0–10 минут: Попросите основателя объяснить компанию простыми словами. Какую проблему они решают, для кого и почему это важно именно сейчас? Если без жаргона объяснить не получается, это уже сигнал.
• 10–25 минут: Переходите к продукту, пользователям и traction. Спросите, чем клиенты пользуются чаще всего, что игнорируют, сколько у них активных пользователей и что изменилось за последние 90 дней.
• 25–45 минут: Перейдите к выпуску. Кто что делает, как принимаются решения, что находится в дорожной карте и как работа выходит в прод? Спросите, как часто они выпускаются, где работа застревает и кто может снять блокировку.
• 45–60 минут: Заканчивайте AI, доступом к данным и следующим узким местом. Спросите, что они уже автоматизировали, какие данные реально можно использовать и что мешает им двигаться быстрее в этом месяце.

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

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

Замечайте продуктовые риски заранее

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

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

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

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

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

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

Внимательно смотрите на удержание. Если команда не может объяснить, почему люди остаются, значит, она еще не понимает свою силу притяжения. Стартап с 500 регистрациями и слабым повторным использованием часто рискованнее, чем стартап с 25 лояльными клиентами, которые зависят от продукта каждое утро понедельника.

Замечайте риски выпуска заранее

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

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

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

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

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

Простой пример это хорошо показывает. Представьте стартап с шестью инженерами, который говорит, что выпускается каждую неделю. Когда вы спрашиваете, что вышло на прошлой неделе, команда упоминает один hotfix, две задержанные функции и откат, который никто не задокументировал. CTO утверждает каждый merge, один backend-инженер обрабатывает все production-алерты, а в бэклоге до сих пор лежат задачи четырехмесячной давности. У этой команды проблема не столько со скоростью. У нее проблема с координацией.

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

Оценивайте готовность к AI без догадок

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

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

Настоящий сценарий использования звучит конкретно. «Сортировать тикеты поддержки до того, как их увидит человек» — это реально. «Делать черновики follow-up заметок по продажным звонкам» — тоже реально. «Добавить чат-бота» — обычно нет. Если основатель не может объяснить, что должен делать бот, какие данные ему нужны и как будет выглядеть успех, оцените идею ниже.

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

Небольшой пример помогает. Один стартап хочет AI-ассистента для поддержки. У него есть размеченные тикеты, история ответов и руководитель поддержки, который владеет процессом. Эта команда довольно готова. Другой стартап хочет «AI для роста», но у него нет чистых данных, нет повторяемого процесса и нет ответственного. Оцените его низко и двигайтесь дальше.

Простой пример когорты

Представьте пакет из трех стартапов в первую неделю. Все они выглядят занятыми и все звучат срочно. Простая оценочная шкала сразу показывает различия.

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

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

У стартапа C самый ясный кейс для AI. В логах поддержки каждый день повторяются одни и те же вопросы. Сотрудники снова и снова тратят время на сортировку тикетов, краткие итоги звонков и черновики ответов. Это практичная основа для автоматизации. У команды уже есть реальные данные, повторяющиеся задачи и простой способ оценить результат. Не нужно гадать, есть ли у AI-пилота сценарий использования. Он уже есть.

Как меняется ранжирование

Когда вы одинаково оцените всех троих, порядок станет простым.

• Стартап B получает помощь по продукту первым, потому что большее количество релизов не исправит слабый спрос.
• Стартап A получает помощь по выпуску следующим, потому что спрос есть, но релизы запаздывают.
• Стартап C получает AI-пилот первым, потому что работа повторяется и ее легко измерить.

Именно так и должна работать сортировка. Она должна показывать, где время основателей поможет сильнее всего в этом месяце.

Ошибки, которые замедляют разбор

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

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

Еще одна частая ошибка — уходить глубоко в архитектуру до того, как подтверждена бизнес-проблема. Команда может говорить об agentах, vector databases или сложных workflows, но все это неважно, если проблема клиента все еще размыта. Сначала спросите, кто пользователь, что болит сегодня и какие доказательства есть, что кому-то вообще нужен этот фикс. Потом переходите к технической части.

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

AI создает и свою ловушку. Интерес основателя к AI — это дешево. Готовность к AI — нет. Команда не готова просто потому, что хочет чат-бота, планирует добавить copilots или говорит, что автоматизация снизит расходы.

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

Короткие проверки перед тем, как ранжировать когорту

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

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

Держите чек-лист коротким. Подтвердите, что каждый стартап прошел одинаковый входной сбор и получил одинаковую длительность встречи. Если одной команде дали подробный pre-read, а другую быстро провели по звонку, оценки несопоставимы. Убедитесь, что каждая оценка опирается на доказательства. Высокая оценка по продукту должна подтверждаться, например, интервью с пользователями, данными по удержанию, активными пилотами или явным сигналом покупки. Низкая оценка по выпуску должна опираться на факты вроде пропущенных релизов, отсутствия ответственного за важную работу или слабых практик тестирования.

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

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

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

Что делать после сортировки

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

Обычно хорошо работают три группы:

• Действовать сейчас: у стартапа есть явный риск, который в ближайшие 30–60 дней может ударить по выручке, выпуску или доверию.
• Наблюдать внимательно: команда может продолжать двигаться, но одна слабая зона скоро потребует доказательств.
• Вернуться позже: у стартапа есть открытые вопросы, но ничего срочного не мешает нормальному прогрессу.

Такой рейтинг не дает когорте воспринимать каждую проблему как пожар. Он также помогает основателям понять, что сортировка — это про последовательность. Им не нужно исправлять вообще все в этом месяце.

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

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

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

Некоторым когортам после первого прохода нужна внешняя помощь. Если у нескольких стартапов повторяется один и тот же рисунок — например, слабые архитектурные решения, медленный выпуск или неясные AI-планы — Oleg Sotnikov на oleg.is может посмотреть выводы как fractional CTO и помочь основателям превратить их в реалистичный план. Такой формат поддержки лучше всего работает, когда заметки короткие, ранжированные и привязаны к доказательствам.

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