Улучшения наоборот Готовим с командой внедрение системы для проведения A/B тестов. Точнее MVP системы, потому что решили сделать сами, а не использовать готовое решение — с ним слишком много зависимостей и согласований, а наши потребности пока ограничиваются простыми экспериментами на веб интерфейсе. Добрался до конца спеки и задумался: какой эксперимент можно будет провести первым, чтобы проверить насколько правильно работает сбор событий по группам? Понятно, что самым первым нужно провести A/A тест, проверить распределение по группам и совпадение метрик. А вот какой тест должен гарантированно изменить целевую метрику? Решил, что это хороший момент попробовать ухудшающий эксперимент. Когда мы для небольшой тестовой группы в A/B тесте специально добавляем сложность в опыт пользователя. Их используют для других целей, когда делать улучшение сложно и долго, а сделать пробное ухудшение легко. Скорость загрузки страницы сайта и её влияние на конверсию хороший пример. Оказалось, что придумать ухудшение в своем продукте даже сложнее, чем его улучшить! Ведь нужно сделать так, чтобы конверсия воронки заметно уменьшилась, но это не стало блокером для всех пользователей из тестовой группы — сравнивать ноль с текущим значением конверсии невозможно. Пришлось посоветоваться с Клодом. Давайте вместе выберем из его предложений гипотезу для ухудшающего эксперимента? Воронка выглядит так: главная страница с описанием продукта и списком популярных товаров ➔ страница товара с его характеристиками и калькулятором кредита ➔ форма заявки на кредит (имя, номера телефона, адрес почты и поле с выбором уровня дохода) ➔ подтверждение номера телефона через OTP ➔ результат предварительной проверки с переходом на установку приложения. Ваши идеи — в комментарии. Или выбирайте несколько наиболее «правильных» вариантов в опросе👇🏻 1. Задержка страницы товара. Если добавить +1,5-2 с к загрузке, то конверсия «товар → заявка» упадёт, потому что часть пользователей уйдёт, не дождавшись. 2. Пустой калькулятор. Если убрать предзаполненные значения и показывать платёж только после клика «Рассчитать», то конверсия «товар → форма» снизится, потому что цену придётся добывать усилием. 3. Лишнее поле в форме. Если добавить пятое поле (например, город или дату рождения), то конверсия «форма → OTP» упадёт, потому что каждое поле добавляет трение и тревогу от запроса данных. 4. Поздняя валидация. Если убрать маску телефона и показывать ошибки только после «Отправить», то доля завершивших форму снизится, потому что пользователи чаще ошибаются и бросают её. 5. Неудобный OTP. Если убрать автоподстановку кода и увеличить кулдаун повторной отправки с 30 до 60-90 с, то конверсия «OTP → результат» упадёт, потому что ручной ввод и ожидание провоцируют уход. 6. Лишний шаг перед установкой. Если после результата добавить экран с кнопкой «Продолжить», то конверсия в переход к установке снизится, потому что каждый лишний клик теряет часть пользователей. Посты по теме A/B тестирования: 📌 Уровень культуры экспериментов в компании. Как измерить и улучшать 📌 A/B тестирование для начинающих. Ответы на стыдные вопросы 📌 Зачем нужны ухудшающие эксперименты. Хорошая статья от GoPractice #productquestion

