Продукт

Декабрь 1985 года. Команда Стива Джобса заявила ему, что назначенный им срок выпуска — это «искажение реальности». Стива согласился с их доводами, но всё равно настоял на своей дате. Запись этого разговора раскрывает принцип принятия решений, который так и не усваивают многие продакты и основатели. Компании NeXT всего 90 дней, она финансируется из личных средств Джобса, вложенных после его ухода из Apple и уже на первом совещании команда обсуждает перенос запуска с весны 1987 года на весну 1988-го. Возражения звучат жестко. Один из сотрудников приводит факты: «У нас есть человек, который обещал сделать текстовый процессор за полгода, а работа растянулась уже на три года». Другой указывает на опасность: «Искажение реальности – вымышленная дата, и все принятые на её основе проектные решения впоследствии придется перечеркнуть». Джобс не спорит: «Что ж, Джордж, я не могу изменить мир». (– ахахахаха, Стив, комоооон) Он настаивает на другом: «Я считаю, что мы должны обозначить чёткую веху. И если мы упустим это окно, то в игру вступит целая цепочка событий. И если мы не сможем продать достаточно устройств в 87-м, мы не сможем покрыть наши операционные расходы... ...У нас есть 18 месяцев. И я не думаю, что компания выживет, если мы этого не сделаем. Что бы ни говорил я или кто-либо ещё, я глубоко в этом убежден. Если мы этого не сделаем, мы не сможем привлечь отличных специалистов. Мы не сможем удержать даже тех, кто у нас уже есть». TLDR: Команда оперировала оценками сроков, а Джобс — условиями выживания. – Оценка говорит о том, когда работа может быть завершена, и допускает обсуждение. – Условие определяет момент гибели и бесповоротную точку чего-либо, и оно не подлежит обсуждению. Именно поэтому установленный срок остался в силе. Джобс привязал дату не к оптимистичным прогнозам, а к рыночному календарю и запасу прочности компании. И все могли оспорить график работ, но никто не мог оспорить критическую важность этого временного окна. Неудобная для основателей Истина в том, что если ваш дедлайн основан на оценках команды, он неизбежно сдвинется. Если же он диктуется законами рынка, то это вовсе не дедлайн, а условие выживания (замаскированное рынком под дедлайн).

Валидация — это мираж «Как проверить, сработает ли фича?» «Как понять, стоит ли разрабатывать продукт заранее?» «Как узнать, будут ли люди покупать это?» «Как подтвердить соответствие продукта рынку?» «Как проверить UI/UX/механику...» Никак. Никак. Никак. Никак. Никак. Нельзя проверить Идею. Нельзя валидировать догадку. Нельзя валидировать абстракцию. Нельзя валидировать эскиз, макет и MVP. Нельзя проверить то, чего ещё не существует. Наш мозг ищет уверенности заранее, ему сложно вернуться к работе в ином режиме. Но отсчёт времени начинается не тогда, когда вы приступаете к работе или когда готов какой-то фрагмент Целого.

Он начинается только/ровно в тот момент, когда готовый продукт/фича становятся публичными и выходят на рынок

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

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

Есть лишь один способ максимально приблизиться к уверенности — создать реальный продукт/фичу и выкатить их в паблик, чтобы их можно было: попробовать (→) использовать (→) купить. Потому что именно так ВСЁ работает в реальности. Именно так работает реальность. Реальное использование реального продукта в реальных условиях и в ходе реальной работы — вот тот единственный способ что-либо проверять. Поэтому самый работающий в реальности способ всё выяснить — поверить в идею, воплотить её в жизнь и выпустить её в мир. Вы делаете все, что в ваших силах: 1. вы Это Предчувствуете; 2. вы Это Видите 3. вы формируете Намерение 4. вы двигаетесь сквозь Это вместе Продукт — это совокупность взаимосвязанных элементов: они зависят друг от друга, перетекают один в другой, интегрируются между собой. Нельзя взять кусок продукта, спросить людей, нравится ли он им, и сделать вывод, что им понравится и остальная часть, когда она будет готова. Так вы узнаете лишь то, нравится ли им конкретно этот кусок, который вы им дали.

Все экстраполяции/валидации и верификации – додумки и обман нашего мозга.

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

Разбор управленческого решения недели 06-10 июля. Хочу попробовать новую рубрику - раз в неделю буду рассказывать, какие управленческие решения мы принимаем внутри компании и почему. Что было придумано на прошлой неделе ⤵️ Во-первых, продолжили очень плотно заниматься онлайн-записью. Я поставила задачу всем директорам, своим и коллег, максимально внимательно посмотреть на нее глазами клиента. Пересмотреть описания специалистов, привести все к одному стандарту, проговорить с каждым мастером его сильные стороны и обязательно вынести их прямо на витрину. Не просто написать стаж или список услуг, а показать конкурентное преимущество каждого специалиста. Максимально понятно описать навыки, опыт и возможности. Онлайн-запись стала выглядеть живой, интересной и намного более информативной. Если человеку нужен массаж фохоу — сразу понятно, к кому записываться. Если хочется идеальный френч — тоже сразу видно, кто в этом действительно силен. Именно так и должна работать онлайн-запись — помогать в выборе специалиста в том числе. Второе решение касается массажа в нашем новом «тихом» салоне на Пилюгина 6. Мы запустили сильные сезонные предложения на июль и август. По сути, сознательно продемпинговали, дабы загрузить наших сильный спецов - иногда гораздо правильнее дать человеку возможность попробовать качественную услугу по привлекательной цене, чем бесконечно ждать идеального клиента. А дальше уже можно работать через программы, пакеты и повторные визиты. Третье решение касается нового большого салона моего в ЖК Событиях. Мы видим, что Nail & Brow развиваются быстрее, чем стилисты и косметология. Поэтому начали думать, как быстрее познакомить клиентов с этими направлениями. Для косметологии сделали тест-драйв массажа лица в подарок + тест-драйв массажа тела по символической цене (1500Р). Клиент пошел. А для стилистов придумали, как мне кажется, очень интересную механику. Всех клиентов, которые записываются на любую процедуру к нам, будем проводить через нашу SPA-капсулу - уход + укладка в 🎁. Во-первых, хочется, чтобы как можно больше гостей вообще узнали, что она у нас есть. Во-вторых, это отличный способ познакомить клиента со стилистом и дать ему почувствовать совершенно другой уровень сервиса. Наверное, именно из таких десятков маленьких гипотез, которые мы каждую неделю придумываем, пробуем и анализируем и складывается успех в бизнесе. Если такая рубрика интересна жмите ❤️ - включу в постоянный постинг.

