Саша Капустин про продукт, управление людьми и не только.

Сегодня начал день с того, что вылез из мусорного контейнера. Ну и понятное дело, что до этого я туда залез. Видеть глаза таксиста, который подъехал, и увидел меня в белой майке и кроссовках (а штаны песочные!), вылезающего из помойки, и марширующего к нему – отдельное удовольствие. Ладно не уехал от меня. Заслуженная пятерка и чаевые. В помойке я оказался не из-за ИИ и сокращений в IT, а потому что я выкинул ключи вместе с мусором (а какая была бы статейка!). А сделал я это потому, что у меня кончился запас "прочности" мозгов и я конкретно перегрузился работой, на которой мы за последнее время: 1) запустили за год новый апп для Ростикс (это вообще нифига себе задачка, как бы вам не казалось, что нет) и причем не уронили никаких метрик (вообще шок) 2) прикрутили рекомендашки и начали двигать "всякое МЛьное" в оффлайн, что вообще еще сложнее, чем запустить апп. Кто расскажет мне как проводить АБ тесты на киосках в ресторанах, учитывая что нормально сплитануть надо... Людей (а как идентифицируем, лояльность и логины около 30%?)? Железки? Сессии? Рестораны? Короче, это мясо! 3) перестраиваем в корне историю про гостевой опыт в оффлайн и делаем его ультра-диджитал (хе-хе) и добавляем просто сумасшедший уровень обзервабилити?.. (спасибо AI, да-да...) 4) SLA 99,97 сам тоже не дается на такой огромной махине с немалым RPS 5) полностью перекроили все команды (их много) и процессы вокруг продукта, и занимаемся командами в данных и корп системах И это малая (процентов 15%) часть вещей, которые происходят, и которые я держу в своей уже не совсем продуктовой голове. Еще аудиты, налоги, HR процессы (это тоже у меня в голове, угу). И вот ключи и полетели в контейнер, получается. При этом, я все равно уделяю важную часть нескольким вещам, и буду уделять: 1) я продолжаю учить. Свое свободное время я посвящаю во многом этому, ничего не жду в ответ (правда недавно мне сказали "спасибо, я у тебя учился когда-то, теперь у меня крутая работа и меня ценят, и ты помог туда свернуть". Я был страшно горд собой, если что). Буду читать курс по финтеху в ЦУ в следующем году студентам (адаптированный, тот самый, который делаем с Мишей Колосковым из Авито) 2) я продолжаю учиться. Я разучился решать продуктовые кейсы, и умею только вас тренировать. Начал сам, а то продукт ускользает от меня, и мне обидно. Хотя я шарю теперь во многом больше, но специальность надо держать, считаю 3) у меня был план попасть в пару СД или бордов, который с треском провалился, потому что я лох (зачеркнуто), и не вышло пока упаковать свой УТП, несмотря на прикольный опыт. Я радостно помог паре клиентов на консалте, с треском (и бесплатно) профакал еще парочку, получив опыт "куда не надо идти точно помогать" и "где я точно не помогу" 4) я думаю, как вести канал, чтобы снова сделать его прям продуктово-бизнесовым, и набабахать потом альманах "лучшие продуктовые байки от Капустина" 5) буду скоро выступать на паре крутых конференций: в июле у своих друзей, и в сентябре у других. Там и увидимся Последнее время, не знаю как у вас, ввиду турбулентности рынка и, в целом неожиданных сложностей на нем, у меня пропало четкое понимание "а что дальше", и я действую по налаженной программе, перестраивать которую "на ходу" очень сложно. Надеюсь, получится адаптироваться. А в канал так и буду писать всякое полезное, чтобы помочь в чем-то адаптироваться вам. Пацанский коммит – написать про запуск новой мобилы на живом трафике (делал не я, я рядом стоял) и написать про оффлайн и тесты в нем. Ну и еще хочу статью про гостевой опыт бабахнуть, тоже интересное. И статьи будут, есть еще в загашниках (статья про велосарай выше, кстати, неожиданно зашла многим из вас, спасибо за отзывы!) недописанное, пусть и не собирает лайкасов, и собирает отписки. Ну и интервью хочу вернуть. Жанр хороший. Заходите сами, давайте поболтаем, если у вас есть темы! Ждите, и классного вам вечера!