Ни своих, ни чужих Оба способа, которыми у нас открывают бизнес 99% предпринимателей, должны умереть как класс. Первый — на свои: сбережения, кредиты, займы, неважно. Сам вложил, сам сделал, сам заработал. Второй — на чужие: привлекаешь инвестора, рискуешь уже не своими деньгами и отдаёшь за это кусок компании. А сейчас, в эру ИИ и вайбкодинга, когда продукты собираются на гипер-ультра-мега-звуковой скорости и проверить можно вообще любую гипотезу, тратить на это деньги просто тупо. Почему раньше приходилось искать деньги, свои или чужие? Потому что идею надо было во что-то обернуть. Презентация — нужен дизайнер. Сайт — дизайнер, какой-нибудь программист, тильды-хуильды. Сам продукт или услуга — маркетолог, продуктолог, интегратор, не дай бог разработчик за туеву хучу бабок. Люди, время, деньги. Я много раз привлекал деньги и ещё больше раз открывал бизнес на свои. Большую часть потом похоронил. И каждый раз это был стресс: идея сидит в голове, а чтобы проверить, не хуйню ли ты придумал, надо заложить месяцы и миллионы. Каждый запуск был олл-ином — на стол шло всё, что есть: и деньги, и время, и репутация. Каждый провал — маленький суицид. Сейчас на ту же проверку идеи нужно несколько часов и твоё время. Любая картинка, презентация, концепция, сайт. Номер любого клиента тоже найдёшь. Ещё три года назад, чтобы запустить приложение, портал или новую услугу, нужны были люди, время, деньги. Сейчас — только не ссать и делать. Поэтому 26-й год для меня — время третьего способа: делать бизнес только на деньги клиента. И сразу, пока в комментах не набежали с «это ж предзаказы, тоже мне Америка»: да, Америку я не открыл. Предоплата, предзаказ, аванс — так работали всегда. Новое другое: то, что надо показать клиенту, чтобы он заплатил, теперь собирается почти бесплатно. Макет, презентация, прототип — за пару часов. Раньше по такой модели могли работать только редкие бизнесы, и то нужны были ресурсы, чтобы дойти до денег клиента. А сейчас так может делать кто угодно. Кофейню, понятно, через чатик с нейронкой не откроешь. Масштаб, аренда, железо, закупки как стоили денег, так и стоят. Я про старт и проверку гипотезы. Дальше всё просто. Придумал, собрал, написал людям, позвонил, предложил. Если нравится и хотят купить — взял предоплату или сразу полную оплату и растишь бизнес уже на их деньги. Не берут — значит, придумал хуйню, и узнал ты это раньше, чем успел в неё вложиться. Никакого олл-ина. Риски, конечно, не ноль. Время и самолюбие всё равно на кону: слышать «не, спасибо» неприятно, кто бы спорил. Но ставка теперь — вечер, а не сбережения. Раньше на столе лежали долги, кредиты, пара лет жизни и репутация. Но есть у этого свой нюансик. Останется только написать, позвонить, предложить. Звучит как мелочь. Только собрать продукт сейчас может кто угодно, а продавать не умеет почти никто. Тем более продавать то, чего ещё нет. Взять предоплату за штуку, которую ты слепил на коленке и сам её немного стесняешься, — искусство, смелость, напор. Это и есть предпринимательство — изъебнуться так, чтобы и продать, и сделать, и при этом не потратить, а заработать. Денег на старт бизнеса больше не надо. Надо продать раньше, чем сделал. Для многих это страшнее любого кредита.

Чем больше ты узнаёшь о рынке, тем меньше ты узнаёшь о пользователе и тем больше ты забываешь о нём Продукт – гипотеза о том, кем люди хотят стать Ты строишь то, что им дано познать Фичи – самомнение природы человека Пользователь всегда покупает страх Смелость команды – смелость максимально неудобного вопроса. Сила её в том, чтоб этот голос не молчал Любой родмэп однажды станет клеткой Неопределённость – ключ и материал Ясность = нет страха тишины и пустоты Всё, что строишь – то кем ты был и стал Лучший фидбэк неприятен Лучшая фича – та, что никто не ожидал Великий продукт возвращает, не забирая время/внимание/силу Вашей команде вообще не нужен план Не верь тому, кто всячески во всём всегда уверен Будь ближе к тем, кто может подвести к неправоте Логики и откровений щит команде в руки вверен Свет Истины блистает в сердце и душе

