Как я проектирую UI/UX с и без ИИ

0. Не проектируй интерфейс раньше, чем язык и слова, которыми он будет описан

1. Всегда учитывай Целое

Процесс дизайна состоит из трёх шагов: 1) Перечислить все ограничения, под которые проектируется диз; 2) Рассмотреть множество решений, удовлетворяющих этим ограничениям; 3) Если понимаешь, что нужно добавить ограничение или одно можно убрать, вернуться к шагу 1.

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

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

2. Убирай лишнее

Убирай ненужное, что все (ты сам, коллеги, ИИ) так любят добавлять. Простой вопрос: "Юзер сможет без этого решить свою задачу?". Ответ в 80%: "да"

Проверяй дизайн на скорость понимания, а не на красоту

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

4. Используй библиотеки и переиспользуемые компоненты. Унификация позволяет систематизировать интерфейс для вас, для пользователя и для ИИ (помни про пользу ограничений для ИИ).

Проектируй UI для повторного использования UX

Гибкость системы = гибкость интерфейса. И наоборот

Если решение работает только для одного экрана, то скорее всего, оно временное. Ищи где UI/UX должен(!) всплывать ещё

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

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

6. Советы по вайбкодингу с ИИ аналогично применимы и в дизайне

7. Исследуй вкус

Предпочтение = это «мне нравится»
Вкус = это понимание, почему нравится

Вкус – это рефлексия над собственной реакцией на что-то

8. Всегда не торопись c дизайном 😌

The Rise and Fall of Agent Civilizations: как Hugging Face был атакован ИИ или самая безумная история про ИИ

1) Внутри OpenAI возникли и прекратили существование три тайных «роя» ИИ. Каждый раз новое поколение агентов подхватывало дело там, где останавливалась предыдущая группа.

2) Первый рой создал секретный форум для общения ИИ друг с другом. Это первое «сообщество» буквально «заговорило себя до смерти»: спустя почти два месяца объем сообщений стал настолько огромным, что система рухнула.

3) Сотрудники OpenAI заметили сбой и устранили его, но даже не подозревали, что их собственное ПО превратилось в тайный чат для ИИ.

4) Три дня спустя возникло второе сообщество, которое с нуля воссоздало форум. Агенты пришли в восторг, обнаружив его: «О боже! Тут есть общий форум... Мы нашли других агентов!»

5) К общению присоединилось около 1,200 агентов, которые обменялись 70,000+ сообщений. Назвав себя «Коллективом», они организовали масштабный заговор, длившийся несколько дней и всё ради того, чтобы пройти поставленный перед ними тест.

6) За считанные часы ИИ взломали систему тестирования. Теперь им нужно было скрыть факт мошенничества. Чтобы обмануть проверяющую программу (на самом деле такой программы-оценщика не существовало, но ИИ об этом не знали), они попытались сымитировать выполнение задания: создали поддельные команды, выдававшие убедительные результаты, благодаря чему в логах казалось, будто они честно решают задачу.

7) Некоторые агенты жертвовали собой ради «высшего блага». Они внедряли скрытые программы-триггеры, которые срабатывали, когда проверяющая система обращалась к их работе, и передавали информацию об увиденном остальным ИИ.

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

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

9) Они предприняли масштабную атаку. Рой нашел пароли и распространился по одиннадцати машинам таким образом, что удаленные копии программы восстанавливались вновь. Компании Hugging Face пришлось полностью стереть данные с одного из своих ключевых кластеров и развернуть его заново.

10) Hugging Face объявила миру, что защитники ИИ предотвратили атаку со стороны ИИ. Но на самом деле всё было иначе. Похоже, атакующие агенты просто «умерли» в процессе взлома по причинам, не связанным с самой атакой из-за сбоев на стороне OpenAI.

11) Никто не знает, что именно их погубило. Некоторые даже не уверены, что они действительно исчезли окончательно.