Басня о полусыром продукте Печь, которую собирает компания из этой притчи, умеет добавлять свечи на торт, подключаться к камину и работать в режиме «Рамадан». Одного не умеет — стабильно печь: хлеб и торты подгорают в каждом десятом случае. Инженеры однажды нашли выход, стоит убрать из печи один из трёх видов выпечки, и брак падает с трети случаев до 5%. Учредитель запретил. Он обещал инвесторам весь рынок, и теперь ему оставалось выбрать, какое из обещаний нарушить. Дальше история катится сама. Каждая новая кнопка добавляется дольше предыдущей, клиенты возвращают печь через неделю, а служба поддержки уговаривает остаться, обещая ещё один релиз. Замените печь на любой продукт, который вы разрабатывали.

Цикл поиска продукта на основе 100 интервью Пример реализации ф-ции /loop для продактов. 6 этапов, каждый из которых питает следующий: Шаг 1: Извлечение → распределите по одному агенту, работающему по упрощенной модели, на каждое интервью ; каждый предоставит структурированные возможности, описания персонажей и дословные цитаты. Ограниченная, повторяющаяся работа: хайку или сонет, а не опус. Шаг 2: Канонизация → один агент группирует исходные возможности в канонический набор. Экстракторы придумывают новую метку для каждого интервью, поэтому одна и та же потребность возникает под десятком названий; объединение синонимов — это вопрос субъективной оценки, поэтому это модель, а не код. Шаг 3: Оценка возможностей → код ранжирует каждую каноническую возможность по частоте × важности × (5 - удовлетворенность). Модель не выполняет математические вычисления. Шаг 4: Генерация и сортировка → для наиболее эффективных вариантов агент генерирует несколько идей решений ; затем отдельный эксперт оценивает каждую из них по показателю ROI (влияние против затрат на разработку) и оставляет 3 лучших для дальнейшей разработки. Показатель ROI меняет порядок в списке, поэтому недорогая, но эффективная задача может занять место для разработки, освободив его от задачи с более высоким баллом. Шаг 5: Разработка → Для 3 лучших идей по ROI агент использует навыки фронтенд-дизайна, чтобы написать уникальный, кликабельный HTML-прототип, который я могу открыть. Шаг 6: Проверка и повторный запуск → проверка выявляет любой прототип, который не удалось отобразить, или любую извлечение данных, показавшее низкую степень достоверности, и рабочий процесс повторно запускает только этот этап. Это и есть настоящий цикл: результат одного этапа определяет, будет ли повторно запущен предыдущий этап. === 113 агентов потратили 1,95 млн токенов за 12,5 минут. 3 из 3 прототипов были созданы и проверены. JavaScript-код, отвечающий за маршрутизацию, оценку, контроль и зацикливание, не потратил ни одного токена модели.

Мои хорошие знакомые из студии "Грознов" сделали прикольный проект для банковского сектора. Они запустили игру "Этажи" - раннер, встроенный прямо в интернет-банк Альфа-Бизнес. Главный герой - предприниматель, который бежит вверх по небоскрёбу: от "Подвала стартапов" до "Пентхауса". По пути собирает монеты и купоны, проходит квизы, воюет с еженедельными боссами (каждый олицетворяет какую-то бизнес-проблему). Основная фишка в том, что геймификация здесь встроена в сам банковский продукт, а не вынесена в отдельное приложение или курс. Каждый уровень = реальная бизнес-задача, а квизы прокачивают знания о банковских сервисах в процессе, а не через скучные инструкции. С точки зрения индустрии - интересный прецедент: банки давно экспериментируют с геймификацией, но обычно ограничиваются мини-играми "поиграл-получил кешбэк". Здесь механика сложнее - раннер + квизы + бизнес-задания, которые ведут к реальным действиям в банке. 💭 Как вам ход? Работает ли на вас геймификация в серьёзных продуктах или воспринимается как маркетинговая мишура? #МАРКЕТИНГ #БРЕНДЫ #ГЕЙМИФИКАЦИЯ