(часть 4 статьи выше) Начало тут https://t.me/productanddot/334 Культурные изменения 1 Нормализация неопределённости (а я часто про это пишу!). В командах, где bikeshedding процветает, часто есть неявная норма: «хорошее решение должно быть обоснованным по всем параметрам». Это создаёт тревогу перед большими решениями и компенсаторную уверенность в малых. Лидеру нужно явно демонстрировать, что признание неопределённости – признак зрелости, а не слабости. 2 Разделение решений по стоимости обратимости. Джефф Безос описал это как решения «одностороннего» и «двустороннего» входа. Решения, которые можно отменить (двустороннее) – принимать быстро, делегировать, не тратить коллективное время. Необратимые – обсуждать медленно и структурировано. Сделать эту классификацию явной частью культуры команды. 3 Ретроспективный аудит времени. Периодически анализировать: где реально тратилось время команды за последний месяц? На что ушло больше всего синхронного времени? Соответствует ли это приоритетам? Одно только это упражнение часто меняет поведение. Важно, что bikeshedding не означает, что детали не важны. Важны. Плохой нейминг накапливается в технический долг. Плохой UX-копирайт снижает конверсию. Проблема не в предмете дискуссии, а в диспропорции: когда усилие и время не соответствуют весу решения. Кроме того, иногда за тривиальной дискуссией скрывается настоящая проблема. Если команда часами спорит о названии фичи – возможно, она не понимает, для кого эта фича и зачем. Bikeshedding может быть симптомом нерешённого фундаментального вопроса. Как итог скажу, что закон тривиальности Паркинсона описал шестьдесят лет назад то, что до сих пор ежедневно происходит в тысячах команд и я постоянно вижу это у себя в практике, и замечаю за собой. Мы тяготеем к тому, что понятно, безопасно и даёт быстрое ощущение завершённости – и избегаем сложного, неопределённого и рискованного. Это не баг командной динамики, это фича человеческой психологии и попытка показать свою важность, "вставив" что-то ну очень (нет) ценное на совещании, где, как вам кажется, промолчать нельзя. Понимание этого механизма – уже половина решения. Тимлид или продакт-менеджер, способный распознать паттерн в моменте и назвать его вслух, возвращает команде фокус без конфликта и без потери времени. Остальное – вопрос системы: структуры встреч, явных критериев остановки и культуры, в которой признание неопределённости не воспринимается как слабость.

