Глядя на то как развиваются LLM модели, я как и многие задаюсь вопросом - а что станет с профессией продакт-менеджера в перспективе нескольких лет. Останется ли она, исчезнет или видоизменится до неузнаваемости? Да, вокруг ИИ сейчас много хайпа - одни рассказывают как при помощи Cursor коммитят в прод и ускоряют проверку фич в несколько раз, другие упирают, что модели не могут справиться даже с базовыми задачами бухгалтера по разнесению выписок.
На мой взгляд правы и те и другие. Как говорится, будущее уже здесь, просто неравномерно распределено. Лично я считаю, что при текущих темпах развития LLM моделей и агентов, профессия продакт-менеджера должна очень сильно потерять в функционале и приобрести новый несвойственный ей сейчас функционал.

Если посмотреть на логику развития создания ИТ продуктов, то лет 50 назад программист совмещал в одной роли и дизайнера и продакта и тестировщика, а иногда и бизнес-заказчика. Расслоение на отдельные роли началось позднее и продакт-менеджер был хронологически последней ролью, которая выделилась в отдельную профессию. И кажется, что эта профессия может стать первой, которая начнет обратно сливаться с другими ролями. Текущие ИИ инструменты размывают границу между продактами, дизайнерами и разработчиками, причем в обе стороны. Если продакт в условном v0 или Cursor может сделать лендинг, страницу админки или прототип новой функции в веб-сервисе, то зачем ему дизайнер или разработчик. Аналогично дизайнеры и разработчики с продуктовым мышлением могут полностью заменить необходимость в выделенном продакт-менеджере.

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

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

Как считаете, что станет с продакт-менеджерами в век ИИ? Или считаете, что это пустой хайп и ничего не изменится?

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

Оглядываясь назад могу сделать выводы из этого провала
1. Без самостоятельного продвижения в других каналах, возможностей площадки совершенно недостаточно для успешного запуска краудфандинга. Проблемой для меня было понять, где и как продвигать настольную игру - я не смог найти подходящих телеграм каналов, где можно было бы рекламировать кампанию, при этом прошлая кампания была успешна именно благодаря правильному подбору ТГ каналов.
2. Если на старте кампании собрано 0 денег, то скорее всего так и будет до конца срока кампании.
3. Оптимальнее было попробовать запуск на площадке Crowdrepublic, которая более заточена под настольные игры.
4. Сама игра из-за её тематики с серой моралью возможно не столь привлекательна игрокам. Я даже столкнулся с отказом одной из типографий напечатать пробный экземпляр с формулировкой "начальство запретило печатать такие карты".

Поскольку я сейчас, как вы понимаете, в поисках работы, то решил провести небольшое исследование, а как в 25 году собеседуют на продуктовые позиции. К сожалению, по этой теме нет никаких акутальных исследований, так что попробую стать первым )
Если вы недавно проходили собеседования на продактов, то буду крайне благодарен за ответы. Ну и конструктивная критика по форме и содержанию исследования тоже принимается. Постарался сделать опросник максимально кратким из-за чего некоторые важные аспекты мог упустить.
По итогам исследования результат конечно же опубликую в канале.
А вот и ссылка на опросник https://forms.gle/ERMwVJaaT18Y8At87

Как я (пока) не стал CPO

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

На самом деле я фактически выполнял функционал директора по продукту в B2B направлении, поскольку у всех директоров по продукту основной их фокус был на B2C витрине. А в B2B я делал, что давало наибольший эффект для бизнеса, исходя из оценки потребностей и запросов пользователей, бизнеса и собственных идей продактов. Надо сказать, что ресурсов на продуктовое развитие было крайне мало, поскольку значительные ресурсы разработки уходили на борьбу с легаси платформы (а она на 120% была из легаси), на борьбу с постоянной сменой фокуса у технических руководителей, и внедрение обязательных законодательных изменений, типа новых ставок НДС.

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

