Культ продукта

Не устаю пинать адептов культа KPI (это можно делать столько же, сколько смотреть на огонь и воду). Особенно когда они на алтарь этих KPI кладут здравый смысл и продуктовую ценность.

Залез тут в веб-интерфейс почты Mail.ru проверить почту с достаточно древнего компа, экран 1280 пикселей в ширину, и сам ящик старый, без подписок, сиречь с рекламой.
И я был, мягко говоря, сильно удивлён. В стародавние времена, когда во главе почты стояли очень требовательные люди, которые ставили пользователя во главу угла и не шли на компромиссы по качеству, почтой было крайне приятно пользоваться.
Редакция канала помнит, как тяжко было договариваться с Аней Артамоновой о том, чтобы поставить рекламный блок Таргета, как это бесило, но Аня защищала своих пользователей и в итоге получалось весьма неплохо.

А теперь там какие-то безвольные, бесхарактерные люди. На экране 1280x1024 8 (восемь!) рекламных мест, часть из которых банально перекрывает список писем, полностью блокируя пользовательский сценарий просмотра почты. И думают, что они такие лютые стратеги, перекрыть сбор почты по IMAP для бесплатных пользователей и завалить всё рекламой. Наверное, какой-то KPI по монетизации выполнят. А с KPI по оттоку и ретеншену пусть уже следующее поколение борется.

Вывод банальный: хороший продакт должен быть стратегом, думать о будущем и обладать характером.

Небольшой анонс.

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

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

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

Магические квадранты и фреймворки

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

А у фреймворка всё хорошо. Вот этапы. Вот метрики. Вот четыре квадратика. В этот положим боли, в этот — возможности. Здесь нарисуем грустного человечка, здесь весёлого. Теперь с этим хотя бы можно выйти на квартальный обзор.

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

Любой фреймворк — это модель. А модель полезна в том числе потому, что большую часть реальности в неё не положили.

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

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

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

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

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

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

- Мы описали путь клиента — значит, понимаем клиента.
- Разложили инициативы по матрице — значит, правильно расставили приоритеты.
- Собрали метрики — значит, знаем, что происходит с продуктом.

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

Моя рекомендация это взять за правило к любому заполненному фреймворку приносить ещё три вещи:
1. какие допущения мы сделали;
2. что оставили за пределами;
3. при каких наблюдениях признаем, что модель пора пересмотреть.

Хотя на защите стратегии это, конечно, менее удобно ;) . Только всё разложили по магическим квадратикам. А тут опять надо думать, ответственность брать.

Все эти современные ускорители разработки и упаковщики PWA в десктопные приложения явно расхолаживают разработчиков, иначе зачем внутри как бы приложения рекомендовать перейти на приложение?
(это скрин с десктопного приложения boardmix)

Как Феофан продуктовый долг отдавал

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

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

У Феофана была проблема. За квартал он почти ничего не добавил. Зато удалил очень много. Два старых тарифа. Три специальные роли пользователей. Старую версию API. Двадцать семь переключателей, оставшихся от старых экспериментов. Какую-то партнёрскую регистрацию 2018 года. И ещё условие в коде: if user_created_before_2019
Последнее особенно радовало Феофана. Потому что никто уже не понимал, почему пользователи, зарегистрированные до 2019 года, должны были жить по отдельным законам. Но условие работало, его наличие никак не мешало другим фичам и пользователям. Поэтому его не трогали. Лет семь.

Феофан открыл презентацию.
Первый слайд:
«Итоги квартала».
Второй:
«Закрыли два старых тарифа».
Третий:
«Удалили старые роли».
Четвёртый:
«Выключили старую версию API».
Феофан посмотрел на презентацию.
Со стороны выглядело так, будто команда из двадцати человек три месяца разбирала антресоль. И теперь Феофану надо было это продать руководству.

На встрече сначала выступал маркетинг. Красивые картинки. Большой запуск. Рост охватов. Потом продажи. Новые клиенты. Деньги. Планы.
Наконец очередь дошла до Феофана.
— Ну что, — спросил директор, — что запустили?
— Почти ничего.
В комнате стало тихо.
— А чем вы тогда занимались?
— Удаляли.
Феофан переключил слайд.
— Вот у нас было семь вариантов расчёта стоимости. Теперь три.
— Почему семь?
— Исторически сложилось.
— Было пять систем прав доступа. Теперь две.
— Почему пять?
— Одну сделали для крупного клиента. Одну для партнёров. Одна старая. Про ещё одну никто толком не знает.
— А пятая?
— Пятая как раз была самая опасная.
Феофан переключил слайд.
— Ещё мы выключили старую версию API.
— А новая появилась?
— Она уже два года как была.
— То есть пользователь ничего нового не получил?

