Тарифная сетка начинает выгорать 💶

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

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

Первая реакция - сделать ещё один тариф. Потом ещё один: для малого бизнеса, для совсем малого, без финансиста, с финансистом, с проектами и без проектов. В какой-то момент тарифная сетка превращается в мусорку хотелок, где уже никто нормально не понимает разницу✖️

На зарубежном рынке всё чаще используют другую конструкцию: платформенное ядро + модули под конкретные задачи.

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

🟢HubSpot, например, снизил порог входа и сделал более гибкой оплату за пользователей. Клиент может начать с меньшего объёма и расширяться по мере роста ценности.

🟢Intercom пошёл ещё дальше: их AI-агент Fin оплачивается за решённую задачу. То есть клиент покупает не доступ к функции, а конкретный результат.

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

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

Вот такие кейсы я в том числе беру изучая различные папки и обрабатывая их разом через агентов - вот подборка нескольких папок каналов про ИИ, IT, digital и технологии. А так же папка с Biz/IT

Мы в продукте почему-то почти всё называем кастдевом⚪️

Хотя по факту это разные исследования🙃

Если говорим с потенциальной аудиторией▶️
Ищем Jobs, проблемы, альтернативы, причины переключения.
👇
Это скорее Problem Discovery.

Если говорим с текущими клиентами▶️
Смотрим, как они реально используют продукт:
Job → сценарий → функция → результат → костыль.
👇
Это уже Product Usage Research.

Если проверяем конкретный интерфейс или функцию▶️
Смотрим, где человек понял, не понял, застрял.
Это UX / Usability Research.
Если разбираемся, почему не активируются, не возвращаются или уходят
👇
Это уже исследования Activation / Retention / Churn.

Казалось бы, какая разница, как назвать.
Но проблема слова «кастдев» в том, что команда часто идёт «просто поговорить с клиентом».
А исследование должно начинаться с другого вопроса:
👇
Какое продуктовое решение мы хотим принять после этого разговора?

Кажется, ещё один кусок разработки постепенно можно забирать себе 😊

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

И вот на последнем пункте «быстро» обычно заканчивается.
У Tilda недавно появился Вайб-блок. По сути, описываешь словами, что хочешь получить, а ИИ собирает блок прямо внутри редактора. Потом там же через чат можно сказать: поменяй логику, анимацию, структуру и докручивать результат дальше. Можно делать интерактивы, калькуляторы, слайдеры, формы со сложной логикой и другие штуки, под которые раньше требовался код.

Но мне даже интереснее их второе обновление CMS Потоки.

Представим, что гипотеза полетела и у тебя уже не 5 страниц, а 100. Каталог объектов, услуги, команда, вакансии, кейсы неважно.

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

CMS → быстрее масштабировать то, что уже работает.
По сути, ещё немного сокращается расстояние между «я придумал» и «это уже можно показать пользователю».

А по моему промокоду vc4tilda (до 1.09) можно получить 1 месяц бесплатного тарифа Personal для новых пользователей

Как воскресний футбол превратился в небольшой data‑продукт 😃

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

Потом мы начали записывать результаты. Следом появились голы и передачи. Затем — составы, позиции, описания матчей и короткие видеообзоры с голами и опасными моментами ⚪️

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

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

Если кому-то интересна техническая часть: интерфейс сделан на React и TypeScript, данные хранятся в SQL-базе Cloudflare D1, а Python используется для переноса, проверки и пересчёта статистики, а также балансировки составов. AI-агенты помогают разбирать архив, восстанавливать историю матчей, проверять данные и готовить рекомендации.

Что получилось👇
У каждого игрока теперь есть личный профиль и персональный код для входа.
Игрок заполняет структурированную анкету: выбирает позиции, оценивает технические, тактические, физические и психологические качества, указывает сильные стороны и зоны роста.
Отдельно можно отметить текущее состояние:
🎊 полностью готов;
🎊 готов частично, например на 70%;
🎊 восстанавливается;
🎊 травмирован;
🎊 временно не может играть.
На сайте сохраняются:
📟 история матчей и составов;
📟 счета и результаты по таймам;
📟 голы и передачи;
📟 кто кому ассистировал;
📟 последовательность игровых событий;
📟 короткое описание того, как проходил матч;
📟 накопительная статистика игроков;
📟 рейтинг результативности;
📟 PPG — среднее количество командных очков за матч

После каждого матча открывается голосование на 24 часа. Участники выбирают MVP, лучшего атакующего, полузащитника, защитника и вратаря — отдельно в каждой команде.
Пока голосование продолжается, никто не видит чужие голоса, счётчики и предварительных лидеров. Все результаты открываются только после закрытия, чтобы в небольшой группе нельзя было вычислить выбор конкретного человека.