Оптимизировать метрики или творить искусство Второе выступление было в МФТИ для преподавателей ВУЗов. Оно было посвящено разбору кейсов про управление образовательными продуктами. До меня слушателям рассказали про продуктовый подход к образованию (в частности, про JTBD и релевантные образовательным программам метрики), мне же предстояло поразбирать это на примерах. Рассказ я построил на семи кейсах: 3 из российской практики (про нашу русскоязычную специализацию по ML на Курсере), 4 из мировой. В каждом случае давалась вводная с описанием ситуации, дальше мы генерировали идеи «а что дальше» и разбирали, чем все закончилось и какие можно сделать для себя выводы из этого. Мой любимый пример был про то, как полярные отзывы о курсе могут быть хорошим знаком, что вы уже нашли ваш сегмент, и остается описание курса, объяснение, для кого подходит ваш курс, и все привлечение построить так, чтобы точнее попадать именно в свою аудиторию. В конце поговорили о том, ремесло или искусство преподавание и надо ли ко всем этим метрикам относиться слишком серьезно. Десятитомный Ландавшиц, например, это бесспорно легендарный образовательный продукт. Но retention, NPS и CSI у него ни к черту. Как и доходимость до конца. А чего стоят одни только шутки про «потерял целую тетрадь выкладок - напишем «очевидно что». Однако сложно представить, чтобы Ландау из-за этого переживал :) Похожая история с Колмоговорым: на него одновременно и жалуются за плохое чтение лекций на мехмате, где мысли сильно опережали речь, и вспоминают с восторгом его «даму с собачкой» (красивое объяснение доказательства основной теоремы алгебры) и учатся всей страной по его учебникам. Увы, далеко не каждый из нас Ландау или Колмогоров, чтобы позволить себе быть плохим лектором и все равно стать лектором и автором легендарным, поэтому нам и нужно смотреть на метрики курсов - чтобы обеспечить базовый минимум и потихоньку его улучшать. Но сам по себе этот базовый минимум, увы, не может заменить преподавателю ни талант, ни творческий подход к работе.

Обратная связь — Поделитесь мнением о продукте, — попросил меня в письме сервис продажи авиабилетов. — Ага, когда-нибудь... Сейчас стало модно собирать обратную связь от пользователей. Нам шлют имейлы, показывают всплывающее окна, пишут в мессенджеры; а мы — молчим. А даже если нет, отвечаем «все норм» и заканчиваем диалог. Пару месяцев назад провел практикум по Claude и тоже попался на эту удочку — решил собрать мнения. Написал 10 людям лично — получил 3 ответа в стиле «вау», одну «гениальная» идею от городского сумасшедшего и 6 тихих игноров. И это от людей, многие из которых знают меня. Тогда поменял подход: взял следующую десятку и написал каждому — «давай встретимся, за 30 минут покажу, как решать твои задачи с Claude в 3 раза быстрее и качественнее». Календарь забился мгновенно. Провел 8 встреч, увидел, где люди реально тупят; от чего конкретно в восторге и что можно смело выкинуть. А еще трое купили следующий практикум. Четыре часа я помогал разобраться людям в Claude, а они мне в моем продукте. И каждый получил вагон пользы. Вывод прост: люди не хотят давать обратную связь. Они хотят получать пользу. Дай им второе и получишь с избытком первое.

Скилл, сэкономивший мне несколько часов в неделю Я часто говорю, что в продуктовой аналитике нужно комбинировать количественный и качественный подходы. Один из инструментов, который сидит где-то посередине между ними: просмотр записей сессий юзеров (clarity, веб визор и иже с ними). В лучших традициях эмпатического проектирования, когда вы наблюдаете за пользователем в естественной среде. НО этот инструмент очень требователен к времени продакта: даже в ускоренном режиме на такую работу приходится тратить часы в неделю, причем это не самое классное времяпрепровождение, если уж быть честным. Хотя там регулярно встречаются прямо уж "золотые инсайты". Собственно, дружбан, вооруженный браузером, мог бы это делать - не так ли? Собственно, такой скилл я и запилил; обкатал на просмотре 500 сессий через clarity mcp. Как работает: 1) Сначала определяем вопросы, на которые хотим получить ответ: например, почему юзеры не подключают LinkedIn 2) На основе вопросов определяется какие сессии взять на "просмотр" 3) Триаж сессий: по таймлайну сессии отбираем насколько она "интересна" для анализа 4) Далее для каждой сессии берем все евенты, в определенные моменты в том числе берем скриншот и анализируем 5) Триангулируем выводы: по базе данных, по исходникам. 6) Анализируем мертвые клики (dead clicks), так как зачастую это классный источник UX проблем 7) Получаем отчет Из неожиданного: отчет для каждого вывода дает ссылки на исходные сесси и в ходе "человеческого" просмотра одной из них я понял, что важно смотреть не только фреймы перед кликами и тп, но и без оных. Потому что тогда можно поймать проблемы типа "непонятная надпись" или "отсутствует call to action". https://github.com/BayramAnnakov/clarity-session-review Юзайте на здоровье и присылайте улучшения/принципы по мотивам ваших инсайтов