Причин, как я их выделяю, может быть несколько
Во-первых, личностный фактор - я привык говорить прямо, без обиняков и было заметно, что это не всем нравится, и культура компании, исходившая от топов, культивировала демонстрирование позиции "у нас все хорошо, никаких проблем, мы все молодцы, заметаем под ковер", даже когда были явные косяки с миллионными потерями.
Во-вторых, географический фактор - я работал на удаленке по отношению к головному офису, а как обычно принято, кто ближе к руководству, постоянно на глазах, тот скорее получит повышение, особенно если в компании не проработаны кадровые процессы. Да, еще можно сказать, что CPO надо светить лицом и идеями перед акционерами, но пока еще самолеты летают, это не является каким-либо ограничивающим фактором.
Я не выделяю, как отдельный фактор свою компетентность для позиции CPO. Трезво оценивая мои харды и софты, мой вижен пути компании в отрасли, поделив все на синдром самозванца, я более чем уверен, что справился бы с этой позицией. Когда компания решила поискать нового CPO на внешнем рынке, то я специально показал паре людей вакансию и они в голос заявили, что она списана с меня и того, что я уже ежедневно делал )

Что можно было сделать иначе, чтобы добиться роста в компании?
1. Действовать более гибко и заранее заручиться поддержкой у ряда топов, в прямых интересах, которых мной развивался продукт.
2. Во встречи с руководством по запросам на повышение добавить больше демонстрации результатов, обоснованности предлагаемой продуктовой стратегии.
3. Чаще светить лицом перед руководством с регулярной демонстрацией результатов.

А что бы вы посоветовали? Как расти в позициях, не участвуя в политических играх? Или это невозможно?

Продукт с памятью

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

Чем такая модель работы продукта полезна пользователям и самому продукту?
Во-первых, ускоряются типовые сценарии взаимодействия пользователя с продуктом, особенно там где по сценарию возникает повторный ввод одинаковых данных. Например, если в поисковой форме тревел сервиса запоминается выбранная дата и конфигурация гостей, то можно избавиться от больше чем половины ручного взаимодействия с этой формой. При этом можно разделить память продукта на неявную, как в примере с формой, так и явную - когда пользователь сам говорит какие данные запомнить - данные платежной карты, персональные данные для покупки ж/д или авиа билетов.
Во-вторых, появляется возможность применять память для выдачи рекомендаций пользователю. Применительно к тому же тревел сервису, это может быть повышение в поисковой выдаче тех отелей, где клиент уже делал бронирования или которые он многократно смотрел в прошлых поисковых сессиях, либо напоминание, что в этот отель вы уже ездили в прошлом году в такие-то даты - давайте повторим. А можно имея информацию о том, что пользователь избегает смотреть, добавлять в рекомендации наоборот те отели, которых пользователь не видел. Например, почему функция дискавери новых видео так хорошо работает на Youtube и плохо у VK - как раз потому, что первые пытаются в информационный пузырь пользователя вставить что-то новое, тогда как вторые этого не делают.

Для внедрении концепции памяти в свой продукт необходимо начать фиксировать следующее:
- Данные, которые вводит пользователь в продукте
- Действия пользователя в продукте, а также отсутствие определенных действий
- Последовательность действий и в какое время они совершались
- Частотность действий

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

А вы замечаете, как продукты используют концепцию памяти и что они запоминают о вас?

Обучаемость больше не нужна

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

Сейчас все ожидают идеального совпадения по опыту, типу продукта, набору требуемых навыков. Это особенно больно бъет по джунам, у которых по сути кроме обучаемости и нет ничего в багаже опыта, но также затрагивает и все остальные грейды. Нет 100% совпадения вашего резюме с вакансией и оно сразу идет в отказ. Иногда доходит до смешного - в требованиях есть условная Jira, а у кандидата указан Яндекс.Трекер, и это тоже служит причиной отказа, хотя формально системы примерно одного уровня и принципа работы, и перейти человеку с одной на другую на пользовательском уровне можно за пару дней.

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

Можно ли с этим что-то поделать со стороны кандидата? Если человек уже в поиске на рынке, то кажется, что нет - только ждать пока ситуация на рынке изменится и снова начнут котироваться кандидаты с потенциалом, способные быстро обучаться, быстро и системно разбираться в новых продуктах и сегментах рынка. А всем остальным можно только порекомендовать внимательно следить за теми требованиями, которые есть на рынке и нарабатывать соответствующий опыт. Ну и чтобы себя не расстраивать отказами, то заведомо не стоит откликаться на те вакансии, где не видите хотя бы 70% совпадения по типу продукта и связанному опыту с требованиями вакансии.

