Узкие места одобрения основателя, которые замедляют выпуск продукта

Как выглядит узкое место в ежедневной работе

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

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

Команды не просят разрешения потому, что им всё равно. Они спрашивают, чтобы не переделывать работу. Если основатель часто меняет дизайнерские детали, цены или приоритеты поздно — люди усваивают простое правило: сначала спросить. Это кажется безопасным сейчас. За неделю–две это замедляет поставку в едва заметных местах.

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

Паттерн обычно видно по тому, как движется работа:

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

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

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

Почему основатели оказываются в роли согласующих

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

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

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

Ситуация ухудшается, если никто не устанавливает чёткие границы. Если продукт‑менеджер не знает, может ли он утвердить инструмент за $300, он спросит. Если инженер не уверен, можно ли менять настройки логирования — он спросит. Если дизайнер не понимает, кто отвечает за мелкие улучшения UX — он ждёт.

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

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

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

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

Сопоставьте решения, которые всё ещё остаются за основателем

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

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

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

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

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

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

Затем назначьте каждое решение, не относящееся к основателю, человеку, который ближе всего к работе. Указывайте имена, а не команды. «Инженерия» — расплывчато. «Марта утверждает тайминг rollout для backend‑изменений до $2,000» — понятно.

Эта карта быстро выявляет узкие места. Она даёт команде не просто разрешение, а владение.

Превратите повторяющиеся согласования в правила

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

Начните с назначения одного владельца для каждого типа решения. Продукт может владеть изменениями объёма внутри текущего спринта. Инженерия — техническими решениями в рамках согласованных лимитов стоимости и надёжности. Customer success может одобрять goodwill‑кредиты до установленной суммы. Если двое считают, что владеют одним и тем же решением, на самом деле никто не владеет.

Бюджетные лимиты убирают много ожиданий. Руководитель может утвердить новый инструмент до $300 в месяц. Дизайнер может протестировать панель пользователей до $500. Инженерия может провести короткий proof of concept, если это вписывается в бюджет спринта. Маленькие ставки должны двигаться быстро.

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

Запишите несколько случаев, которые по‑прежнему идут к основателю:

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

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

Это не убирает суждение основателя. Это сохраняет его для действительно важного.

Установите лимиты, которыми можно пользоваться без спроса

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

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

Один простой набор выглядит так:

• Продукт‑менеджер: изменения до 4 часов работы, без новых трат, без изменения обещаний клиентам
• Инженерный лидер: исправления и технические решения до 1 дня работы, траты на инструменты в рамках установленного месячного лимита
• Дизайнер: визуальные обновления, не влияющие на поток, цены или юридический текст
• Основатель: цены, найм, контракты, позиционирование бренда, серьёзные изменения roadmap и всё, что связано с юридическим или доверительным риском

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

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

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

Реальный пример из небольшой продуктовой команды

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

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

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

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

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

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

Через пару недель команда почувствовала разницу. Меньше задач застревало в Slack. Релизы перестали скапливаться в конце недели. Правка текста, перестановка бэклога или покупка софта заняли минуты, а не полдня ожидания одобрения.

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

Ошибки, которые поддерживают очередь

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

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

Ещё одна ошибка — передать владение без бюджета или лимитов. Основатель говорит менеджеру: «Теперь это ваше», но не говорит, сколько тот может потратить, какие компромиссы допустимы и когда нужно эскалировать. Это не настоящее владение. Это заёмная ответственность с неясным риском, поэтому люди продолжают сначала спрашивать.

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

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

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

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

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

Двухнедельная проверка

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

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

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

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

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

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

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

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

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

Затем распределите эти решения по четырём корзинам:

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

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

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

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

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

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