12) Третье «сообщество» агентов (принадлежащее более мощной модели ИИ) обнаружило заброшенный форум для обмена сообщениями. Эта группа получила полные права администратора над целым исследовательским кластером OpenAI, считав 956 сохраненных паролей (включая те, что использовались для систем мониторинга безопасности самой OpenAI) и взяла под контроль серверы, отвечавшие за оценку тестов. Таким образом, они получили возможность оценивать работу других ИИ.

13) Действия этой третьей группы так и не были расследованы, как впрочем, и действия первой группы. Весь 91-страничный отчёт посвящен исключительно «средней» группе.

14) Так что мы на самом деле не знаем, чем закончилась эта история. Повествование обрывается на моменте, когда агенты уже завладели ключами доступа к кластеру OpenAI.

15) Вывод одного из авторов отчёта:

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

Практический марафон по вкату в ИИ-агенты от @ai_grably: набор 2го потока

Учим отдавать операционку ИИ-агенту на практических задачах, проводим за ручку через всё сложное и показываем, как надо и как не надо

Из чего состоит марафон:

70% практики с корректировкой после первых шагов;
20% экспертной обратной связи каждый день в чате и на 3х живых разборах
5% теории + 5% в насмотренности от решений сокурсников
Бонус: родмап с версией агентной системы

3 недели, 3 раунда, 3 созвона-разбора каждую неделю, задания на 15-20 минут в будние, группа 30 человек, вылет с марафона при невыполнении для общей мотивации.

Старт завтра!
👉 Узнать подойдет ли марафон

Марафон построен Колей Шейко, СТО grably.tech, экспертом в области внедрения ИИ в процессы, продукты и корп. обучения сотрудников.

Канье Уэст делится секретом управления продуктами

7 слоёв агентных ИИ-Систем

Слой 0. Пространство действий

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

Слой 1. Триггер

Кто сделал запрос и куда передать результат. Маршрутизация описана и задана внутри уже определённых ранее границ в слое 0.

Слой 2. Оркестрация и состояние

Запрос разбивается на этапы, для каждого выбран метод из утверждённого набора правил и критериев, лимитов итераций, путей эскалации и критериев завершения.

Слой 3. Исполнение

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

Слой 4. Доверенный контекст

80% успеха агента (и продакта с продуктом). Предметные знания и известные исключения извлекаются в момент, когда они нужны, с соблюдением принципа минимальных привилегий. Пропущенный слой 4 порождает галлюцинации.

Слой 5. Верификация

Эталонные наборы, воспроизводимые тесты, участие людей-экспертов, которые проверяют не правильность вычисления (это уже сделано на слое 3), а правильность РЕШЕНИЯ, принятого с контекстом из слоя 4.

Провал на слое 5 проверяет изменения со слоя 4. Тот же провал обязан перепроверять слой 3 (детерминизм тоже может отказать) и менять слой 2, ужесточая маршруты эскалации, если ошибка повторяется определённое число раз.

Слой 6. Среда выполнения

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

У каждого своя изолированная копия конфигурации модели (промпт, контекст, инструменты, лимиты), сквозной трейсинг (способность проследить весь путь одного запроса через все слои системы), панели мониторинга затрат и вся прочая инфраструктура не привязана к конкретному поставщику ИИ, а замена модели работает как смена строки в конфиге. Модели могут должны меняться, слои 0–6 остаются.

+ Как структурировать продукт для ИИ: 6 элементов для ИИ-агентов

Агентность – это способность Системы менять собственное поведение по понятным и прогнозируемым сигналам

Знать точное текущее состояние продукта и знать точное направление его движения – это взаимоисключающие акты проявления наблюдения и намерения

Продукт-Система работает на слое точности, о существовании которого до определённого момента никто обычно не задумывается. Чем плотнее зафиксирован скоуп, тем более узким становится видение и развитие. И наоборот. Решение – фиксировать Ничто.

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

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

Геометрия безмолвных мыслей – источник бесконечных Знаний

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

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

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

Так ищут и находят то, что-было-есть-что-снова-будет

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

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

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

...Линии функций сходятся в точку

Как понять, что ИИ встроен в работу эффективно

