ASYNC-ONLY — ИНОГДА ЭТО НЕ ПРО ПРОИЗВОДИТЕЛЬНОСТЬ
В заметке про «асинхронный django» главный поворот не в async, а в выборе стратегии изменения системы.
Автор сначала пробовал мягкий путь: гринлеты, совместимость, два режима работы одновременно. Итог предсказуемый для любого продукта: растёт test matrix, сложнее поддержка, дороже каждое изменение. Если у вас есть и старый, и новый сценарий, вы платите за оба.
Потом он выбирает радикальный ход: не сохранять совместимость, а переписать всё на async-only. Это уже не «улучшение функции», а смена архитектурной рамки. Такой подход часто обсуждают в продукте тоже: когда важно не “добавить режим”, а снять дублирование и упростить систему вокруг одного основного сценария.
Интереснее всего мотивация: проект нужен не потому, что async даст вау-эффект, а как полигон для агентного программирования. То есть реальная JTBD здесь — не «ускорить django», а «получить контролируемую среду, где много повторяемой работы и понятный план изменений».
Иногда лучший эксперимент — тот, где польза вторична, а ценность в самом процессе замены старой модели на новую.
В заметке про «асинхронный django» главный поворот не в async, а в выборе стратегии изменения системы.
Автор сначала пробовал мягкий путь: гринлеты, совместимость, два режима работы одновременно. Итог предсказуемый для любого продукта: растёт test matrix, сложнее поддержка, дороже каждое изменение. Если у вас есть и старый, и новый сценарий, вы платите за оба.
Потом он выбирает радикальный ход: не сохранять совместимость, а переписать всё на async-only. Это уже не «улучшение функции», а смена архитектурной рамки. Такой подход часто обсуждают в продукте тоже: когда важно не “добавить режим”, а снять дублирование и упростить систему вокруг одного основного сценария.
Интереснее всего мотивация: проект нужен не потому, что async даст вау-эффект, а как полигон для агентного программирования. То есть реальная JTBD здесь — не «ускорить django», а «получить контролируемую среду, где много повторяемой работы и понятный план изменений».
Иногда лучший эксперимент — тот, где польза вторична, а ценность в самом процессе замены старой модели на новую.
БЛОКИРОВКА — ЭТО НЕ ВСЕГДА ПРО САЙТ. ЧАЩЕ — ПРО ПРИВЫЧНЫЙ КАНАЛ ДОСТУПА
Иногда «не открывается сайт» на деле означает: сломался не продукт, а связка контекста, браузера и сетевого маршрута.
Показательный кейс: Chrome не пускает на beget.com, хотя сам сайт жив. Пользователь видит одну боль — «сайт заблокирован», а причина сидит глубже: в политике криптосоответствия браузера и том, как она пересекается с ТСПУ/РКН-фильтрацией. Решение — не «переубеждать пользователя», а изменить один параметр в chrome://flags.
Что здесь важно для JTBD-подхода:
— job пользователя: быстро получить доступ к нужному ресурсу
— pain: непредсказуемая блокировка в конкретной среде
— trigger: рабочая задача срочная, а доступ ломается внезапно
— контекст: один и тот же сайт ведёт себя по-разному в разных браузерах и сетях
Хороший research-вывод тут не «люди ненавидят блокировки», а куда точнее: **пользователь не умеет диагностировать слой, на котором сломалось взаимодействие**. И значит, продуктовые решения должны начинаться с вопроса: где именно в цепочке пользователя рвётся доступ? 🔍
Иногда «не открывается сайт» на деле означает: сломался не продукт, а связка контекста, браузера и сетевого маршрута.
Показательный кейс: Chrome не пускает на beget.com, хотя сам сайт жив. Пользователь видит одну боль — «сайт заблокирован», а причина сидит глубже: в политике криптосоответствия браузера и том, как она пересекается с ТСПУ/РКН-фильтрацией. Решение — не «переубеждать пользователя», а изменить один параметр в chrome://flags.
Что здесь важно для JTBD-подхода:
— job пользователя: быстро получить доступ к нужному ресурсу
— pain: непредсказуемая блокировка в конкретной среде
— trigger: рабочая задача срочная, а доступ ломается внезапно
— контекст: один и тот же сайт ведёт себя по-разному в разных браузерах и сетях
Хороший research-вывод тут не «люди ненавидят блокировки», а куда точнее: **пользователь не умеет диагностировать слой, на котором сломалось взаимодействие**. И значит, продуктовые решения должны начинаться с вопроса: где именно в цепочке пользователя рвётся доступ? 🔍
СПАМ НА WORDPRESS: КОГДА БОЛЬШЕ НЕТ СМЫСЛА ПЛАТИТЬ ЗА «ЗАЩИТУ»
Cloudflare заблокировали, DDoS-Guard стоит как крыло от самолёта, а .htaccess с тысячами IP уже сам начинает тормозить сайт. В какой-то момент задача меняется: не «поставить сервис», а «сделать защиту, которая не ломает продукт и не съедает бюджет».
Что здесь показательно:
— white/black list по IP — базовый контроль без лишней магии;
— фильтрация по User-Agent — отсечение очевидного мусора;
— защита комментариев — точка, где спам бьёт чаще всего;
— Redis-кэш — чтобы сама защита не стала новой проблемой.
Это хороший пример JTBD-логики в инфраструктуре: пользователь «нанимает» не Cloudflare, а отсутствие спама, предсказуемую нагрузку и управляемые расходы. Если текущий инструмент не закрывает job без побочных эффектов, появляется свой плагин. Не потому что хочется писать код, а потому что альтернативы перестали работать. 🔧
Cloudflare заблокировали, DDoS-Guard стоит как крыло от самолёта, а .htaccess с тысячами IP уже сам начинает тормозить сайт. В какой-то момент задача меняется: не «поставить сервис», а «сделать защиту, которая не ломает продукт и не съедает бюджет».
Что здесь показательно:
— white/black list по IP — базовый контроль без лишней магии;
— фильтрация по User-Agent — отсечение очевидного мусора;
— защита комментариев — точка, где спам бьёт чаще всего;
— Redis-кэш — чтобы сама защита не стала новой проблемой.
Это хороший пример JTBD-логики в инфраструктуре: пользователь «нанимает» не Cloudflare, а отсутствие спама, предсказуемую нагрузку и управляемые расходы. Если текущий инструмент не закрывает job без побочных эффектов, появляется свой плагин. Не потому что хочется писать код, а потому что альтернативы перестали работать. 🔧
ВИДИМОСТЬ В НЕЙРОВЫДАЧЕ — ЭТО ТОЧНО JOB?
Пока рынок массово «оптимизирует под ИИ», стоит остановиться и проверить: какой реальный job мы вообще пытаемся закрыть.
Часто за запросом «хочу быть в нейровыдаче» скрываются разные потребности:
— снизить CAC;
— забрать demand у конкурентов;
— стать заметнее в категории;
— не отстать от рынка.
Но это не один job, а четыре разных мотива. И у каждого — свой контекст, свои триггеры, свои метрики успеха.
Ключевой вопрос для исследования не «как попасть в ответы нейросети?», а:
**когда и зачем клиент вообще ищет ответ через ИИ, а не через поиск, сайт, рекомендации или менеджера?**
Если такого поведения у вашей аудитории нет — вы оптимизируете не под пользователя, а под хайп.
Перед GEO-оптимизацией я бы проверил 3 вещи:
1. Есть ли у клиентов сценарий «задаю вопрос ИИ вместо поиска»?
2. На каком этапе воронки это происходит?
3. Что человек хочет сделать после ответа — купить, сравнить, сократить выбор?
Без этого «видимость» легко превращается в красивую метрику без продукта. 🤖
Пока рынок массово «оптимизирует под ИИ», стоит остановиться и проверить: какой реальный job мы вообще пытаемся закрыть.
Часто за запросом «хочу быть в нейровыдаче» скрываются разные потребности:
— снизить CAC;
— забрать demand у конкурентов;
— стать заметнее в категории;
— не отстать от рынка.
Но это не один job, а четыре разных мотива. И у каждого — свой контекст, свои триггеры, свои метрики успеха.
Ключевой вопрос для исследования не «как попасть в ответы нейросети?», а:
**когда и зачем клиент вообще ищет ответ через ИИ, а не через поиск, сайт, рекомендации или менеджера?**
Если такого поведения у вашей аудитории нет — вы оптимизируете не под пользователя, а под хайп.
Перед GEO-оптимизацией я бы проверил 3 вещи:
1. Есть ли у клиентов сценарий «задаю вопрос ИИ вместо поиска»?
2. На каком этапе воронки это происходит?
3. Что человек хочет сделать после ответа — купить, сравнить, сократить выбор?
Без этого «видимость» легко превращается в красивую метрику без продукта. 🤖
ИИ УЖЕ ЧИТАЕТ ВАШ САЙТ. ВОПРОС — ПО КАКИМ ПРАВИЛАМ?
Раньше было просто: robots.txt говорил, кого пускать в индексацию, SEO — как попасть выше в выдаче, а пользователь был финальной точкой маршрута.
С LLM-агентами появилась новая аудитория: не человек, не классический бот, а «читатель-посредник». Он может:
— собрать контекст со страниц,
— пересказать его в ответе,
— действовать без клика в ваш интерфейс.
И тут старые правила становятся недостаточными. Если сайт открыт для робота, это не значит, что он должен быть открыт для агента. Если страница индексируется, это не значит, что ее можно свободно использовать для генерации ответа.
Появляется вопрос JTBD-уровня: не «как закрыть доступ», а «какой job выполняет этот агент и в каком контексте ему можно помогать?»
LLMs.txt — попытка добавить слой явных инструкций для машин, которые читают сайт не как каталог страниц, а как источник смысла 🤖
Для research-команд тут интересный сдвиг:
не только кто приходит на сайт, но и кто теперь делает выводы вместо пользователя.
Раньше было просто: robots.txt говорил, кого пускать в индексацию, SEO — как попасть выше в выдаче, а пользователь был финальной точкой маршрута.
С LLM-агентами появилась новая аудитория: не человек, не классический бот, а «читатель-посредник». Он может:
— собрать контекст со страниц,
— пересказать его в ответе,
— действовать без клика в ваш интерфейс.
И тут старые правила становятся недостаточными. Если сайт открыт для робота, это не значит, что он должен быть открыт для агента. Если страница индексируется, это не значит, что ее можно свободно использовать для генерации ответа.
Появляется вопрос JTBD-уровня: не «как закрыть доступ», а «какой job выполняет этот агент и в каком контексте ему можно помогать?»
LLMs.txt — попытка добавить слой явных инструкций для машин, которые читают сайт не как каталог страниц, а как источник смысла 🤖
Для research-команд тут интересный сдвиг:
не только кто приходит на сайт, но и кто теперь делает выводы вместо пользователя.
ШАНС НА РОСТ — ЭТО ЕЩЁ И АЛЬТЕРНАТИВА НАЙМУ
Интересный кейс из продуктового кластера: вакансию системного аналитика закрывали не только рынком, а внутренним ростом. Смысл простой — сначала понять, кого можно дорастить внутри, а не автоматически открывать поиск снаружи.
JTBD здесь читается довольно чётко:
когда у команды растёт нагрузка и качество анализа становится узким местом, ей нужен способ быстро закрыть роль без длинного цикла найма, онбординга и риска промаха.
Что важно для такого подхода:
— увидеть сотрудников с потенциалом до того, как они «застряли» в текущей роли;
— дать понятный маршрут развития, а не абстрактное «у тебя есть потенциал»;
— встроить рост в операционный процесс, а не в разовые героические решения.
Это полезно не только для HR. Для PM и руководителей это способ снизить зависимость от внешнего рынка и быстрее закрывать критичные разрывы в компетенциях. Для сотрудников — шанс получить новую роль без прыжка в неизвестность 🔍
Интересный кейс из продуктового кластера: вакансию системного аналитика закрывали не только рынком, а внутренним ростом. Смысл простой — сначала понять, кого можно дорастить внутри, а не автоматически открывать поиск снаружи.
JTBD здесь читается довольно чётко:
когда у команды растёт нагрузка и качество анализа становится узким местом, ей нужен способ быстро закрыть роль без длинного цикла найма, онбординга и риска промаха.
Что важно для такого подхода:
— увидеть сотрудников с потенциалом до того, как они «застряли» в текущей роли;
— дать понятный маршрут развития, а не абстрактное «у тебя есть потенциал»;
— встроить рост в операционный процесс, а не в разовые героические решения.
Это полезно не только для HR. Для PM и руководителей это способ снизить зависимость от внешнего рынка и быстрее закрывать критичные разрывы в компетенциях. Для сотрудников — шанс получить новую роль без прыжка в неизвестность 🔍
БОЛЬШЕ НЕ НУЖНО «ПОДБЕРУ ПЛАГИНЫ ПО ХОДУ»
Когда человеку надо быстро собрать сайт на WordPress, у него редко есть запрос на «архитектуру». Есть другой job: закрыть базовые сценарии без разработчика и без сюрпризов.
Что видно в таком запросе:
— форма должна не просто отправлять заявку, а принимать файлы, видео, несколько вложений
— первый экран должен продавать через портфолио, а не через текст
— на мобилке фотки должны листаться нормально, а не «почти работают»
— юридические штуки вроде согласия на обработку данных должны быть встроены в поток, а не добавлены потом
Это не про «красивый сайт». Это про набор готовых решений для типовых рисков: потерять лид, сломать UX на мобилке, забыть обязательный блок, потратить часы на кастомизацию.
Хороший продукт для такой аудитории — не тот, где «можно всё», а тот, где нужные возможности уже собраны в один предсказуемый набор 🧩
И тут ключевой вопрос для исследования: что именно пользователь пытается не делать сам?
Когда человеку надо быстро собрать сайт на WordPress, у него редко есть запрос на «архитектуру». Есть другой job: закрыть базовые сценарии без разработчика и без сюрпризов.
Что видно в таком запросе:
— форма должна не просто отправлять заявку, а принимать файлы, видео, несколько вложений
— первый экран должен продавать через портфолио, а не через текст
— на мобилке фотки должны листаться нормально, а не «почти работают»
— юридические штуки вроде согласия на обработку данных должны быть встроены в поток, а не добавлены потом
Это не про «красивый сайт». Это про набор готовых решений для типовых рисков: потерять лид, сломать UX на мобилке, забыть обязательный блок, потратить часы на кастомизацию.
Хороший продукт для такой аудитории — не тот, где «можно всё», а тот, где нужные возможности уже собраны в один предсказуемый набор 🧩
И тут ключевой вопрос для исследования: что именно пользователь пытается не делать сам?
СЕТЕВОЙ ИНЖЕНЕР НЕ МОЖЕТ «ПРИЕХАТЬ ПОСМОТРЕТЬ» НА КАЖДУЮ ТОЧКУ
Когда у компании много офисов, складов и дарксторов, Wi‑Fi-проблема перестаёт быть задачей «для выезда». Нужен быстрый способ понять: что происходит на месте, где слабое место и что чинить первым.
Павел Семенищев из Yandex Infrastructure сделал под это два инструмента: WiProber для Android и WiFi Prober для iOS. По сути — полевой сканер сети, который собирает параметры прямо на локации и помогает инженеру не ехать вслепую.
JTBD тут очень понятный:
— когда связь деградирует в удалённой точке, инженер хочет быстро снять картину сети;
— когда на месте нет времени на ручную диагностику, нужен «комбайн» с коротким циклом проверки;
— когда ОС ограничивает доступ к сетевым данным, важно обойти эти ограничения, не теряя скорость работы ⚙️
Полезный паттерн для продуктовой команды: не «сделать ещё один диагностический инструмент», а убрать трение в полевом сценарии, где решение нужно за минуты, а не после длинного анализа.
Когда у компании много офисов, складов и дарксторов, Wi‑Fi-проблема перестаёт быть задачей «для выезда». Нужен быстрый способ понять: что происходит на месте, где слабое место и что чинить первым.
Павел Семенищев из Yandex Infrastructure сделал под это два инструмента: WiProber для Android и WiFi Prober для iOS. По сути — полевой сканер сети, который собирает параметры прямо на локации и помогает инженеру не ехать вслепую.
JTBD тут очень понятный:
— когда связь деградирует в удалённой точке, инженер хочет быстро снять картину сети;
— когда на месте нет времени на ручную диагностику, нужен «комбайн» с коротким циклом проверки;
— когда ОС ограничивает доступ к сетевым данным, важно обойти эти ограничения, не теряя скорость работы ⚙️
Полезный паттерн для продуктовой команды: не «сделать ещё один диагностический инструмент», а убрать трение в полевом сценарии, где решение нужно за минуты, а не после длинного анализа.
ТЕЛЕГРАМ НЕ РАБОТАЕТ — И ЧТОБЫ МНЕ БОЛЬШЕ НЕ ЗВОНИЛИ
Звучит как шутка, но это и есть нормальный JTBD: не «хочу приложение», а «хочу, чтобы связь просто работала и не приходилось разбираться в батниках».
NetFix — GUI-обёртка для Zapret и TgWsProxy, собранная под очень конкретный контекст: пользователь не хочет лезть в консоль, искать конфиги, вручную обновлять и понимать, что именно сломалось. Ему нужен один понятный шаг вместо цепочки технических действий.
Что здесь сильного с точки зрения продукта:
— полная автоматизация установки и настройки;
— само следит за состоянием;
— само обновляется;
— вместо набора инструментов — одна кнопка.
Это хороший пример, как из технического решения делают продукт: убирают не фичи, а когнитивную нагрузку.
И отдельно радует деталь про ритм-игру 🎮 — когда утилита не просто функциональна, а ещё и запоминается.
Главный инсайт тут простой: иногда «удобство» — это не интерфейс, а снятие всей работы, которую пользователь не хочет делать вообще.
Звучит как шутка, но это и есть нормальный JTBD: не «хочу приложение», а «хочу, чтобы связь просто работала и не приходилось разбираться в батниках».
NetFix — GUI-обёртка для Zapret и TgWsProxy, собранная под очень конкретный контекст: пользователь не хочет лезть в консоль, искать конфиги, вручную обновлять и понимать, что именно сломалось. Ему нужен один понятный шаг вместо цепочки технических действий.
Что здесь сильного с точки зрения продукта:
— полная автоматизация установки и настройки;
— само следит за состоянием;
— само обновляется;
— вместо набора инструментов — одна кнопка.
Это хороший пример, как из технического решения делают продукт: убирают не фичи, а когнитивную нагрузку.
И отдельно радует деталь про ритм-игру 🎮 — когда утилита не просто функциональна, а ещё и запоминается.
Главный инсайт тут простой: иногда «удобство» — это не интерфейс, а снятие всей работы, которую пользователь не хочет делать вообще.
САУНДБАР КАК ТОЧКА АТАКИ
Пока автор пытался просто подружить Linux с Creative Sound Blaster Katana V2X, он наткнулся на куда более интересный job: устройство не только играет звук, но и принимает команды по воздуху.
Что обнаружилось:
— уязвимости позволяют атакующему в радиусе ~15 метров управлять саундбаром;
— не нужно ни сопряжение, ни физический доступ;
— из «домашней колонки» устройство превращается в шпионский инструмент и Rubber Ducky.
Для JTBD здесь важен контекст использования: пользователи покупают саундбар как «безопасный бытовой аксессуар», а не как сетевую поверхность атаки. Но реальные сценарии показывают другое — любая всегда включённая периферия становится частью доверенной среды, пока кто-то не найдёт, как в неё встроиться 🔍
Хорошее напоминание для исследований: смотреть не только на основной job, но и на скрытые входы в систему — какие сигналы, каналы и режимы работы остаются незамеченными пользователем.
Пока автор пытался просто подружить Linux с Creative Sound Blaster Katana V2X, он наткнулся на куда более интересный job: устройство не только играет звук, но и принимает команды по воздуху.
Что обнаружилось:
— уязвимости позволяют атакующему в радиусе ~15 метров управлять саундбаром;
— не нужно ни сопряжение, ни физический доступ;
— из «домашней колонки» устройство превращается в шпионский инструмент и Rubber Ducky.
Для JTBD здесь важен контекст использования: пользователи покупают саундбар как «безопасный бытовой аксессуар», а не как сетевую поверхность атаки. Но реальные сценарии показывают другое — любая всегда включённая периферия становится частью доверенной среды, пока кто-то не найдёт, как в неё встроиться 🔍
Хорошее напоминание для исследований: смотреть не только на основной job, но и на скрытые входы в систему — какие сигналы, каналы и режимы работы остаются незамеченными пользователем.