Продукт

Забавный рабочий кейс. Один клиент Finom'а в LinkedIn написал достаточно неприятный пост по поводу того, что наш AI неплохо работают. Дальше команда маркетинга попросила меня ответить. Я ответила и рассказала про фичи, которые у нас уже были запланированы и которые решат его боль. Потом этот клиент начал со мной такое публичное общение в LinkedIn. Он меня отмечал на каких-то своих постах и говорил, что нам нужно сделать Public MCP connection сделать. На самом деле уже вот в этот момент мы проходили ревью в ревью Anthropic и OpenAI. Сегодня ревью прошло и коннектор Finom публично доступен - многие менеджеры наши менеджеры написали про это (и я тоже). И вот этот клиент публикует у себя пост - «Блин, как круто, вы такие молодцы». Что мы послушали, сделали - и вот так и должен работать продукт. Как-то так здорово получилось, что подключились совместно продукт и маркетинг. Забавная просто случайность, которая в итоге привела к тому, что клиент счастлив - еще и публично об этом рассказал. Люблю такое.

Выживет ли SaaS-проект с ИИ? «SaaS-апокалипсис» — преувеличение, примерно 10-20% SaaS-компаний находятся под угрозой исчезновения Разделим угрозы на две группы: атаки на предложение (supply) и на спрос (demand). Атаки на сапплай: 1. Клиенты сами вайбкодят нужный им продукт 2. Конкуренты быстро достигают паритета фич 3. ИИ ускоряет развитие open-source-решений 4. Крупные платформы и системы учета встраивают ваши функции бесплатно 5. Агентства создают кастомное ПО по цене SaaS-подписки 6. ИИ-модели поглощают часть вашего функционала Атаки на спрос: 7. ИИ разрушает бизнес-модели ваших клиентов 8. Сокращается число рабочих мест и платящих «seats», потому что ИИ-агенты заменяют сотрудников 9. Исчезает сама потребность в категории ПО — например, в сервисах тестов для найма 10. Человеческих операторов заменяют автономные ИИ-агенты 8 защитных «рвов» (moats), которые работают Чтобы выжить, SaaS должен опираться на то, что трудно скопировать: 1. Доверие и бренд. Клиенты и партнеры рекомендуют продукт, потому что знают и доверяют ему. 2. Система записи. Продукт становится основным источником данных, в который «зашиты» ежедневные операции. 3. Право на действие. ПО не просто советует, а выполняет транзакции: платежи, обновления, изменения. 4. «Никто не проверяет вашу работу». Доверие к результату настолько высоко, что клиенты не перепроверяют его 5. Официальные одобрения. Лицензии, сертификаты и соответствие регуляторным требованиям, которые конкурентам сложно получить. 6. Сетевой эффект. Весь бизнес или команда должна перейти на продукт одновременно — это резко повышает стоимость переключения. 7. Петля обучения. Каждый новый клиент делает систему умнее и полезнее для всех остальных. 8. Тяжелое обслуживание. Сложная инфраструктура, которую мучительно поддерживать — например, обход спам-защит и блокировок, — становится преимуществом.

Новые статьи от гаражистов на 🔤🔤 👉 Как мы сделали мобильные релизы более предсказуемыми без потери скорости поставки Release Manager Саша рассказал, как за квартал перестроил предрелизное тестирование: перенес Google Play Review на более ранний этап, ввел обязательное подтверждение тестов до Code Freeze и подключил QA Community к ревью сценариев. Вместо 10–12 человек теперь тестируют трое, а crash-free rate вырос с 99,23 до 99,66%. 👉 Data-driven или data-hopeful: зачем аналитике становиться системой Руководитель продуктовой аналитики Олег разбирает, как понять, что команда data-driven, а не data-hopeful. Его команда собрала матрицу зрелости из семи доменов, оценила 16 команд и превратила результаты в планы развития, по сути ИПР, только для команды. #GarageEight_habr

Новое видео на ютубчике: Типы и свойства работ Если у вас есть продукт — ваш продукт может выполнять разные работы [задачи] людей. В зависимости от типов и свойств этих работ, вы можете получать разную бизнес-ценность. Из этой лекции вы узнаете: • Шесть типов работ и шесть свойств работ, и зачем вам знать все типы и свойства. • Как находить «налоговые работы» и как они влияют на клиентский опыт и отвалы. • Как частотность работ влияет на повторные покупки и почему важно учитывать это при выборе работ и сегментов. • Как задействовать «виральные работы», чтобы получить виральный рост продукта. • Как не повестись на фантазии людей о том, что они не будут делать и не потратить деньги на продукт, который не будут покупать и почему в исследованиях важно смотреть на реальные действия клиентов в прошлом, а не их планы 🔗 Смотреть видео на ютубе

