Продукт

Что бы я делала сейчас, если бы запускала мобилку или веб-продукт со ставкой на органическое привлечение: 1. Сделала бы простую посадочную страницу с простым доменом. Повесила бы аналитику, поставила бы форму предзаписи. 2. Запустила бы тик-ток / инсту / тредс - там, где в основном обитает моя аудитория. 3. Посмотрела бы, есть ли хотя бы посещения страницы. В идеале - заявки на покупку. 4. Пилила бы продукт только когда канал показал свою состоятельность: есть посещения страницы, в идеале заявки. Если органический канал не работает с посадочной, то есть высокая вероятность, что и с продуктом не сработает. Так было у меня с тик током :) Плюс как бонус вы протестите креативы на платную рекламу 😉 #PG_размышления

Как структурировать продукт для ИИ: 6 элементов Новая точка ценности возникает в создании интерфейса-протокола-API, который позволяет ИИ понимать ваш продукт и действовать в нём (назовём это AIX вдобавок к привычному UX).

AIX, как и UX, ломается не на сложных, а на неявных действиях

Чтобы продукт стал более удобным для ИИ, его можно разложить на несколько элементов: 1) Структурированный контекст, чтобы ИИ-агент мог видеть то же, что видит пользователь. Но ИИ-агенту нужен не весь контекст продукта, а нужный слой на нужном действии, так как избыточный контекст так же ломает агента, как недостаточный (ибо разнообразие должно соответствовать, а не максимизироваться). 2) Типизированные действия, чтобы ИИ-агент знал, какие действия доступны в процессах а) пользователя; б) продукта и бизнеса.

Типизированное действие = предусловие (срез контекста, при котором действие применимо) + действие + постусловие + альтернативный поток (эскалация на человека).

3) Правила эскалации с версионируемой схемой политик поломок и явным владельцем, чтобы ИИ-агент (и человек) знали, при какой ситуации необходимо предпринять действия коррекции и кому. У каждого типизированного действия должна быть задана стоимость отката. Если откат действия дороже самого действия (необратимые операции: отправка, платёж, удаление), эскалация к человеку должна быть предусловием, а не постусловием. 4) Как только продукт структурирован, его частям нужен ИИ-контракт ИИ-контракт определяет, как фича работает на системном уровне, её связь с каждым компонентом, объектом и правила их взаимодействия внутри продукта, чтобы разные продуктовые области могли подключаться и заставлять своих ИИ-агентов выполнять желаемое поведение. И да, версионируйте контракты ВСЁ, иначе без этого ИИ-агенты молча начинают действовать на устаревшей модели продукта. 5) Цикл. Цикл призван улучшать Систему в времени. Примером ценного цикла может служить захват сигнала коррекции: разницы между тем, что сделал ИИ-агент, и тем, исправил ли это пользователь. Например, когда пользователь редактирует текст, сгенеренный ИИ или отменяет предложенный вариант, это разные по силе сигналы. Первый про качество ответа ИИ, второй про доверие/уместность действия со стороны ИИ в глазах юзера, поэтому разделяйте постусловие на «успех» и «частичный успех». Поэтому каждый цикл коррекции должен иметь владельца (ИИ или человек?), который решает, применять ли исправление системно или считать его исключением.

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

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