Ну, а что там в практике ? (часть третья статьи выше! Начало тут https://t.me/productanddot/334) Bikeshedding принимает разные формы в зависимости от контекста: В разработке: — Многочасовые code review с комментариями о форматировании вместо обсуждения логики или подготовка тех доков "по формату" — Споры о названиях переменных, файлов, коммитов — Бесконечные дискуссии об инструментах (IDE, линтеры, CI-система), пока реальная задача стоит В продуктовом менеджменте: — Груминг, на котором половина времени уходит на уточнение формулировок в тикетах, а не на приоритизацию — Долгие обсуждения дизайна кнопок на экране онбординга при нерешённом вопросе о стратегии развития продукта — Совещания по планам на квартал, превращающиеся в редактирование описаний фич В управлении: — Совет директоров, принимающий многомиллионное решение за 10 минут и тратящий час на выбор места для корпоратива — Стратегические сессии, захваченные дискуссией о дизайне слайдов А как починить? Перед тем как внедрять практики, нужно признать симптомы: 1 Встречи регулярно заканчиваются без решений по ключевым вопросам, зато с детально проработанными второстепенными 2 Один и тот же нетривиальный вопрос возникает на нескольких встречах подряд без продвижения 3 Участники с наименьшим контекстом в теме говорят больше остальных 4 После встречи у команды ощущение продуктивности, но нет конкретных договорённостей по важным вещам 5 В задачниках много «быстро решённых» тикетов и мало прогресса по ключевым эпикам Структурные практики, чтоб избежать таких "обсуждений не важного" 1 Явное распределение времени по важности. Перед встречей назначайте вес каждому пункту повестки – и буквально: «на этот вопрос – 25 минут, на этот – 5». Публичный таймер резко сокращает тривиальные дискуссии. 2 Метод «достаточно хорошо» (good enough). Для решений с низкой стоимостью ошибки явно формулируйте критерий остановки: «нам нужен любой разумный вариант, а не оптимальный». Это снимает психологическое разрешение на бесконечный спор. 3 Ограничение права участия в дискуссии. Для технических решений ввести правило: только те, кто будет реализовывать или нести ответственность за последствия, участвуют в обсуждении. Остальные могут оставить письменный комментарий заранее. 4 Асинхронный режим для деталей. Детальные вопросы (нейминг, форматирование, копирайт) решать асинхронно в письменном виде. Синхронное время слишком дорого для вещей, которые можно обсудить в комментарии. Фасилитационные техники 1 Именование паттерна в моменте. Когда дискуссия уходит в bikeshedding, прямо назвать это: «Кажется, мы сейчас в велосипедном сарае. Давайте вернёмся к реактору». Общий словарь снижает напряжение – это не критика, это наблюдение. 2 Техника «паркинг-лот» (parking lot). Видимый для всех список вопросов, которые важны, но не для текущей встречи. Даёт участникам ощущение, что их мысль зафиксирована и не потеряется, – и позволяет двигаться дальше. 3 Явное назначение «хранителя фокуса» (scope keeper). Один человек на встрече имеет мандат прерывать обсуждение, которое ушло в детали. Ротация роли снижает ощущение иерархического давления. (окончание ниже)

(часть 2ая статьи выше https://t.me/productanddot/334) ...Разбираемся! 1. Асимметрия когнитивной доступности Человеческий мозг устроен так, что легче рассуждать о конкретном, чем об абстрактном. Выбор реализации, например "что юзаем: PostgreSQL и MongoDB" – это разговор о схемах, запросах, типах данных. Оценка стратегического риска масштабирования на пять лет требует удержания в голове множества неопределённых переменных одновременно. Первое комфортно, второе – когнитивно затратно. Мозг склонен к когнитивной разгрузке: он нативно тяготеет к задачам, где ощущение прогресса достигается быстро. Обсуждение цвета кнопки даёт немедленный выхлоп – решение можно принять прямо сейчас. Обсуждение дальней стратегии развития продукта – нет 2. Иллюзия компетентности и страх исключённости В фуллстек команде каждый обладает разным уровнем экспертизы в разных областях. Когда обсуждается сложный архитектурный выбор, новый член команды, продакт без технического бэкграунда или дизайнер могут не иметь содержательного вклада – и это дискомфортно. Тривиальный вопрос уравнивает: мнение о расположении элементов в интерфейсе или о названии переменной может высказать любой. Участие в дискуссии сигнализирует о вовлечённости и ценности, а молчание – нет. Это создаёт стимул к участию там, где участие легко, а не там, где оно нужно 3. Статусная динамика и безопасное несогласие В иерархических командах не принято открыто оспаривать стратегические решения, принятые сверху. Высказаться о выборе микросервисной архитектуры, которую предложил CTO, психологически рискованно. А предложить другое название для фичафлага– безопасно. Оба несогласия являются актом автономии, но только одно из них несёт социальные последствия. Bikeshedding, таким образом, частично выполняет функцию замещённого инакомыслия: команда находит арену, где можно спорить без риска 4. Эффект завершённости и прогресса Исследования в области поведенческой экономики показывают, что люди переоценивают ценность завершённых действий и недооценивают незавершённые. Закрытый тикет с правкой копирайта создаёт ощущение продуктивности. Три часа размышлений над архитектурным компромиссом не особо, даже если второе принесло в сто раз больше пользы. Этот эффект усиливается в командах, где метрики продуктивности измеряют количество, а не качество решений 5. Коллективный паралич перед неопределённостью Сложные решения содержат неустранимую неопределённость. Сказать это вслух – признать, что команда может ошибиться. Уход в детали создаёт иллюзию контроля: мы не знаем, правильная ли это архитектура, но мы точно можем определиться с дизайном или неймингом переменных, да? Ну, а как лечим? (часть третья ниже!)...

А сегодня вам от меня статейка на тему bikeshedding, или почему команды тратят время на не важное, когда есть реально острые задачи. Статья в 4х частях, и это первая, а остальные ниже. Если вам не актуально, смело скипайте все 4 поста, хотя, как по мне, тема "живая"! Тема остро встала сразу в нескольких моих контекстах: 1 Я часто на совещаниях (всяких уровней) вижу, как коллегия уважаемых специалистов спорит на тему... ну вообще не важную, и уделяет этому большую часть времени встречи, когда на важное времени уже не остается. 2 Команды разработки тратят время на бесконечные технические документы и всякие "а если ..., то что будем делать?", причем весьма в странных кейсах, типа "у нас RPS 100, а вот если будет 1000000 что будем делать?" (а не будет, такого трафика нет просто) 3 Команда продукта бесконечно обсуджает дизайн, а УТП доказанного у продукта нет (один из примеров) 4 Мой друг из крупного бигтеха пожаловался мне на это, с хорошими примерами, когда тех менеджмент просто до смерти долбит "рядовых" по каким то тех докам, вместо реально реализации, до которой еще и не доходит часто. А команда выгорает и демотивируется От чего так выходит? Давайте разбираться в моей мини статье, которую я готовил давно для выступления, и обновил для вас сейчас. Начнем со скучного: с теории. Так откуда взялся термин и причем тут велосипеды? В 1957 году британский историк и теоретик организационного управления Сирил Норткот Паркинсон описал закономерность, которую он назвал законом тривиальности (Law of Triviality). Суть его проста: в организациях непропорционально много времени уделяется вопросам, которые легко понять, и непропорционально мало – тем, которые действительно важны. Паркинсон иллюстрировал это воображаемым заседанием комитета, на котором рассматривались два вопроса: строительство атомного реактора и строительство велосипедного сарая при офисе. Реактор стоил миллионы, имел сотни технических нюансов и был понятен лишь узким специалистам. Комитет одобрил его за восемь минут – члены просто не знали, что возразить. Сарай обсуждался три часа: у каждого было мнение о материале кровли, цвете стен и расположении входа. Термин bikeshedding популяризовал разработчик Поул-Хеннинг Камп в своём письме в рассылку проекта FreeBSD в 1999 году. Он применил его к разработке программного обеспечения, наблюдая, как сообщество часами спорило о незначительных деталях, игнорируя архитектурные решения с долгосрочными последствиями. Важно понимать, что bikeshedding – не проявление некомпетентности. Напротив, он часто поражает именно умные и вовлечённые команды, а причины не совсем тривиальны. Разбираемся! (часть 2 следует далее)

Знаете что я заметил в своей деятельности больше всего в свете развития ИИ? 1. На обучениях я даю уже не теорию просто, а сделал фокус в кейсы и практику. Потому что теория ищется очень легко, а ценность теперь особенно в живых кейсах. Всегда их давал, а сейчас на них все и строю 2. Я больше не гуглю. Ни инструкции. Ни гайды. Ничего, все через умный поиск 3. Стадия Дискавери в товарах («какие колонки лучше для комнаты 20м2») теперь ушла чисто в ИИ сценарий 4. Рутину и всякие скучные материалы готовлю теперь не я 5. Разработчики часто не могут объяснить что они делают и как. И продакты тоже 😂 Это прям из очевидно забавного, я вам скажу. Не считая всякого «накодить что-то быстро» и «найти корреляции в данных». Еще я стал очень сильно хихикать с того, что все братья продакты, кто консалтит, теперь консультанты по ИИ поголовно. И каналы все переименовали даже. И компании свои. Хайп, батюшка, все едет и едет. А у вас как? Что я упускаю?)

"Как ты спокойно выступаешь на +- любые темы?" Частый вопрос от коллег, от частотных слушателей (такие совпадения бывают), да и вообще от всех сочувствующих. Есть три сценария: 1. Я это уже рассказывал. Аудитория другая, тема старая. У меня есть "мастер преза" на 700+ слайдов, из которой я могу собрать +- любой рассказ про продуктовый процесс и его составляющие. И рассказать. Это не сложно, я все делал это сам руками, и помню. 2. Я рассказываю "историю": какой-то кейс, какое-то +- авторское мнение и вообще что-то, что знаю только я. Ясен красен тут не ошибиться, все это превращается в веселый стендап и я этот жанр люблю и практикую: мне нравится, и слушателям, как правило, тоже. 3. Я ВЫСТУПАЮ не спокойно. Не частый сценарий, и, обычно, он происходит тогда, когда я 1) Промахнулся с темой, и плохо встроился к прошлому выступлению (это бывает в обучениях в рамках целой программы). Такое происходит тогда, когда я, по какой-то причине, не уделил внимания проработке именно встраивания себя в программу, ну или предыдущий лектор поступил аналогично. Пару раз выходил, когда все рассказали по моей теме до меня, ну и приходилось на лету переобуваться и уходить от теории к практике, превращая ее в что-то кейсовое или стендап на тему как я накосячил или что-то вот такое. Работает нормально, но очень тяжело на ходу рожать все заново, по-сути. 2) Промахнулся с аудиторией. Самый частый кейс, на самом деле. Я вот вчера, ранее радостно получив бриф на выступление про метрики для инвесторов ("как оценивать стартап, метрики и экономику продукта в частности"), решив что все звучит изи, пришел рассказывать профессионалам рынка (серьезная была аудитория очень) инвестиций что такое CAC/LTV баланс, какие метрики на каких стадиях развития продукта важны и нужны и как собирать аналитику. Это как сварщику про сварку рассказывать: будет интересно, но скорее вам, чем ему :) Пришлось на ходу добавить лейтмотив "я продакт, я инвесторам циферки рисовал, сейчас расскажу на что там смотреть, и где можно кинуть", ну и делать это в течении 30ти минут до выступления, чтобы аудитория совсем не заскучала. Мне понравилось выступление, не понравилась моя подготовка, и очень понравилась аудитория. Какие-то советы, не очевидные, я дать не смогу, вот вам очевидные: • узнайте хорошо аудиторию, запросите профиль. Обычная продуктовая работа, боли / решения, УТП / ЦА и проч • узнайте, как вы встраиваетесь в общую конву дня, что уже рассказывали аудитории и какие были отклики • если что-то пошло не так, рассказывайте про самое важное: про практический опыт, в поле рассказываемой темы, который у вас есть. А если его нет, чего пошли рассказывать :)   • Боитесь? Начните с разговора с аудиторией, чтобы разогреться. Поделитесь своим опытом, авторским мнением, смешной ситуацией по теме и вообще устройте смолл-чат с аудиторией. Помогает мне. Ну или просто скажите "господи какая крутая аудитория, аж страшно". Мне подобное признание помогает снять нервоз. Может и вам поможет. • Репетируйте. Если даже рассказывали 100 раз. Время жмет, будет душно в аудитории, вы поругаетесь с таксистом по дороге, надо быть на 100% готовым. • Ну и понятное дело: надо выспаться до :) У меня после слабого сна вообще не работает голова. Я не могу быстро "переобуваться" и думать, от слова совсем. А может пригодиться. • Не фокусируйтесь на всей аудитории (!!!). Чисто мое из опыта. Всегда будут те, которым скучно. Им не из-за вас скучно, а просто по жизни, например. Всегда будут люди, которые уже знают, что вы рассказываете. Всегда есть те, которым тупо все не нравится. И всегда есть те, которым интересно, которые реагируют, одобрительно кивают и тд. Рассказывайте для тех, кому важно, а они вас поддержат своим вовлечением и реакцией. Понятно, что "терять" аудиторию не надо, вы же на нее работаете, но пытаться угодить всем и реагировать на раздражители – путь к нервам, и плохому рассказу. Будьте благодарным слушателем, это очень помогает тому, кто выступает! А ему сложно. У вас есть какие-то трюки, которыми вы пользуетесь на питчах, выступлениях, лекциях?