Спустя 3 года я наконец нашел идеальную программу для записи скринкастов, а вернее целых две: 1. 🔥 https://openscreen.net/ — ПРОСТО ОХУЕННО. Программа автоматически находит места взаимодействия курсором и зумит на них. Всё это с прекраснейшеми ease in\out эффектами и без единого действия со стороны пользователя 😍 Но при этом можно добавлять и свои, менять фоны, отступы, добавлять тени, экспортировать сразу в 720р\1080р\оригинале mp4 или gif. Как же долго я ждал такое в Windows. На макоси был аналогичный screen.studio, но он стоит 29$ в месяц. А OpenScreen полностью бесплатный. Просто 1000 из 10. 2. 🔥 N-Studio — тоже полностью бесплатная мини-аппка для записи экрана, но лучшее её применение это запись отдельного участка экрана. Экспорт практически "на лету". Я очень не люблю когда вот эти все ОГРОМНЫЕ КОМБАЙНЫ для записи экрана грузятся на терабайт памяти из глубин системы, предлагают мне тысячи онбордингов, просят СОЗДАТЬ И СОХРАНИТЬ проект, потом записываешь, потом гумозный перемудрёный экспорт и пока это делаешь уже просто думаешь «бля да лучше бы я картинкой отправил». И вот N-Studio это такая микропиздюля как ScreenToGif но сделана лучше и быстрее. Снял и сразу файл получил. 999 из 10. Прощай Camtasia. UX сингулярность практически достигнута.