Новое знание и непрогнозируемый ущерб Первый параметр хорошей ошибки: это новое знание. Если в результате действия мы получаем новую информацию, то это уже не ошибка, а опыт или эксперимент. Если же в результате мы ничего нового не узнаем, то это не опыт, это может быть просто глупостью. Если мы кинем ноутбук в воду и после этого он перестанет работать — то тут нет никакого нового знания. Мы просто сделали глупую вещь. Если же мы кинули кусок каучука на плиту и получили вулканизированную резину — то это полезная ошибка. Второй параметр: нет значительного непрогнозируемого ущерба. Иногда эксперименты стоят денег, даже сравнительно больших денег. В краш-тестах бьют машины чтобы понять, как машина ведет себя при аварии. В этом случае наши затраты на тест — это стоимость машины. Это может быть значительная сумма, однако она необходима для сертификации или создания более безопасных машин. Мы прогнозируем эту сумму как убыток, для нас не будет сюрпризом, что мы списали эту машину. Если мы разбили машину и не получили новой информации — то вот это точно глупость. Во всем нужен баланс. Чернобыльская авария дала нам кучу новой информации про радиацию, работу оборудования, поведение природы при облучении и т.д. Однако цена за это новое знание была слишком высока, чтобы признать это полезной ошибкой. Если определять сколько же мы можем потратить на новое знание — зависит от компании и ее аппетитов. Нетфликс достаточно четко понимала, что для того, чтобы понять рынок, необходимо тратить деньги. В 2017 году перед Нетфликс стояла задача выйти на зарубежные рынки. 80% роста было за пределами США. Нужно было завоевать Бразилию, Индию, Индонезию. Однако компания совершенно не представляла что происходит на рынках этих стран, какие шоу будет пользоваться успехом, какие нет. Один из принципов, как принимать решения: это познавательная ценность неудачи. Когда ваша команда покупает и производит контент в разных странах мира, необходимо сосредоточиться на уроках, которые можно извлечь из любого опыта. Будьте готовы делать крупные рискованные ставки в странах с наибольшим потенциалом, таких как Индия и Бразилия, чтобы мы могли как следует изучить их рынок. Нам нужны победы, но еще больше нам нужны крупные, громкие поражения, на которых мы сможем учиться. Нам нужно постоянно задаваться вопросом: «Если мы купим вот эту программу и она провалится, какую информацию нам это даст? Если какую-то большую и важную, нужно покупать». То есть, Нетфликс спокойно могла позволить потерять несколько миллионов долларов — но компания прогнозировала этот ущерб. И здесь ключевые слова: значительный и непрогнозируемый. Если ущерб не значительный — то можно не думать и даже не особо волноваться на этот счет. Если ущерб значительный, но прогнозируемый — то почему бы и нет? #чф #ошибки

Заметки на полях Ошибка продуктовых компаний: они часто измеряют то, что растёт, а не то, что объясняет экономику продукта Например, онлайн-кинотеатр измеряет часы просмотра и рапортует, что они выросли на 2%, примерно до X млн. часов. Но если аудитория при этом выросла быстрее, то watch hours per subscriber могли снизиться. То есть агрегированная метрика позволяет рассказать историю «engagement растёт», даже если средний пользователь смотрит меньше. Это универсальная ловушка: для растущих платформ абсолютные метрики почти всегда выглядят лучше когортных. Поехали дальше. Но возможно, watch hours per subscriber вообще не главная метрика онлайн-кинотеатра. Пользователь платит не за каждый просмотренный час. Он платит за опциональность: «Когда мне захочется что-нибудь посмотреть, у сервиса будет что предложить». Ценность продукта не обязана быть пропорциональна интенсивности использования. Поэтому человек, который посмотрел онлайн-кинотеатр 8 часов, необязательно менее ценен или менее удовлетворён, чем человек, посмотревший 25. Для бизнеса гораздо важнее: есть ли у пользователя достаточно причин не отменять подписку? Поэтому engagement надо связывать не с количеством часов, а с вероятностью продления подписки. Интересная продуктовая метрика могла бы выглядеть скорее так: контент → просмотр → ценность → retention → revenue. И тогда может оказаться, что дополнительные 10 часов просмотра почти ничего не дают retention.А один сериал, который человек действительно ждал, даёт очень много. То есть не все часы одинаковы. Более того: разные типы просмотра имеют разную экономическую ценность. Час прямой трансляции ЧМ по футболу и час сериала одинаково попадут в метрику watch hours. Но бизнес-эффект может быть совершенно разным. Сами понимаете, почему.

