Ретроспективы когорт стартапов для лучшего следующего набора

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

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

Это нормально. На раннем этапе команды упираются в одни и те же дедлайны, одно и то же давление инвесторов и одни и те же пробелы в опыте. Если одна когорта застревает на scope, customer discovery или выборе архитектуры, следующая, скорее всего, тоже застрянет.

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

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

Размытые темы воркшопов только усугубляют ситуацию. Сессия с названием «growth», «fundraising» или «building your product» звучит полезно, но часто оставляет основателей с разрозненными заметками и без чёткого следующего шага. В итоге у них появляются идеи, но не решения. Потом менторы снова и снова слышат те же вопросы в личных звонках — уже по одному основателю за раз.

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

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

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

Что собирать после каждой когорты

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

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

Эти заметки показывают трение простым языком. Основатель может высоко оценить воркшоп, а потом провести три офлайн-встречи, задавая один и тот же вопрос о pricing, customer interviews или настройке облака. Такой повторяющийся паттерн важнее, чем один раздражённый комментарий.

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

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

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

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

Как пошагово провести ретроспективу

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

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

Хорошо работает простой процесс:

1. Соберите всю обратную связь в один документ или на одну доску.
2. Разложите каждую проблему по понятным темам: продажи, продукт, найм или технологии.
3. Отметьте, сколько команд столкнулись с одной и той же проблемой.
4. Отметьте, какие проблемы сильнее всего тормозили прогресс, даже если о них говорили реже.
5. Выберите короткий список изменений для следующей когорты.

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

Как превратить обратную связь в полезные паттерны

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

Когда основатель говорит, что воркшоп был «неполезным», не оставляйте такой ярлык. Переведите его в формулировку, с которой можно работать, например: «основатели без опыта не смогли превратить customer interviews в чёткое описание проблемы» или «командам с рабочим прототипом нужна была помощь с ценой, а не проверка идеи». Такой небольшой пересказ делает обратную связь пригодной для использования.

Сортируйте по типу, а не по объёму

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

Вам также нужен чёткий раздел между базовыми и продвинутыми проблемами. Ранним командам обычно нужны основы: customer discovery, scope для MVP, простые выборы инструментов и способы не тратить время на ненужную разработку. Более поздние команды задают более узкие вопросы: тесты цен, настройку аналитики, расходы на инфраструктуру или то, как проверять код, сгенерированный ИИ. Если посадить обе группы на одну и ту же сессию, одной станет скучно, а другая потеряется.

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

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

Как улучшить воркшопы и экспертные сессии

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

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

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

Общие советы плохо работают и тогда, когда основатели пытаются применить их сами. Добавьте время на живой разбор. Короткая сессия может завершиться 15-минутным разбором одного pitch deck, онбординга, roadmap или плана развёртывания. Люди учатся быстрее, когда видят, как реальную проблему исправляют прямо на их глазах.

Простой фильтр помогает делать воркшопы полезными:

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

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

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

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

Хороший чеклист закрывает такие пробелы за 15–20 минут. Если на него уходит час, люди перестают им пользоваться или пролистывают его наспех.

Что в него включить

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

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

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

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

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

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

«Есть ли у вас способ восстановить базу данных?» работает лучше, чем «Опишите вашу стратегию disaster recovery». На один вопрос люди отвечают. На другой — молчат.

Сохраняйте один и тот же формат

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

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

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

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

Простой пример от одной когорты к следующей

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

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

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

Программа изменила три вещи для следующего набора.

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

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

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

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

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

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

Частые ошибки, из-за которых полезная обратная связь пропадает

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

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

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

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

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

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

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

Что сделать до старта следующей когорты

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

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

Короткий предпрограммный обзор помогает удерживать программу честной:

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

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

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

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

Повторяющиеся технические проблемы заслуживают особого внимания. Если в каждой когорте всплывают слабые решения по архитектуре, хаотичные привычки развёртывания или путаница вокруг ИИ-инструментов, привлеките внешнюю помощь ещё до начала набора. Oleg Sotnikov на oleg.is работает со стартапами как Fractional CTO и советник, так что он хорошо подходит для ревью программы, технических чеклистов и поддержки на раннем этапе архитектуры. Во многих случаях целевой разбор до старта когорты обходится дешевле, чем ещё один набор с теми же слепыми зонами.