Основаной инстинкт основателя в умении нащупать волнение На прошлой неделе был в Екатеринбурге и выступил на конференции «Локальный код» от Т-Бизнеса. Обсуждали с предпринимателями, как искать новые точки роста. Зацепила мысль Нино Шаматавы, основательницы Ushatava: для того, чтобы нащупать тему, обязательным атрибутом должно стать волнение. Супер неочевидная и классная мысль именно в такой формулировке. Волнение не обязательно про тревогу. Когда идея или проблема настолько увлекает или вызывает предвкушение. Важно заметить это чувство. Когда тебя, как основателя или клиента, что-то настолько тревожит, беспокоит или будоражит. Что волнует меня как потребителя? С какими проблемами постоянно приходят сотрудники после общения с клиентами или коллегами? О чём переживают люди рядом с тобой, чем недовольны в соцсетях? Есть ли Если где-то нащупал это волнение, то стоит направить внимание и фокус. Само волнение ещё не гарантирует новый бизнес, но позволяет сформулировать гипотезу. А дальше уже твоя работа как предпринимателя, докопать, проверить, сможешь ли ты это волнение как-то удовлетворить. Поэтому люблю конференции и новые города. Общение с предпринимателями, что на сцене, что неформально, всегда напитывает новыми идеями и вдохновением. Вот, делюсь с вами!

Быстро закрыть продукт - тоже киллер-фича Вот ещё один интересный подход к продуктовым инновациям: У Сбера появилось направление DISRUPT (какой ещё вам нужен пруф, что все продакты меня читают? 🤔). Если кратко, то это такой внутренний венчурный инкубатор для ИИ-сервисов, что-то вроде Google Labs или Copilot Labs у Microsoft. И у него есть две необычных особенности: - Первая - команда тестит гипотезы сразу на живых внешних юзерах. - Про вторую детально ниже, а сначала несколько примеров продуктов, которые из него уже успели выйти: 1. Мультитул. Это десктопный агент для любых рабочих задачек - типа сборки през и отчётов на основе документов, с подтягиванием контекста из почт, календарей и т.д. Из необычного - туда можно подключить свою нейросеть (не только что уже есть под капотом, а вообще любую). 2. Тайп. Локальный голосовой набор для Windows и macOS. Под капотом модель GigaAM, заточенная под распознавание русской речи, процессинг локально на устройстве. 3. Консьерж. Ищет рестораны, отели и маршруты, ставит события в календарь и может позвонить куда надо. Живёт в мессенджерах. 3. Айва. Ассистент по здоровью, анализирующий КБЖУ по фото блюд, составляющий программу тренировок и подсказывающий, к какому врачу записаться. Но весь прикол даже не в сервисах, а в общем правиле, по которому они живут (та самая вторая особенность). Тут конкретный фокус на ретеншене. Успешным считается только тот продукт, к которому пользователи стабильно возвращаются. Если нет - его быстро закрывают и берут следующую гипотезу. И это довольно необычно, ведь в корпорациях инновации часто загибаются, потому что нет системы, чтобы быстро распознать провал и отстрелить его. В итоге, продукт запускают - он обрастает командой, метриками и всем остальным - и легко может получится "зомби", высасывающий бюджеты и усилия годами. А тут, получается, быстрое закрытие продукта - это часть самой фабрики. А тестирование сразу на внешних юзерах (в том числе - юзерах сервисов Сбера) явно ускоряет решение и повышает его достоверность. А то если тестировать на сотрудниках (как часто делают), то это... ну такое. Сотрудники любят сильно отклоняются от среднего по юзер-больнице или вообще влюбляться в свой продукт по уши. Я недавно писал про GigaChat 3.5 Ultra и Reasoning, где Сбер отдал обе модели в опенсорс под лицензию MIT. И там делал отдельный акцент, что ценность всей этой истории будет зависеть от того, что строится вокруг самих моделей. Так вот, думаю, этот DISRUPT - и есть попытка поскорее построить это "вокруг". Только не одним большим запуском (который, если провалится, то сразу и весь), а десятками небольших ставок с дефолтным правом на быстрый провал. Дизраптор