Еще вот таким балуюсь на досуге. Хочу автоматизировать создание роликов-туториалов для новой платформы stepimy.com не за все деньги мира, т.е. бесплатно, локально и относительно быстро. Готового сервиса нет, но есть два бесплатных куска, собранных вместе. Облачный диктор Google Chirp 3 HD читает мой текст: миллион знаков в месяц бесплатно, это примерно полторы тысячи роликов. Дальше Chatterbox под лицензией MIT перекрашивает чужой голос в похожий на мой. Ему нужны 20 секунд моей начитки как образец, и всё. Считает локально. Первое, обо что споткнулся при выборе, – это лицензии. Русских бесплатных голосов много, но ролик для платного сервиса, а это коммерческое использование. Silero и Piper ruslan – CC BY-NC, нельзя. У Piper irina права вообще не указаны, тоже мимо. Остались CC0-голоса Piper, MIT у Chatterbox и Chirp по бесплатному тарифу. Перед тем как брать голос, обязательно читайте лицензию корпуса, на котором он обучен. Второе: как понять, что синтез не сжевал слово. Готовую озвучку прогоняю через распознавание и сверяю со сценарием. Автотест на речь. И само собой слушаю сам. Три вещи, которые нашлись только замерами. 1. Теги пауз модель не понимает. Вместо тишины в записи слышно, как она читает тег вслух. 2. Знаки препинания дают разную тишину: запятая 0,15 секунды, тире 0,24, точка с запятой от 0,3 до 0,7, точка 1,25. Поэтому в тексте для голоса запятые заменены на точку с запятой, а на экране в субтитрах остались нормальные запятые. 3. Слово "хэшем" модель приняла за аббревиатуру и прочитала по буквам: "х-э-ш-е-м", полторы секунды вместо полусекунды. Лечится написанием через "е". Далее чтобы не искать только ухом, сборка сама ищет в распознавании подряд идущие однобуквенные "слова" и называет виновника. Картинку тоже никто не записывает руками. Сценарий ролика – это код: открыть страницу, навести курсор на кнопку "Создать доступ", нажать, подождать. Браузером управляет Puppeteer, клики настоящие, курсор дорисован прямо в странице, кадры снимаются с движка и потом собираются в видео. Поменялся интерфейс – ролик переснимается командой, а не заново записывается руками. Итого: бесплатно, локально, считайте безлимитно для моих задач. Да, не elevenlabs, но в этом случае и не надо.

Чистота комьюнити Иногда, чтобы сообщество, близкое по вайбу, жило, развивалось и просто участники норм могли общаться, надо периодически чистить/кикать участников, кто по вайбу просто не подходит, а если этого не делать, то то, что кто-то развивал годами может разрушиться. У меня на это взгляд как у фэйс-контроля в ночном клубе: там тебе могут не пустить не потому что у тебя какие-то неверные научные/политические/культурные взгляды, а просто по вайбу этого ночного клуба ты не проходишь. Еще ближе аналогия - стебные рилсы вышибалы из "вечеринки для 35+", когда, чтобы пройти фейс-контроль, тебе дают кассету с вытащенной пленкой и карандаш, а только если ты трушный чувак из 90х, поймешь, что надо карандашом крутить касету. Клуб интересен, потому что близкие по духу люди там.

Хорошие ошибки То есть, у нас есть хорошие и плохие ошибки. На мой взгляд, критерием как мы можем отличить «хорошую» ошибку от «плохой» являются два вопроса: 1. получим ли мы новое знание от этой ошибки 2. может ли ошибка принести значительный ущерб Значительный — больше чем мы планируем потерять. По тому как процессы работают с отклонениям их можно расположить между двумя полюсами: 1. процессы, где отклонение приведет к значительной неудаче, катастрофе или аварии. Это обслуживание и управление самолетами, работа атомных электростанций, содержание опасных вирусов, управление машинами, массовое производство и тому подобные процессы. 2. процессы, где вариативность можно и нужно наращивать. Творчество, создание кинофильмов, поиск новых сплавов и/или материалов, разработка новых идей, поиск новых вирусов или молекул лекарства и так далее. Если мы хотим получить что-то новое — то надо начать делать неожиданные вещи. Понятно, что не надо хаотично дергать руль автомобиля, но попробовать новый варианты доехать до работы или с работы или попробовать новую кухню — хороший вариант. То есть, в ряде процессов нам надо наращивать вариативность или количество разнообразных ошибок. Можно запланировать систему, которая будет искать эти «полезные ошибки». Равно как Талеб предложил построить антихрупкую систему, которая за счет ошибок становится прочнее, точно также можно и настроить систему, которая будет искать эти новые возможности, и в том числе за счет ошибок — будет становится лучше. В обучении есть интересный парадокс: самое полезное для нас знание мы узнавали случайно. То есть, благодаря какой-то ошибке и какой-то вариабельности процесса. #ЧФ #ошибки

