Продукт

Хорошие ошибки То есть, у нас есть хорошие и плохие ошибки. На мой взгляд, критерием как мы можем отличить «хорошую» ошибку от «плохой» являются два вопроса: 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

Вообще не осталось продакт-менеджеров, которые бы не упоролись напрочь в нейросети. Мне кажется это какие-то неправильные менеджеры, кто этого еще не сделал. Поэтому я и веду свой второй канал @gleb_pro_ia, и делаю это примерно в 100 раз активнее, чем этот. Чего-то высасывать из пальца при этом тоже не хочется. И я все думал. а про что ж писать тут? Решение висело под носом. Тут уже написано в заголовке про бизнес, значит буду продолжать писать про бизнес. Пусть и с нейросетевым уклоном, так как без этого сейчас ну вообще без вариантов. А на втором канале продолжу исповедовать гонзо-журналистику про то, каких агентов я потрогал сегодня, и как они меня возблагодарили в ответ.

#кейс_стади Разбор с СEO, вайбкодом и Едрит Многие ответили на задачу с позиции мидл-менеджера: провести ретро, спросить архитектора, поправить процессы, не лезть в чужую работу. Но CEO здесь вообще в другой позиции. У него сорван крупный контракт, под риском следующий рейз, потеряно доверие к инженерным оценкам и появился контрпример. Его задача быстро вернуть управляемость Первое Показать свою ветку CTO и поставить задачу ее опровергнуть. И не с позиции "я сделал лучше вас", а "вот решение, которое по моей текущей оценке закрывает то же самое за две недели 1 человеком". Можно остановить менее важные задачи, подключить сильных инженеров и прогнать тот же набор проверок. Если решение развалится -> отлично, CEO получит конкретные причины, чего он не понимал. Если после недели допила оно сравнимо -> вопрос становится очень неприятным Второе CTO должен объяснить не код, а управленческое решение. Что из вот этого platform наворота было еально необходимо для Дастархана, что строилось на будущее, кто принял вообще сравнивал варианты и какая экономика у них. Критичный бизнес-дедлайн был известен заранее. Если инженерка сознательно обменяла его на красивую платформу, бизнес должен был участвовать в этом решении, а не узнать о последствиях через пять месяцев Третье С этого момента подобные решения принимаются иначе. Есть жесткое внешнее ограничение -> CTO приносит несколько вариантов со сроками, рисками и стоимостью: быстро закрыть потребность, сделать нормально, строить платформу. Какой риск купить -> решает CEO. Архитектура не существует отдельно от экономики, особенно когда на другой стороне контракт и инвестиционные деньги Четвертое CTO должен принести отчет, причем не нейрослоп HTML-бандл от клодкода, а понятные 2 странички с хронологией проекта, где были проблемы, что для них делали и почему не уложились в сроки. Отдельно информация как им управляли и контролировали. По отчету станет прозрачно осознавал ли техдир важность проекта и делает ли менеджмент в компании полезную нагрузку Отдельно меня удивило, сколько людей вообще начали обсуждать, правильно ли CEO втихаря вайбкодит и должен ли он лезть в работу разработчиков. Это взгляд из своей профессиональной колокольни. В условиях кейса CEO уже вайбкодит, уже достаточно погружен и получил новую информацию о собственной компании. Спорить с условиями задачи вместо принятия решения -> уходить от самой задачи. Тем более я постоянно общаюсь с C-level продуктовых компаний и это уже совсем не экзотика, когда даже фаундер собирает себе что-то И дальше самое важное -> реакция CTO. Ошибка в архитектуре допустима. Сорванный срок тоже иногда допустим. Недопустимо, когда критичный для бизнеса срок сорван, последствия воспринимаются как данность, альтернативное решение никто не хочет проверять, а объяснение заканчивается на вам не понять разработку. Если CTO сам разбирает ситуацию, показывает где ошибка CEO и меняет систему -> доверие можно восстановить. Если защищает статус-кво -> я бы ставил CTO испытательный срок

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