Пока я еще в поисках компании, которой нанести пользу, захотелось понять, а что вообще происходит на рынке труда и сокращений в российских компаниях. Кажется, что в отличии от официальной статистики, что у нас почти нулевая безработица и потребность в миллионах работников, анализ массовых сокращений и увольнений более явно покажет реальное состояние дел в компаниях.
Так появился проект мониторинга увольнений в российских компаниях - сайт Уволены.
На сайте публикую новости об увольнениях и сокращениях, официальную статистику Росстата по уровню безработицы и среднему времени поиска работы кандидатами. Также веду статистику по наиболее массовым сокращениям в компаниях разных отраслей.
Как показывает мониторинг новостей, если компании традиционных отраслей сокращают персонал публично с выполнением всех требований трудового кодекса, то российский бигтех, заботясь о репутации, проводит сокращения непублично, вынуждая сотрудников уходить по соглашению сторон и обычно с недоплатой выходного пособия, по сравнению с требованиями ТК.
Так что, если обладаете информацией о непубличных сокращениях, то анонимная форма на сайте ждет ваших сообщений.

Что надо знать продакту о пайплайне ML обучения

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

Что же надо знать продакту о том как создать и запустить ML модель - пайплайне ML обучения.

Во-первых, нужно сформулировать цели, зачем нам нужна ML модель. Цели формируются через метрики - например, мы хотим повысить скринтайм - время проведенное пользователем за чтением ленты в нашей социальной сети, или мы хотим повысить объем продаж в системе рекомендаций маркетплейса. Эти метрики первого порядка обычно являются медленно изменяемыми и это может препятствовать разработке и циклу улучшений ML моделей.

Поэтому второй шаг, найти быстро меняющие метрики второго порядка, которые коррелируют с метриками первого порядка. Например, число кликов на карточку рекомендуемого товара или лайков в случае ленты социальной сети. На языке дата сайентистов, это называется ML Target - целевая метрика, которую будет предсказывать и оптимизировать ML модель.

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

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

И только после этих шагов уже можно идти к ML специалистам с готовыми целями, метриками, референсными значениями, базой событий или предложениями, где получить нужный для обучения датасет. ML специалисты делают магию, готовят инфраструктуру для развертывания ML модели в продакшен и приходят к вам с метриками качества ML модели, такими как accuracy, precision, recall и так далее. Тут я не буду детально останавливаться, поскольку в этой части многое зависит от назначения модели, где и как она будет применяться. Из совместного обсуждения и тестирования модели вы сможете понять достаточно ли точна модель и применима ли она к вашей ситуации. На этом же этапе стоит разобраться могут ли дополнительные эвристики (фиксированные правила) улучшить итоговый результат модели.

После этого наступает шаг внедрения модели в продакшен систему. Если это модель для рекомендаций товаров, то начинать стоит с A/B тестирования - например, делим пользователей нашего маркетплейса на сегменты и смотрим как меняются быстрые метрики второго порядка для сегмента, которому рекомендации выдаются по старой схеме и для сегмента, который получает рекомендации через новую ML модель. Это позволяет провести быстрый эксперимент и результат сравнения покажет вам достигли ли вы своей цели, смогли ли улучшить быстрые метрики и получить значимый для бизнеса результат.

Далее наступает этап сопровождения и улучшения модели. ML специалисты смотрят, как еще улучшить модель, какие еще данные можно добавить в фичи модели, и повысить целевую метрику, а продакт на длительном промежутке смотрит не происходит ли ухудшение метрик первого порядка по сравнению с референсными значениями, ради которых все и затевалось, правильно ли была выбрана целевая метрика (ML Target) для модели. Необходимо периодически производить ревизию качества модели и оценивать уровень её влияния, чтобы добиться итеративного её улучшения без переоптимизации и ситуации, когда модель из всего набора получаемых данных фиксируется на ограниченном наборе данных и начинает выдавать некорректные предсказания (иначе это называется переобученностью модели). Ну и периодически цикл повторяется - модель дообучается на новых данных или дообучается на выявленных ошибках, либо целиком заменяется ядро модели за счет перехода на другой тип модели.