Онбординг это не тур по продукту, а последовательность убеждения. Порядок экранов решает больше, чем их количество Мне попался разбор онбординга одного подписочного приложения: после переделки 94% тех, кто начал онбординг, доходят до пейволла. Не покупают, а именно доходят, то есть их не теряют по дороге. Подход показался интересным и применимым почти к любому продукту с подпиской, поэтому делюсь. Старая версия открывалась туром по фичам: welcome, три-четыре экрана про то, что умеет приложение, и только потом вопросы. По сути питч-дек, и люди отваливались ещё до оффера. Идея переделки простая: человеку плевать на ваши фичи, пока он не почувствовал, что его понимают. Поэтому логику перевернули. Сначала спрашиваем про его проблему, потом показываем решение. Каркас нового флоу: 1. Идентичность первой. Имя и пара базовых вопросов до всего остального. Это запускает ощущение, что продукт делают под меня, с первого экрана. 2. Контекст. Как часто у человека возникает проблема. Это калибрует, как дальше лягут копирайт и цифры. 3. Желание до фич. Спрашиваем, что человек хочет получить, ещё не показав ни одной фичи. Ищем работу, которую он нанимает продукт сделать. 4. Инвестиция. Экраны предпочтений как будто настраивают продукт под ответы. Человек уже вложился, хотя ничего ещё не построено. 5. Доверие. Отзывы и social proof идут после шагов вовлечения, а не на втором экране. Доверие заходит лучше, когда уже есть чувство собственности. 6. Разрешения. Пуши просим после того, как ценность уже почувствована, и никогда не блокируем прогресс из-за отказа. 7. Усиление боли. Четыре вопроса про одну и ту же проблему с разных сторон, включая эмоциональный: как это ощущается. Боль проговаривается словами пользователя, а не вашим копирайтом. 8. Мы вас услышали. Экран с надписью персонализируем на пару секунд закрывает петлю после вопросов про боль. 9. Доказательство боли. Статистика прямо перед оффером, пока проблема максимально свежая: это не только ваша беда, это распространено. 10. Оффер. Paywall ровно в тот момент, когда проблема максимально выпуклая. 11. Аккаунт последним. Регистрация только после покупки, а не до неё. #PG_education @productgames

Волей случая посмотрел несколько видосов, как фаундеры всяких стартапов презентуют новый апдейт или фичу. И казалось бы, люди заморочились, все спланировали, студию сняли, свет поставили, звук настроили, скрипт написали, фаундера на табуреточку посадили и... заставили читать с телепромптера. И это так крипово! У человека, читающего с телепромптера, энергия оленя, выбежавшего в свет фар: все вычислительные ресурсы мозга идут на попытку понять, че там написано, в результате ни эмоций, ни интонаций, ни естественности. Зритель, который смотрит это, думает: зачем тут я? Выступающий явно с бумажкой общается, а не со мной. Решение тоже простое: напишите скрипт, но пусть человек расскажет его своими словами. Он же фаундер! Он все эти идеи придумал, он их по сто раз всем рассказывал, он уже отполировал, как эффективнее всего их продать, наловчился, так сказать, объяснять. Ну вот пусть это еще раз, на камеру сделает. Ну запишете пять дублей, а не один. Ничего страшного. Все равно этот ролик потом монтируется. Ну будут там всякие у-му-ой-кстати. Ну и отлично! Живость, спонтанность, энергия живого общения. Легкая неопределенность, небольшой риск сказать что-то неправильно — это все чувствуется. Понятно, что не все люди по природе харизматичны или хорошие ораторы. Но этого и не требуется! Сама по себе живая, естественная речь любого человека держит внимание уже ого-го как. Как, по-вашему, работают разговоры? Почему собеседник не уходит через минуту? Потому что ему интересно, а неотполированность речи держит интерес, заставляет мозг чуть слегка сильнее работать, чтобы отфильтровать неровности. И вуаля! В общем, я удивлен, что никто этой механистичности не видит и не осознает, а все играют в ведущих теленовостей (которые, во-первых, всю жизнь тренируются, а во-вторых не сильно-то лучше у них получается), а когда выходит криповая ерунда, делают, наверное, вывод, что они «просто не умеют говорить на камеру». А ничего уметь и не надо. Надо просто сесть и рассказать все как есть. Не будьте, котороче, роботами, будьте человеками. Баранкину привет.