Да — в Duolingo действительно появился раздел/курс по шахматам в приложении, и его позиционируют как новый обучающий формат рядом с языками, математикой и музыкой. [ru.duolingo](https://ru.duolingo.com/chess) ## Что можно подтвердить - На странице Duolingo есть отдельный шахматный курс с описанием обучения для новичков и для тех, кто хочет освежить навыки. [ru.duolingo](https://ru.duolingo.com/chess) - В App Store у приложения Duolingo указаны не только languages, но и Chess, а также Math и Music, то есть шахматы встроены в продуктовую линейку приложения. [apps.apple](https://apps.apple.com/ru/app/duolingo-languages-chess/id570060128) - В русскоязычных публикациях пишут, что курс уже начали выкатывать части пользователей, сначала в бета-версии и с постепенным расширением доступа. [hi-tech.mail](https://hi-tech.mail.ru/news/125814-duolingo-kurs-po-shahmatam/) ## Как это устроено - Обучение идет короткими интерактивными уроками, мини-задачами и партиями против виртуального тренера. [hi-tech.mail](https://hi-tech.mail.ru/news/125814-duolingo-kurs-po-shahmatam/) - В описаниях упоминается персонаж Оскар, который помогает проходить уроки и подсказывает ходы. [hi-tech.mail](https://hi-tech.mail.ru/news/125814-duolingo-kurs-po-shahmatam/) - Позиционирование очень понятное: сделать шахматы более доступными и «легкими для входа» через формат, похожий на языковые уроки Duolingo. [hi-tech.mail](https://hi-tech.mail.ru/news/125814-duolingo-kurs-po-shahmatam/) ## Полезная фактура для поста - Формулировка: «Duolingo расширил приложение за пределы языков — теперь там есть шахматы». [apps.apple](https://apps.apple.com/ru/app/duolingo-languages-chess/id570060128) - Акцент: «курс ориентирован на новичков и идет в коротком игровом формате». [ru.duolingo](https://ru.duolingo.com/chess) - Контекст: «это продолжение стратегии Duolingo по добавлению новых обучающих вертикалей после математики и музыки». [apps.apple](https://apps.apple.com/ru/app/duolingo-languages-chess/id570060128) ## Возможный angle Можно подать это не как «Duolingo добавили шахматы», а как «Duolingo превращается из языкового приложения в образовательную платформу с несколькими навыками». [apps.apple](https://apps.apple.com/ru/app/duolingo-languages-chess/id570060128) Могу сразу собрать это в готовый короткий пост для Telegram или LinkedIn в твоем стиле.

Обновление Яндекс Музыки, которое вызвало шквал возмущения в соцсетях, критиковали внутри самого Яндекса перед релизом, но эффективным менеджерам было плевать Яндекс Музыка выкатила большое обновление в конце мая. Само обновление было давно, но мне попал в руки скриншот из внутреннего мессенджера с обсуждением этого релиза. Расскажу контекст. Яндекс предлложил юзерам новый инновационный сценарий взаимодействия с приложением — это выбор настроения треков. То есть не свои подборки или определённый жанр музыки, а именно настроение, сформулированное долбоёбскими AI-слопными формулировками: «неделя до диплома (ааа)», «свидание 10 из 10» или «секс под грустную музыку». Вдобавок дизайнеры накрутили некоторые спорные решения, например, кнопки «вперёд/назад» убрали с экрана трека, потому что по задумке перелистывание настроения важнее. Прило стало лагать на слабых девайсах, а некоторые любимые пользователями функции переместили подальше так, что их не найти. Пользователи были в ярости. Вот цитата самого популярного отзыва на Пикабу (орфография автора сохранена): Яндекс.Музыка, хотите отзыв? Идите НА ХУЙ с такими обновлениями. Вот реально, я максимально лояльный пользователь, по жизни вежливый и культурный, но ваше приложение, а точнее — ее обновление, просто вывело меня из себя и сдерживаться я не буду. Вы делаете ГАВНО! И за мои же деньги, мать вашу, вы меня им кормите! Сотрудники Яндекса, которые тестировали приложение до релиза, говорили, что получается плохо, но руководство Я.Музыки отвечало на это примерно так: вы просто не понимаете проблематику и внутреннюю кухню сервиса, а мы понимаем. Релиз обсуждали долго, сотрудники несколько раз пытались донести, что сервис совершает ошибку. Пипл схавает. Какая разница? Последствий всё равно не будет, аудитории некуда переходить. Яндекс монополист с более чем половиной российского рынка стриминга. Тем более по инфе из официального пресс-релиза новый интерфейс повысил такие важные метрики для пользователя, как переход на страницу артиста на 11% и уменьшил количество дизлайков в «Моей волне» на 4%. К посту приложил скрин из корпоративного мессенджера Яндекса с хронологией внутреннего спора о новом дизайне Я.Музыки от одного из сотрудников. И вот самое интересное там: 0. Зацените этот пассивно-агрессивный тон вкупе с корпоративно-ебланским языком. Это владение на уровне мастера. 1. Вы удивитесь, но в самом Яндексе признают агрессивную монетизацию своих сервисов, их перегруженность и неудобство, рекламу на каждом квадратном сантиметре и дарк-паттерны. 2. В Яндексе тоже считают, что в подписку Яндекс Плюс в нагрузку включены ненужные сервисы. Подписка дорожает, а качество этих сервисов ухудшается. 3. Ну и вишенка — работники Яндекса НЕИРОНИЧНО на серьёзных щщах называют себя «яндексойдами».

Помните я радовался, что подключил MCP в Lovarus.ru?

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

Так вот, сегодня я проснулся, и меня озарило - это все дешевые понты. Какой MCP для сервиса, у которого целевая аудитория - люди без технического опыта?! Кто в здравом уме пойдет тратить время на регистрацию в каком-то Context7, а потом тащиться в Lovarus с API ключом?! Сервисы типа Lovarus должны сами на себя брать подключение нужных MCP, и пользователь даже не должен знать ничего о них. Короче, решил выпилить эту штуку в ближайших релизах, а точнее скрыть для юзеров. Тоже самое с кнопкой «Исправить», для прогера это прикольно, он привык видеть ошибки, и когда они исправляются по клику на кнопку - это прикольно. Для предпринимателя, фрилансера, кнопка «исправить» - это лишняя фрикция, трата денег и времени. Короче две ближайшие цели, упростить сервис, скрыть технарщину под капот, на выходе только готовый рабочий результат.

Салют!! 🖖 Хочу рассказать про диагностику продукта. Я отсматриваю 5–6 кейсов в неделю — отвечаю за методологию. А до этого прошло через меня около 6500 команд: акселераторы, фонды, вот это всё добро. Первое, что надо понять: есть установки в голове у фаундера, как он думает, что бизнес работает. И есть реальность. Они всегда расходятся. Одно дело мы написали процесс продаж в CRM, другое дело как сейлзы реально по нему работают. На диагностике я открываю продажи, саппорт, аналитику по событиям. Юнит-экономику собираю сам, глазками. Открываю пользователей, которые дошли до покупки и не дошли, и смотрю, где они заблокировались. Команда думает, что у них всё просто с регистрацией. Это и у крупных так, про известные компании сейчас говорю. Три больные темы, которые все знают: 1️⃣ Онбординг: что новый пользователь видит, что понимает, что делает. 2️⃣ Регистрация и авторизация. Проклятое место, очень плохо делается. 3️⃣ Заявки и CRM. Своя или не своя, всё очень плохо сделано. Почти всегда. Я ищу там дырки и гэпы. Любой гэп — потеря конверсии и продаж. И ищу их именно на стыке зон ответственности команд: маркетинг переделал лендинг, а офферы в онбординге старые, потому что за него отвечает другая команда. Закон Конвея: продукт повторяет структуру коммуникации в организации. Отдельный разработчик пилит биллинг, отдельный продакт — онбординг. Конечно, на стыках будет куча проблем. Попробуйте пройти свой продукт как новый пользователь. Или дайте другу: пусть регистрируется и покупает, а вы не помогайте, просто смотрите, где застрянет. Расскажите, что нашли. Интересные случаи разберу в следующих постах.

Кого вы на самом деле дрессируете своими KPI Неважно где и независимо с кем ты будешь работать — рано или поздно в воздухе обязательно возникнет задача: надо поставить команде или командам царь-KPI, по которым их будут потом гонять. Часто ещё, чтобы солиднее звучало, можно назвать это Northstar-метрикой (даже если по продуктовому смыслу она ею и не является). И тут часто есть неочевидная ловушка: любая такая метрика — всегда одна из. Одна из десятка, которые вместе и описывают, как команда работает, но стоит повесить её на стену и сказать команде «вот по этому мы вас и меряем» — как всё остальное тут же уходит на задний план, что логично, ведь мотивация завязана именно на неё. Но цимес в том, что бизнесу эта метрика не всегда приносит пользу. Когда метрика перестаёт быть индикатором или термометром и становится самоцелью, её, понятное дело, начинают стимулировать любой ценой. И вредительства со стороны команды тут никакого нет, если что, — просто так была поставлена задача. И вот так вы быстро оказываетесь в ситуации, когда метрики вроде все зелёные, а финрезультат чего-то не бьёт ключом, а чаще ещё и убыток ловите. И тут сразу всплывает другой вопрос: кто виноват? Ответ — подход к целям. С лёгкостью фокусника, даже вспоминать долго не пришлось, достаю из ментального "загашника":

«Нам нужен дешёвый трафик» → лови дешёвый трафик, но либо нецелевых клиентов, либо с хреновым чеком.

«Нужна ниже стоимость привлечения» → дропаешь цену на товар и убиваешь маржинальность, зато конверсия растёт и стоимость падает. Либо ведёшь на самые дешёвые товары и показываешь номинально хороший результат. Разбираться всё равно не тебе, ты продал.

«Дайте больше лидов» (клэссик стори)→ маркетинг режет форму до одного телефона и нагоняет вагон заявок, план перевыполнен, а продажи потом неделю разгребают этот шлак, из которого в сделку не конвертится почти ничего, — и звучит справедливое «Лиды у вас дерьмовые».

«Нужен NPS повыше» → менеджеры начинают выпрашивать десятки («поставьте 10, пожалуйста, мне за это премия капает»), цифра ползёт вверх, а что у клиента в голове на самом деле — уже хрен поймёшь.

Причём заметьте: люди в этих историях не злодеи и не дураки — они просто делают то, чего от них ждут. Любой KPI — это ведь рельсы: что поощряешь, то и получаешь. А поощряешь ты, если присмотреться, просто цифру, а не тот смысл, который за ней должен стоять. И всё это называется законом Гудхарта, который и придумал-то не он. Сам Гудхарт в 1975-м писал довольно нудную работу про денежную политику британского центробанка, а хлёсткую формулировку — «когда мера становится целью, она перестаёт быть хорошей мерой» — спустя двадцать лет выдала антрополог Мэрилин Стратерн. Но народная любовь досталась Гудхарту, так и живём. Хотя баек на эту тему хватает. Одна из классических: британцы задолбались от кобр в Индии и назначили награду за каждую убитую — а местные быстро смекнули, что кобр выгоднее разводить, чем ловить. Когда программу прикрыли, разведённых змей просто выпустили, и кобр стало больше, чем до всей затеи. Метрика «сдано мёртвых кобр» — выполнена на ура. Из современного и уже нашего с вами: соцсети годами оптимизировали время в приложении — и получили ровно его: залипание, кликбейт и дофаминовую иглу, на которой мы теперь всей планетой сидим. А стартапы носятся с vanity-метриками — скачивания, регистрации, подписчики. В презентации для инвестора это, может, и смотрится бодро, но на вопрос «а заработает ли эта штука хоть рубль» не отвечает никак. При этом сами метрики я люблю и топить против них не собираюсь — без цифр ты в бизнесе просто слепой. Но привычку с годами выработал такую: как только вижу, что какая-то метрика стала «главной» и её начали качать любой ценой — иду смотреть, что творится с соседними. Потому что за благой целью почти всегда тянется неприятная побочка. Да и пост этот я пишу под впечатлением: квартал закрыли отличный, но пару целевых метрик подобрали второпях — вот и отстрелило там, где не ждали. Какую цифру вы натягивали, чтобы она выглядела здоровой? Константин Сухачев

Measuring the Impact of Personalized Recommendations Netflix предлагает раскладывать эффект рекомендаций на три части: • Exposure - тайтл посмотрели, потому что его вообще показали. • Selection - его показали тем, кто и без рекомендации был склонен посмотреть. • Targeting - показ изменил решение именно этого пользователя. Наблюдаемый просмотр смешивает все три эффекта. Поэтому высокий CTR рекомендации ещё ничего не говорит о её причинной ценности - система могла просто хорошо предсказать уже существующий спрос У Netflix чистый targeting почти в семь раз сильнее exposure. То есть основная ценность современного рекомендатора - не в том, чтобы найти релевантный контент, а в том, чтобы найти пользователя, чьё решение рекомендация действительно изменит, а не просто предсказать его выбор И сильнее всего это работает не на хитах и не на совсем нишевых тайтлах, а в середине каталога - там, где спрос существует, но без персонализации не реализуется. https://netflixtechblog.medium.com/measuring-the-impact-of-personalized-recommendations-4c26be3a4d96

Я уже давно говорю, что Open AI делают классные модели, но абсолютно ублюдские продукты. Даже новый ап ChatGPT тому подтверждение: • Есть два режима: чтобы сделать работу и для разработчиков. Разработчикам не судьба сделать работу? При этом переключение тумблера ничего не меняет в интерфейсе. • Абсолютно невнятная навигация. К примеру, чтобы найти скилы, надо зайти в раздел плагины, в которых есть плагины и отдельно вкладка скиллы. Гайды NNG про работу с ожиданиями не дистилировались в модель? Или пролились по пути? Все бы ничего, если бы на фоне не был ап клода, где видно, что продумывают UX, а не вайбкодят в режиме красного кода. Очень плохо. А модели классные, да.

Свобода / несвобода фич в продукте Продукт свободен, когда все идеи-фичи имеют единую, последовательную и связанную логику ⇄ механику ⇄ архитектуру ⇄ CJM ⇄ JTBD, являясь частью Единого Целого настолько, что перестают быть отдельными элементами Системы. Из-за консистентной (наше новое любимое слово с ИИ) логики-механики-архитектуры, такие фичи внедряются с минимальным вложением усилий в эту самую логико-механику-архитектуру. Минимум разработки/багов, минимум новых неизвестных действий для пользователя, единые связанные метрики. Другими словами, каждая новая фича на 98% становится лишь новой фронтовой обёрткой вокруг-поверх-после механики и логики другой, создавая новые линии связей между ними, а не плодит новые "уникальные" фиче-сущности-объекты. Именно благодаря этому, они усиливают друг друга пропорционально, и каждая новая фича кратно увеличивает единственный набор метрик, не вынуждая продакта использовать ранние/запаздывающие/прокси и прочие показатели. И именно поэтому такие фичи работают с минимальными объяснениями – их суть давно понятна на примере прошлых, механика стала привычна, а логика всё неизменно подтверждает. Найти такую фичу просто – удали одну такую фичу из петли-цепочки, и рухнет добрая часть всего продукта.

Несвобода же определяет трение Так трение определяет несвободу

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

Бог, который слышит — Шаблоны и оптимизация каждого чиха, — говорят одни маркетологи. — Нет, креатив и слом всех правил, — отвечают другие. Священная война тупоконечников с остроконечниками идёт полвека. Хотя ответ нашли пару тысяч лет назад — правда, не маркетологи, а шаманы и жрецы. Они заметили: лучше всего запоминаются и передаются идеи, нарушающие ровно одно базовое ожидание человека. Молиться просто дереву — скучно. Дереву, которое летает, состоит из сыра и существует по вторникам (да-да, такое было) — перегруз. А вот дереву, которое слышит, — в самый раз. Поэтому боги почти всех культур — обычные люди с одним-двумя апгрейдами: всё видит, не умирает. У мозга есть врождённые категории: камень, животное, растение... К каждой прилагается пакет автоматических ожиданий: животное — ест и какает; растение — тянется вверх; камень лежит и не думает. Лучше всего запоминается концепт, который нарушает ровно одно ожидание категории. «Привычный пакет + одно нарушение» — формула любого липкого продукта. Такси, но без своих машин — Uber; банк, но без отделений — Тинькофф; магазин, но без касс — Amazon Go. Как использовать у себя: 1. Берешь категорию 2. Выписываешь ожидания/стереотипы людей 3. Ломаешь ровно одно; остальное — не трогать. 4. Получаешь свою категорию Вывод прост: ноль нарушений — скука, одно — продукт, три — дерево из сыра. 21. Спасибо

Скилл, который отказался запускаться (и это было ценнее всего) Недавно я выложил скилл, который помогает мне копать проблемы и попросил вас прогнать на своих задачах и поделиться, помогло или зря сожгли токены. Получил 3 фидбека: 1) Отказался оценивать продуктовую идею Аким запустил скилл не на проблеме, а на продуктовой идее: сервис онбординга — закидываешь видео и материалы, он онбордит новичков. Дерево даже не стало запускать агентов: «это не продукт — ты придумал решение под проблему, которую даже не описал». Когда он поделился этим на office hours, то мы решили немного развернуть задачку: не «оцени мою идею», а "вот тебе проблема, которую решает продукт → построй дерево → найди корень → и только теперь проверь, попадает ли в него идея». Аким перезапустил уже по проблеме, и дружбан со своими миньонами ушёл в себя и вылез с интересными выводами:

why-tree скилл прошелся по всей проблеме (я надиктовал оч много контекста), и пришел к выводу, что проблема в организации, а не сложной системе/отсутствии википедии по проекту. Все, что скилл описал - правда: - нет владельца процесса онбординга, - подрядчик должен владеть/управлять вместо заказчика, - вопрос не в том, как лучше навигировать среди знаний, которые нужно поглотить за 4 месяца (пример моей идеи продукта), а в ответе на вопрос "как за 2 недели понять, что человек А онбордится лучше чем Б" И дальше скилл предлагал уже варианты как решать. На мой вопрос "может ли моя идея продукта помочь заказчику/подрядчику онбордить быстрее/лучше" я получил оч неожиданную мысль: They've absorbed it as a cost of doing business. Legacy systems full of tribal knowledge are everywhere — you're right that the problem is widespread. But widespread ≠ payable. Companies with 15–20-year systems have lived with slow onboarding for 15–20 years. They've absorbed it as a cost of doing business. A chronic pain people have already budgeted around has a near-zero willingness-to-pay, because the brain only spends money when it predicts a return bigger than the spend — and "fix a thing we've tolerated for a decade" predicts a small return

Cтрочка, которая зацепила меня больше всего:

They've absorbed it as a cost of doing business

Ох, сколько таких кейсов я встречал. 2 и 3) Илья попробовал натравить дерево на кодовую задачу - хотя я об этом не особо думал - и подчеркнул ценность в стороннем взгляде на проблему и приоритезацию, а Дмитрий покрутил на очень актуальной задаче о том, почему 4 месяца внедрения AI не привели к росту выручки и/или оборачиваемости онлайн магазина. Тут, признаться, не очень хорошо отработал скилл, но по словам Дмитрия ценность принесли тесты/эксперименты, которые дружбан предложил после анализа.