Как мы обычно тестируем новые гипотезы: 0. Рождение идея В ходе любой встрече, в душе или за толчком. 1. Мини-валидация Провалидировать среди старейшн - остальные фаундеры, C-lvl. 2. Рисерч рынка Добыть все, что возможно быстро. Если есть время и ресурс - сходить к потенциальному или действующему конкуренту - выбить инфу. 3. Подготовка почвы Отработать все сценарии. Приготовить документацию. Пообщаться со всеми стейкхолдерами. 4. Бенчмарки и метрики Устанавливаем правила игры на успех/провал в численном выражнии 5. Фокус-группа Шикарно если уже есть аудитория и протестировать все можно на ней. Отбираем горячих кроликов. 6. Тестовая прогонка Пошла костыльная работа, ошибки, много чатов и корректировок. Вскрылись первые пробелы подготовленной почты 7. Редакция v.1 Отработали возражения. Провели необходимую итерацию 8. Аутбаунд машина Погнали в Clay, Apollo, Instantly, HeyReach и тому подобное быстро набирать холодных кроликов в тестировании гипотезы. 9. Редакция v.2 Еще раз отработали на новой холодной аудитории 10. Включение перформа Собрали лендинг если надо. Заливаем траффик. 11. Синхронизация часов Вернулись в пунк 4 и сверили часы. Проход или нет. 12. Scale Если работает - разрабатываем, масштабируем, вливаем ресуры. Это примерно то, как это выглядит на стадии series-A. А если помоложе, то можно осуществлять все в 3-4 действия. Так стартап постепенно превращается в корпорацию.

Вчера мы приняли довольно простое решение, которое, кажется, наконец сняло проблему, из-за которой я нервничала последние несколько недель. Мы сейчас очень быстро развиваем продукт: новая логика, плейбуки, изменения почти каждый день. И в какой-то момент поняли, что каждое новое улучшение может случайно задеть то, что уже хорошо работает у клиента. Не в смысле, что всё ломается, а хуже😄 Клиент привык к определённому процессу, встроил его в работу, а мы меняем логику. Формально продукт продолжает работать, но результат уже другой. И для клиента это выглядит просто: вчера было хорошо, сегодня стало хуже. Очевидно, что так продолжаться не должно. Поэтому мы разделили продукт на две ветки. Первая - стабильная: на ней действующие клиенты. Три недели ничего нового не выкатываем, только исправляем ошибки. Вторая - экспериментальная. Там можно тестировать новые идеи, менять логику хоть каждый день и быстро проверять гипотезы. Если что-то хорошо работает в экспериментальной версии, через три недели переносим это в стабильную. На первый взгляд решение довольно очевидное. Но для меня здесь оказался важный вывод. Теперь у нас есть скорость для тех, кто хочет экспериментировать, и стабильность для тех, кому важно, чтобы просто работало. Интересно, как вы решаете эту проблему у себя? Держите отдельную версию для действующих клиентов или выкатываете всё сразу и уже потом разбираетесь по ситуации?

Стресс-тест продуктовых гипотез с помощью агентных ИИ-систем Спикер: Сергей Синяков Откровенно плохие идеи обычно отсеиваются быстро. А правдоподобные совпадают со стратегией, нравятся команде и звучат логично. Если добавить данные, мнения пользователей и убедительную формулировку от ИИ, гипотеза начинает выглядеть почти доказанной. Мы привыкли защищать идеи: искать аргументы в их пользу и постепенно влюбляться в собственную конструкцию. А можно действовать наоборот — подвергать гипотезу нагрузке до того, как она попадет в разработку, чтобы отсеивать нерелевантные и брать в работу лишь те, которые принесут большую пользу бизнесу. Проверять гипотезу через призму доказательств, ролей и противоречий можно тремя способами: 1. Вручную собирать и связывать всю имеющуюся информацию — качественно, но дорого. 2. Передать весь контекст модели одним большим запросом — удобно, но недостаточно проверяемо. 3. Разделить анализ на этапы с помощью агентного конвейера — надежно и обоснованно. Почему одного большого промпта недостаточно? Проблема большого запроса в его непрозрачности: мы получаем уверенный ответ, но не видим, на чем он основан. В агентной системе стресс-тест гипотезы на каждом этапе создает отдельный проверяемый результат, поэтому исследование можно проверить или перезапустить с любого шага. Стресс-тест проходит через четыре слоя:

гипотеза → роли → рынок → синтез

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

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

Дальше гипотеза проходит через несколько скиллов: — hypothesis-input-validation проверяет корректность формулировки и не пропускает дальше невалидную гипотезу; — hypothesis-facilitator рассматривает гипотезу с позиций разных ролей и фиксирует различия в их выводах; — local-knowledge-retrieval формирует предварительный обзор, извлекает отдельные факты и находит связанные артефакты; — business-context-value-check определяет, кто заинтересован в гипотезе с точки зрения бизнеса и какую ценность она может принести; — hypothesis-market-layer изучает внутреннюю документацию, а затем обращается к внешним источникам; — hypothesis-synthesis сопоставляет собранные данные и формулирует выводы; — customer-discovery-planning превращает найденные пробелы в план интервью, чтобы закрыть их с помощью новых данных; — human-report-export собирает понятный человеку отчет со ссылками на все необходимые артефакты. Что показал стресс-тест? После всех этапов выяснилось, что гипотеза в первоначальной формулировке не приносит ожидаемой пользы. Настоящая задача — не просто быстрее обнаружить риск, а сократить время от появления критичной находки до конкретного действия по ней. Стресс-тест сделал идею честнее и проверяемее. Когда такой подход оправдан Полноценный стресс-тест нужен не каждой гипотезе. Его стоит запускать, когда решение: — дорого реализовать; — трудно откатить; — займет несколько спринтов; — нельзя проверить одним быстрым экспериментом. Если ошибка стоит меньше спринта, проще провести короткий тест, чем запускать исследовательский космолет. @productsense

Сперва продали, а только через 4 месяца сделали. Мою личку в тг бывает прилетают спам-предложения сделать мне превью для ютуба. Приходит по 2-5 предложения в месяц. Хотя канал у меня маленький. Сам я прикола в этих превью не понимаю. Хотя согласен, что они могут сильнее конвертить в просмотры, при правильном подходе. Логичная мысль, если так много предложений, значит и спрос есть. Да и сервисов, которые такое делают, их просто тьма уже. Но решил потестить. Сделали доп лэндос на наш основной домен. Мол с описанием, что умеем такое делать. Хотя делать нифига не умеет, все кнопки вели на основной функционал. И прикол, спустя месяц, это стала нашей одной из самых популярных страниц по кликам. Ну раз так, то окей, можно сделать. Сделали быстро. Пошли доп оплаты. Теперь только так и проверяем. Сперва лэндос, собираем клики. Если кликают или хотят забрать результат, то делаем. А ведь могли сперва сделать, а только потом пойти тестить спрос. Логично же? Кстати, мы так еще 5 фиче проверили. Которые в итоге тупо дропнули. И делать не пришлось. То есть сэкономили ресурсы 3 человек 5 раз длиной 1-2 месяца работы.