/btw на максималках или Codex side chat Продолжаем рубрику подборка лучших UX решений. Когда кодишь с агентом довольно часто возникает ситуация, когда из одного чата нужно быстро форкнуться в новый чат, чтобы исправить что-то, возникшее по пути, не прерывая работы в старом чате. Раньше мы использовали fork для этих целей, но форк довольно тяжеловесный + не из всех состояний он доступен. В общем, если выделить текст в прямо чате Codex App'а, то сверху можно увидеть всплывающее меню с разными действмия, в т. ч. Ask in side chat. Наверное, видели. Можно подумать, что это старый добрый /btw а-ля клод код. Но нет, на деле у этого сайд чата тоже есть полноценный write доступ и из него действительно можно делать небольшие правки (например, в скиллах, как на скрине) прямо по ходу основной задачи, вообще никак в нее не вмешиваясь. Не знаю как вам, но мне не хватало такой возможности - настолько, что решил и вам рассказать. Напомню, что ранее я уже рассказывал про неочевидную удобную возможность реордеринга (как это по русски подскажите в комментариях) очереди сообщений в Codex App. Если не видели - посмотрите. А еще, теперь можно попросить Codex App запустить какую-то задачу в новом диалоге и он прям из текущего чата спавнет вам новый диалог. И читать сторонние или текущий диалог Codex App теперь тоже умеет. Подробнее про то, как это работает рассказывал Тимур. И да, в Claude Code Desktop тоже есть подобный side chat, но он readonly, что не так интересно, хоть и удобно иногда что-то доспросить. @ai_driven

Басня: система и ее части Одна автобусная компания решила создать «лучший в мире автобус». Они разобрали лучшие машины конкурентов, взяли самый надежный двигатель от одной марки, лучшую подвеску от другой, идеальную коробку передач от третьей. Когда они попытались собрать всё вместе, детали даже не подошли друг к другу. Система - это не сумма её частей, а продукт их взаимодействия. Пример в IT У вас четыре продукта. Если вы наймете лучшего UX-дизайнера для Продукта А, лучшего data-инженера для Продукта Б и лучшего маркетолога для Продукта В, но заставите их работать изолированно, ваш портфель не станет лидером рынка. Или другой пример: попытка взять «лучшие практики» из разных фреймворков (Scrum, SAFe, Basecamp Shape Up) и слепо объединить их в один процесс без учета культурного контекста компании приведет к коллапсу разработки. Вывод Улучшение отдельных частей системы может ухудшить систему в целом. Фокусируйтесь на интерфейсах взаимодействия между вашими продуктами и командами, а не на локальной эффективности каждого из них. P.S. Кайфую от системной логики. Божечки, почему я так долго откладывал это обучение😍 #продуктовыйпуть

Как автомаркетплейсы адаптируются к эпохе AI помощников В свежем выпуске AIM Group Automotive Marketplaces Annual вышла моя статья на тему использования LLM технологий в популярных продуктах для покупки авто. Целиком опубликовать не могу, отчет распространяется по подписке, но хочу поделиться ключевыми фактами и мыслями. Большинство маркетплейсов уже понимает, что нужно защищать свои позиции, чтобы клиенты со временем не ушли искать и выбирать машины в ChatGPT. Ведь в какой-то момент долгий путь поиска и принятия решения о покупке машины с помощью чтения обзоров и отзывов, сравнения цен и характеристик, просмотра сотен объявлений, может свестись к запросу в AI чате вида «У меня семья и двое детей, езжу в основном в городе, не хочу тратить много на обслуживание авто. Подбери мне подходящие варианты с низким ежемесячным платежом». Или, что ещё хуже для маркетплейса — «На основе того, что ты про меня знаешь, посоветуй варианты покупки нового авто». Способы защиты могут быть разные. 📌 Кто-то делает своих умных помощников и встраивает их прямо в интерфейс поиска — CarGurus, Auto.ru. 📌 Кто-то запускает это как отдельный сервис с громким пиаром — Carson от Cars.com и Mobee от Mobile.de. 📌 Кто-то интегрируется в экосистему OpenAI с помощью создания приложений, которые умеют лучше понимать контекст и содержимое базы маркетплейса — CarMax, AutoTrader, OLX (Otomoto). Разобрал несколько примеров внедрения LLM технологий в продукты глазами покупателя авто. Вспомнил молодость и провел мини юзабилити исследование — прогнал несколько типичных сценариев использования от простого поиска машину под определенную задачу до сложных кейсов типа «Какая машина самая лучшая в мире?» на каждом сервисе. Забавно, но несколько участников исследования хорошо справились с этим запросом — пошутили, что такой машины не существует, у каждого она своя, задали уточняющее вопросы и смогли выдать список вариантов со ссылками на актуальные объявления. В итоге получился рейтинг по моей субъективной оценке удобства и пользы от LLM для покупателя авто. Кому интересна тема, пишите, скину статью в pdf. #aifuture #marketplaces #aimgroup

