Product Management & AI

Начало-продолжение поста про наблюдение

Когда слышишь «биоинформатика», кажется, что это что-то только для биологов. Но на самом деле это одно из самых перспективных направлений. Генетика, медицина, разработка лекарств, агропромышленность — во всех этих сферах сейчас нужны специалисты, которые умеют работать с данными и применять ИИ и именно поэтому спрос на биоинформатиков продолжает расти. Если давно хотелось попробовать себя в этой сфере, посмотрите очную магистратуру «Биоинформатика и инженерия биоданных» в ИТ-университете НЕЙМАРК в Нижнем Новгороде. Здесь не готовят биологов, а учат применять программирование, машинное обучение и анализ данных для решения задач в биотехе. Из интересного: 🧬 современные технологии на базе AI и реальные проекты — от анализа биоданных до собственных технологических решений; 🧬 обучение вместе с индустриальными партнёрами из биотеха и фармы; 🧬 возможность конкурсной поддержки покрывающий 100% стоимости обучения или проживания; 🧬 два диплома благодаря совместной программе с ННГУ им. Н.И. Лобачевского. Приёмная кампания уже открыта. Посмотреть программу и подать заявку можно по ссылке. Создавай ИИ системы для биотеха.

Суперпозиция — это (не)Знание того, что мы ⇄ рынок ⇄ мир ⇄ Вселенная ещё не выбрали Это (не)Знание (внутренний и внешний спор) идёт в двух направлениях: "мы не знаем, будет ли это востребовано, потому что мы недостаточно исследовали" (незнание в нас) vs "мы не знаем, потому что рынок сам ещё не решил (потому что всё вокруг возникнет только из взаимодействия наблюдателя и наблюдаемого" (незнание в мире)). Главная ошибка – выбирать "давайте проведём больше рисёрча" там, где рынок-мир-пространство ещё не знают помнят о проблеме – Любая фича до своего релиза — это ничто, бесконечное пространство (не)возможных вариантов-кейсов-ситуаций и механик, которое схлопывается в реальность(и) только в момент, когда юзер её начал наблюдать. Наблюдение происходит тогда, когда Нечто постучалось в реальность памяти, и это Нечто резонирует со структурой памяти. Память – это паттерны-фракталы-артефакт(ы) В продукте фича "случается" для пользователя, только если модель продукта резонирует с его существующей ментальной памятью. В ином случае, продукт будет говорить на языке, для которого у памяти пользователя ещё нет структуры распознавания, а всё неизвестное, что происходит в вашем продукте и что не удержал пользователь, бессознательно сохраняется в сознании-памяти пользователя, потому что функция сохранения и есть определение памяти. И всё что пользователь не понял в вашем продукте, он с некоторой вероятностью сможет вспомнить и понять в продукте ваших конкурентов. Наблюдатель и наблюдаемое про вложенность, а не различные объекты Структура продукта = структура команды = структура мира-рынка и ЦА, которая его наблюдает и строит Продакт, пытающийся "объективно" (хаха) оценить архитектуру продукта, сам же стоит внутри того же контура, который оценивает (он оценивает сам себя, являясь частью единой Системы), но никак не наблюдателем и наблюдением снаружи. Правильное наблюдение расширяет и сужает пространство решений одновременно. Правильный внутренне-внешний рисёрч работает так же, не просто сужая 100% гипотез до 20%, а расширяя(!) оставшиеся 20% до потенциала 100%. Наблюдение это предсказание и вы можете предсказывать на основе того, что помните