Захотелось обсудить бизнес модель отельного агрегатора и может ли она в чистом виде выжить в текущих российских условиях.
Данная модель на уровне бизнеса работает так: отельный агрегатор - это маркетплейс, где в роли поставщиков выступают отели и прочие объекты размещения гостей, а в роли потребителей выступают онлайн турагенства (типа Яндекс Путешествий, Островка) и бизнес турагентства. Агрегатор заключает прямые договоры с отелями, выступает для них единой точкой продаж во все онлайн сервисы бронирования отелей, а для сервисов бронирования выступает одной точкой, где можно из одной интеграции получить большую часть отелей региона. И это все работает по комиссионной схеме - отель дает % агрегатору, а агрегатор делится этим % с агентствами, а живет на оставшуюся разницу.

На уровне модели кажется все норм, но далее возникают нюансы технологического плана и рыночные реалии. В технологическом плане агрегатор не работает с отелями напрямую - да, у агрегатора есть экстранет для отелей (интерфейс для ввода информации об отеле, цен и доступности), но основная масса отелей подключается к агрегатору через дополнительных посредников - менеджеры каналов продаж. А рыночные реалии таковы, что многие годы эти посредники не брали за свое посредничество денег с агрегаторов. Следующие кто создают давление на агрегатора и спят-видят как бы его исключить из цепочки продаж - это собственно сами онлайн турагентства. Если при прямом договоре с отелем агентство может оставлять себе всю комиссию отеля (примерно 15-20% от стоимости брони), то в случае работы с агрегатором агентсвтво получает только 7-8%. И это вынуждает агентства также идти на прямую интеграцию с менеджерами каналов продаж и в прямые договоры с отелями.

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

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

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

И мой тейк в том, что агрегатор, который не может выстроить контроль над большей частью цепочки продаж не жизнеспособен. Он может существовать в узкой нише, но стать лидирующим игроком будет не способен. В России есть компании, например Smartway, которые выстроили полный контроль над цепочкой продаж от отеля через менеджер каналов продаж до конечных b2b и b2c клиентов. Менеджер каналов продаж Travelline выстроил целую экосистему сервисов для отелей и фактически владеет половиной цепочки продаж при продажах через сервисы бронирования, а в случае прямых продаж с сайта отеля владеет полной воронкой продажи, что также дает устойчивость его модели развития.

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

Может ли агрегатор выжить в условиях такого рыночного и технологического давления?
На мой взгляд могут быть следующие сценарии:
- Уход в нишу, там где силы агрегатора еще велики - сегмент b2b онлайн турагентств, которые не идут в прямой контрактинг с отелями, но этот сценарий уменьшает доходы агрегатора и влечет уменьшение его размеров.
- Внедрение в свою работу модели Bed bank, когда агрегатор массово выкупает у отелей номера с высоким дисконтом, но в России пока никто не работает по такой модели из-за её сложности и низкой рентабельности.
- Поглощение агрегатора сервисом бронирования, в этом случае выполняется условие по полноте контроля цепочки продаж и агрегатор исчезая, как отдельная компания, становится просто частью функций сервиса бронирования. И примером такого сценария является недавнее поглощение Яндексом агрегатора Академ Онлайн.

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

Решил и я записаться в вайб-кодеры. Взял проблему, которая меня давно мучает и за 3 часа получил вполне приемлемое для меня решение.

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

В общем, я подумал, а почему бы не сделать свой плагин, который отправлял бы видео и страницы сайтов на саммаризацию в яндексовский сервис 300.ya.ru, тем более, что качество обработки в нем меня устраивало.

В итоге, создание плагина заняло у меня буквально 3 запроса. Я уже читал насколько важно дать нейросети четко прописанный PRD в промпте и что желательно не просить нейросеть исправлять ошибки в коде, а просто начинать генерацию с нуля, но с доработкой промпта. Вооружившись этими знаниями, я приступил. Для простоты я использовал обычный Deepseek, а не специализированный инструмент типа Cursor.