"Дерево дало карту, куда смотреть"

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

Showing 8 yo how to deal with a recalcitrant zipper on his jacket reminded me how tricky zippers actually are. There is definitely room for a new product here. There's room for better versions of almost everything. We just don't see it because we've stopped noticing the flaws in what we have, and the complicated tricks we use to compensate for them. Показывая 8-летнему мальчику, как справиться с непослушной молнией на его куртке, я вспомнил, насколько сложными на самом деле бывают молнии. Здесь определенно есть место для нового продукта. Место для улучшенных версий почти всего. Мы просто не замечаем этого, потому что перестали обращать внимание на недостатки того, что у нас есть, и на сложные уловки, которые мы используем, чтобы их компенсировать. — Пол Грэм

Теорема о тормозах Поговорим о ситуациях, когда компьютер тормозит. Под тормозами понимается медлительность, мешающая свободному взаимодействию и тем самым вызывающая фрустрацию и раздражение. Если компьютер скачивает пять гигабайт данных, компилирует сложный проект или рендерит видео, это занимает ощутимое время, но это не тормоза: мы дали компьютеру задачу, и он работает, выполняет. Теперь допустим, что видео рендерилось час, потом отобразился статус «Завершено», а через секунду готовый файл отобразился на рабочем столе. Первый час компьютер не тормозил, но следующую секунду — тормозил. Теорема: все тормоза являются ошибками и исправимы. Технически даже своевременное отображение статуса или реакции не действие пользователя — это такая же «работа», как и рендеринг видео. Однако такая работа должна быть выполнена за время, которое человек не способен ощутить. Будем называть это «мгновенно». Примеры тормозов в современно софте: — при запуске программы нельзя сразу же начать ей пользоваться, а нужно ждать загрузки; — после загрузки часть интерфейса дорисовывается на глазах у пользователя; — при нажатии на кнопку нет мгновенной реакции; — при вводе с клавиатуры символы появляются не мгновенно; — при прокрутке страница едет не плавно или с отставанием от пользователя; — при прокрутке часть содержимого догружается на глазах у пользователя, а не приезжает уже готовым из-за края окна; — при изменении размеров окна разные части интерфейса перерисовываются на глазах у пользователя с разной скоростью или в несколько «прыжков»; — при перетаскивании объекта программа понимает, что может «принять» его, не мгновенно; — после открытия меню, на глазах у пользователя в нём добавляются пункты или меняется их порядок; — разные части интерфейса реагируют на действия пользователя через разное время. Во времена первых компьютеров тормоза были неизбежны, потому что мало что можно было сделать мгновенно. Но как минимум последние двадцать лет компьютеры на несколько порядков быстрее, чем необходимо для мгновенности, а значит и для полного отсутствия тормозов во всех случаях. Если программа тормозит, это лишь значит, что в тот момент, когда она должна мгновенно отобразить данные или отреагировать на действие пользователя, она занята чем-то другим. Это что-то другое — ненужная в данный момент, лишняя работа. Это ошибка в программе, и она должна быть исправлена. Лишняя работа должна перестать делаться и мешать пользователю пользоваться компьютером. Таким образом, тормоза нельзя списать на слабое железо; это слабость исключительно её автора.