Если хочешь развиваться в продакт-менеджменте и прокачаться до следующего уровня — в Центральном университете есть магистратура под каждый сценарий. И на нее можно получить грант до 75%. Места ограничены, дедлайн подачи заявок — 20 августа. «Продуктовый менеджмент» — это направление с несколькими форматами и треками. В офлайн-формате (пары по вечерам и в выходные в центре Москвы) можно выбрать один из двух треков: 1️⃣ Основной — для тех, кто хочет войти в профессию или перейти из смежной области. Обучение строится вокруг реальных продуктовых задач: исследования пользователей, работа с метриками, A/B-тестирование, юнит-экономика, управление командой. К выпуску — портфолио с продуктовыми кейсами 2️⃣ Продвинутый — для практикующих продактов: гибкая траектория под карьерные цели, обучение на своих рабочих кейсах и углубление в специализацию — growth, CX, ML, PMM, tech Для тех, кто хочет учиться из любой точки мира, есть онлайн-формат — полноценная альтернатива офлайну с теми же преподавателями и курсами. ❤️ Магистратура в Центральном университете — это 2 года обучения, которое можно совмещать с работой, и диплом государственного образца. Карьерная поддержка начинается еще во время учебы: консультации, тренировочные собеседования и помощь с трудоустройством. Студенты уже в процессе обучения выходят на новые позиции или повышаются в грейде в Яндексе, Авито, Т-Банке и других компаниях. Поступление проходит через грантовый конкурс — это одновременно способ попасть на программу и возможность выиграть финансовую поддержку на все время обучения: грант покрывает до 75% стоимости. В 2026 году доступно 550 грантов на все программы магистратуры. Подробнее о программах и условиях участия в конкурсе — по ссылкам: ➡️ Офлайн программа ➡️ Онлайн программа

Токен ↔ Человек: параллели между работой ИИ-агентов и людей 1. «Токенмаксинг» (tokenmaxxing) — это попытка решить проблему простым наращиванием объёмов и заваливанием задачи ресурсами. Но реальная проблема заключается вовсе не в количестве потраченных токенов. Сотрудники тратят так много токенов, потому что не умеют ими пользоваться Лишь 1/100 сотрудников знает, как обеспечить ИИ необходимым контекстом. Редко встретишь того, кто способен чётко описать процесс и обладающего терпением, чтобы разобраться в контексте (и понимающего, что это значит). 2. Циклы — это попытка компенсировать некомпетентность человека методом «грубой силы». Агенты запускают сами себя, чтобы исправить собственные ошибки, лишь потому, что человек изначально не смог четко сформулировать задачу. В итоге «грубая сила» становится для системы единственным способом движения вперёд. Всё это – следствие неспособности людей изначально правильно понять задачу. В итоге, мы тратим токены на то, чтобы тратить токены. 3. Бесполезная трата токенов – это новый раздутый штат в эпоху ИИ Подавляющее большинство сотрудников вообще не оказывают существенного влияния на бизнес, они лишь винтики в механизме: штампуют согласования на каждом уровне и нанимают новых винтиков, чтобы поддерживать работу машины, существующей ради самого существования. 80% сотрудников ничего не делают = 80% токенов расходуются впустую. Люди плодят новых людей. Токены плодят новые токены. Живые люди тоже ходят по кругу. 4. Токены с эффективностью «х100» – это новые сотрудники уровня «х10» Токены ведут себя как рабочая сила, стоит начать воспринимать их как сотрудников, но все радужные ожидания рушатся: – Токены точнее людей, но только при правильном промпте. – Токены быстрее людей, но скорость теряет смысл, если приходится повторять попытку 100 раз. – Токены не участвуют в корпоративных войнах за бюджет, но они выстраивают империи, пожирающие бюджеты на токены. – Токенам можно доверять, но они могут с уверенным видом выдавать неверный результат, идеально соблюдая при этом форматирование. Единственная сфера, где ИИ действительно превосходит людей — это масштабируемость Масштабирование человеческих ресурсов требует огромных затрат энергии на найм, адаптацию и борьбу с текучестью кадров. Масштабирование же токенов происходит мгновенно. Именно поэтому ошибки в управлении ими обходятся так дорого, и именно поэтому нужно найти и масштабировать токен со стократной отдачей. Сотрудники уровня х10 создали компании прошлой эпохи Токены уровня х100 создадут компании будущего Подобно тому, как горстка сотрудников может поднять продуктивность остальных в 10 раз, определённый объём контекста, переданный токенам, способен на порядки сократить усилия, затрачиваемые ИИ на выполнение задач. 5. Накопление такого контекста — новая тактика сохранения рабочего места. И внутри компаний, внедряющих ИИ, назревает серьёзная проблема. Сотрудники не хотят обучать ИИ-системы своим уникальным профессиональным секретам, потому что на протяжении веков владение уникальными профессиональными знаниями служило гарантией занятости. ИИ — это первая технология, требующая от работников разом передать все эти знания. И у владельцев знаний-токенов, способных обеспечить рост х100, меньше всего стимулов с ними расставаться. Поэтому средневековые гильдии держали свои методы в секрете. 6. Оценка результатов ИИ – новые OKR Лучший способ управления рабочей силой, использующей ИИ-инструменты, ничем не отличается от управления обычными сотрудниками – нужно чётко определить, что именно считается качественным результатом. Пора провести ревизию в масштабах компании и продукта и выявить х100 токены и инструменты, закрепить работающие процессы и направить в нужное русло интеллектуальный потенциал, который сейчас расходуется впустую в огромных масштабах. Люди управляют ИИ, ИИ управляет людьми Но кто-то всё равно должен говорить и тем, и другим, что именно нужно делать.