С первого же запроса Deepseek выдал мне работающий код плагина, который умел делать саммари страниц по ссылкам, используя API сервиса 300.ya.ru. На это у меня ушло два часа, из которых полтора часа я пытался разобраться, а почему же плагин выдает ошибку для ссылок на Ютуб видео, при том, что через сайт эти ссылки прекрасно работают. Потратив время на обмазывание js кода отладочной информацией, для чего моих небольших знаний хватило, я пришел к выводу, что API сервиса намерено ограничили и добиться через API обработки таких ссылок невозможно.

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

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

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

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

Какие выводы можно сделать из процесса?
1. Это действительно вайб, если бы не необходимость поспать, то я бы наверное все сделал с одного захода. Начав процесс, уходишь в поток и не очень контролируешь сколько потратил время.
2. Качественное описание постановки задачи в промпте решает. Чем больше времени потратишь на детализацию промпта, тем более быстро получишь желаемый результат от нейросети.
3. Знать программирование все же желательно. Тем кто не знает, может быть трудно понять где посмотреть ошибки или как проверить базовую корректность кода.
4. Учитывая, что js я знаю практически никак, то выполнение той же задачи без нейросети у меня заняло бы часов 20 по моей оценке. И неизвестно сохранил ли бы я мотивацию закончить на протяжении этого времени.
5. Удивило, что нейросеть выдавала консистентный код - я каждый новый промпт запускал в новом чате без истории и нейросеть выдавала идентичный код для ранее реализованного функционала, не меняла от промпта к промпту код кардинально.

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

На днях бывшая коллега в интервью, изложила практически тоже, что я писал недавно про модель отельного агрегатора. Коллега подтверждает, что вне экосистемы такой бизнес выжить не может. А экосистема МТС оказалась совсем не экосистемной, что и привело к закономерному исходу. Без злорадства напрашивается вывод, что число игроков на рынке тревела может подуменьшиться.

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

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

Но речь немного не об этом. Это только контекст. Я хочу показать как решал бы такую задачу на месте руководства этой компании и к какому решению пришел бы.

Первое конечно же целеполагание - ответ на вопрос от лица самого отеля, а зачем нам растить прямые продажи. Да, может показаться, что отелю это выгодно - вместо 15-20% комиссии ОТА платить на порядок меньшие суммы за модуль бронирования. Но при этом часто забывают про то, что в случае прямых продаж отелю придется тратить на маркетинг и продвижение сайта даже больше чем сумма комиссий ОТА, да и в силу эффекта масштаба малым объектам выстроить качественный маркетинг малореально.

Исходя из такого соображения вытекает второй пункт - а в чем же разница между продажами через ОТА и сайт, а точнее что такое есть у сайта отеля, чего нет у ОТА. И это достаточно важный элемент, который и может дать ответ на вопрос как вырастить прямые продажи. Мой вариант такой - в отличие от пассивных продаж через ОТА, где отель практически не имеет контроля над коммуникацией с клиентом, прямые продажи с сайта отеля обеспечивают полноту этого контроля. Сайт отеля позволяет обеспечивать лояльность не сервису бронирований, а самому отелю, вести проактивный поиск целевой аудитории этого отеля, обеспечивать возвращаемость этой аудитории в отель. И для всего этого используются стандартные маркетинговые инструменты, которые не может дать ОТА - формирование турпродукта в виде мероприятий, акций, настраиваемых условий лояльности, политик работы с клиентами и создания для них впечатлений до и после проживания, и далее продвижение этого турпродукта через доступные каналы связи с клиентом - рассылки, мессенджеры, рекламу. Конечно будет специфика в выборе целевой аудитории и разные возможности для формирования турпродукта для городского отеля и для загородного.

Если мы хотим вырастить прямые продажи с сайта отеля, то мы должны понимать всю эту специфику и возможности и помогать управляющим отелями в ведении их бизнеса через консалтинг, обучение, лучшие практики и конечно же учитывать все необходимые инструменты в своем продукте. И собственно на коммуникационную составляющую указанная компания пока внимания не обращает. Соответственно решением, которое исходя из целеполагания и выявленной разницы между продажами через ОТА и сайт отеля, которое позволило бы увеличить прямые продажи - является сервис для автоматизации маркетинговых коммуникаций с учетом отельной специфики. Дальше можно еще рассуждать на тему функций сервиса, обучению работы с ним и выстраиванию качественного маркетинга и сервиса отеля, но это уже выходит за рамки объема этого поста.