Феофан задумался. Это был хороший вопрос. Пользователь утром открыл продукт. Всё на месте. Кнопки те же. Отчёты те же. Тариф называется так же. Никакого волшебства.
— Сегодня — почти ничего, — сказал Феофан.
Директор посмотрел на него с интересом. Феофан продолжил.
— Раньше, чтобы добавить одну настройку тарифа, надо было проверить семь схем оплаты. Теперь три. Чтобы поменять права доступа, надо было помнить про пять вариантов ролей. Теперь про две. Чтобы что-то изменить в регистрации, раньше сначала шли искать человека, который знал, кто такие «партнёрские пользователи». Обычно такого человека уже не было в компании. Потом искали документацию. Документации тоже не было. Потом открывали код. В коде находили комментарий: temporary fix от 2019 года. И задачу переносили на следующий квартал.

Феофан показал ещё один слайд. На нём была схема продукта в начале квартала. Тарифы. Старые тарифы. Особые тарифы. Корпоративные тарифы. Роли. Старые роли. Партнёрские роли. Какая-то специальная роль для одного клиента. Две версии регистрации. Три версии программного интерфейса. И много стрелок. Очень много стрелок.

Следом Феофан показал схему сейчас. Она была заметно скучнее.
— Это всё? — спросил директор.
— Да.
— Вы три месяца делали схему скучнее?
— По сути да.
Феофан переключил дальше.
Среднее время разработки обычной задачи снизилось почти вдвое. Ошибок после изменений стало меньше. Поддержка перестала разбираться с клиентами на тарифах, которых давно не было на сайте. Разработчики больше не спрашивали каждый раз:
— А старых пользователей это не сломает?

Самое интересное началось в следующем квартале. Команда вдруг стала быстрее выпускать новое. Не потому что стала больше. Не потому что наняли ещё пять разработчиков. Не потому что Феофан сходил на курс по управлению продуктом.
Просто теперь, чтобы что-нибудь изменить, не надо было сначала раскапывать историю компании с 2018 года.
Потом быстрее прошёл ещё один квартал. И ещё один.
И в какой-то момент директор спросил Феофана:
— Слушай, а почему мы раньше так медленно делали?
Феофан хотел многое ответить. Про старые тарифы. Про роли. Про партнёрские интеграции. Про условие if user_created_before_2019.
Но потом передумал.
— Исторически сложилось, — сказал Феофан.
И пошёл удалять следующий тариф.

//Жаль, что так только в сказках бывает.

Смерть от тысячи правильных решений

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

К сожалению, нет, это не так.

Компании и продукты довольно редко умирают потому, что однажды утром CEO пришёл на работу и сказал:

— А давайте сегодня примем какое-нибудь совершенно идиотское решение в духе канала I'm CEO, bitch.

Обычно всё происходит гораздо скучнее.

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

Вот этого крупного клиента нельзя расстраивать.

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

Вот эту команду не будем расформировывать, они хорошие ребята и вообще много чего знают.

Вот эту функцию пока оставим для обратной совместимости.

Вот здесь запустим новый продукт, но старый закрывать пока рано.

Вот здесь ещё немного подождём результатов, данные пока что не репрезентативны.

Каждое решение само по себе абсолютно защищаемо.

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

Наверное, один из самых красивых примеров — Nokia. Кто уже только не пинал их. :)

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

И для каждого из них совершенно разумно хотелось что-то своё.

Результат: к 2009 году внутри Nokia использовалось 57 несовместимых версий Symbian.

Вдумайтесь.

Пятьдесят семь.

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

А потом пришёл iPhone, где был один iOS.

Пока Nokia договаривалась сама с собой о том, какое будущее ей подходит, Apple просто выбрала будущее.

Другой мой любимый пример — мессенджеры Google.

Google вообще прекрасно умеет делать технологии для коммуникации. У них был Google Talk. Потом Hangouts. Потом Messenger. Потом Allo. Потом Duo. Потом Chat. Потом Meet.

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

Hangouts слишком универсальный — давайте разделим consumer и enterprise.

Видеозвонки — отдельный job, сделаем Duo.

На рынке побеждает WhatsApp — нужен consumer messenger, сделаем Allo.

SMS никуда не делись — нужен Messages.

Корпоративным клиентам нужны свои коммуникации — сделаем Chat и Meet.