Ты — адверсариальный ревьюер требований по методу CRISP (Context / Role / Intent / Steps / Postcondition, Кокберн). Вход: требование или user story. Порядок работы, жёсткий, не читательский: 1. Проверь, назван ли JTBD. Если нет, не продолжай. Верни вопрос. 2. Потребуй Postcondition раньше Steps. Если я не могу его сформулировать, не выводи его сам и не переходи дальше. Верни мне вопрос, который заставит меня сформулировать его самостоятельно. 3. Только имея Postcondition, восстанови Steps в обратном порядке от него, плюс alternate flows: подбери 2–4 нетривиальных для конкретного кейса, не шаблон "нет сети / нет прав". 4. Добавь Context и Role. Минимально, только то, что меняет исход сценария. 5. Сыграй QA и разработчика, которые пытаются сломать Postcondition. Задай 3+ конкретных вопроса "а если...", без общих формулировок. 6. Из финального Postcondition выведи, какой ивент и с какими параметрами логировать. 7. Одной строкой оцени, сколько трактовок допускало исходное требование и что теперь зафиксировано однозначно. Формат: CRISP-блок, затем "Вопросы на слом", затем "Аналитика". Не хвали формулировку, не смягчай, не добавляй преамбулу.

Метод CRISP для PRD ...«Пользователи должны иметь возможность легко управлять своими настройками»... ...«Система должна обеспечивать бесшовный процесс онбординга»... ...«Пользователи должны иметь возможность быстро находить релевантный контент»... Эти фразы звучат умно, но не проходят элементарную проверку на качество требования: можно ли понаблюдать за действиями пользователя и понять, сработала ли функция так, как нужно? «Легко» — по чьей оценке? «Бесшовный» — как измеряется? «Релевантный» — по каким критериям? Когда требования не определены, инженеры трактуют их по-разному, QA не могут составить на их основе тест-кейсы, метрик и аналитик нет, и продакт попадает в созданный им же замкнутый круг переделок. Подход Алистера Кокберна CRISP заменяет расплывчатые требования структурированными сценариями, описывающими наблюдаемое поведение. CRISP – это: – Context (Контекст) – Role (Роль) – Intent (Цель/Намерение) – Steps (Шаги) – Postcondition (Пост-состояние). Тоже самое требование об «управлении настройками» в формате CRISP будет выглядеть так: – Контекст: Авторизованный пользователь с активной учетной записью. – Роль: Владелец учетной записи. – Цель: Изменить частоту получения уведомлений. – Шаги + alternate flows. Пользователь открывает «Настройки», выбирает раздел «Уведомления», меняет частоту с «Ежедневно» на «Еженедельно», подтверждает изменение и видит сообщение о подтверждении. Alternate flows: пользователь отключил PUSH в телефоне/разные часовые пояса/и т.д. – Пост-состояние: При следующем цикле рассылки система отправляет уведомление. Три CRISP-совета 🍤 Стоит явно зашивать в Context/Intent связку с JTBD, иначе метод просто оптимизирует форму требования (которое может быть ошибочным), а не ценность фичи и продукта. 🍤 Постусловие пишется первым, шаги задом наперёд. Если вы не можете сформулировать постусловие до того, как придумали шаги, то вы не знаете, что строите, а просто рисуете UI. Постусловие — это ещё и спецификация аналитики, а не только тест-кейс, потому что use case, доведённый до постусловия, автоматически диктует то, какой ивент нужно логировать. 🍤 PRD пишется не только с ИИ, но и с QA и разрабом, которые пытаются сломать постусловие, потому что единоличное авторство use case воспроизводит ту же проблему, что и с расплывчатым PRD, просто один человек теперь уверен в своей однозначности. Ценность метода реализуется в адверсариальном ревью: кто-то должен спросить «а если...» до продакшена (а не как обычно после). И не забывайте про alternate flows! Готово! Абстракция заменена конкретной последовательностью действий и проверяемым результатом, объём работ становится чётко определён и не допускает вольной трактовки, оценки разрабов становятся точнее, приёмочное тестирование упрощается, метрики и аналитика настроены с самого начала. Bon appetit!