Как повысить эффективность бизнес-процессов с помощью оптимизации пайплайна В любой сфере деятельности ключевую роль играет эффективность. Оптимизация пайплайна — это не просто улучшение отдельных этапов работы, а комплексный подход к повышению производительности всей системы. Такой подход помогает сократить издержки, ускорить выполнение задач и устранить возможные задержки. Начинать следует с детального анализа текущего процесса. Это позволяет выявить слабые места и понять, где именно теряется время или ресурсы. Следующий шаг — внедрение автоматизации, перераспределение ресурсов и использование современных инструментов, которые позволяют работать быстрее и точнее. Важно помнить, что оптимизация — это не разовое действие. Пайплайн требует регулярного пересмотра и адаптации, особенно в условиях быстро меняющейся рыночной среды и технологического прогресса. Фаундер | Бизнес и Стартапы

💰 Серебро дороже золота. Так теперь можно Caviar это контора, у которой любая электроника рано или поздно обрастает драгметаллом. Теперь она добралась до умных очков Ray-Ban Wayfarer II. Коллекция называется Odyssey. Версия Odyssey получила декоративные накладки с покрытием из 24-каратного золота. Odyssey Silver — вставки из 22-каратного стерлингового серебра. Металл куют, гравируют и полируют вручную, гравировка идёт греческими мотивами, а на дужках сидят звёздочки из чёрной эмали. Оправа подо всей этой роскошью — стандартная чёрная Wayfarer. Тираж всего по 24 экземпляра каждой модели. Число выбрано не наугад: ровно столько песен в «Одиссее» Гомера. Зарядный кейс тоже не остался обделённым — его обтянули чёрной крокодиловой кожей и повесили на застёжку фирменную эмблему. Внутри, ровно те же самые Ray-Ban, всё идентично серийной версии. За золото и крокодила доплачивают исключительно снаружи. Ценники: золотая Odyssey — 6130 долларов (~503 000 рублей), серебряная Odyssey Silver — 6840 (~560 000 рублей). Да, серебро вышло дороже золота. Логику ищите сами, мы пас. Есть и практический нюанс, о котором Caviar скромно умолчала: сколько всё это добавляет к весу. А для очков, которые предполагается носить на носу весь день, вес — вещь довольно принципиальная. Заказы уже открыты. А что? Ну вдруг надо? @droidergram

Выбор оптимального канала продаж для вашего бизнеса Подход к организации продаж может существенно различаться в зависимости от особенностей компании. К примеру, Dell сделала ставку на прямое взаимодействие с клиентами, исключив посредников из процесса покупки. В то время как такие гиганты, как General Motors и Coca-Cola, отдают предпочтение сотрудничеству с посредниками и дистрибьюторами, что позволяет охватить более широкую аудиторию. Ralph Lauren сочетает оба подхода — используя как собственные каналы, так и партнерские сети. Apple же выбрала путь создания фирменных магазинов, где может полностью контролировать клиентский опыт и качество сервиса. Выбор стратегии продаж определяется рядом факторов: от особенностей продукции и характеристик целевого рынка до стратегических задач компании. Главное — чтобы канал продаж гармонично вписывался в общую бизнес-модель, способствовал достижению ключевых целей и укреплял имидж бренда. Фаундер | Бизнес и Стартапы

Июльский дайджест продактов звучит жарой и светом её Солнца – От лошадей к стартапам – Цена фичи – Contextual Product Management – Про «чтобы что» – Закон Фолкленда – Закон Брукса – Правило 7% – 3 Истины Систем – Главное из AEO – Зачем продукту видение – Be NICE – Diff-in-Diff: A/B-тест невозможен – Process Communication Model – Как перестать быть незаменимым – The truth about being a manager – Что проверять в AI-продуктах – Немного про контрольные карты – Scream-тест продукта – Суперпозиция продукта – Токен ↔ Человек – Метод CRISP для PRD – Валидация — мираж – Культура загнивает незаметно – Как проектировать UX AI – Чатоцентричный интерфейс – Играем в «Оракл» с продуктом – ИИ внушает ложную уверенность – Book: Product Design Psychology – Гайд: Метрики UX – The Layers of AI experience – Симулятор сотрудника FAANG – Каталог когнитивных искажений – ИИ о человеческих страданиях – 3 ways people respond to a problem – What AI can tell us about human suffering – The Laws of this World (Game Theory) – По вере вашей дано будет вам 🌞 Yoshiko Sai ～ Taiji no Yume 🔭 Chiemi Manabe - Untotooku