А вы что думаете? Что ограничивает прямые продажи отелей и какой продукт нужен для их развития?

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

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

И чем же это хорошо? Обычная проблема, когда в компании появляются новые сотрудники или уходят старые, то происходит разрыв экспертизы и потеря знаний компании. Одно время тема управления знаниями была довольно горячей, но из-за сложностей оцифровки знаний и извлечения экспертизы тема не полетела, и кажется из этой новой итерации может выйти что-то толковое. Как было раньше - сотрудник ушел из компании, вся его почтовая переписка удаляется, никакой фиксации его звонков и совещаний и вовсе не было. В результате, все что было в его голове уходит вместе с ним. Аналогично приходит новый сотрудник и получить эти утерянные знания ему неоткуда. Цифровой же двойник решает эту проблему - ты можешь ему как реальному человеку задать вопрос, спросить что он обсуждал по такому то проекту с другим сотрудником, попросить назначить встречу, согласовать документ и т.п. Более того, ты можешь так общаться не только с двойниками текущих сотрудников, но и всех сотрудников, которые когда-либо работали в компании.

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

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

А вам бы помог цифровой двойник?

Давно задавался вопросом, почему VK имея доступ к огромной аудитории и супер активно поддерживая тревел блогеров, не идет в тревел бизнес, ни сами, ни через партнерства. Но кажется лед тронулся и VK решили попробовать зайти в этот бизнес через свой назойливо продвигаемый MAX.

Чего хочет добиться VK -

переосмыслить опыт путешествий, включая размещение в отелях, перелёты, поездки на поездах, посещение объектов показа, через призму платформы MAX. Мы хотим, чтобы пользователь мог не только купить билет, но и получать актуальную информацию о поездке, общаться с попутчиками, управлять бронированиями, получать рекомендации и сервисы, предъявлять в одном устройстве все необходимые документы — всё внутри привычного интерфейса мессенджера. Это не «очередной тревел-агрегатор». Это новый пользовательский сценарий путешествия с максимальной цифровизацией всех процессов — в формате embedded experience, с поддержкой мини-приложений, чат-ботов и real-time уведомлений.

Будет интересно посмотреть. А если чувствуете силы и не испытываете к MAXу негативных эмоций, то можете попробовать реализовать это видение сами - https://hh.ru/vacancy/128141078

Хочу немного набросить про эджайл коучей. Как-то не очень везет мне с ними.

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

Но что я вижу на примере эджайл коучей, с которыми работал, и многочисленных выступлений разных коучей на конференциях - они не понимают откуда взялся тот или иной принцип, почему в Scrum написано так, а в SAFe иначе, они не пытаются понять смысл за жесткими структурами фреймворков. И поэтому проявляют крайнюю негибкость в том, как сделать разработку реально гибкой. Внедрим этот фреймворк от буквы до буквы и будет нам счастье - вот подход большей части эджайл коучей и цифровых трансформаторов. Зачем, почему, как это повлияет и на что - эти вопросы кажется для них табу. То что почти все гибкие методологии и фреймворки нацелены на мотивированные команды - тоже остается вне поля их зрения. В итоге получается не гибкость, а гипербюрократия. Мотивация же команд погибает где-то в процессе - речи про автономность, доверие компетентности, признание заслуг обычно и не ведется.

Доходило до смешного - эджайл коуч запрещал ставить звонки с подчиненными продактами, если этот звонок не указан в фреймворке. И вот эта негибкость бесит. Другая проблема, которую я видел - это желание следовать до букве написанному в фреймворке. Тут тоже есть смешное - эджайл коучи не любят смотреть на первоисточники и в результате неправильный перевод на русскоязычных сайтах приводит к совершенно неверному пониманию фреймворка. В результате Confidence в ICE некоторые понимают, как уверенность в оценке трудоемкости, а не уверенность в достижении планируемого результата.
Если подитожить, то мне не повезло и я сталкивался только с крайне негибкими, зашоренными и любящими бюрократию эджайл коучами.

А как у вас? Были такие, которые задумывались, что они делают и зачем?

Про выбор