СРО жалеет о существовании профессии продакт-менеджера У Лении вышел подкаст, где СРО Том Веррилли (ex-Twitch, ex-Twitter) о том, как ИИ обнажает масштабы «продуктового театра» Тезисы:

- управление продуктом — это навык, который приобретается на практике, а не просто должность, и иногда командам лучше, когда инженеры и дизайнеры принимают решения самостоятельно - системное мышление становится всё более востребованным - главная польза ИИ для продакт-менеджеров сейчас заключается в Data Science, а не в прототипировании - лучшие менеджеры по продукту сосредотачиваются на технических деталях, понимании клиентов и принятии решений - Роль смещается от «политики» и «совещаний по согласованию» к отдельным специалистам, которые выполняют реальную работу и углубляются в детали продукта - Для роста следует думать о том, как система работает в масштабе, представить все возможные проблемы, а затем исправить их до того, как они произойдут - При найме сотрудников ищите людей, которые могут защитить свои идеи, используя данные, а не тех, кто просто умеет говорить и заводить друзей - Любимая ошибка Верилли за карьеру — доверять средним показателям. Фичу с 3 процентами использования легко списать как бесполезную. Но для этих трёх процентов она может быть единственным сценарием использования продукта. Отключил фичу — обрушил чей-то бизнес.

Прочитайте это, прежде чем оставлять только одну услугу в агентстве 🔵В прошлом посте закончил на том, что в нашем агентстве из услуг мы оставили только одну – исследования. Рассказываю, чем это обернулось) Ставка выглядела логично. Работали мы в основном с корпоратами, а они заказывали исследования регулярно. У нас был один заказчик, которому мы за год отгрузили порядка 90 исследований. Каждый месяц собирали для них конкурентные исследования по разным продуктовым направлениям, помогали запускать продукты, делали качественные и количественные исследования для их продуктовых команд. То есть клиент платил не разово, он платил ПОСТОЯННО. А потом в 2022 корпораты порезали бюджеты и забрали исследования внутрь. И в какой-то момент у нас не осталось ни одного клиента, который платит регулярно... Вот тут и вылезла главная проблема. Мы продаём дорого и качественно, чек хороший, работа классная. Только каждого клиента приходится привлекать ЗАНОВО. Сделал проект, получил деньги, и по новой ищешь следующего)) Мы несколько лет еб*лись с этим и пытались что-то сделать: искали новые типы клиентов и услуг внутри исследований, где появились бы повторные заказы. Уходить из исследований очень не хотелось, там уже была собрана команда и настроены процессы. И, главное, что стабильные лиды то тоже были. Сайт мы качали через SEO с 2021 года, по коммерческим запросам стояли в топе выдачи, и заявки шли стабильно каждый месяц, в том числе от классных крупных компаний. Самая тяжёлая часть задачи была решена. Клиенты приходили сами, а бизнес всё равно топтался на месте - лиды есть, а LTV нет. Если коротко, то вот вывод, который я сделал: высокий чек ничего не гарантирует, если клиент разовый. Можно быть загруженным по уши, продавать дорого (как-то продали клиенту исследований на 1,5 млн) и при этом каждый месяц начинать с нуля. А добила эту историю ещё одна вещь, про которую расскажу в следующем посте...

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

На фотографии – пульт от моего телевизора. Ему лет десять, он похож на предыдущий и, надеюсь, он не будет похож на следующий.   Сейчас, к счастью, эра классических ТВ-пультов уходит. Я держал их в руках годами, но если быть честным - понятия не имею, зачем нужны 80% этих кнопочек. Тем более, всегда можно выйти в меню и там натыкать, что угодно.   Этот вопрос волновал не только меня, но и Мартина Линдстрома, которому однажды повезло путешествовать вместе с инженером компании, разрабатывающей пульты. Разгадка оказалась не в эргономике, а в психологии корпоративных войн.   Пульт один, и он маленький. А телевизор — это не просто экран, а конгломерат сервисов: кабельное, стриминг, интернет, приложения, игры и т.д.   Каждая из этих фич приносят деньги. Каждой занимается отдельный дивизион внутри корпорации. И для руководителей этих направлений пульт не средство управления, а самая дорогая недвижимость в мире. Все хотят иметь свой, пусть и маленький кусочек.   Поэтому инженеры, отвечающие за разработку пультов, искренне гордятся результатом: «Смотрите, как виртуозно мы впихнули и поделили пространство между всеми игроками!». Потому что пользователь далеко, а всякие вице-президенты весьма близко.   Пульт - это такая овеществленная иллюстрация закона Конвея: "организации проектируют системы, копирующие структуру коммуникаций внутри этой организации".   Я стал специально проверять – и да, в каждой компании можно найти собственный «пульт». Такой памятник корпоративным интригам, условностям и амбициям. Эти объекты имеют глубокий смысл внутри конкретного ООО, но абсолютно чужды и даже враждебны для покупателей.   (пульт от Apple TV хвалим в комментах 😉) | MAX | подкаст | | Личная жизнь и мысли - Молчанов.Life |