Вчера встречал жену с поезда после долгой дороги. Решил купить ей кофе, минут за 15 до прибытия. Поезд задержали ещё на 20. Сижу, стаканчик стоит на стуле. До приезда остается минут пять, беру стакан и иду к поезду... и тут весь кофе оказывается на моих джинсах, куртке и кроссовках. Хорошо, что за полчаса он успел немного остыть. И вот стою я в мокрых штанах и думаю: кто виноват? 1. Продакт Starbucks, который отвечает за стаканчики. Сценарий "купил и сразу выпил" предусмотрели. А сценарий "купил другому человеку и ждёшь"? Если у стаканчика есть ограничение по времени использования, хотелось бы узнать о нём до того, как отвалится дно. 2. Экологи. Может, стаканчик настолько экологичный, что начал разлагаться прямо во время использования? Может под их влиянием компания убрала последние нанометры полиэтиленового покрытия, и оставшаяся бумага просто размокла за 30 минут. Вообще хотелось бы сначала допить кофе, а уже потом спасать планету. 3. Железнодорожная компания. Приехал бы поезд вовремя, наверно мы бы успели выпить кофе. А так внешняя зависимость сломала весь пользовательский сценарий. Почему оторвалось дно, я не знаю, может просто попался бракованный стаканчик. Со мной такое впервые. Но получилось обидно: хотел встретить жену с кофе, а встретил в кофе. Кого зовём на разбор инцидента? Вариант "сам виноват" просьба сопровождать ссылкой на инструкцию к стаканчику.

Tokenmaxxing через BB: выжимка эфира Спасибо всем, кто залетел! К сожалению, в зуме был лимит 100 человек, поэтому выиграли те, у кого самые быстрые пальцы на Диком Западе. Эфир получился огонь, вот выжимка 👇 Что такое BB Бесплатная IDE для агентов, которая собирает сама себя. Подключаешь несколько аккаунтов Claude и Codex, и она сама роутит между ними. Не хватает фичи - одним промптом генеришь плагин, и он сразу появляется и на десктопе, и в мобилке. Ребята сделали фундамент: треды, общение между ними, плагины, автоматизации. Остальное каждый допиливает под себя. Мои плагины (гитхаб) - Account usage - сколько лимитов осталось и когда ресет. С него все и началось - Canvas - кидаешь скрины и оставляешь заметки прямо на них. Агент видит, какой коммент к какой картинке, и фидбек на UI становится в разы точнее - Superhuman - zero inbox для тредов. Каждый тред - это задачка: готово - в архив, ждет чего-то - уходит в снуз и пропадает, пока снова не понадобится. Плюс делает BB удобным на телефоне Рабочий подход такой: сделано хорошо - берешь чужое, сделано так себе - за пару промптов делаешь, как нравится. Мой сетап Все крутится дома на Mac Mini, а я подключаюсь с ноута или телефона. Агентам дал браузер (Aside), чтобы сами заводили аккаунты, создавали ключи и тд. Пришла идея по дороге за кофе - сразу отгружаю с промптом «параллелизируй максимально, не жалей токенов». Агент сначала присылает скрины, что все работает, а в конце кидает ссылку на окружение, где я могу убедиться сам прямо с телефона. Параллельно держу до 10 тредов, больше голова не вывозит. Каждый сам запускает своих сабагентов. Треды умеют общаться между собой. Делали бенчмарк: один тред гоняет модели, второй оформляет результаты на сайте. Поменялись данные - первый пишет второму «иди поправь». А в Тесле открываю BB в браузере, включаю hands-free режим на GPT Live и голосом спрашиваю, что там по тредам 😎 Workflows Это скрипт, который дирижирует агентами. Не промпт «сделай план, потом код, потом проверь», который модель может и проигнорить, а настоящий код: этот шаг делает Codex, этот - Claude, этот - дешевая модель, и цикл крутится, пока ревьюер не скажет ок. У Дениса Неклюдова из Google коллеги кидают таски в канбан, отдельный тред их разбирает и запускает нужный workflow. Для фронта план пишет Codex, код - безлимитный GLM, а скрины из браузера проверяет мультимодальная модель. Не прошло - новый круг. У Кирилла Потехина из Adapty весь процесс живет в Linear: у агента там свой юзер, менеджер ведет план, исполнитель пишет код и тесты, а ревьюит модель другого провайдера. В main только после зеленого CI и апрува человека. Linear тут просто входящие, а workflow - рецепт, как делается каждая таска. Ссылка на видос: https://youtu.be/-ly—GQUPqs