А вот и догоняю обещанной презой по экономике / метрикам и вот этому всему. Не знаю, будет ли она вам полезна, и вообще читаемо ли это без моего стендапа в параллели, но я не буду расстроен, если кому-то из вас оно пригодится, а то я давно что-то не выкладывал вам тут чего-то 🙂 Ловите вот тут https://docs.google.com/presentation/d/1St39MV1-6qVuen7k0dSXEiSYD2mopbkMhbWLYPaKCuk/

Сижу занимаюсь лекцией по оценке стартапов, ну а что вы хотели! Я тут все пытаюсь найти время писать, но оно пока не находится. Как так вышло, что в воскресенье я не отдыхаю? Пришли ко мне тут и говорят, а давай расскажем про экономику продукта будущим инвесторам так, чтоб они все поняли, и сразу! Ну а я чего, я и начал готовиться. И как побежали у меня флешбеки вьетнамские перед глазами: цифры с потолка, гипотезы от TAM а не от SAM, отсутствие sanity check'ов при составлении экономики (помню кейс, когда принесли продукт, у котого будет к 2028ому году 260 млн MAU. Круто, но продукт на российский рынок только), экстраполяция на экстраполяции и вообще все, что часто бывает, когда нужно кейс внутри "защитить" и ресурс получить. От этого мне казалось, что будет вдвойне приятно готовить рассказ, на что базово смотреть и как ловить такие вещи. А никак не ловить, только самим полностью погружаться. Вот. Потому что обоснование гипотез лежит чисто на стороне команды, и, если ей доверия нет, то... ну... э... Раскопать подлог, который может сделать хороший продакт менеджер просто нереально, если не проделать полную дискавери работу. Презу я вам сюда выложу, когда закончу. Сегодня, или завтра утром. А пока вот, смешная картиночка с линкеда, чтоб вы знали, что канал еще жив, как и его автор, и еще друзьям скинули, например!