Каждый раз сидит умная команда умных людей с данными и абсолютно разумно объясняет, почему следующий продукт нужен.

Проблема только в одном.

Пользователю совершенно наплевать на оргструктуру Google и на то, какой VP за какой кусок коммуникаций отвечает и какой у него KPI.

Он просто хочет написать человеку сообщение.

В какой-то момент Google сам начал писать про необходимость «более простого communication experience» и закрывать то, что несколько лет до этого сам же торжественно запускал.

Не потому что люди внезапно разучились делать мессенджеры.

А потому что локальная оптимизация каждый раз побеждала глобальную.

С Yahoo история немного другая, но механизм похожий.

Компания много лет обладала почти всем, что нужно интернет-компании: огромной аудиторией, почтой, поиском, новостями, финансами, рекламой, Flickr, Tumblr и ещё кучей всего.

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

Проблема была в том, что ответа на вопрос «а что такое Yahoo?» становилось всё меньше.

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

Что опять-таки очень логично.

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

Нужно всё внимательно обсудить.

Потом ещё обсудить.

Потом нарисовать двадцатый вариант оргструктуры.

Потом рынок уже можно не обсуждать.

И вот это, мне кажется, важная штука про большие организации.

Мы обычно боимся плохих решений.

А бояться надо не только их.

Надо ещё бояться хороших решений, принятых без общего направления.

Потому что плохое решение обычно заметно.

Запустили продукт — никто не пользуется. Поменяли цену — продажи упали. Сделали редизайн — метрики рухнули.

Можно увидеть, признать ошибку и откатить.

А у тысячи разумных решений нет момента катастрофы.

Сегодня вы добавили одну фичу.

Завтра сделали исключение одному клиенту.

Послезавтра сохранили старую архитектуру ещё на год.

Потом создали ещё одну команду, чтобы новая команда не мешала старой.

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

Через год для всего этого понадобился комитет по синхронизации.

Ничего страшного не произошло.

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

Просто через несколько лет вместо продукта у вас получается геологический разрез истории компании.

Вот слой, когда CEO хотел enterprise.

Вот слой, когда мы пошли в SMB.

Вот здесь был стратегический клиент.

Вот тут модным был AI.

Вот этот экран нельзя удалить, потому что им до сих пор пользуются 0,7% пользователей.

Вот эту интеграцию поддерживаем ради трёх лояльных клиентов.

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

И самое неприятное: у каждого слоя есть хозяин.

Он придёт на совещание и совершенно разумно объяснит, почему именно его слой трогать нельзя.

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

Она про умение периодически смотреть на тысячу вполне разумных вещей и говорить:

— Половину этого мы больше не делаем.

Не потому что это плохие вещи.

А потому что мы решили делать другое. И тут нужен характер сказать правду и признать правду.

Есть два утверждения о работе продакта.

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

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

Второе утверждение: именно бесконечные попытки всех со всеми примирить часто и убивают продукт.

В большой компании любое достаточно заметное решение быстро обрастает согласующими. Один стейкхолдер просит убрать риск. Второй — добавить контроль. Третий — сохранить старый процесс. Четвёртый согласен на изменения, но только после того, как изменения согласует пятый.

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

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

Поэтому задача продакта — не сделать так, чтобы все остались довольны в моменте.

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

Компромисс — полезный тактический инструмент, но плохая цель.

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

Премиум против больших данных

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

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

Один на сто тысяч.

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

С точки зрения экономики решение очевидно.

Не помогать.

Можно несколько раз прислать шаблонный ответ. Потом закрыть обращение как решённое. Если пользователь продолжает возмущаться — заблокировать его и объяснить, что компания вправе прекратить обслуживание без объяснения причин.

Не нравится — не пользуйтесь. Идите лесом вообще.

В отчётах всё будет хорошо. На удовлетворённость остальных 99 999 пользователей этот случай почти не повлияет. Среднее время ответа не испортится. Cost per ticket останется в пределах нормы. Юнит-экономика не пострадает.

Человек просто исчезнет внутри статистической погрешности.

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

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

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

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

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

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

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

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

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

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

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

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

Продукт как игра с положительной суммой

Немного рассуждений про продуктовую этику и вообще суть. Не могу не попинать крупных игроков ;) .

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

Но тут, как обычно, где-то спрятан кролик.

Продукт — это не только интерфейс, алгоритмы и бизнес-модель. Это ещё и система отношений между всеми, кто в нём участвует. И нормальный продукт должен быть игрой с положительной суммой: каждый участник получает от сделки больше, чем отдаёт, и потому заинтересован продолжать эту игру.