Опенсорс фреймворк от CopilotKit для Intelligent UI, и он уже в топ-5 трендов GitHub 🔥 Идея в том, что агент отвечает на запрос не текстом, а живым интерфейсом: интерактивными графиками, 3D-сценами, формами, симуляциями и визуализациями алгоритмов. Всё рендерится в песочнице прямо в чате. Под капотом Next.js 16 с React 19, бэкенд на LangChain Deep Agents, который подгружает визуализационные скиллы по требованию, и отдельный MCP-сервер. Через него дизайн-систему и сборщик HTML можно подключить к Claude Desktop, Claude Code и Cursor. Лицензия MIT, запускается командами make setup и make dev. В анонсе пишут про работу с любым LLM и любым агентным фреймворком. В README по умолчанию стоит Claude, для OpenAI достаточно ключа, а для остальных провайдеров нужно править модель в коде. Слабые модели, по словам авторов, часто ломают вёрстку. Авторы уверяют, что к 2027 году такой агентный слой будет в каждом приложении. Спорно, но направление понятно: интерфейс всё чаще генерируется под задачу, а не рисуется заранее. Источник: https://github.com/CopilotKit/OpenIntelligentUI @ai_machinelearning_big_data #ui

Эта штука продолжает вируситься. 0$ на рекламу и спонсорство. Воронка: • 2 820 посетителей • 1 048 регистраций • 269 скачали карточку • 60 опубликовали пост (в реальности думаю 70+, отмечают не все) Но самое интересное - кто именно публиковал. Почти все - небольшие LinkedIn-инфлюенсеры плюс около 10 авторов покрупнее: • В среднем 24 тыс. подписчиков • Суммарно 1.4 млн подписчиков • Суммарный охват этих авторов: ~208 млн показов за год Если бы мы покупали такую рекламу: • 60 спонсорских постов у авторов такого калибра стоили бы от $30-40k+ При этом забавно: я изначально думал, что механика может завируситься, но предыдущую версию мы выпустили слишком поздно и без вау-эффекта (вылизанной анимации). Итог - ноль виральности. В этот раз докрутили визуал, и люди сами захотели этим делиться. Виральность никогда не гарантирована, но её точно можно инженерить.

Продал рекламу в канале и сделал ИИ-скилл для продажи рекламы Так как я уже 20 лет работаю в рекламе и на собственной шкуре (а также на шкуре моего DGX Spark) ощущаю всю радость от оформления документов на рекламу в агентстве, то я очень сильно не хотел связываться с размещением рекламы у себя в телеграм-канале: маркировка, ОРД, подготовка договоров, напоминания сделать скриншоты статисткии…. бррр. Но там где есть тонна рутины удобно делать скилл для агента: пусть он мне напоминает собрать статистику и выслать акт. 😀 Вуаля, скилл для рекламы у блогеров

🦀 Так как у меня репозиторий со скиллами называется polyakov-claude-skills, то когда мы с коллегами по цеху выбирали называние скилла, то придумывали, как бы сделать его максимально непривлекательным для бана, был вариант sber-bloggers-ads-skill

В общем я собрал воедино свой скилл для документов (тот самый лаконичный скилл, который для создания документа вообще не требует контекст), найденные правила по работе с маркировкой рекламы, дополнил это инструкцией, погонял тесты на GTP Luna High и Kimi K3 — работает, ведет работу по созданию договоров и счетов. Лол, я даже разработку УПД в формате XML для отправки по ЭДО туда добавил. 🔗 Ссылка на скилл: https://github.com/artwist-polyakov/polyakov-claude-skills/tree/main/plugins/blogger-ads-skill/skills/blogger-ads-skill Работает в Claude Code/Cursor/Codex/BB и любых других популярных обвязках. Можно даже в скиллы клоду отправить. 🚀 Как бы я хотел чтобы это развилось Если вы тоже покупаете или продаёте рекламу в блогах, если вы обладаете экспертизой в этой области — я буду очень рад вашему контрибьюту. Кидайте issues / PR с предложениями, я оперативно обрабатываю. Просто затестите скилл, сравните с теми договорами которые получаются у вас сейчас и пишите запросы или усовершентсвуйте свой собственный процесс работы. А ведь если у нас уже есть коннекторы к телеграм, нужно только немного подождать MCP Диадока и всё рекламу можно будет продавать агентами! 🤦🏻‍♂️ Код писала Astra ночь, а потом я правил его два дня В разработке скила заметил неприятную особенность фронтирных моделей OpenAI. Они совершенно не понимают, что логические части можно отдать агенту, а не коду. В результате скилл был на 30 000 строк кода, и скрипты на питоне проверяли в нем различные эвристики уровня: совпадает ли номер договора и основание в счёте и т д. Вся это радость была тщательно покрыта тестами. Короче пришлось вычищать эвристиик буквально одиночными промптами. Правда после третьей правки мне уже подсказка в Codex предложила отправить. Astra искать все эвристики, которые можно покрыть умом языковой модели. В общем если у вас есть знакомые блогеры, или рекламные агенты, поделитесь пожалуйста этим постом с ними. В комментариях предлагаю обсудить, какую адскую рутину вы упаковали в скилы? Как дела у вашей бухгалтерии в этом вопросе? ---- Поляков считает — AI, код и кейсы