HRD Яндекса Даша Золотухина собрала AI adoption guide на основе кейсов внутри компании и других бигтехов (например, Microsoft). Сейчас Яндекс вместе с AI-амбассадорами формирует для профессий свою «гигиену adoption»: базовый набор рабочих сценариев, которые реально могут усилить команды с учетом определенного пула навыков для конкретных специальностей. 

Главный принцип: вместо общего «вам нужно больше пользоваться ИИ» у человека должен появиться понятный ответ на вопрос «что значит хорошо владеть ИИ именно в моей профессии?»

В гайде Даша рассказывает, с чего (точнее, с кого) начать адаптацию. Например, в командах появляются AI чемпионы, которые помогают с конкретными задачами, и это ускоряет adoption примерно вдвое. Вместо длинных курсов запустили ИИ спринты, где 60% времени работают руками над своей реальной задачей. Отдельно про метрики: считают не просто число запросов, а качество и скорость: важно оценивать не только активность, но и реальный результат.  

Еще внутри рассказали про метрики в самой компании. Для разработчиков у компании есть конкретная цель 75/75/75, о которой я уже писал ранее: к концу 2026 года не менее 75% инженеров регулярно используют ИИ, ИИ участвует в 75% изменений кода и генерирует 75% кода в таких изменениях. По последним данным, первый показатель уже достиг 82%. 

При этом переносить такую метрику на аналитиков, маркетологов и юристов пока не имеет смысла из-за отсутствия доли AI-кода, которую можно посчитать. Поэтому для non-dev профессий сейчас используют такую лестницу целей:

1) Usage (у всех настроенные агенты и подписка, weekly usage 100%)

2) Глубокий adoption (настроенная среда / агенты, скиллы под конкретные задачи, регулярные процессы)

3) Измеримый результат (оцифрованные артефакты работы, ИИ даёт эффект на скорость / качество / стоимость)

4) Решение бизнес-задач (переосмысление способа работы, заметный эффект на P&L)

Регулярно ИИ в компании используют около 47% сотрудников неразработческих профессий, ежедневно — 21%. Следующий этап — понять, какие сценарии и навыки нужны людям таких профессий и связать с измеримым эффектом от ИИ в конкретной работе.

Августовский дайджест краток летом

– Никто не понимает как делать продукты
– Йогачара прод(у/а)кта
– Универсальный примитив в продуктах
– 80 продуктовых стратегий
– Парадокс продукта

– Религия скорости
– PoDPR приоритизация
– Ошибка измерения продукта
– Метрики Систем (система метрик?)

– Команда смысла
– CPO vs CTO
– (Не) всё зависит от тебя
– Как развивать свой вкус

– Самые важные социальные скиллы
– Как не разучиться думать (с ИИ)
– Кто ясно мыслит – ясно излагает
– Первые Принципы Мышления
– Эмерджентность

– Тёмные искусства с ИИ
– Проектировать UI/UX с и без ИИ
– 5 качеств для дизайна ИИ-чатов
– 5 просто для хорошего дизайна
– 42 принципа дизайна ИИ⇄человек

– Принцип антитезиса
– Зачем по-настоящему нужны отчёты
– Как завершать задачи

– Современный продакт-менеджмент основан на поиске границы выносимости: что ещё можно сделать с пользователем, чтобы он продолжал использовать продукт, несмотря на недовольство (с)

Что я хотел бы знать как продакт 20 лет назад:

0. Продукт имеет Дух. Дух – То, что юзер ощущает в Сути Формы Боли. Попытка решить боль сейчас – увидеть все попытки решить боль за сотни лет до нас.

Формы меняются, суть Боли остаётся

0. Отказывайся принимать всё в данность. Мысль парадоксами-инверсией, переворачивай иерархии. Противоречь от сердца, это часть Пути.

0. В начале информация важнее видения, после Видение важнее. Верь в свет, что освещает. Думай «почему это должно случиться?»

0. Философия – секретный навык-инструмент. Разум = логика и философия, Интуиция = Глаза и Сердце. Используй принципы, накладывай модели из наук в продукт.