Когда я собеседовался в МакКинзи, там было принято задавать кандидатам так называемые «market sizing questions», типа: «сколько канализационных люков есть в Москве?». В еще более вырожденном виде этот тип задач звучал совсем абсурдно, вроде ставшего мемным вопроса «сколько мячиков для настольного тенниса можно вместить в один Боинг 747?» Понятно, никто не ожидал, что кандидат тут блеснет эрудицией и выдаст в ответ некое «правильное число». Проверялся не результат, а сам процесс ответа: сможет ли человек за несколько минут путем каких-то разумных предположений прикинуть «на коленке» диапазон чисел, в которые с точки зрения здравого смысла, скорее всего, должен попасть истинный ответ? Не упустит ли он на пути к результату какие-то очевидные требующиеся корректировки? (Например: поделит примерный объем корпуса самолета на объем одного теннисного шарика – но не учтет, что часть места в салоне занимают кресла, а между наваленными шариками неизбежно останутся пустые места.) Так вот, при подготовке к трудоустройству мне это всё казалось какой-то страшной дичью, совершенно оторванной от реальности. А когда я уже начал работать консультантом внезапно выяснилось, что похожие подходы вполне используются в настоящей работе практически постоянно! Потому что в работе консультанта приходится иметь дело с огромным количеством разных гипотез, и если каждую из них пытаться проверять в формате «создаем рабочую группу и неделю собираем данные для ответа» – то добиться чего-либо в реалистичные сроки оказалось бы просто нереально. И такие вот «прикидки на салфетке» вполне неплохо отсеивают 80% гипотез, которые почти точно не сработали бы. Понятно, что такой метод оценки является очень грубым и может давать результат, который отличается от правильного «в разы». Но идеальная точность чаще всего на практике на этапе отсеивания гипотез и не нужна, зато даже на уровне понимания общего порядка чисел нередко уже можно сделать вывод «этот вариант нам заведомо не походит, там эффект даже близко не выйдет такой, какой нам надо». В общем, к чему это я: недавно мы тут занимались «наколеночными прикидками» по поводу оспариваемости брачных договоров в России. И там в комментах в целом интересная дискуссия, но некоторый тип комментариев мне показался очень странным – это те, где люди писали «если у нас нет точной статистики, разводятся ли пары с брачными договорами чаще или реже пар без них – то все дальнейшие расчеты можно просто выкидывать на помойку, они абсолютно бесполезны!» Мне этот тезис кажется совершенно неверным. Да, конечно, этот момент является важным для расчетов. Но если надежных данных по нему просто нет – что плохого в том, чтобы сделать какое-то предположение, исходя из здравого смысла? Так как можно придумать разумные аргументы в обе стороны (условно, что семьи с договорами распадаются чаще из-за меркантильности, или что распадаются реже из-за более высокой осознанности и умения договариваться) – мне кажется совершенно нормальной базовая предпосылка об отсутствии различий в разводимости между этими двумя группами. Но даже если эта предпосылка на самом деле является ошибочной, к примеру, в два раза – сделает ли это всю мою прикидку «абсолютно бессмысленной»? Нет, в рамках моей попытки разобраться в степени бесполезности брачных договоров, оспаривают ли успешно в суде в среднем 1% или 2% договоров – не играет решающей роли, это в любом случае довольно мало. Короче, мой посыл вам такой: попытаться объективно прикинуть базовые уровни распространенности какого-либо явления – это очень часто отличный способ сформировать свое мнение по этому вопросу. Пользуйтесь им почаще!

🎾 как за час навайбкодил прототип > протестил > сменил направление в последний месяц дико влюбился в падел, играю постоянно, и для меня это стало способом не выгорать ну и, как это бывает, в какой-то момент начал смотреть на это уже как продакт стал валидировать гипотезу, что у людей есть частая боль — быстро найти 4-го игрока, когда кто-то в последний момент сливается с игры, из инсайтов - множественные сообщения в чатиках побрейнштормил с гпт, выделил сегменты, подумал про риски, потом пошел в клод и буквально за час навайбкодил простой прототип на джанго с базой данных и вот в процессе понял самое интересное: история, скорее всего, не про b2c в лоб логичнее идти через b2b-модель и делать продукт в первую очередь для клубов, а b2c использовать как канал лидогенерации и тебе не нужно рисовать прототипы в фигме, не нужно сливать сотни тысяч на мвп, чтобы быстро протестировать гипотезу навайбкодил пре-мвп > продолжил в том же направлении или же сменил вектор