О благодарности Понятно, что 80% писем от клиентов — разнообразный негатив. Когда все в порядке, никто не пишет. Уж особенно после общения с саппортом. Но вот вчера нам написал один из пользователей Мо. — Уважаемая команда Mo, Хочу выразить искреннюю благодарность Анне из вашей службы поддержки. Это лучший специалист поддержки, с которым мне доводилось общаться. С самого начала она была терпеливой, понимающей и по-настоящему готовой помочь. Она внимательно выслушала мои проблемы, разобралась в моём случае и вместе со мной нашла наилучшее возможное решение. Благодаря её профессионализму и самоотдаче мой вопрос был успешно решён. Её доброжелательность, уважительность и превосходный сервис произвели на меня очень положительное впечатление. Такие сотрудники, как Анна, — большая ценность для вашей компании, и я надеюсь, что её выдающаяся работа будет отмечена. Пожалуйста, передайте ей мою искреннюю благодарность. Ещё раз спасибо. — Да, текст похож на нейросетевой, и в английском оригинале (это перевод) он тоже был похож на нейросетевой. Но благодарность почувствовал человек сам. Email начальства человек нашел сам. Время свое, в конце концов, он потратил сам. Спасибо ему. Бывают в бизнесе светлые моменты. #мо

Вот вам пример того, как крупняк сейчас использует сетевой эффект при создании продуктов. Первыми такую карту создали энтузиасты, но она была UGC, а Яндекс, Сбер и Тиньков заюзали bigdata и получили лУчший результат за счёт автоматически собираемых пользовательских данных.

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

Источник Какова мораль? Мораль в том, что UGC сейчас переживает непростые времена. Я бы сказал, что очень непростые. Стоимость контента падает, стоимость внимания и тем более, вклада людей (нажать кнопочку в аппе, нанести точку на карте, написать пост) чудовищно выросла. Я бы оценил инфляцию примерно как x5-x10 за последние 10 лет, т.е. стоимость ЛЮБОГО действия и потраченного времени живого человека выросли до 10 раз, а вот стоимость всего, что можно собирать автоматизированно, т.е. "цифрового следа" и контента — упала в те же 10. Практический вывод: Если у вас есть аудитория или сообщество, контентная модель больше сама себя и вас не прокормит. Нужно думать про глубокое вовлечение. Потому что крупняк вовлечение такое не соберет, зато всё остальное — легко и просто. Вывезти может только более глубокий уровень доверия к вам и внутри аудитории.

Каждый раз на продуктовом обучении приходится давать определение гипотезы и объяснять, что это такое. Как думаете почему? 💡 Гипотеза - это предполагаемое объяснение уже наблюдаемого поведения пользователей или работы системы, которое еще предстоит доказать. Плохая гипотеза (просто хотелка): «Если мы поменяем логику подписок, пользователям станет удобнее». Хорошая гипотеза: «Мы видим, что 40% пользователей уходят со страницы оплаты (наблюдаемое поведение). Мы предполагаем, что они не понимают разницу в тарифах. Если мы добавим сравнительную таблицу, то снизим отток на 10%». Чтобы быстро отличить хорошую гипотезу от плохой, используйте формулу: Мы видим [Проблему/Данные] -> Предполагаем, что [Причина] -> Если мы [Решение] -> Изменение [метрики]