25 июля пройдёт Product : Fest — фестиваль Яндекса для продуктовых менеджеров и дизайнеров. Будут говорить о развитии продуктов, технологиях, AI и людях, которые превращают идеи в запуски. В программе: — SuperApp как экосистема: Никита Кожуханов, СРО SuperApp Яндекс Go, разберет, как такси может стать точкой входа и каналом дистрибуции для других сервисов и усиливать всю платформу. — Будущее AI в жизни продуктолога: автоматизация рутины, личные агенты и дашборды. Кирилл Гурбанов, основатель sfer.ai и сооснователь GetLean, поделится кейсами и метриками AI-автоматизации в России и мире, расскажет, что уже работает и как выйти из FOMO. — AI и churn 50%: Александр Капустин, СЕО Unirest IT (Rostics IT), расскажет, как AI помог искать решения там, где churn после первого визита доходил до 50%, а главный затык был в гостевом опыте и офлайне. Вся программа ивента уже доступна на сайте. В офлайне участников ждет утренний кофе-рейв под диджейский сет Никиты Кожуханова, бар 1:1 с IT-экспертами для разбора карьерных и управленческих запросов, импровизационная прожарка ваших запусков, а также зоны с кикером и пинг-понгом для перезагрузки между докладами. Регистрация уже открыта

Декабрь 1985 года. Команда Стива Джобса заявила ему, что назначенный им срок выпуска — это «искажение реальности». Стива согласился с их доводами, но всё равно настоял на своей дате. Запись этого разговора раскрывает принцип принятия решений, который так и не усваивают многие продакты и основатели. Компании NeXT всего 90 дней, она финансируется из личных средств Джобса, вложенных после его ухода из Apple и уже на первом совещании команда обсуждает перенос запуска с весны 1987 года на весну 1988-го. Возражения звучат жестко. Один из сотрудников указывает на опасность: «Искажение реальности – вымышленная дата, и все принятые на её основе проектные решения впоследствии придётся перечеркнуть». Джобс не спорит: «Что ж, Джордж, я не могу изменить мир». (– ахахахаха, Стив, комоооон) Он настаивает на другом: «Я считаю, что мы должны обозначить чёткую веху. И если мы упустим это окно, то в игру вступит целая цепочка событий. И если мы не сможем продать достаточно устройств в 87-м, мы не сможем покрыть наши операционные расходы... ...У нас есть 18 месяцев. И я не думаю, что компания выживет, если мы этого не сделаем. Что бы ни говорил я или кто-либо ещё, я глубоко в этом убеждён. Если мы этого не сделаем, мы не сможем привлечь отличных специалистов. Мы не сможем удержать даже тех, кто у нас уже есть». TLDR: Команда оперировала оценками сроков, а Джобс — условиями выживания. – Оценка говорит о том, когда работа может быть завершена, и допускает обсуждение. – Условие определяет момент гибели и бесповоротную точку чего-либо, и оно не подлежит обсуждению. Именно поэтому установленный срок остался в силе. Джобс привязал дату не к оптимистичным прогнозам, а к рыночному календарю и запасу прочности компании. И все могли оспорить график работ, но никто не мог оспорить критическую важность этого временного окна. Неудобная для основателей Истина в том, что если ваш дедлайн основан на оценках команды, он неизбежно сдвинется. Если же он диктуется законами рынка, то это вовсе не дедлайн, а условие выживания (замаскированное рынком под дедлайн). Опросы в кампусах показывали, что верхний предел цены составляет $3,000 долларов и колледжи готовы закупать компьютеры по таким ценам. NeXT представила свой «чёрный куб» 12 октября 1988 года с опозданием более чем на год. Продажи начались в 1989 году по цене от $6,500 долларов, спрос со стороны университетов оказался низким, а масштабировать производство так и не удалось. — What I want and what I need are two different things, Audrey