Сейчас внутри уже 62 профиля игроков, 26 карточек истории, почти 30 матчевых записей, более 300 участий и свыше 90 сохранённых игровых событий. Получились не условные «150 параметров», а тысячи отдельных значений, связанных между собой🔥

А где здесь AI? 👻
Перед следующей игрой я передаю агентам список готовых игроков. Они сопоставляют позиции, результативность, PPG, текущую готовность, сыгранность и качественные наблюдения по прошлым матчам.

После этого AI предлагает два состава и объясняет логику баланса: где сильнее защита, кому нужен быстрый форвард, кого нельзя оставлять единственным центральным защитником и кому требуется ротация.

🔄 По моим ощущениям, на серии последних игр рекомендации уже не раз давали очень плотные матчи, где исход решался одним-двумя мячами. Были и промахи — зато теперь их можно не просто обсуждать, а разбирать на данных и учитывать дальше.

В итоге из обычного любительского футбола получилась своя маленькая аналитическая платформа 🇮🇹

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

Теперь думаю, как эту механику можно развить дальше и можно ли адаптировать её для других любительских команд🙃

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

А менять работу каждые полгода только ради новой насмотренности... идея так себе 😊

Поэтому мне нравится формат проектной работы. Можно параллельно зайти в продукт из другой отрасли, проверить себя на новом рынке, поработать с другой командой и заодно добавить нормальный кейс в портфолио.

Для этого есть EasyStaff Connect — международная площадка, где компании ищут специалистов под проектные задачи.

Продакту там можно упаковать свой опыт в discovery, исследованиях, аналитике, стратегии, запусках и развитии продукта: описать кейсы, вклад, метрики и откликаться на подходящие проекты.

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

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

На этой неделе у нас был, пожалуй, самый горячий sprint review за последнее время 🔥

И это было отлично😊
Разбирали одну вполне обычную задачу по новому тарифу. В какой-то момент обсуждение разогрелось, и стало понятно: проблема вообще не в этой конкретной задаче.

У нас просто сломалась цепочка до разработки.
Где-то не добили бизнес-логику. Где-то не зафиксировали состояния. Тексты приехали сырыми. В каких-то местах вообще оказалось непонятно, кто отвечает за финальный смысл.

А тестирование получило всё это последним и внезапно должно было разобраться, что вообще считается правильным результатом✖️

И тут команда оживилась
💬Тестирование говорит: «Я не могу это принять, потому что ожидаемый результат не определён».
💬Разработка говорит: «Не надо генерировать нам огромное ТЗ на 20 страниц. Скажите нормально, что должно получиться».
💬Дизайн говорит: «Я могу хорошо упаковать текст, но не могу придумать за продукт, что мы хотим сказать клиенту».

И в какой-то момент я понимаю: окей, это уже не проблема конкретной задачи. Это проблема процесса.

Мы очень любим считать узким горлышком разработку.
Просто именно туда приезжают все долги, которые накопились раньше: продукт не договорился с маркетингом, не собран GTM, не готовы тексты, не продуманы состояния, не подключили вовремя юриста, нет критериев приёмки.

И разработка превращается в место, где все наши «потом разберёмся» наконец становятся проблемой.

По итогам решили не изобретать ещё один идеальный шаблон ТЗ.
Нам нужен нормальный Definition of Ready перед разработкой:
🟢 что получит пользователь;
🟢 какие есть сценарии и состояния;
🟢 какие тексты он увидит;
🟢 какие тарифы, роли и ограничения затрагиваем;
🟢 подтверждена ли бизнес-логика;
🟢 нужен ли маркетинг / юрист / бухгалтерия;
🟢 готов ли дизайн;
🟢 как мы поймём, что задача сделана;
🟢 что точно НЕ делаем в рамках этой задачи.

Пока этого нет 😕 задача не Ready.

Для меня это был очень хороший sprint review.
Да, местами горячий🙃
Но я гораздо больше не люблю встречи, где все вежливо говорят «в работе» и расходятся.
Сильная продуктовая команда — это не команда, где нет конфликтов.
Это команда, которая умеет вовремя сказать: «ребята, у нас здесь система не работает» — и начать её чинить.

CPO и CTO не обязаны сразу понимать друг друга⚪️

Есть довольно частая история: CPO и CTO спорят о задачах, сроках, качестве постановки и готовности продукта к разработке.

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

CPO думает о клиенте, бизнес-результате и скорости выхода на рынок. Его главный страх 🟢 потратить месяцы и не получить никакого эффекта.
CTO думает о реализуемости, качестве и устойчивости системы. Его главный страх — 🟢быстро выпустить решение, которое потом придётся долго и дорого переделывать.
И оба по-своему правы.

Проблема начинается, когда вместо обсуждения этих различий появляются формулировки:

🟣«Разработка слишком медленная».
🟣«Продукт приносит неподготовленные задачи».
🟣«Сделайте нормальное ТЗ».
🟣«Не усложняйте и просто выпустите».

За этими словами обычно скрываются не плохие люди и даже не слабая команда. Скрываются разные представления о том, что значит «задача готова».

На мой взгляд, зрелая продуктовая команда появляется не тогда, когда CPO победил CTO или наоборот.
Она появляется, когда они смогли договориться:
🟢 какой результат нужен бизнесу и пользователю;
🟢 какая информация необходима до начала разработки;
🟢 какие вопросы обязан закрыть продукт;
🟢 где требуется участие технической команды;
🟢 какие риски допустимы ради скорости;
🟢 кто принимает решение, если идеального варианта нет.

Иногда до этого приходится пройти несколько тяжёлых итераций. Поспорить. Пересобрать процесс. Признать, что где-то неправильно понял другого или не услышал его ограничения✔️

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

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

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

Потому что в конечном счёте CPO и CTO делают не две разные части работы.
Они вместе делают один продукт💜

На днях вышел GPT Astra и пока мне прям очень нравится👨‍💻

Работает безумно быстро. Агенты на ней просто начинают летать: задачи закрываются быстрее, взаимодействие с браузером, устройствами и разными сценариями ощущается уже совсем на другом уровне☯️

И главное видно, что её реально можно адаптировать почти под любую рабочую среду и процесс.

Но есть один жирный минус: токены она просто сжирает🟡

Причём с такой скоростью, что даже недельные лимиты начинают выглядеть как что-то очень временное 😭

А вчера у меня родился кейс, сын обожает поезда. Прям очень, а с 1 сентября он пошёл в школу.
И я вечером подумал: а что, если это вообще совместить?

Полез смотреть игры про поезда. Нашёл несколько нормальных референсов: как устроены железные дороги, станции, маршруты, кабины, сами поезда, логика движения. Взял оттуда саму модель игры. Добавил уже наши поезда, российские города, станции, условные Москву, Питер и т.д.

И дальше всё это начал крутить с Astra.
В итоге с нуля появилась браузерная игра: 3D-модели поездов, кабины, города, железные дороги, станции, нормальная детализация.✨
Но самое крутое, я всё это завязал на школьные знания.
Хочешь отправить поезд дальше, реши задачку по математике, разберись с географией, русский язык и тд.
Где-то логика, графические задания и другие школьные штуки.

То есть ребёнок вроде бы просто играет в то, что ему реально нравится. Но внутри игры постоянно учится.

И я сижу потом, смотрю на это и думаю:
охереть как круто👏
Ты можешь буквально за вечер сделать своему ребёнку персональную образовательную игру под его конкретное увлечение.
Не ждать, пока кто-то когда-нибудь выпустит нужное приложение.

Теперь главный вопрос, как всё это немного оптимизировать, не потеряв в скорости и качестве. Потому что по самой работе, пока очень кайфово😱

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

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

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

16 сентября hh team собирает продуктовый RecSys-митап с кейсами hh.ru, Авито и Циан.

19:00–21:30 участвовать можно офлайн в Москве или подключиться онлайн.

➡ Яна Семененя, руководитель поисковых и рекомендательных продуктов, hh.ru
Кому отдать следующий показ: балансируем релевантность и бизнес-цели в RecSys

➡ Андрей Демидов, Head of DS Products, Авито
От стрижки до элитной недвижки: развитие алгоритмов монетизации рекомендательной выдачи Авито

➡ Катя Лунина, продакт поиска и рекомендаций вакансий, hh.ru
От описания желаемой работы до подходящих вакансий: как мы построили диалоговый LLM-поиск

➡ Саша Павленко, Head of product Search and Recommendations, Циан
RecSys в недвижимости: специфика домена и что она меняет в продукте

Живое общение, интерактивы с призами, еда, напитки и нетворкинг с коллегами по цеху 🦀

Участие бесплатное, офлайн или онлайн.
Регистрируйтесь по ссылке 🥰

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

Но, кажется, есть ещё одна ловушка: слишком долго смотреть на продукт только глазами продакта.

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

Мне вообще нравится этот тренд: меньше «я продакт, это не моя зона», больше понимания того, как продукт реально собирается на стыке нескольких профессий. И крупные компании активно идут в него, не разделяя конфы на отдельные профессии, а, наоборот, идя в кроссопыление.

Т-Банк, как например, собирает сразу и продактов, и дизайнеров, и аналитиков на своей «Продукты 24 & FFDD2D» 12-го сентября.

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

Так что, если будете в Москве 12-го сентября, можно заглянуть. В комментариях отмечайтесь, кто уже идёт. Может, сразу и компания соберётся. 👇