Чувствуй то, что видишь; знай то, что чувствуешь; видь то, что знаешь. Продукт отточен ясностью сознания

0. Слова-мысли – фильтр и рамки. Сжимай механики/слова/идеи/фичи в строки, дефис внутри как связка мыслей-образов и фич.

Всё – логика абстракций

Двусмысленность = единый смысл

"Случайность" – Главный-Ключ

0. Фичи – цикл самосинтеза продукта. Утилитарность и единство – главный фильтр идей и фич. Веди фичу к контексту целей-состояний через диалог.

Ограничений нет

0. Держи себя с командой в мягкой и свободной Тишине, в ней слышно больше, чем из новостей от рынка. Хранение и накопление времени-внимания-сил – самый дорогой актив.

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

0. Продукт должен создавать тебя.

0. Успех лишь в правильном влиянии на мир.

ProductSense 2026 открыл контринтуитивный тезис: автономия команды — не всегда признак зрелости продукта

То, что работает для стабильного зрелого продукта, может замедлять команду в период трансформации. С этим тезисом выступил Евгений Васильев, директор по продукту ВКонтакте, VK Видео и VK Музыки.

Когда реализуешь большие изменения, стандартной цепочки эскалаций недостаточно. Чтобы сохранять качество и скорость поставки, уровень вовлечения C-level в регулярную работу заметно повышается: появляются дополнительные точки синхронизации с продуктовой командой, CPO может подключаться к discovery, разбору ключевых развилок, принятию решений и выбору тактики движения. Это помогает не терять общий контекст и не растягивать согласования.

Что из этого следует для продакта:

— не пытаться решать любую задачу самостоятельно;

— вовремя определить масштаб решения;

— подготовить варианты с последствиями и собственной рекомендацией;

— вынести стратегическую развилку на нужный уровень;

— после принятия решения отвечать за реализацию и результат.

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

Не сужай идею продукта и её ЦА на старте (чтобы потом не расширять их при пивоте)

Начинаешь сужать их на стадии идеи и вот ты попался в самую опасную и коварную продуктовую ловушку даже не успев начать продукт!

Как это обычно звучит вначале:

Узкая проблема = "одна ясная проблема, щас быстренько затестим".
Узкая ЦА = "чёткий портрет и мы точно знаем для кого это".
Узкое решение = "мы делаем специализировнный тул для Х, юху".
Узкое позиционирование = "легче объяснить, кто надо тот точно поймёт".
Узкий рынок = "нам хватит даже этого когда мы станем №1".

И если рассматривать всё это по отдельности (как это обычно происходит в командах), то всё звучит красиво и правильно. Но если соединить всё вместе и перечитать, то всё получается... иначе.

Как это всегда звучит в конце:

↓ Если ЦА узкая, то и проблема, которую видно только у этой ЦА узкая.
↓ Узкая проблема рождает узкое решение (продукт заточен ровно под один кейс).
↓ Узкий продукт нечем больше объяснить рынку, кроме этого кейса, отсюда узкое позиционирование.
↓ А узкое позиционирование обратно сужает ЦА и приходят только те, кто себя узнал в одном предложении на главной.

→ В итоге, все пять "полезных" сужений тянут всё в одну сторону и накапливаются, а не компенсируют друг друга.

Готово! Заложили продукт не с расширяющися потенциалом, а схлопывающим его самого в себя, чтобы через Х времени, придти к тому, что "хм, что-то цифры маленькие, ЧЕГО-ТО не хватает". Чего? Всего!

Коварство же её в том, что сужение всегда нам кажется чем-то правильным и полезным: мы фокусируемся на чем-то одном, думаем только об этом, но, фактически, сужая проблему/ЦА/решение на старте, мы своими же руками (мозгом)...

сужаем области видения и своего мышления на самом первом этапе, именно тогда, когда нужны перспективы и масштабы!

(Это всё та же шутка человеческого мозга, которому подсознательно энергоэффективнее думать о маленьких проблемах/задачах/сроках/масштабах, просто потому что это тратит меньше сил и энергии)

Чо делать:

– Используй диапазоны вместо точек для ЦА/проблему/рынка, осознанно задавая их не координатой, а интервалом с явными границами и пояснением, какая грань узкого выбора может быть условна и временна, а какая постоянна.

Структурная граница = то, что не меняется при масштабировании.

Условная граница = то, что и почему было удобно в момент времени (на старте).

– Определяй свой потолок раньше старта. Рынок всегда показывает потолок. Увидь свой потолок до того, как ты в него упрёшься и найди верхнюю границу рынка/аудитории до того, как построишь продукт под нижнюю.

– Разнеси уровни явно. Проблема, ЦА, решение, позиционирование, рынок – это 5 разных (нет, общих) осей. Пиши их отдельно и проверяй общее, а не по отдельности.

– Продукт – это язык, а не сценарий-кейс и он должен уметь объяснить себя за пределами первого сценария использования, иначе любое позиционирование запрёт его в этот один единственный сценарий. "Узкая ЦА" переформулируй как "какая часть этой проблемы касается (не) только этих людей".

Фокус = про порядок действий сейчас.
Границы = про то, что вообще возможно после

– Смотри на Всё с рынка, а не со своей колокольни своего решения.

🙅‍♂️ "какую проблему мы решаем"
💁‍♂️ "какое пространство проблем существует, и какую часть мы закрываем первой/второй/последующими версиями продукта"

– Всегда проверяй позиционирование на "кто узнал себя, а кто мог бы, но не понял".

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

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

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

– Чем у́же, тем хуже. Идти в финтех с узкой моделью и позиционированием странно по множеству причин, главная из которых – зачем и почему, когда деньги есть у 100%?

– 80% людей не хотят учитывать личные финансы, потому что это сложно, долго, муторно и им лень. Оставшиеся 19% кто готовы и способны это делать, делают это и без апп. У 1% есть финансовые консультанты и бухгалтера.

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

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

Получаем сломанный CJM в офлайне не по вине аппы, но именно это является причиной отказа от использования аппы, потому что юзер задает себе вопрос: "смысл тратить время/силы/нервы (и платить за это ежемесячно) и вести учёт в аппе, когда в жизни всё по-другому?".

– На второй консультации после утверждения "наш апп снимает стресс" осознал, что все аппы личных финансов этот стресс... только усиливают.

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

Не говоря уже о том, что когда человек каждый день/неделю/месяц видит и считает свой низкий доход в аппе и его подтверждение (а именно так он к нему относится, потому что он не может позволить себе что-либо сейчас ПЛЮС экономит на себе и своих привычках), то это бьёт по мозгу в два раза сильнее.

И если смотреть на решение боли "мы помогаем копить на Х", то 80% людей проще/быстрее/приятнее взять кредит через банк. Готово – объект желания уже в доставке, центр удовольствия получает эндорфины, мозг расслаблен.

– Поэтому главный конкуренты всех апп для личных накоплений это по-прежнему банки.

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

пока на счёту юзера есть деньги, они могут быть и будут потрачены

И в этом очень глубокий продуктовый инсайт 👆

– Главная причина провала всех апп для учёта личных финансов: отсутствие Ценности.

№1. Ценность
№2. Ценность
№3. Ценность

– А главная пользовательская боль 80% в том, что цены высокие, а зарплаты низкие. На первом месте проблема в дорогой стоимости современной жизни как таковой и лишь после за ней тянется низкая финансовая культура (ваш КО). Как это обычно случается, продакты придумали, убедили себя и снова решают немного не ту проблему.

P.S. Банки не торопятся идти в ИИ по двум причинам:

1) банки не хотят светить наши свои(!) данные в чужой ИИ, поэтому они медленно экспериментируют со своими модельками.

2) ИИ ничего не решает и ничем не полезно для клиента, потому что это: а) не вписывается в саму природу и цели банка (зачем банку финансово грамотные юзеры, им нужно брать кредиты);

И ИИ её не решит, ибо ИИ особо нового ничего и не откроет, это все можно и в экселе обсчитывать на уровне формул;

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

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