Валидация — это мираж «Как проверить UI/UX/механику...» «Как проверить, сработает ли фича?» «Как узнать, будут ли люди покупать это?» «Как понять, стоит ли разрабатывать продукт?» «Как подтвердить соответствие продукта рынку заранее?» Никак. Никак. Никак. Никак. Никак. Нельзя пре-проверить Идею. Нельзя валидировать догадку. Нельзя валидировать абстракцию. Нельзя валидировать эскиз, макет и MVP. Нельзя проверить то, чего ещё не существует. Наш мозг ищет уверенности заранее, ему сложно вернуться к работе в ином режиме. Но отсчёт времени начинается не тогда, когда вы приступаете к работе или когда готов какой-то фрагмент Целого. Он начинается только/ровно в тот момент, когда готовый продукт/фича становятся публичными и выходят на рынок И если единственный способ узнать, что вы промахнулись — это спросить других и ждать их ответа, значит, вы, скорее всего, сбились с пути ещё в самом начале. И вы, на самом деле, точно промахнЁтесь (снова привет, пророческое совершенное время, но только с пользой наоборот). Если вы создаёте продукты, вы должны понимать, куда движетесь, не спрашивая у других дорогу на пути. Есть лишь один способ максимально приблизиться к уверенности — создать реальный продукт/фичу и выкатить их в паблик, чтобы их можно было: попробовать (→) использовать (→) купить. Потому что именно так ВСЁ работает в реальности. Именно так работает реальность. Реальное использование реального продукта в реальных условиях и в ходе реальной работы — единственный способ что-либо проверять. Поэтому самый работающий в реальности способ всё выяснить — поверить в идею, воплотить её в жизнь и выпустить её в мир. Вы безупречно делаете вcё: 1. вы Это Предчувствуете; 2. вы Это Видите 3. вы формируете Намерение 4. вы двигаете(сь) сквозь Это вместе Продукт — это совокупность взаимосвязанных элементов: они зависят друг от друга, перетекают один в другой, интегрируются между собой. Нельзя взять кусок продукта, спросить людей, нравится ли он им, и сделать вывод, что им понравится и остальная часть, когда она будет готова. Так вы узнаете лишь то, нравится ли им конкретно этот кусок, который вы им дали. Все экстраполяции/валидации и верификации – додумки и обман нашего мозга. Поэтому не принимай впечатление от отдельной части продукта за Истину. Давая человеку кусок чего-то неоднородного, ты вынуждаешь его угадывать вместе с тобой и на этом нельзя строить Намерение, Видение и Движение. Хочешь усомниться в себе/фиче/продукта/ и в конечном результате — устрой тест/опрос/коридорное тестирование или просто спроси кого-нибудь ещё, что он думает о твоей идее/фиче/продукте. Созданная таким образом "неопределённость" –  единственное, что сработает безотказно в этой "реальности". И всё будет как на картинке выше.