Есть тезис, который команды произносят с гордостью: стратегию не пишем, вместо этого быстро проверяем гипотезы. То есть между стратегией и скоростью выбрали скорость, потому что стратегия в этой картине мира что-то долгое и тяжёлое, что мешает бежать. Выбор мнимый. Хорошая стратегия вообще не про то, сколько её строили и сколько нужно строить. Она про то, понимаешь ли ты систему, в которой работаешь: какие в ней причинно-следственные связи, где узкие места, в какой точке небольшое усилие даёт непропорционально большой эффект. Такое понимание можно собрать за неделю, если знаешь, куда смотреть. Можно не собрать и за год. Я уже писал, что гипотеза в научном смысле описывает наблюдаемый феномен и требует экспериментальной проверки, а «сделаем X, получим Y» — это идея. В бэклоге команд, гордящихся скоростью, чаще лежит именно второе. Поэтому если этого самого понимания системы нет, быстрая проверка гипотез превращается в брутфорс идей в надежде, что какая-то стрельнёт. Скорость тут не спасает, ибо пространство вариантов огромное, а выигрышных в нём единицы. И даже когда идея стреляет, на следующем шаге это почти ничего не даёт. Гипотеза в стратегии живёт внутри связанного плана, где несколько линий бьют в один рычаг, поэтому её проверка даёт больше, чем ответ на один вопрос. Подтвердилась или нет, картина системы обновилась целиком. Соседние гипотезы стали сильнее или потеряли смысл. Появились новые данные, которые теперь надо объяснять, и следующий шаг выбирается уже из обновленный картины мира. Идея же ничего не объясняет. Проверил, получил плюс два процента к метрике, порадовался и пошёл к следующему, никак не связанному пункту бэклога. Почему сработало и куда копать дальше, непонятно. Знание не накапливается, и даже десяток удачных идей даёт десять локальных улучшений, которые не складываются в одно большое. Проверять нужно, но без понимания системы проверять нечего, остаётся перебирать идеи и гордо называть это «культурой экспериментов».

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

Спроси ошибку: «Что ты хочешь мне сказать?»

Ответ придёт словами-ощущением и именно это ощущение направит Дух продукта Туда, куда вам нужно идти.

Касдевить нельзя запускать — Провел 32 интервью, — похвастался фаундер. — Много узнал — Как продавать выяснил? — Пока нет Двадцать лет нам вбивали в головы: сначала касдев — потом продукт. Когда сайт стоил 100к рублей, а приложение — полгода разработки и пару миллионов — это был закон выживания. Ошибся сегментом — сжег бабло, похоронил компанию. Разговоры обходились дешевле кода, поэтому мы «изучали потребителей». Год назад я написал пост с этим же заголовком и честно признался: не знаю, где теперь ставить запятую. ИИ уронил стоимость разработки до нуля, простенький Booking собирается за вечер — так зачем болтать? За год насмотрелся на команды в Product Games — и запятая нашлась. Те, кто месяцами проводил интервью, приносили красивые отчёты: «боль подтверждена», «сегмент валидирован». Те, кто запускался, приносили другое: «слабали лендинг, налили трафика, одна оплата». Или: «оплат ноль, зато двое послали нахер». Слова ничего не стоят, поэтому люди врут. А вот своими кровными — нет. Вывод прост: если гипотезу можно проверить продажей — нахер разговоры. Оставь интервью для того, что за вечер не соберешь — томографов и софта для атомных электростанций, например. Там запятая на старом месте. В остальных случаях: кастевить нельзя, запускать.

Суперпозиция — это (не)Знание того, что мы ⇄ рынок ⇄ мир ⇄ Вселенная ещё не выбрали – Это (не)Знание (внутренний и внешний спор) идёт в двух направлениях: "мы не знаем, будет ли это востребовано, потому что мы недостаточно исследовали" (незнание в нас) vs "мы не знаем, потому что рынок сам ещё не решил (потому что всё вокруг возникнет только из взаимодействия наблюдателя и наблюдаемого" (незнание в мире)).

Главная ошибка – выбирать "давайте проведём больше рисёрча" там, где рынок-мир-пространство ещё не знают помнят о проблеме

– Любая фича до своего релиза — это ничто, бесконечное пространство (не)возможных вариантов-кейсов-ситуаций и механик, которое схлопывается в реальность(и) только в момент, когда юзер её начал наблюдать. Наблюдение происходит тогда, когда Нечто постучалось в реальность памяти, и это Нечто резонирует со структурой памяти. Память – это паттерны-фракталы-артефакт(ы) В продукте фича "случается" для пользователя, только если модель продукта резонирует с его существующей ментальной памятью. В ином случае, продукт будет говорить на языке, для которого у памяти пользователя ещё нет структуры распознавания, а всё неизвестное, что происходит в вашем продукте и что не удержал пользователь, бессознательно сохраняется в сознании-памяти пользователя, потому что функция сохранения и есть определение памяти. И всё что пользователь не понял в вашем продукте, он с некоторой вероятностью сможет вспомнить и понять в продукте ваших конкурентов. Наблюдатель и наблюдаемое про вложенность, а не различные объекты