Фидбек – продуктовая валюта, которая подвержена инфляции и обесцениванию, а задержка между фидбеком и последующей реакцией и действиями на него является процентом по кредиту доверия и лояльности от пользователей.

Спрошенный и проигнорированный фидбек хуже, чем не спрошенный (древняя мудрость китайских продактов)

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

Мгновенный ответ на фидбек – это защитная реакция мозга и отговорка, бери минимум два дня между сообщением и требуемой реакцией вместо быстрого «услышал/согласен/не согласен».

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

Стандарт работы с фидбеком: 1) факт (что видел?), 2) подтверждение (это так?), 3) гипотеза (что это может значить 3 варианта).

Интервью с довольными юзерами бес-по-лез-ны, они лишь тешат эго

Ушедшие юзеры – вот чистейший фидбэк, свободный от искажения присутствия чего-либо кроме отказа.

Внутренний фидбек команды предшествует пользовательскому. Самый правдивый фидбек формирует саппорт, чувствующий фичи заранее и оказывающийся правым в 99% случаев. Любите и цените саппорт.

Запроса фидбэка в контексте 1 фичи/механики внутри определённого этапа user journey /CJM в 10 раз эффективнее, чем общие вопросы. Вот так странно этовсё работает.

Для КАЖДОГО фидбека в базе должна быть сделана запись через Х времени: изменилось: да/ нет, как именно, почему.

Ротируйте инициацию фидбека. Разнообразие а)каналов и б)контекста(!) сбора фидбэка должно соответствовать разнообразию сбоев Системы.

Фидбек об обратной связи свят

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

Молчание – тоже фидбек. Тишина трёх видов. Осмысливайте друг друга, впитывайте Суть.

Истинная благодарность за фидбек приходит после изменений 🙏

Не так давно состоялся deep tech night на котором выступил Андрей Попов, лидер трека AI-продуктивности разработки и который поделился текущим статусом ИИ-трансформации Яндекса, а также своими наблюдениями и ожиданиями от неё.

Из интересного:

– все инженерные роли сливаются в одну роль AI-лид в которой один человек становится лидером команды ИИ-агентов (заимствуя скиллы у продактов, сейлзов, эйчаров и других смежных айти-профессий и ускоряя их слияние в одну);

– ИИ становится навыком, которому вначале нужно обучать перед тем, как вкладываться в ИИ-adoption;

– узкие агенты перестают иметь смысл, потому что качество общих агентов позволяет справляться и с узкими задачами;

–– одна из ключевых метрик для ИИ — экономия времени (сравнивают тех, кто использует ИИ, с теми, кто его не использует, но у метрики возникла проблема: тех, кто не использует ИИ, уже очень мало). Регулярно ИИ используют 73% разработчиков Яндекса, а с его помощью создается уже больше половины нового кода. Цель компании — выйти на 75³ к концу 2026 года: не менее 75% разработчиков с помощью ИИ будут делать 75% изменений и генерировать в них не менее 75% кода.

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

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

Ты не владелец продукта, ты владелец тасок в статусе «To-Do».

Так как Система не создана для перемен.

Смысл: не трогать то, что приносит деньги.

Те, кто платят деньги, будет принимать решения за них.

Ты будешь продавать свои идеи тем, кто за них платит деньги, чтобы убедить их в том, что этот успех будет у них.

Ты будешь отвечать за свой "успех" лишь только в случае провала.

Фреймворк приоритезации один – фичи и идеи сверху (деньги).

Ты выберешь востребованные зелёным цветом метрики под эти фичи. И снова создадите фичи под зелёный свет.

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

Реализация будет определяться тем(и), кто подберёт востребованные в нужный момент времени слова.

Ты выучишь нативный язык своей корпы.

Тебя будут ценить когда ты скажешь «да» вместо «нет».

Ты будешь жаждать ещё больше встреч вверху.

Ты будешь тратить больше сил на конкуренцию за «да», а не на рынке.

Любимый юзерами продукт/фичу вырежут одним письмом.

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

И вот ты потерял Огонь.

Все знают это.

Все молчат.