Discovery становится дешевле. Но продукты быстрее расти не начинают✖️

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

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

Но на практике я этого почти не вижу⚪️

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

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

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

И вот здесь пока никакой агент не заменит человека.
✔️Нужна насмотренность.
✔️Понимание рынка.
✔️Умение читать аналитику.
✔️Понимание экономики продукта.
И самое главное — способность отказаться от девяти хороших идей ради одной действительно сильной.

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

Поймал классическую проблему больших команд🔐

Мы сейчас создаём новый тариф. Вроде всё сделали как положено: посмотрели аналитику, конверсии, конкурентов, определили ценность для клиента, посчитали экономику. Гипотеза собрана, можно запускать🛒

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

И вот тут началось👇
Каждый принёс свои опасения. Большинство из них вообще не мешают запустить тариф сейчас. Это скорее риски из серии:

«А что будет, если через год…»
«А вдруг какой-то клиент когда-нибудь…»
«А как это потенциально повлияет на другой процесс…»

Все вопросы по отдельности разумные, но когда решение должны согласовать десять человек, оно внезапно становится в десять раз сложнее😕

Нужно закрыть потребности каждого, собрать всех на встречу, устранить каждое недопонимание и заранее предусмотреть вообще всё. И небольшая гипотеза, которую можно было проверить за пару недель, начинает месяцами ползти к релизу〰️

Поэтому я для себя принял довольно простое решение👇

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

Но мы не выкатываем тариф на всю базу и не высаживаемся с ним на Марс.
Мы запускаем A/B-тест, смотрим метрики и довольно быстро понимаем: работает гипотеза или нет.

Цена такой ошибки ограничена. А цена бесконечного согласования почему-то обычно вообще никем не считается.
При этом карт-бланш важен ещё и по другой причине.
У многих людей внутри компаний есть страх:

«Сейчас я что-то решу, запущу, оно не сработает — и мне прилетит».

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

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

Поэтому задача руководителя, не убрать все риски. Это невозможно.
Задача — ограничить размер ошибки и дать ответственному человеку право быстро её совершить📌

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

Есть одна вещь, которую бизнес обычно недооценивает.

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

Что входит:

⚪️льготное обслуживание на тарифе «Успех» — 1000 ₽/мес., вместо стандартных —1780 ₽/мес.;
⚪️ переводы физлицам — до 2 млн ₽ бесплатно;
⚪️100 платежей юрлицам в другие банки — без комиссии;
⚪️онлайн-бухгалтерия — бесплатно.

Без скрытых условий и неожиданных изменений.

Успешный успех по акции. Поддержка — навсегда.

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

Подробнее — по ссылке 🔗

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

Сейчас занимаюсь новыми тарифами и столкнулся с простой проблемой: клиенту часто не нужен весь пакет. Ему нужны конкретные 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-го сентября, можно заглянуть. В комментариях отмечайтесь, кто уже идёт. Может, сразу и компания соберётся. 👇