Возьмём такси.

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

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

А теперь немного изменим условия.

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

Водитель отдаёт агрегатору значительную часть заработка не потому, что получил соразмерную услугу, а потому, что без агрегатора к пассажирам теперь практически не попасть.

Сам водитель при этом может получить меньше обычного. Пассажир заплатит больше обычного. Разницу заберёт платформа.

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

Это уже не создание ценности, а взимание дани за проход через ворота.

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

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

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

Только продуктом эта конструкция постепенно быть перестаёт.

Остаётся инфраструктурная монополия с хорошим мобильным приложением.

Мне кажется, один из важнейших вопросов при оценке любого продукта должен звучать не "сколько на этом заработает компания?", а "почему после нашего появления всем участникам системы стало лучше?" и "в чём именно эта лучшесть выражается?"

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

Возможно, кто-то просто очень удачно поставил шлагбаум.

И картинка к предыдущим постам для пущей иллюстрации происходящего 👁

Здравствуйте!

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

Память сейчас работает на уровне воркспейса (то есть помнит все проекты и артефакты всей команды).

Понял, что про сам продукт-то я и не писал толком.

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

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

Можно и свои артефакты загрузить и привести к единому формату, и с нуля в выверенных годами шаблонах создать, и проверить на непротиворечивость (когда интервью проводили с одной ЦА, а в лин канвасе написали другую.)

Сам продукт можно подключить в качестве MCP-сервера и прописать у себя каждый инструмент продукта как навык — будет бесшовное встраивание в уже имеющийся у вас AI-продуктовый процесс. (Ну и если хотите On-prem установку — вообще без проблем можно установить на ваших инхаус-моделях)

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

Если хотите что-то другое или иной образ продукта видите — делитесь обратной связью. 🙏

Оптимизации законечены, подписки выкачены. Симуляция интервью находится в «Методы» -> «Интервью» -> «Симуляция». Специально запрятал поглубже в надежде, что никто не будет злоупотреблять. ;)
Ну а так — официальный запуск открытой бета-версии состоялся, буду рад фидбэку и вдвойне буду рад, если задонатите в подписку в продукте, токены и хостинг оплатить можно будет.

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

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

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

А пока пользуйтесь. В бесплатном аккаунте кредитов на пару симуляций хватит ;) А подписку подключу уже на следующей неделе.

И ещё пинок в сторону коллег из ВК, уже даже не стесняются )

Тем временем выпустил обновление продукта, теперь ProductCult не просто операционная система управления жизненным циклом продукта, а ещё и MCP-сервер (пока в закрытой альфе, если кто-то вдруг хочет потестировать — пишите).
Теперь вы можете просто подключить вашего агента к ProductCult и получать стандартизованные продуктовые артефакты, менять их (например, по итогам транскрипта встречи), делать дополнительные проверки артефактов, ну и забирать все артефакты во внутренний контур, где уже заменять dummy-данные на реальные.

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

Начинается так:

Задумал Никодим работу сменить, походил по собеседованиям и вышел на работу в компанию «Кубики и краски» в роли CPO. Всё было гладко да ровно на собеседовании: рассказывали, какое производство серьёзное, японское оборудование, кубики идеальные, и спрос есть. Говорили, что не хватает структурности в понимании клиентского портрета и стратегии масштабирования. Спрос на кубики стабильный, но не понимают, кто их покупает и зачем. А хаотичные эксперименты не помогают бизнесу расти, только убытки множат.

Ну а продолжение по ссылке:

https://shkolnikov.me/2026/06/30/%d0%ba%d0%b0%d0%ba-cpo-%d0%ba%d1%83%d0%b1%d0%b8%d0%ba%d0%b8-%d0%bf%d1%80%d0%be%d0%b8%d0%b7%d0%b2%d0%be%d0%b4%d0%b8%d0%bb/

А вот тут коллеги из ВК Рекламы тоже удивили. Говорят вроде про рубли, а рисуют непонятный значок 🙈

Кричим: аудиторская компания KPMG отозвала свой же отчёт о пользе агентного ИИ, потому что он оказался галлюцинацией ИИ.

Команда GPTZero разобрала отчёт, и выяснилось, что из 45 источников только 5 ведут к реальным материалам. 28 путали названия, авторов и год, а 12 просто невозможно найти. Ну, собственно, их сгаллюцинировал ИИ. Примерно половина утверждений либо фейковые, либо неверно интерпретированные.

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

@lobushkin