This media is not supported in your browser
VIEW IN TELEGRAM
Жёсткая правда: то, что запрашивают ваши пользователи, редко является тем, что им действительно нужно (с)
Продакт-менеджеры терпят неудачу, потому что они воспринимают отзывы пользователей как прямые требования, а не как сигналы, указывающие на более глубокие проблемы.
И большинство продактов следуют этому НЕПРАВИЛЬНОМУ процессу:
1) давайте соберём отзывы;
2) сгруппируем похожие запросы;
3) расставим приоритеты по частоте;
4) внедрим самые популярные запросы.
Этот подход кажется ориентированным на данные, но на самом деле создает раздутые, запутанные продукты, которые решают поверхностные проблемы.
В тот момент, когда вы начинаете реализовывать запросы функций буквально, вы перестаёте быть менеджером по продукту и становитесь приёмщиком заказов.
Решение – метод извлечения сигнала.
Вместо того, чтобы воспринимать обратную связь буквально, извлеките базовый сигнал, используя 3-частную структуру:
1. Контекст.
2. Триггеры.
3. Желаемые результаты.
Контекст
Никогда не оценивайте обратную связь изолированно. Всегда спрашивайте:
«Над чем вы работали, когда вам это было нужно?»
«Где это вписывается в ваш процесс?»
«Как часто возникает эта ситуация?»
Это раскрывает фактический рабочий процесс, а не просто запрос новой функции.
Триггеры
Для каждого фрагмента обратной связи определите:
«Какое конкретное событие заставило вас задуматься об этом решении?»
«Чего вы пытались достичь, когда столкнулись с этой проблемой?»
«Какие обходные пути вы использовали?»
Желаемые результаты
Волшебный вопрос, который меняет всё:
«Если бы у вас была эта функция, что бы изменилось в вашей работе/жизни?»
Это показывает, как на самом деле выглядит успех для пользователя, который почти никогда не выражается в функциии, которую он просил.
Но большинство продактов буксуют на фразе:
«Но мои заинтересованные стороны хотят, чтобы мы были ориентированы на клиентов!»
Ответ, который изменит всё:
«Мы решаем основную потребность, стоящую за этими запросами. Вот три решения, которые решают эту проблему более эффективно».
Если они и дальше игнорируют качественную обратную связь:
«Мы выявили закономерность в 12 разговорах с клиентами. Этот сигнал сопоставляется с падением на 9% в воронке конверсии на шаге 3. Вот гипотеза, которую мы должны проверить».
Обратите внимание, как связывается боль пользователя с метриками.
TLDR:
– 5-7 глубоких бесед с клиентами достаточно;
– клиент выступает советчиком;
– поиск паттерна поведения;
– триангуляция отзывов с данными об использовании;
– сегментация отзывов по ценности для клиента;
– поиск решения для результата, а не запроса.
И помните, что в тот момент, когда пользователи начинают говорить вам, что именно для них нужно создать, вы теряете нить событий.
Работа продакта не в том, чтобы быть приёмщиком заказов. Ваша задача — быть детективом, находящим настоящие проблемы, скрывающиеся за поверхностными запросами.
Продакт-менеджеры терпят неудачу, потому что они воспринимают отзывы пользователей как прямые требования, а не как сигналы, указывающие на более глубокие проблемы.
Ваша задача не создавать то, что просят пользователи, а решать проблемы, которые у них действительно есть.
И большинство продактов следуют этому НЕПРАВИЛЬНОМУ процессу:
1) давайте соберём отзывы;
2) сгруппируем похожие запросы;
3) расставим приоритеты по частоте;
4) внедрим самые популярные запросы.
Этот подход кажется ориентированным на данные, но на самом деле создает раздутые, запутанные продукты, которые решают поверхностные проблемы.
Потому что, когда пользователи говорят «добавьте панель управления для X», они на самом деле они просто говорят «Мне сложно понять X».
В тот момент, когда вы начинаете реализовывать запросы функций буквально, вы перестаёте быть менеджером по продукту и становитесь приёмщиком заказов.
Решение – метод извлечения сигнала.
Вместо того, чтобы воспринимать обратную связь буквально, извлеките базовый сигнал, используя 3-частную структуру:
1. Контекст.
2. Триггеры.
3. Желаемые результаты.
Контекст
Никогда не оценивайте обратную связь изолированно. Всегда спрашивайте:
«Над чем вы работали, когда вам это было нужно?»
«Где это вписывается в ваш процесс?»
«Как часто возникает эта ситуация?»
Это раскрывает фактический рабочий процесс, а не просто запрос новой функции.
Триггеры
Для каждого фрагмента обратной связи определите:
«Какое конкретное событие заставило вас задуматься об этом решении?»
«Чего вы пытались достичь, когда столкнулись с этой проблемой?»
«Какие обходные пути вы использовали?»
Желаемые результаты
Волшебный вопрос, который меняет всё:
«Если бы у вас была эта функция, что бы изменилось в вашей работе/жизни?»
Это показывает, как на самом деле выглядит успех для пользователя, который почти никогда не выражается в функциии, которую он просил.
Но большинство продактов буксуют на фразе:
«Но мои заинтересованные стороны хотят, чтобы мы были ориентированы на клиентов!»
Ответ, который изменит всё:
«Мы решаем основную потребность, стоящую за этими запросами. Вот три решения, которые решают эту проблему более эффективно».
Если они и дальше игнорируют качественную обратную связь:
«Мы выявили закономерность в 12 разговорах с клиентами. Этот сигнал сопоставляется с падением на 9% в воронке конверсии на шаге 3. Вот гипотеза, которую мы должны проверить».
Обратите внимание, как связывается боль пользователя с метриками.
TLDR:
– 5-7 глубоких бесед с клиентами достаточно;
– клиент выступает советчиком;
– поиск паттерна поведения;
– триангуляция отзывов с данными об использовании;
– сегментация отзывов по ценности для клиента;
– поиск решения для результата, а не запроса.
Решайте проблемы, а не функции.
И помните, что в тот момент, когда пользователи начинают говорить вам, что именно для них нужно создать, вы теряете нить событий.
Работа продакта не в том, чтобы быть приёмщиком заказов. Ваша задача — быть детективом, находящим настоящие проблемы, скрывающиеся за поверхностными запросами.
This media is not supported in your browser
VIEW IN TELEGRAM
product manager preparing to write a PRD no one will read
11 хард-скиллов продакт-менеджера God Mode:
– Понимание того, из чего складываются метрики бизнеса и как на них влияют метрики продукта/фич. Умение переключаться между разными уровнями абстракций.
– Понимание системной связи между фичами в продукте (или её отсутствия) и потоков данных, движущихся через систему.
– Наблюдение, отслеживание и контроль жизни фич во времени.
– Умение проводить собеседование с любымспециалистом человеком.
– Умение работать с командами с разными навыками и опытом. Эмоциональная регуляция команды.
– Скорость обучения. Стратегическое терпение.
– Умение получать релевантные данные с рынка не только из первых рук.
– Поведенческая экономика. Ecosystem thinking.
– Конфигурации аналитических систем.
– Интуиция относительно того, что важно.
– Влияние без полномочий (заслуживать доверие через данные и убедительные доводы). И интуиция по людям.
– Понимание того, из чего складываются метрики бизнеса и как на них влияют метрики продукта/фич. Умение переключаться между разными уровнями абстракций.
– Понимание системной связи между фичами в продукте (или её отсутствия) и потоков данных, движущихся через систему.
– Наблюдение, отслеживание и контроль жизни фич во времени.
– Умение проводить собеседование с любым
– Умение работать с командами с разными навыками и опытом. Эмоциональная регуляция команды.
– Скорость обучения. Стратегическое терпение.
– Умение получать релевантные данные с рынка не только из первых рук.
– Поведенческая экономика. Ecosystem thinking.
– Конфигурации аналитических систем.
– Интуиция относительно того, что важно.
– Влияние без полномочий (заслуживать доверие через данные и убедительные доводы). И интуиция по людям.
В целом, дело даже НЕ в «хард-скиллах», а в том, насколько чётко ты понимаешь, вкаком хаосечём ты умеешь хорошо ориентироваться.
Please open Telegram to view this post
VIEW IN TELEGRAM
Product Management & AI
Неудачи и факапы — это данные Относись к ним соответственно и научи себя и команду быстро восстанавливаться после любых факапов, мгновенно переходя от ощущения эмоций к анализу причин. Как только вы закончите анализ, так же мгновенно пробуйте новое. В противном…
This media is not supported in your browser
VIEW IN TELEGRAM
11 советов как продакт-менеджеру заранее предотвращать срывы сроков разработки (и что делать, если они срываются)
0. Всегда умножай оценки сроков х2-3. А при коммуникации со стейкхолдерами давай диапазоны вместо точных дат.
1. Не критикуй разрабов за пессимистичные прогнозы разработки – пусть лучше они честно скажут, что это займёт месяц, чем под давлением пообещают 2 недели и завалят всё на 2 месяца.
3. Декомпозируй задачи до уровня обнаружения в ней любых возможных блоков через 2-3 дня её разработки.
Если задачу нельзя разбить до такого уровня, значит задача недостаточно тобой детализированна.
4. Помни про Critical path - последовательность задач, в которой задержка любой задачи сдвигает всю дату релиза.
Выделяй сеньоров на критический путь + всегда имей прозапас запасного участника такого уровня для критической части.
5. Включай в сессии по оценке сроков разарботки не только сеньоров, но и мидлов. Именно мидлы пишут код и именно их оценки самые реалистичные.
6. Требуй тех. задание от лид-инженера перед началом разработки.
Оно заставляет команду разработки продумать архитектуру, выявить зависимости и определить точки интеграции ДО написания кода.
7. Стендапы нужны для выявления блокеров и отклонений. Нет блокеров и отклонений – не мучайтесь с командой ежедневными созвонами, они ведут к выгоранию, которое ведёт к потере чувства времени и сроков.
Вместо них можно ведите автоматизированный стендап в Slack с указанием % готовности задач и уведомлениями о превышении запланированных сроков и объяснением причин и новой оценкой времени со стороны тимлида.
Что делать, если сроки срываются?
8. Red Room – экстренный режим работы с ежедневными встречами всех ключевых участников для быстрого принятия решений и устранения блокеров.
Если Red Room длится более одной недели, значит проблема сроков разработки носит стратегический характер и требует структурных кадровых/культурных решений, а не разовых фиксов/припарок.
Урезай фичу до версии, которая всё ещё решает основную пользовательскую проблему и приносит ценность юзерам/бизнесу
Урезанная версия идёт по 3 сценариям с чёткими критериями: время vs scope vs качество.
И если вы не можете убрать 30% скопа без потери основной ценности, значит изначальное решение было over-engineered.
Всегда документируй такие решения для избежания вопросов со стороны заинтересованных лиц (и конфликтов в будущем).
10. Перераспределение ресурсов с менее критичных задач и привлечение дополнительных разрабов работает только при наличии:
а) чёткой и описанной архитектуры;
б) возможностей для параллелизации задач;
в) разрабов с опытом в конкретной области/стэке;
г) наличии 1-2 недель на их онбординг.
11. Регулярные post-mortem после каждого релиза позволяют команде учиться на своих ошибках и повышать точность планирования. Если одни и те же проблемы повторяются в нескольких post-mortem, это снова про систематическую ошибку и кардинальные решения по её исправлению.
Каждая фаза разработки должна приносить ценность для пользователя и бизнеса, а не быть очередным спринтом-забегом на время для команды разработки.
0. Всегда умножай оценки сроков х2-3. А при коммуникации со стейкхолдерами давай диапазоны вместо точных дат.
1. Не критикуй разрабов за пессимистичные прогнозы разработки – пусть лучше они честно скажут, что это займёт месяц, чем под давлением пообещают 2 недели и завалят всё на 2 месяца.
Поощряй и стимулируй в команде точность и предсказуемость поставки, а не скорость и оптимистичные оценки
3. Декомпозируй задачи до уровня обнаружения в ней любых возможных блоков через 2-3 дня её разработки.
Если задачу нельзя разбить до такого уровня, значит задача недостаточно тобой детализированна.
4. Помни про Critical path - последовательность задач, в которой задержка любой задачи сдвигает всю дату релиза.
Выделяй сеньоров на критический путь + всегда имей прозапас запасного участника такого уровня для критической части.
5. Включай в сессии по оценке сроков разарботки не только сеньоров, но и мидлов. Именно мидлы пишут код и именно их оценки самые реалистичные.
6. Требуй тех. задание от лид-инженера перед началом разработки.
Оно заставляет команду разработки продумать архитектуру, выявить зависимости и определить точки интеграции ДО написания кода.
Если лид не может написать ТЗ за 3 часа, значит задача УЖЕ недостаточно понятна для реализации
7. Стендапы нужны для выявления блокеров и отклонений. Нет блокеров и отклонений – не мучайтесь с командой ежедневными созвонами, они ведут к выгоранию, которое ведёт к потере чувства времени и сроков.
Вместо них можно ведите автоматизированный стендап в Slack с указанием % готовности задач и уведомлениями о превышении запланированных сроков и объяснением причин и новой оценкой времени со стороны тимлида.
Что делать, если сроки срываются?
8. Red Room – экстренный режим работы с ежедневными встречами всех ключевых участников для быстрого принятия решений и устранения блокеров.
Если Red Room длится более одной недели, значит проблема сроков разработки носит стратегический характер и требует структурных кадровых/культурных решений, а не разовых фиксов/припарок.
9. Урезание функционала это про чёткое понимание текущих приоритетов и их влияния на бизнес-цели, а не сокращение/навёрстывание сроков
Урезай фичу до версии, которая всё ещё решает основную пользовательскую проблему и приносит ценность юзерам/бизнесу
Урезанная версия идёт по 3 сценариям с чёткими критериями: время vs scope vs качество.
И если вы не можете убрать 30% скопа без потери основной ценности, значит изначальное решение было over-engineered.
Всегда документируй такие решения для избежания вопросов со стороны заинтересованных лиц (и конфликтов в будущем).
10. Перераспределение ресурсов с менее критичных задач и привлечение дополнительных разрабов работает только при наличии:
а) чёткой и описанной архитектуры;
б) возможностей для параллелизации задач;
в) разрабов с опытом в конкретной области/стэке;
г) наличии 1-2 недель на их онбординг.
Если добавление разрабов не ускоряет доставку кода через 2 недели, правильным решением будет их отозвать и не мучать
11. Регулярные post-mortem после каждого релиза позволяют команде учиться на своих ошибках и повышать точность планирования. Если одни и те же проблемы повторяются в нескольких post-mortem, это снова про систематическую ошибку и кардинальные решения по её исправлению.
Каждая фаза разработки должна приносить ценность для пользователя и бизнеса, а не быть очередным спринтом-забегом на время для команды разработки.
This media is not supported in your browser
VIEW IN TELEGRAM
Почему разрабы мы все факапим сроки? Посвящается всем разрабам и продактам
Причина №1 – у нас искажено системное мышление, из-за чего мы видимкод продукт мир как цепочку причинно-следственных связей и параметров:
– Требование → Инструкция → Решение
– Input → Output.
– Ошибка → Исправление.
Но продукты — это Системы, в которых есть Пользователи, Бизнес и Хаос.
И одержимость «параметрами» (функциями, спецификациями, архитектурой и культурой кода) считается самой слабой точкой влияния в любой Системе.
Самая сильная?
Ментальные модели и цели Системы.
Потому что продукт это не просто набор технически работающих фич. Это сложная Система, в которой:
– Каждая новая функция связана и влияет на существующие.
– Поведение пользователей создаёт цепочки общих циклов действий.
– И даже небольшие изменения могут иметь неожиданные последствия, создавая новые проблемы (Хаос).
И распространенная ошибка – поиск «первопричин проблем».
В Системах редко бывают первопричины.
Вместо этого есть структуры, которые создают Шаблоны поведения Систем и пользователей.
Более того, сами Системы обманывают нас, представляя себя как серию событий, на которые мы реагируем:
– Запросы фич от юзеров.
– Текущие ошибки в коде.
– Конкуренты/рыночек и всё такое.
Поэтому мы ошибочно фокусируем внимание на том, ЧТО и КАК строить, а не на понимании, ПОЧЕМУ Система ведёт себя так, а не иначе.
Это всего лишь со-бы-ти-я.
Настоящая сила продакта и разраба в том, чтобы видеть Шаблоны.
Наше мышление — не слабость. Это основа, потому что мы понимаем:
– Циклы обратной связи.
– Управление состояниями.
– Сложные зависимости.
– Системные ограничения.
Всё, что нам нужно – это применять их к Человеческим Системам, чаще задавая себе вопросы:
– Каковы скрытые Шаблоны?
– В чём задержки Системы?
– Какие ментальные модели определяют все решения?
Поэтому, прежде чем каким-либо образомулучшить нарушить работу Системы, лучше посмотреть, как она себя ведёт.
Не начинайте с решений.
Не спешите с выводами.
Просто наблюдайте.
🤷♂️
Причина №1 – у нас искажено системное мышление, из-за чего мы видим
– Требование → Инструкция → Решение
– Input → Output.
– Ошибка → Исправление.
Но продукты — это Системы, в которых есть Пользователи, Бизнес и Хаос.
И одержимость «параметрами» (функциями, спецификациями, архитектурой и культурой кода) считается самой слабой точкой влияния в любой Системе.
Самая сильная?
Ментальные модели и цели Системы.
Потому что продукт это не просто набор технически работающих фич. Это сложная Система, в которой:
– Каждая новая функция связана и влияет на существующие.
– Поведение пользователей создаёт цепочки общих циклов действий.
– И даже небольшие изменения могут иметь неожиданные последствия, создавая новые проблемы (Хаос).
И распространенная ошибка – поиск «первопричин проблем».
В Системах редко бывают первопричины.
Вместо этого есть структуры, которые создают Шаблоны поведения Систем и пользователей.
Более того, сами Системы обманывают нас, представляя себя как серию событий, на которые мы реагируем:
– Запросы фич от юзеров.
– Текущие ошибки в коде.
– Конкуренты/рыночек и всё такое.
Поэтому мы ошибочно фокусируем внимание на том, ЧТО и КАК строить, а не на понимании, ПОЧЕМУ Система ведёт себя так, а не иначе.
Это всего лишь со-бы-ти-я.
Настоящая сила продакта и разраба в том, чтобы видеть Шаблоны.
И наименее очевидная часть Системы, её функция и Цель, часто является наиболее важным фактором, определяющим само поведение Системы.
Наше мышление — не слабость. Это основа, потому что мы понимаем:
– Циклы обратной связи.
– Управление состояниями.
– Сложные зависимости.
– Системные ограничения.
Всё, что нам нужно – это применять их к Человеческим Системам, чаще задавая себе вопросы:
– Каковы скрытые Шаблоны?
– В чём задержки Системы?
– Какие ментальные модели определяют все решения?
Поэтому, прежде чем каким-либо образом
Не начинайте с решений.
Не спешите с выводами.
Просто наблюдайте.
🤷♂️
Понедельник – день (не)существенных задач
Понедельники be like: стата вся обновлена, багрепорты/фидбек свежее, инфа читается иначе, вокруг все в курсе актуальности событий.
Но начинаются забеги по созвонам, таскам, личкам.
В них часто смотришь на опережение (не)существующих задач.
Задач, которые сам сделал/стали/перестали таковыми быть из-за изменений рынка, методологий, настроений (всё об одном и том же, это тоже часто вспоминаешь в понедельник).
Думай по понедельникам про 👆
Понедельники be like: стата вся обновлена, багрепорты/фидбек свежее, инфа читается иначе, вокруг все в курсе актуальности событий.
Но начинаются забеги по созвонам, таскам, личкам.
В них часто смотришь на опережение (не)существующих задач.
Задач, которые сам сделал/стали/перестали таковыми быть из-за изменений рынка, методологий, настроений (всё об одном и том же, это тоже часто вспоминаешь в понедельник).
Что То одно существенное?
Ради чего Всё динамично в понедельник?
Думай по понедельникам про 👆
This media is not supported in your browser
VIEW IN TELEGRAM
Майский дайджест для продактов и их команд уже готов к просмотру (c эйчбио) 🍿
– Продуктовый дзен
– Продуктовый серфинг
– Игры разработчиков
– RAID – реестр рисков
– Карьера в форме пирамиды
– Вопросы ждут от кандидатов
– Как не убить культуру ошибок
– Другая постановка задачи
– Как собирать обратную связь
– Когда масштаб убивает суть
– Дифференцируй, а не конкурируй
– 3 стадии с продуктовым исследованиями
– 39 шаблонов для UX-исследований
– Research Debt
– Чёрный SEO — это GEO
– Когда VIP не VIP
– История ухудшения продукта
– Слабая активация — слабая аура
– Важность shit tolerance
– Как знакомиться первым
– "Так, а задача?"
– Отмазки для продакта
– Кто правит миром
– Лень, невнимательнось и деньги
– Как хвастаться своей работой
– Искусство переговоров c результатом
– Одна метрика выросла, вторая упала
– Фаундер на саппорте
– Что отделяет сеньоров от стаффов
– Работаем с лоу-перформерами
– Процесс тестирования гипотез
– Про User Story mapping
– Не понимаешь? Создай шаблон
– Шаблон амазоновских мемо
– Адаптивность — про способность чувствовать
– Фактор роста: найти, усилить, не потерять
– Дисфункциональность команды
– Остаться в живых
– Новая работа — минное поле
– Задачи, которые воруют энергию
– Гайд: как манипулировать данными
– Пути внедрения LLM в продукт
– Атрофия навыков из-за AI
– ИИ не знает, когда не знает
– Зачем менеджеру смотреть в бездну
– Поговорки продуктолога
– Исследование продактов в России
Обзор международного рынка продактов 2025: 40% опрошенных считают своих менеджеров бесполезными; выгорание на критическом уровне; самые счастливые люди – фаундеры стартапов (ахахахахахахаха. YES, BUT. – прим.).
💫 Hiraeth & ᐰksarnerk - See The Stars
– Продуктовый дзен
– Продуктовый серфинг
– Игры разработчиков
– RAID – реестр рисков
– Карьера в форме пирамиды
– Вопросы ждут от кандидатов
– Как не убить культуру ошибок
– Другая постановка задачи
– Как собирать обратную связь
– Когда масштаб убивает суть
– Дифференцируй, а не конкурируй
– 3 стадии с продуктовым исследованиями
– 39 шаблонов для UX-исследований
– Research Debt
– Чёрный SEO — это GEO
– Когда VIP не VIP
– История ухудшения продукта
– Слабая активация — слабая аура
– Важность shit tolerance
– Как знакомиться первым
– "Так, а задача?"
– Отмазки для продакта
– Кто правит миром
– Лень, невнимательнось и деньги
– Как хвастаться своей работой
– Искусство переговоров c результатом
– Одна метрика выросла, вторая упала
– Фаундер на саппорте
– Что отделяет сеньоров от стаффов
– Работаем с лоу-перформерами
– Процесс тестирования гипотез
– Про User Story mapping
– Не понимаешь? Создай шаблон
– Шаблон амазоновских мемо
– Адаптивность — про способность чувствовать
– Фактор роста: найти, усилить, не потерять
– Дисфункциональность команды
– Остаться в живых
– Новая работа — минное поле
– Задачи, которые воруют энергию
– Гайд: как манипулировать данными
– Пути внедрения LLM в продукт
– Атрофия навыков из-за AI
– ИИ не знает, когда не знает
– Зачем менеджеру смотреть в бездну
– Поговорки продуктолога
– Исследование продактов в России
Обзор международного рынка продактов 2025: 40% опрошенных считают своих менеджеров бесполезными; выгорание на критическом уровне; самые счастливые люди – фаундеры стартапов (ахахахахахахаха. YES, BUT. – прим.).
💫 Hiraeth & ᐰksarnerk - See The Stars
Product Management & AI
Майский дайджест для продактов и их команд уже готов к просмотру (c эйчбио) 🍿 – Продуктовый дзен – Продуктовый серфинг – Игры разработчиков – RAID – реестр рисков – Карьера в форме пирамиды – Вопросы ждут от кандидатов – Как не убить культуру ошибок – Другая…
Стадии счастья фаундера стартапа:
0. Мы что-то создаём, что может быть полезно людям.
1. И всё же, что мы создаём?
3. MVP всего вокруг.
5. Последняя N из NNNNN – друг.
6. Время. Шум. Баланс. Гармония.
6. Ода ежемесячной подписке.
7. В голове один "Cost per Event".
8. MRR GO BRR. Шум. Баланс.
9. Гармония.
0. Воу, мы что-то создаём!
0. Мы что-то создаём, что может быть полезно людям.
1. И всё же, что мы создаём?
3. MVP всего вокруг.
5. Последняя N из NNNNN – друг.
6. Время. Шум. Баланс. Гармония.
6. Ода ежемесячной подписке.
7. В голове один "Cost per Event".
8. MRR GO BRR. Шум. Баланс.
9. Гармония.
0. Воу, мы что-то создаём!
This media is not supported in your browser
VIEW IN TELEGRAM
Хорошая продуктовая стратегия
Плохая продуктовая стратегия
– Хорошая стратегия продукта всегда даёт свежий взгляд на рынок и продукт. Плохая стратегия продукта пытается соответствовать уже существующему мнению о том, что следует делать с продуктом.
– Хорошая продуктовая стратегия определяет целевые и нецелевые сегменты клиентов. Плохая игнорирует сегментацию, либо пытается охватить много сегментов.
– Хорошая продуктовая стратегия даёт ясность в отношении потребностей клиента. Плохая представляет собой список функций, которые пытаются "решить" потребности множества сегментов клиентов.
– Хорошая стратегия продукта связывает решения и действия с планами и рисками. Плохая стратегия не видит и не сопоставляет эти факторы.
– Хорошая продуктовая стратегия представляет честную оценку рынка, конкуренции и положения продукта. Плохая преуменьшает конкуренцию, либо, вообще, игнорирует эти факторы.
– Хорошая продуктовая стратегия помогает понять как играть на поле с действующими конкурентами. Плохая по-умолчанию принимает их правила игры.
– Хорошая стратегия продукта полагается на его долгосрочные преимущества. Плохая опирается на текущие и краткосрочные, переоценивая их реальное влияние на продукт.
– Хорошая стратегия продукта возникает из глубоких размышлений, но сформулирована так, что любой её может понять и повторить. Она вдохновляет, потому что ярка, амбициозна, достижима. Плохая стратегия пытается казаться таковой.
Плохая продуктовая стратегия
– Хорошая стратегия продукта всегда даёт свежий взгляд на рынок и продукт. Плохая стратегия продукта пытается соответствовать уже существующему мнению о том, что следует делать с продуктом.
– Хорошая продуктовая стратегия определяет целевые и нецелевые сегменты клиентов. Плохая игнорирует сегментацию, либо пытается охватить много сегментов.
– Хорошая продуктовая стратегия даёт ясность в отношении потребностей клиента. Плохая представляет собой список функций, которые пытаются "решить" потребности множества сегментов клиентов.
– Хорошая стратегия продукта связывает решения и действия с планами и рисками. Плохая стратегия не видит и не сопоставляет эти факторы.
– Хорошая продуктовая стратегия представляет честную оценку рынка, конкуренции и положения продукта. Плохая преуменьшает конкуренцию, либо, вообще, игнорирует эти факторы.
– Хорошая продуктовая стратегия помогает понять как играть на поле с действующими конкурентами. Плохая по-умолчанию принимает их правила игры.
– Хорошая стратегия продукта полагается на его долгосрочные преимущества. Плохая опирается на текущие и краткосрочные, переоценивая их реальное влияние на продукт.
Хорошая продуктовая стратегия помогает различать: а) варианты; б) компромиссы и оптимизировать их в) долгосрочные преимущества. Плохая сводит всё к краткосрочным компромиссам
– Хорошая стратегия продукта возникает из глубоких размышлений, но сформулирована так, что любой её может понять и повторить. Она вдохновляет, потому что ярка, амбициозна, достижима. Плохая стратегия пытается казаться таковой.
This media is not supported in your browser
VIEW IN TELEGRAM
Парадоксы при discovery в продуктах
Опытные продакты начинают с НЕТ — что вашим пользователям не нужно то, что вы создаёте. А затем выстраивают убеждение на основе идей и находят ДА к тому, что пользователи действительно хотят.
Парадокс в том, что:
– Название нашей должности предполагает, что мы должны знать, чего хотят пользователи.
– Пользователи ожидают, что у нас это будет.
– Наша дорожная карта подразумевает, что мы это поняли.
По факту же:
– Мы разговариваете с пользователями, но задаём наводящие вопросы, которые подтверждают наши же идеи.
– Мы отбираем ту обратную связь, которая совпадает и поддерживает нашу дорожную карту.
– Мы относимся к исследованию пользователей как к проверке, а не как к исследованию.
Настоящее discovery начинается с другого мышления.
Вместо «Нам нужно проверить идею этой функции», думайте «Нам нужно понять эту проблемную область и ситуацию».
Вместо «Хотят ли пользователи фичу?» спросите «Чего на самом деле пытаются достичь пользователи?»
Перед любым разговором с пользователем перечислите свои предположения:
– У кого есть эта проблема?
– Когда они с ней сталкиваются?
– Как они решают её сегодня?
– Что сделало бы решение ценным для них?
– Что заставило бы их отказаться от текущего подхода?
Задавайте вопросы:
Прислушивайтесь к:
– Частоте (как часто это происходит?).
– Силе (насколько болезненным является опыт?).
– Альтернативам (что ещё они пробовали?).
– Контексту (когда это имеет наибольшее значение?).
Составьте карту шаблонов:
– Какие проблемы возникают у нескольких сегментов пользователей?
– Какие контексты делают проблемы более/менее болезненными?
– Какие решения пользователи постоянно хвалят или критикуют?
– По каким результатам они измеряют успех?
Ищите неожиданные идеи в:
– Проблемах, о существовании которых вы не знали.
– Решениях и обходных путях, которые клиенты создали сами.
– Контекстах, в которых рушатся ваши предположения.
Далее, отранжируйте предположения по тому:
– Насколько они важны для целей продукта.
– Насколько вы в них НЕ уверены.
сосредоточив исследование на предположениях с высокой степенью критичности и неопределённости. Эти идеи часто более ценны, чем подтверждение того, что вы итак уже знали и ожидали.
Discovery — навык. Цель discovery — ясность. Неопределённость — это тоже данные.
Опытные продакты начинают с НЕТ — что вашим пользователям не нужно то, что вы создаёте. А затем выстраивают убеждение на основе идей и находят ДА к тому, что пользователи действительно хотят.
Парадокс в том, что:
– Название нашей должности предполагает, что мы должны знать, чего хотят пользователи.
– Пользователи ожидают, что у нас это будет.
– Наша дорожная карта подразумевает, что мы это поняли.
По факту же:
– Мы разговариваете с пользователями, но задаём наводящие вопросы, которые подтверждают наши же идеи.
– Мы отбираем ту обратную связь, которая совпадает и поддерживает нашу дорожную карту.
– Мы относимся к исследованию пользователей как к проверке, а не как к исследованию.
Настоящее discovery начинается с другого мышления.
Вместо «Нам нужно проверить идею этой функции», думайте «Нам нужно понять эту проблемную область и ситуацию».
Вместо «Хотят ли пользователи фичу?» спросите «Чего на самом деле пытаются достичь пользователи?»
Перед любым разговором с пользователем перечислите свои предположения:
– У кого есть эта проблема?
– Когда они с ней сталкиваются?
– Как они решают её сегодня?
– Что сделало бы решение ценным для них?
– Что заставило бы их отказаться от текущего подхода?
Задавайте вопросы:
Расскажите о последнем случае, когда вы столкнулись с [проблемной областью]?
Расскажите мне, как вы сейчас справляетесь с [ситуацией]?
Что больше всего расстраивает в вашем текущем подходе?
Прислушивайтесь к:
– Частоте (как часто это происходит?).
– Силе (насколько болезненным является опыт?).
– Альтернативам (что ещё они пробовали?).
– Контексту (когда это имеет наибольшее значение?).
Составьте карту шаблонов:
– Какие проблемы возникают у нескольких сегментов пользователей?
– Какие контексты делают проблемы более/менее болезненными?
– Какие решения пользователи постоянно хвалят или критикуют?
– По каким результатам они измеряют успех?
Ищите неожиданные идеи в:
– Проблемах, о существовании которых вы не знали.
– Решениях и обходных путях, которые клиенты создали сами.
– Контекстах, в которых рушатся ваши предположения.
Далее, отранжируйте предположения по тому:
– Насколько они важны для целей продукта.
– Насколько вы в них НЕ уверены.
сосредоточив исследование на предположениях с высокой степенью критичности и неопределённости. Эти идеи часто более ценны, чем подтверждение того, что вы итак уже знали и ожидали.
Discovery — навык. Цель discovery — ясность. Неопределённость — это тоже данные.
Product Management & AI
Во всей шумихе с автоматизацией ИИ уделяют мало внимания сервисам старой эпохи а-ля Zapier и IFTTT, которые позволяют подключать практически любые популярные приложения и сервисы и связывать их с такими же сервисами и приложениями триггерами и экшенами. И…
Wade Foster, C-f & CEO Zapier: Мы устанавливаем новый стандарт: 100% новых сотрудников должны свободно владеть ИИ.
Как мы измеряем свободное владение ИИ в Zapier?
Вот несколько примеров для каждой роли. Обратите внимание, что это не требования или поля для проверки. Просто краткие примеры типов навыков, которые мы оцениваем.
Мы сопоставляем по 4 уровням: неприемлемый, способный, адаптивный и преобразующий.
Оценка происходит при отборе, тестах навыков, асинхронных упражнений и живых интервью. Сигналы объединяются на разных этапах.
Неприемлемый: устойчивый к инструментам ИИ и скептически относящийся к их ценности.
Способный: использующий самые популярные инструменты ИИ. Вероятно, менее 3 месяцев опыта использования ИИ.
Адаптивный: сотрудники, интегрирующие ИИ в личные рабочие процессы. Они настраивают подсказки, объединяют модели в цепочки и автоматизируют задачи для эффективности.
Трансформирующий: золотая середина. Используют ИИ для переосмысления стратегии и предложения пользователям решений, которые были невозможны 2 года назад.
Некоторые из вас спрашивали реальные вопросы, которые мы задаём в интервью:
Маркетинг:
– Как ИИ меняет то, как вы планируете или проводите рекламные кампании?
– Как вы используете ИИ для персонализации сообщений, генерации контента или анализа эффективности?
Сотрудники:
– Можете ли вы поделиться примером того, как вы используете ИИ в своей повседневной работе?
– Можете ли вы поделиться примером процесса или программы, которую вы создали с помощью ИИ? (инструменты, результаты и т. д.).
Продукт:
– Как ИИ влияет на SaaS?
– Приведите пример случая, когда вы использовали ИИ в функции продукта. Что улучшилось?
Еще несколько моментов, на которые стоит обратить внимание:
– Это не единственные приемлемые ответы. Навыки работы с ИИ различаются и в значительной степени зависят от роли.
– Ничто из этого не является Евангелием. Чтобы улучшить: пробуйте, собирайте данные, улучшайте на основе данных. Планка будет продолжать расти.
– Инженерия ≠ Маркетинг ≠ Поддержка. Контекст имеет значение. Требования различаются.
Понедельники спокойствий
Помимо выбора, решений, обсуждений, встреч, созвонов, писем – понедельники для личных и спокойных размышлений.
Чем больше мнений, тем сильнее думаешь о них.
Все встречи и созвоны – снова диалоги мнений и решений.
Больше решений → хочется их все принять и донести → больше встреч-созвонов-диалогов-мнений...
Ch-i-i-i-ll.
Спокойствия недели размышлений.
Помимо выбора, решений, обсуждений, встреч, созвонов, писем – понедельники для личных и спокойных размышлений.
Чем больше мнений, тем сильнее думаешь о них.
Все встречи и созвоны – снова диалоги мнений и решений.
Больше решений → хочется их все принять и донести → больше встреч-созвонов-диалогов-мнений...
Ch-i-i-i-ll.
Спокойствия недели размышлений.
Apple выкатила исследование, что Claude, DeepSeek-R1 и o3-mini, на самом деле... вообще не рассуждают. Они просто очень хорошо запоминают шаблоны.
Вместо того, чтобы использовать старые математические тесты, Apple протестировали эти модели на задачах, с которыми они никогда раньше не сталкивались – головоломки.
В Apple обнаружили, что эти модели вообще не рассуждают, а вместо этого выполняют сложное сопоставление шаблонов, которое отлично работает, пока сами шаблоны не становятся слишком сложными.
По мере того, как они становились сложнее, эти «мыслящие» модели начинали думать меньше, использовать меньше токенов и быстрее сдаваться в ответе, несмотря на неограниченный бюджет и вычислительные мощности.
📜 The Illusion of Thinking: Understanding the Strengths and Limitations of Reasoning Models via the Lens of Problem Complexity
Вместо того, чтобы использовать старые математические тесты, Apple протестировали эти модели на задачах, с которыми они никогда раньше не сталкивались – головоломки.
Результат: все модели «рассуждений» упираются в стену сложности, где полностью разрушаются до точности 0%
В Apple обнаружили, что эти модели вообще не рассуждают, а вместо этого выполняют сложное сопоставление шаблонов, которое отлично работает, пока сами шаблоны не становятся слишком сложными.
По мере того, как они становились сложнее, эти «мыслящие» модели начинали думать меньше, использовать меньше токенов и быстрее сдаваться в ответе, несмотря на неограниченный бюджет и вычислительные мощности.
📜 The Illusion of Thinking: Understanding the Strengths and Limitations of Reasoning Models via the Lens of Problem Complexity
Фразы, которые заставят грустить каждого продакта (пьеса в 3-х актах):
– "А давайте..."
– "Это сейчас не в приоритете"
– "Эту фичу сказал сделать СЕО"
– "Дизайнер немного не понял механику"
– "СТО сказал, что она невозможна"
– "Опять он снова про тех. долг"
– "СТО вчера уволился"
– "Бюджет сократили на 50%"
– "У юр отдела есть вопросы"
– "Релиз отложен на полгода"
– "Продажники уже продали эту фичу"
– "В фиче есть небольшие конфликты"
– "На проде критический баг"
– "Сапорт не справляется"
– "Пользователи хейтят эту фичу"
– "Конкурент выкатил нашу фичу улучшенной"
– "Нас отключили от API"
– ...
– СЕО: "О, а что там с моей фичей?"
– "А давайте..."
– "Это сейчас не в приоритете"
– "Эту фичу сказал сделать СЕО"
– "Дизайнер немного не понял механику"
– "СТО сказал, что она невозможна"
– "Опять он снова про тех. долг"
– "СТО вчера уволился"
– "Бюджет сократили на 50%"
– "У юр отдела есть вопросы"
– "Релиз отложен на полгода"
– "Продажники уже продали эту фичу"
– "В фиче есть небольшие конфликты"
– "На проде критический баг"
– "Сапорт не справляется"
– "Пользователи хейтят эту фичу"
– "Конкурент выкатил нашу фичу улучшенной"
– "Нас отключили от API"
– ...
– СЕО: "О, а что там с моей фичей?"
Код, который можно назвать, не является вечным кодом.
Функция, которую можно определить, не является безграничной функцией.
В дизайне: оставайтесь простыми.
В мыслях: принимайте глубину.
В отношениях: будьте добры.
В руководстве: будьте справедливы.
В работе: будьте компетентны.
В действии: учитывайте время.
✨ thewayofcode.com ✨
Функция, которую можно определить, не является безграничной функцией.
В дизайне: оставайтесь простыми.
В мыслях: принимайте глубину.
В отношениях: будьте добры.
В руководстве: будьте справедливы.
В работе: будьте компетентны.
В действии: учитывайте время.
Please open Telegram to view this post
VIEW IN TELEGRAM
The Way of Code
Rick Rubin | The Way of Code: The Timeless Art of Vibe Coding
Rick Rubin brings ancient wisdom to the modern age in The Way of Code, a meditation on the art and science of vibe coding. With Claude by Anthropic, the Grammy-award winning producer and author of The Creative Act turns philosophy into practice with artifacts…
20 технических концепций ИИ-агентов с простыми объяснениями от Shalini Goyal
Product Management & AI
Ответы, на которые есть вопросы Правильный ответ уже зашит в правильном вопросе Каждый сталкивался с подобным: задаёшь кому-то вопрос и к окончанию его озвучивания сам понимаешь, что ответ уже нашёлся. Так устроен мозг – он не любит тратить свою энергию…
Приоритизация фич на основе интуиции (фреймворк)
Для продактов, готовых слышать и принимать свой собственный Внутренний Голос.
Интуиция —фрейморк состояние, в котором решения принимаются не силой воли, а следованием естественному течению событий (привет, ☯ wu wei).
Задача продакта — не управлять Потоком, а наблюдать и принимать его сигналы. Одно лишь наблюдение Потока уже является процессом приоритизации по интуиции (привет, ꩜ квантовая физика).
1. Поток в постоянном движении. Одновременно с этим, внутри него нет постоянства – он (рынок) обновляется каждое мгновение того, что мы называем Временем.
Не пытайся охватить интуициейвсё время весь родмэп, рынок или список фич.
Всё это – попытки рационализировать то, что по своей природе иррационально. Вместо этого применяй интуицию точечно к какой-либо проблеме/идее/фиче/задаче для конкретных решений.
2. В интуитивном восприятии существуют только 2 типа временных горизонтов:
1) Краткосрочные задачи — те, где Время само подталкивает тебя к быстрому решению, которое ты физически Чувствуешь-и-Ощущаешь сейчас.
2) Долгосрочные задачи — те, где Интуиция даёт тебе Время на осознание того, что ты уже Знаешь, но ещё не готов ощутить и принять сейчас.
Среднесрочных планов в интуиции просто не существует.
Они — порождение "аналитического" ума, который пытается заполнить пустоту между "сейчас" и "всегда". И если задача не горит здесь/сейчас/всегда — возможно, что она... вообще не актуальна.
Истинные сигналы звучат там, где сходятся три направления:
1) Того, что ты видишь (образы, возможности, перспективы).
2) Того, что ты чувствуешь (эмоциональный отклик и энергия).
3) Того, что ты знаешь (понимание без доказательств).
Когда эти три направления сливаются в единое течение, образуется Поток и сомнений не остаётся.
Вместо сомнений и поиска опровержений своей Интуиции (видения, чувств и знаний) ищи дополнительные возможности, которые всегда скрываются за интуитивным решением.
– "Как пользователи будут переживать взаимодействие с этой фичей?"
– "Почему это важно сейчас и почему будет важно через много лет?"
– "Что из этого есть сигнал (чувство+видение+логика), а что есть шум (сомнения в чувстве видения логики).
Дай себе десять минут внутреннего диалога с каждой фичей.
Не анализа — диалога.
Мысленно моделируй все возможные взаимодействия всех объектов и условий фичи-задачи.
Когда ты находишься в этом состоянии, выбор становится очевидным не потому, что ты его вычислил, а потому, что ты его чувствуешь всем своим существом.
Только когда ты формулируешь вопрос с полной внутренней честностью, твой "ум" познаёт интуитивный ответ.
Работай одновременно с Разумом (логика + философия) и Интуицией (видение + чувства). Критерий выбора — соотношение положительных эмоций от результата и негативных от усилий (привет, Баланс).
И всегда помни о третьем элементе — Абсолютной Случайности. Именно она порождает самые неожиданные идеи, решения и фичи.
TLDR:
Забудь про фреймворки.
Прислушайся в Тишине к Интуиции.
Следуй за Внутренним Голосом.
Для продактов, готовых слышать и принимать свой собственный Внутренний Голос.
Интуиция —
Приоритизация по интуиции – это состояние Потока и его ощущение Наблюдателем
Задача продакта — не управлять Потоком, а наблюдать и принимать его сигналы. Одно лишь наблюдение Потока уже является процессом приоритизации по интуиции (привет, ꩜ квантовая физика).
1. Поток в постоянном движении. Одновременно с этим, внутри него нет постоянства – он (рынок) обновляется каждое мгновение того, что мы называем Временем.
Не пытайся охватить интуицией
Всё это – попытки рационализировать то, что по своей природе иррационально. Вместо этого применяй интуицию точечно к какой-либо проблеме/идее/фиче/задаче для конкретных решений.
2. В интуитивном восприятии существуют только 2 типа временных горизонтов:
1) Краткосрочные задачи — те, где Время само подталкивает тебя к быстрому решению, которое ты физически Чувствуешь-и-Ощущаешь сейчас.
2) Долгосрочные задачи — те, где Интуиция даёт тебе Время на осознание того, что ты уже Знаешь, но ещё не готов ощутить и принять сейчас.
Среднесрочных планов в интуиции просто не существует.
Они — порождение "аналитического" ума, который пытается заполнить пустоту между "сейчас" и "всегда". И если задача не горит здесь/сейчас/всегда — возможно, что она... вообще не актуальна.
3. То, в нужности чего ты сомневаешься при выборе по интуиции – лишь шум Потока. Шум Потока не является сигналом.
Истинные сигналы звучат там, где сходятся три направления:
1) Того, что ты видишь (образы, возможности, перспективы).
2) Того, что ты чувствуешь (эмоциональный отклик и энергия).
3) Того, что ты знаешь (понимание без доказательств).
Когда эти три направления сливаются в единое течение, образуется Поток и сомнений не остаётся.
Вместо сомнений и поиска опровержений своей Интуиции (видения, чувств и знаний) ищи дополнительные возможности, которые всегда скрываются за интуитивным решением.
– "Как пользователи будут переживать взаимодействие с этой фичей?"
– "Почему это важно сейчас и почему будет важно через много лет?"
– "Что из этого есть сигнал (чувство+видение+логика), а что есть шум (сомнения в чувстве видения логики).
Дай себе десять минут внутреннего диалога с каждой фичей.
Не анализа — диалога.
Мысленно моделируй все возможные взаимодействия всех объектов и условий фичи-задачи.
Когда ты находишься в этом состоянии, выбор становится очевидным не потому, что ты его вычислил, а потому, что ты его чувствуешь всем своим существом.
Только когда ты формулируешь вопрос с полной внутренней честностью, твой "ум" познаёт интуитивный ответ.
Интуиция в приоритизации — это резонанс между внутренним видением и внешней реальностью
Работай одновременно с Разумом (логика + философия) и Интуицией (видение + чувства). Критерий выбора — соотношение положительных эмоций от результата и негативных от усилий (привет, Баланс).
И всегда помни о третьем элементе — Абсолютной Случайности. Именно она порождает самые неожиданные идеи, решения и фичи.
TLDR:
Забудь про фреймворки.
Прислушайся в Тишине к Интуиции.
Следуй за Внутренним Голосом.
Тишина – это пространство
Пространство между мыслями, между словами, между решениями. Не пустота, которую нужно заполнить, а полнота, из которой всё рождается.
В японской эстетике есть понятие "ма" (間) — это пустое пространство, которое придаёт смысл заполненному. Без него между нотами не было бы музыки. Без пауз между словами не было бы поэзии.
В то время как большинство продуктов страдают от перенасыщенности и полноты.
Потому что мы боимся пустого пространства в интерфейсе. Мы боимся свободы в родмэпах и спринтах. Мы боимся пауз мыслей и идей. Боимся даже дней, в которые ничего не происходит.
Мы подсознательно боимся Пустоты.
Но именно в пустых пространствах продакт может понять, зачемему пользователю вообще нужен продукт.
Слова – это попытки упаковать живое в рамки неживых формулировок. Устные ограничения, которые мы сами же сознательно выбираем для себя и окружающих.
И самые эффективные решения приходят не в процессе проговаривания на совещаниях/созвонах/переписках, а в моменты безмолвного созерцания Тишины.
И только когда ум перестаёт воспринимать и генерировать шум внешнего, появляется пространство для подлинно нового.
Когда ты погружаешься в настоящее безмолвие, границы между "твоими" и "чужими" идеями растворяются и ты начинаешь слышать голос всех возможных решений сразу.
Слышать свой Внутренний Голос, который звучит тише шёпота и громче крика.
Тишина – промежутки между задачами, в которые ты НЕ пытаешься сделать или оптимизировать "что-то, чтобы было".
Тишина – паузы, которые ты даёшь собеседнику (и себе!) чтобы услышать то, что-не-было-сказано.
Тишина – это моменты, когда ты перестаёшь "интерпретировать" данные под задачи, навязывая им свои предвзятые выводы и уже подготовленные решения.
Всё это не пассивность. Это – активное присутствие, способность создавать для себя и окружающих место, в котором все могут раскрыть потенциал себя/продукта/рынка.
Тишина – это пространство.
Безмолвие – голос всех идей.
Пространство между мыслями, между словами, между решениями. Не пустота, которую нужно заполнить, а полнота, из которой всё рождается.
Когда продакт работает с Тишиной, он получает доступ к бесконечному источнику всех нерождённых идей
В японской эстетике есть понятие "ма" (間) — это пустое пространство, которое придаёт смысл заполненному. Без него между нотами не было бы музыки. Без пауз между словами не было бы поэзии.
В то время как большинство продуктов страдают от перенасыщенности и полноты.
Потому что мы боимся пустого пространства в интерфейсе. Мы боимся свободы в родмэпах и спринтах. Мы боимся пауз мыслей и идей. Боимся даже дней, в которые ничего не происходит.
Мы подсознательно боимся Пустоты.
Но именно в пустых пространствах продакт может понять, зачем
И главный парадокс управления продуктами: чем больше мы говорим об проблемах и идеях, тем... дальше мы от них уходим.
Слова – это попытки упаковать живое в рамки неживых формулировок. Устные ограничения, которые мы сами же сознательно выбираем для себя и окружающих.
И самые эффективные решения приходят не в процессе проговаривания на совещаниях/созвонах/переписках, а в моменты безмолвного созерцания Тишины.
Потому что безмолвие содержит в себе все возможные идеи одновременно — и те, что уже проявились, и те, что ещё ждут своего времени
И только когда ум перестаёт воспринимать и генерировать шум внешнего, появляется пространство для подлинно нового.
Когда ты погружаешься в настоящее безмолвие, границы между "твоими" и "чужими" идеями растворяются и ты начинаешь слышать голос всех возможных решений сразу.
Слышать свой Внутренний Голос, который звучит тише шёпота и громче крика.
Тишина – промежутки между задачами, в которые ты НЕ пытаешься сделать или оптимизировать "что-то, чтобы было".
Тишина – паузы, которые ты даёшь собеседнику (и себе!) чтобы услышать то, что-не-было-сказано.
Тишина – это моменты, когда ты перестаёшь "интерпретировать" данные под задачи, навязывая им свои предвзятые выводы и уже подготовленные решения.
Инсайты звучат в паузах
Всё это не пассивность. Это – активное присутствие, способность создавать для себя и окружающих место, в котором все могут раскрыть потенциал себя/продукта/рынка.
Тишина – это пространство.
Безмолвие – голос всех идей.