На примере сервисов бронирования отелей хочу подсветить проблему клиентского выбора и отсутствие прогресса в сервисах в этой части. Цель любого маркетплейса - предоставить широкий ассортимент и одновременно ускорить выбор товара. Видите тут парадокс? С одной стороны мы должны дать максимально широкий выбор вариантов, а с другой ограничить этот выбор, чтобы пользователю не пришлось просматривать все варианты и он максимально быстро выбрал тот единственный вариант, который купит.

И если посмотреть на сервисы бронирования отелей, как один из видов маркетплейсов, то мы увидим, что кроме поиска по карте, в этой части за последние лет 20 никакого прогресса и прорывных идей нет. Фильтры, сортировка, отложить в избранное, рекомендации - вот и весь набор функций. Да, забыл про текстовый поиск, а он в сервисах бронирования довольно специфичен - искать обычно можно только по точному названию отеля, поисковая подсказка не показывает все варианты и часто не показывает различий между одноименными отелями. Такое чувство, что идеальный клиент для сервисов бронирования, это тот который заранее знает как точно называется отель и пришел просто сделать заказ этого отеля.
Работать с муками выбора сервисы не хотят. Ведь это действительно сложно. Чтобы понять, как люди выбирают просто продуктового исследования может быть недостаточно, тут скорее нужно разбираться на уровне антропологии и психологии. На личном примере я могу сказать, что в разных ситцациях у одного и того же человека могут быть кардинально разные сценарии выбора. Например, если я еду в командировку, то единственный критерий выбора - близость отеля к месту командировки и функционально для этого достаточно карты в сервисе. Хотя если делать дальнейший шаг, то сервису хорошо бы спросить меня, а куда я буду ездить и подсказать, что выбери ка ты другой отель, тут каждый день пробки на полтора часа между этим отелем и местом куда тебе нужно.

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

Чего же не хватает в этой части сервисам бронирования, и что уже есть на других маркетплейсах? Во-первых, на мой взгляд сервисам не хватает базовой функции сравнения отелей, чтобы сервис говорил, этот лучше этим, а этот этим. Второе, что могло бы ускорить выбор - это если бы сервис в какой-то мере понимал мои предпочтения - через прямые вопросы ко мне или хотя бы историю моих прошлых поисков и бронирований. Но это кардинально отличается от привычного сейчас флоу поиска и бронирования, что видимо никто не хочет рисковать таким экспериментом с UX. А также упирается в плохую структурированность контента в сервисах бронирования. Они продают отели, не понимая специфики и особенностей отеля и номеров в нем.

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

Немного о бизнес стратегии и Яндексе. На рынке отелей небольшой переполох - Яндекс поднимает комиссии и фактически ситуация на рынке становится как во времена Букинга - есть один крупный игрок с достаточно высокой комиссией. Сейчас у Яндекса до 30% рынка и комиссии на уровне Букинга - средние 20% у Яндекса против 22% когда-то у Букинга.

Такое поведение Яндекса было вполне ожидаемо - он не раз повторял это в других сервисах. Вкладываемся в рекламу и делаем близкие к демпингу условия, несём убытки, называя их инвестициями, наращиваем массу клиентов и поставщиков, получаем существенную долю рынка, меняем условия, выходим из убытков в операционную прибыль. Часть поставщиков отпадет, но в силу слабости каждого поставщика по отдельности и отсутствия консолидации на рынке, сами отели вряд ли смогут предпринять что-то существенное. Какие-то отели будут даже рады - как были отели при Букинге, которые все брони получали с Букинга, так и сейчас будут такие же - уменьшается объем документооборота, не надо бегать за разными компаниями для получения выплат, все предсказуемо и удобно.

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

Но мне интересно, могли ли конкуренты притормозить этот безудержный рост Яндекса и не допустить текущего расклада на рынке. Я думаю у них был шанс года 4 назад, когда Яндекс работал над расширением ассортимента - конкуренты ради сиюминутных прибылей сами принесли весь ассортимент Яндексу. Если бы они думали о последствиях своих действий, то Яндексу потребовался бы год или больше на привлечение такого же объема объектов, а задержка на год могла привести к другим раскладам на рынке и возможно позволила бы тому же МТС Тревел достичь устойчивого положения на рынке. А так получилось, что Яндекс фактически бесплатно получил то, за что МТС заплатил несколько миллиардов. МТС своими же руками уничтожил свое преимущество.