Селф чек продакта, как тема для общения со мной на сессиях, стал все чаще и чаще занимать лидирующие места по числу вхождений в менторских посиделках, уверенно опережая поиск работы, стратегию продукта и карьерную стратегию. И это радует, потому что темы поиска работы уже набили оскомину, стратегию я все еще нежно люблю... но уже так много всего сказал, что прям даже не знаю, что еще добавить. Да и книжки новые не помогают, так как там все уже давно знакомое. Что такое селф чек? Это когда продакт говорит: "Вроде у меня есть беклог, но я пока не понимаю, насколько я вообще молодец. У меня выполняются цели, я понимаю что делать, но что-то мне не понятно, а достаточно ли? А не ждут ли от меня больше?". Если вы задаетесь подобным вопросом, хотя бы периодически, то у меня для вас хорошая новость: вы не остановились в развитии, как продакт, и все еще ищете, где можно сделать больше, чем от вас ждут. Селф чек для меня работает следующим образом: 1. Задаемся вопросом: а какие у меня цели? А какие цели у моего руководителя? А какие цели у компании? Насколько результаты моей работы "бьют" в достижение целей моих сейчас (базовый чек) и в цели руководителя и компании (понимание своего "веса" в рамках подразделения и потенциала для расширения, как ответ на вопрос "а достаточно ли я делаю")? Эти вопрос помогают довольно легко навести прозрачность и сформировать примерное понимание, а достаточно ли у вас амбициозные цели, и какой у вас вообще дальше потенциал к росту. 2. Выполняютлся ли мои цели? Если да, то остался ли "зазор"? Если нет, то какие запуски не дали нужный результат и почему? Тут работает такое: 2.1 Трекшн модель: рискуем на графике времени все свои запуски и ожидания от них за период. По факту запусков мы смотрим на planned vs fact и делаем какие то правильные lesons learned, причем внимательнее именно в случае неудачи. Хотя и удачу, конечно, анализировать нужно. 2.2 Если цель не выполняется, о чем нам скажет пункт выше (по-сути, это просто burndown chart вашей цели по году), то... Все понятно: сидим и ищем проблемы / решения, быстро тестируем, ну и делаем свою стандартную продуктовую работу. А вот если мы понимаем, что цель выполняется раньше, то у нас начинается самая интересная часть работы: у нас остается зазор на то, чтобы попробовать какие-то экстримальные (казино, короче) запуски. И, если у вас с целями хорошо, то у вас на это есть ресурсы и нет рисков и можно заниматься RnD и кайфовать, ну и ждать, что цель поднимут ))) А вот если цели не выполняются, то начинается интересное: вам нужно настолько детально и мелко порезать свои "безумные", ну или просто крупные идеи (в плане стоимости и результата), чтобы без вреда для процесса "делаем гарант выполнения цели" (из начала пункта 2.2) еще и протестировать с минимальными затратами самые важные составляющие этих гипотез. И вот это тоже магия (и мое любимое) работы продакта, когда вы проводите постоянно рефлексию на тему "а могу ли я лучше?", "а какие у меня есть еще идеи?" и "какой у меня есть reason to beleive в потенциал своих идей?" и для ответов на эти вопросы ищете максимально простые и дешевые инструменты для увеличения своей же веры в себя, в конце концов, да и веры компании в вас 🙂 Ну и интересное наблюдение, что ко мне приходят абсолютно адекватные люди, которые имеют абсолютно (ну по мне) адекватный беклог и выполнение целей, но при этом сомневаются в своем весе в рамках компании. Видимо, рыночек давит, что хорошо, потому что продакты стали снова "все делать сами", как было раньше, и плохо, потому что именно так работая я и поседел 😄