Продуктовый кейс на собеседовании: на что смотрит интервьюер Менеджеров продуктов часто просят решить кейс, чтобы показать свои знания и навыки. Казалось бы, есть CV, метрики и реальные результаты. Зачем тогда кейс, оторванный от реальности? Продуктовый кейс — это не экзамен с верным ответом, а небольшая симуляция вашей будущей работы. Компании важно не просто увидеть решение, но разглядеть за ним вашу систему принятия решений. Далее разберемся, что обычно под этим подразумевают и как это продемонстрировать. Первое — умеете ли вы правильно поставить задачу. Когда кандидат слышит: «В продукте упала конверсия. Ваши действия?», первой реакцией может быть — найти технический баг и вернуть все в нормальное состояние. Но конверсия могла упасть по разным причинам: изменение трафика, баг в аналитике, проблемы на отдельной платформе, изменение цены или статистическая флуктуация. Когда кандидат сразу предлагает решение, он показывает один подход к работе: сначала действовать, потом разбираться. Когда он размышляет глубже, сначала он конкретизирует проблему. Тогда меняется формулировка и дальнейших вопросов, и поставленной задачи. Например, не просто «нам нужно увеличить ретеншн», а: «нужно увеличить ретеншн 30-го дня новых пользователей на рынке X, так как экономика привлечения не сходится». Второе — умеете ли вы декомпозировать проблему. Интервьюеру важно увидеть не количество гипотез, а способность построить модель происходящего. Если падает выручка, можно сразу обсуждать тарифы и промокоды. А можно сначала разложить, из чего складывается выручка, как формируется клиентская база, что происходит с трафиком, конверсией, частотой покупок и средним чеком. Такая декомпозиция показывает, что вы умеете уменьшать пространство неопределенности, а не просто генерировать идеи внутри него. Третье — понимаете ли вы, какой информации вам не хватает. Один кандидат молча делает предположения или, наоборот, задает десятки вопросов подряд. Другой сначала формулирует гипотезу: «Я бы проверил, связано ли падение с изменением трафика или с ухудшением самой воронки. Для этого нужны данные по источникам и конверсии между этапами. Какие они были за последний период?». То есть вопрос появляется из модели проблемы. Вы не собираете все доступные данные, а понимаете, какая информация поможет принять следующее решение. Четвертое — умеете ли вы выбирать. Кандидаты часто хорошо проходят первые 80% кейса: строят дерево метрик, выделяют сегменты, предлагают гипотезы. А потом говорят: «Можно попробовать A, B, C, D и E». Но как понять, что будет сделано в первую очередь? В одном случае кандидат ответит, что выбрал вариант А, ведь под него уже готова система. В другом случае кандидат тоже скажет, что выбрал вариант А, но пояснит, что выбор сделан с учетом скорости реализации и рисков, а также перечислит критерии принятия решения. Для интервьюера это будут два совершенно разных ответа. Здесь проявляется умение работать с ограниченными ресурсами: выбирать с учетом потенциального эффекта, рисков, стоимости и скорости проверки. Пятое — способны ли вы изменить собственную гипотезу. Как и в жизни, в кейсе могут внезапно появиться новые вводные. Например, в середине кейса вам говорят: «оказалось, что конверсия упала только на iOS». Это не столько подсказка, сколько проверка: готовы ли вы перестроить рассуждение или продолжите защищать первоначальную идею. Способность учитывать новую информацию — один из сигналов того, как кандидат будет действовать в реальной работе. В итоге хороший продуктовый кейс проверяет довольно простую вещь: способны ли вы самостоятельно пройти путь

симптом → цель → структура проблемы → гипотезы → данные → выбор → решение → проверка результата

а не сократить его до:

симптом → идея

@productmindset