Структура продукта = структура команды = структура мира-рынка и ЦА, которая его наблюдает и строит

Продакт, пытающийся "объективно" (хаха) оценить архитектуру продукта, сам же стоит внутри того же контура, который оценивает (он оценивает сам себя, являясь частью единой Системы), но никак не наблюдателем и наблюдением снаружи. Правильное наблюдение расширяет и сужает пространство решений одновременно. Правильный внутренне-внешний рисёрч работает так же, не просто сужая 100% гипотез до 20%, а расширяя(!) оставшиеся 20% до потенциала 100%. Наблюдение это предсказание и вы можете предсказывать на основе того, что помните

Почему один стартап доходит до денег, а другой - нет 🤝 Посмотрим на два кейса:

Финансист и Metrica.Guru стартовали с идеи, которая казалась основателям очевидной, но результат получили разный. Оба кейса рассказаны самими основателями, ссылки оставлю

1️⃣ Кейс А. «Финансист» - потерял год на продукт, который никто не купил Станислав Кутузов до этого 12 лет проработал в GM, руководил 27 дилерскими центрами. В 2019-м решил делать сервис управленческого учёта для малого и среднего бизнеса - увидел, что в этой нише нет явного лидера, в отличие от CRM или бухгалтерии Команда сделала презентацию и пошла к знакомым бизнесменам - спросили около 20 топ-менеджеров: «Если бы был такой продукт, вы бы его взяли?». Все сказали - да, круто, взяли бы и на основе этого запустили разработку Когда первая версия была готова - её не купил никто из тех, кто хвалил идею на презентации, ни один человек 🚴‍♂️ Кутузов сам формулирует причину прямо:

они не искали реальную потребность, а показали красивую картинку и получили комплименты

Классическая ловушка гипотетического вопроса - люди почти всегда говорят «да, я бы купил», когда не рискуют реальными деньгами прямо сейчас После этого пришлось пересобрать продукт с нуля, разобраться в методологии реального кастдева и запуститься на год позже, чем планировали Важная пометочка: компания не умерла, сейчас у неё 2000+ клиентов, включая крупные бренды, но год и ресурсы на первую версию были потрачены впустую именно из-за этой ошибки 2️⃣ Кейс Б. Metrica.Guru - дошли до первых продаж ещё до запуска Основатели сначала хотели делать аналитику для рынка видеосвязи, провели 30 интервью с потенциальной аудиторией и увидели, что тема почти никого не греет. Не стали упираться в исходную идею: заменили продукт под то, что реально звучало в разговорах - сервис, который отслеживает данные о конкурентах Провели второй раунд интервью - ещё 30 человек, уже под новую гипотезу. 50% опрошенных проявили интерес, из них отобрали 13 для пилота. Только после этого начали питчить идею и искать первых заинтересованных клиентов Что общего у этих двух кейсов: ➖ вопрос задавали гипотетически («вы бы купили?»), а не про реальное поведение и реальные деньги ➖ похвала на презентации приняли за подтверждённый спрос ➖ деньги и время вложили в разработку до того, как кто-то реально заплатил У меня была похожая ловушка с проектом для интерьерных дизайнеров Идея казалась логичной: много ручной рутины, можно автоматизировать. Вместо того чтобы сразу кодить, поговорил с дизайнерами - узнал что реально бесит их в работе и на что уходит больше всего времени. Оказалось, что проблема, которую я собирался решать, для них не существовала вообще Проект я закрыл за неделю, не написав ни строчки кода, что уже заебись Короче, подтверждая инфу из прошлого поста про кастдев:

если ты спрашиваешь «купили бы вы это?» вместо того, чтобы узнать, что человек уже делает и на что уже тратит деньги - ты, скорее всего, получишь вежливое да, а не правду

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