Маржа: что у вас здесь происходит?
Просто:
Маржа — это разница между ценой товара и его себестоимостью, может быть выражена в абсолюте, тогда это аналог понятия прибыли.
Или в процентах: какую часть от продажной цены составляет прибыль - это уже Маржинальность.
Пример: пирожки из бабушкиной печи
Представьте, что ваша бабушка печет пирожки и продает их на рынке.
Себестоимость одного пирожка — 70 рублей, а продает она их по 100 рублей. Маржа составляет 30%.
Сложнее:
Маржа — это разница между Выручкой и переменными расходами(производство и продажа).
Маржинальность = Маржа / Выручка × 100%
На картинке к посту объяснения из разных источников, как раз про два варианта.
Ставьте 👍, если вы за простой вариант.
Ставьте 🐳, если вы за вариант посложнее.
@product_lev
#финансы #маржа #маржинальность #бизнес #productmanagement #pm #COGS
Просто:
Маржа — это разница между ценой товара и его себестоимостью, может быть выражена в абсолюте, тогда это аналог понятия прибыли.
Или в процентах: какую часть от продажной цены составляет прибыль - это уже Маржинальность.
Пример: пирожки из бабушкиной печи
Представьте, что ваша бабушка печет пирожки и продает их на рынке.
Себестоимость одного пирожка — 70 рублей, а продает она их по 100 рублей. Маржа составляет 30%.
Сложнее:
Маржа — это разница между Выручкой и переменными расходами(производство и продажа).
Маржинальность = Маржа / Выручка × 100%
На картинке к посту объяснения из разных источников, как раз про два варианта.
Ставьте 👍, если вы за простой вариант.
Ставьте 🐳, если вы за вариант посложнее.
@product_lev
#финансы #маржа #маржинальность #бизнес #productmanagement #pm #COGS
1👍11🐳8❤5
Переломный момент: Как незначительные изменения приводят к глобальным переменам, Малкольм Гладуэлл
Кому: продакт маркетинг менеджерам, кто хочет разобраться в эффектах вирусности продукта
Кол-во страниц: 256
Оценка от меня: 3 движущих силы переломного момента из 3
Отзыв:
Гладуэлл объясняет, как идеи, продукты и паттерны поведения распространяются и внезапно становятся массовыми.
В книге рассматривается, что информация и типы поведения распространяются подобно вирусам, перемены происходят не постепенно, а в некий переломный момент, когда начинают расти прогрессивно.
Переломный момент — это момент, когда незначительные изменения в системе вызывают резкий скачок или перелом, приводя к масштабным последствиям. Как эффект домино, когда одно легкое касание может привести к падению всех камней.
Три фактора развития эпидемии:
1) Закон малых чисел: Небольшая группа людей, обладающих определенными качествами, может значительно влиять на распространение идеи или продукта. Таких людей можно классифицировать как:
▪ «объединители» могут устанавливать и поддерживать отношения с огромным количеством самых разных людей.
▪ «знатоки» не только собирают большие массивы информации, но и активно и бескорыстно делятся ею с окружающими.
▪ «продавцы» способны убедить нас, если мы не верим тому, что нам рассказывают.
2) Фактор прилипчивости: для достижения переломного момента идея должна быть не только интересной, но и запоминающейся.
3) Сила обстоятельств: маленькие изменения в среде могут существенно повлиять на поведение людей.
Как это применимо для продактов?
Понимание механизма переломного момента может помочь продакт маркетинг менеджерам стратегически подойти к запуску и продвижению продукта. В этом отчасти книга отсылает к другой - «На крючке».
Что еще интересного было в книге в новой рубрике #КогнитивныеИнтересности:
1) Число Данбара - ограничение на количество постоянных социальных связей, которые человек может поддерживать. От 100 до 230, в среднем 150.
2) Транзакционная память у партнеров - общее хранилище знаний у группы людей.
3) Магическое число 7±2 - кратковременная человеческая память, как правило, не может запомнить и повторить более 7±2 элементов.
Книжная полка доступна на канале по хэштегу #чтопочитать@product_lev
#чтопочитать #переломныймомент #МалкольмГладуэлл #продуктовыйменеджмент #pm #стратегия #литература
Кому: продакт маркетинг менеджерам, кто хочет разобраться в эффектах вирусности продукта
Кол-во страниц: 256
Оценка от меня: 3 движущих силы переломного момента из 3
Отзыв:
Гладуэлл объясняет, как идеи, продукты и паттерны поведения распространяются и внезапно становятся массовыми.
В книге рассматривается, что информация и типы поведения распространяются подобно вирусам, перемены происходят не постепенно, а в некий переломный момент, когда начинают расти прогрессивно.
Переломный момент — это момент, когда незначительные изменения в системе вызывают резкий скачок или перелом, приводя к масштабным последствиям. Как эффект домино, когда одно легкое касание может привести к падению всех камней.
Три фактора развития эпидемии:
1) Закон малых чисел: Небольшая группа людей, обладающих определенными качествами, может значительно влиять на распространение идеи или продукта. Таких людей можно классифицировать как:
▪ «объединители» могут устанавливать и поддерживать отношения с огромным количеством самых разных людей.
▪ «знатоки» не только собирают большие массивы информации, но и активно и бескорыстно делятся ею с окружающими.
▪ «продавцы» способны убедить нас, если мы не верим тому, что нам рассказывают.
2) Фактор прилипчивости: для достижения переломного момента идея должна быть не только интересной, но и запоминающейся.
3) Сила обстоятельств: маленькие изменения в среде могут существенно повлиять на поведение людей.
Как это применимо для продактов?
Понимание механизма переломного момента может помочь продакт маркетинг менеджерам стратегически подойти к запуску и продвижению продукта. В этом отчасти книга отсылает к другой - «На крючке».
Что еще интересного было в книге в новой рубрике #КогнитивныеИнтересности:
1) Число Данбара - ограничение на количество постоянных социальных связей, которые человек может поддерживать. От 100 до 230, в среднем 150.
2) Транзакционная память у партнеров - общее хранилище знаний у группы людей.
3) Магическое число 7±2 - кратковременная человеческая память, как правило, не может запомнить и повторить более 7±2 элементов.
Книжная полка доступна на канале по хэштегу #чтопочитать@product_lev
#чтопочитать #переломныймомент #МалкольмГладуэлл #продуктовыйменеджмент #pm #стратегия #литература
1👍13❤6✍4
Cash Flow: он же Гога, он же Гоша, он же Юрий, он же Гора...
Мы уже рассмотрели PnL-отчет, который показывает, зарабатывает компания или работает в минус. Теперь разберем второй артефакт, который помогает увидеть, как деньги заходят и выходят из компании, и какое их количество остается на конец отчетного периода — отчет о движении денежных средств (ОДДС или Cash Flow Statement).
Зачем нужен ОДДС?
Он помогает оценить ликвидность компании, то есть её способность генерировать денежные средства для покрытия текущих обязательств. Показывает, насколько эффективно компания управляет своими денежными потоками, и позволяет продакт менеджерам и руководителям принимать решения о финансировании, инвестициях и операционной деятельности, избегать кассовых разрывов.
Основные разделы ОДДС:
1 - Операционная деятельность: Сколько денежных средств генерирует основная деятельность компании. Это основной источник денежного потока и отражает прибыльность компании (+продажи, +авансы, -оплата подрядов, -оплата труда...).
2 - Инвестиционная деятельность: Денежные потоки от приобретения или продажи активов, таких как оборудование или недвижимость. Раздел помогает оценить, насколько компания инвестирует в своё развитие и расширение (оборудование, технологии).
3 - Финансовая деятельность: Финансирование компании, например, выпуск акций, получение и погашение кредитов.
Как ОДДС помогает избежать кассовый разрыв?
Кассовый разрыв — это ситуация, когда у компании недостаточно денежных средств для покрытия текущих обязательств.
Анализ ОДДС позволяет предугадать такие ситуации, оценивая, когда и какие денежные поступления и выплаты ожидаются. Это помогает своевременно корректировать бюджет, планировать дополнительные источники финансирования или оптимизировать расходы, чтобы избежать нехватки денежных средств.
Как использовать ОДДС: миллениалы переизобрели cashflow
Как я-миллениал открыл для себя ОДДС и где он может помочь продакту: конечно, на бизнес-играх!
Надо выделять ответственного за финансы, чтобы он контролировал, что вы не уходите на игре в ноль или в минус больше вашего возможного овердрафта.
Если серьезно, то понимание ОДДС помогает планировать бюджет, оценивать финансовое здоровье компании и принимать обоснованные решения о развитии продукта.
Ставьте 🔥, если еще остались силы на пару финансовых постов
Ставьте 😎, если не боитесь кассового разрыва, потому что сидите в бигтехе
@product_lev
#финансы #cashflow #ODDS #productmanagement #pm #business #овердрафт #бридж-кредит #милыймойбухгалтер
Мы уже рассмотрели PnL-отчет, который показывает, зарабатывает компания или работает в минус. Теперь разберем второй артефакт, который помогает увидеть, как деньги заходят и выходят из компании, и какое их количество остается на конец отчетного периода — отчет о движении денежных средств (ОДДС или Cash Flow Statement).
Зачем нужен ОДДС?
Он помогает оценить ликвидность компании, то есть её способность генерировать денежные средства для покрытия текущих обязательств. Показывает, насколько эффективно компания управляет своими денежными потоками, и позволяет продакт менеджерам и руководителям принимать решения о финансировании, инвестициях и операционной деятельности, избегать кассовых разрывов.
Основные разделы ОДДС:
1 - Операционная деятельность: Сколько денежных средств генерирует основная деятельность компании. Это основной источник денежного потока и отражает прибыльность компании (+продажи, +авансы, -оплата подрядов, -оплата труда...).
2 - Инвестиционная деятельность: Денежные потоки от приобретения или продажи активов, таких как оборудование или недвижимость. Раздел помогает оценить, насколько компания инвестирует в своё развитие и расширение (оборудование, технологии).
3 - Финансовая деятельность: Финансирование компании, например, выпуск акций, получение и погашение кредитов.
Как ОДДС помогает избежать кассовый разрыв?
Кассовый разрыв — это ситуация, когда у компании недостаточно денежных средств для покрытия текущих обязательств.
Анализ ОДДС позволяет предугадать такие ситуации, оценивая, когда и какие денежные поступления и выплаты ожидаются. Это помогает своевременно корректировать бюджет, планировать дополнительные источники финансирования или оптимизировать расходы, чтобы избежать нехватки денежных средств.
Как использовать ОДДС: миллениалы переизобрели cashflow
Как я-миллениал открыл для себя ОДДС и где он может помочь продакту: конечно, на бизнес-играх!
Надо выделять ответственного за финансы, чтобы он контролировал, что вы не уходите на игре в ноль или в минус больше вашего возможного овердрафта.
Если серьезно, то понимание ОДДС помогает планировать бюджет, оценивать финансовое здоровье компании и принимать обоснованные решения о развитии продукта.
Ставьте 🔥, если еще остались силы на пару финансовых постов
Ставьте 😎, если не боитесь кассового разрыва, потому что сидите в бигтехе
@product_lev
#финансы #cashflow #ODDS #productmanagement #pm #business #овердрафт #бридж-кредит #милыймойбухгалтер
🔥17❤6😎6✍1
Balance Sheet: денежный скриншот
По следам постов про PnL и Cash flow.
Балансовый отчет (Balance Sheet) - документ, который дает представление о финансовом состоянии компании на определенный момент времени. Он помогает оценить финансовую устойчивость, анализировать ликвидность и принимать стратегические решения. Например, понять, есть ли ресурсы для разработки нового продукта или нужно привлекать инвестиции.
Основные компоненты Балансового отчета:
1) Активы: Все, чем владеет компания — от наличных средств до недвижимости.
2) Обязательства: Долги компании, включая краткосрочные и долгосрочные обязательства.
3) Капитал: Разница между активами и обязательствами, показывающая чистую стоимость компании.
Балансовый отчет состоит из двух частей: активов и суммы обязательств плюс собственного капитала. Эти две части должны быть равны, что подтверждает правильность составления отчета и сбалансированность финансов компании.
Ставьте 🥰, если дуреете с постов про финансы.
Ставьте 😈, если мне стоит попросить графического дизайнера оформить мои иллюстрации.
@product_lev
#финансы #балансовыйотчет #BalanceSheet #productmanagement #pm #business
По следам постов про PnL и Cash flow.
Балансовый отчет (Balance Sheet) - документ, который дает представление о финансовом состоянии компании на определенный момент времени. Он помогает оценить финансовую устойчивость, анализировать ликвидность и принимать стратегические решения. Например, понять, есть ли ресурсы для разработки нового продукта или нужно привлекать инвестиции.
Основные компоненты Балансового отчета:
1) Активы: Все, чем владеет компания — от наличных средств до недвижимости.
2) Обязательства: Долги компании, включая краткосрочные и долгосрочные обязательства.
3) Капитал: Разница между активами и обязательствами, показывающая чистую стоимость компании.
Балансовый отчет состоит из двух частей: активов и суммы обязательств плюс собственного капитала. Эти две части должны быть равны, что подтверждает правильность составления отчета и сбалансированность финансов компании.
Ставьте 🥰, если дуреете с постов про финансы.
Ставьте 😈, если мне стоит попросить графического дизайнера оформить мои иллюстрации.
@product_lev
#финансы #балансовыйотчет #BalanceSheet #productmanagement #pm #business
1🥰16👍9😈8❤1
3 главных финансовых отчета (3 Statements Model): развитие видения
Модель из 3-х отчетов, которые мы разобрали в постах выше, предоставляет полную картину финансового состояния компании на бумаге:
1) Отчет о прибылях и убытках (P&L Statement): Отражает, сколько бизнес заработал за определенный период времени. Он демонстрирует прибыльность компании и помогает понять, какие продукты или услуги приносят наибольшую выручку.
2) Отчет о движении денежных средств (ОДДС или Cash Flow Statement): Он показывает, хватает ли компании денег, чтобы расплатиться по всем обязательствам. Этот отчет помогает оценить ликвидность и управлять денежными потоками.
3) Балансовый отчет (Balance Sheet): Показывает, как деньги распределены между активами и пассивами. Этот отчет помогает оценить финансовую устойчивость компании и её способность выполнять обязательства.
Помимо прямой прикладной пользы метода, мне кажется, даже знание о таком подходе к оценке прокачивает видение продакта.
А доступ к отчетам и умение с ними работать позволит здраво оценивать финансовую картину компании, принимать финансово обоснованные решения, оптимизировать расходы и уверенно строить долгосрочную стратегию развития.
Ну, как вам наше погружение в мир финансов?:)
🔥 - вошли и вышли, приключение на 20 минут!
Поделитесь в комментах, сталкивались ли вы уже в своей работе с этими отчетами, как оно вам?
@product_lev
#финансы #аналитика #милыймойбухгалтер #PnL #cashflow #ODDS #BalanceSheet #productmanagement #pm #business
Модель из 3-х отчетов, которые мы разобрали в постах выше, предоставляет полную картину финансового состояния компании на бумаге:
1) Отчет о прибылях и убытках (P&L Statement): Отражает, сколько бизнес заработал за определенный период времени. Он демонстрирует прибыльность компании и помогает понять, какие продукты или услуги приносят наибольшую выручку.
2) Отчет о движении денежных средств (ОДДС или Cash Flow Statement): Он показывает, хватает ли компании денег, чтобы расплатиться по всем обязательствам. Этот отчет помогает оценить ликвидность и управлять денежными потоками.
3) Балансовый отчет (Balance Sheet): Показывает, как деньги распределены между активами и пассивами. Этот отчет помогает оценить финансовую устойчивость компании и её способность выполнять обязательства.
Помимо прямой прикладной пользы метода, мне кажется, даже знание о таком подходе к оценке прокачивает видение продакта.
А доступ к отчетам и умение с ними работать позволит здраво оценивать финансовую картину компании, принимать финансово обоснованные решения, оптимизировать расходы и уверенно строить долгосрочную стратегию развития.
Ну, как вам наше погружение в мир финансов?:)
🔥 - вошли и вышли, приключение на 20 минут!
Поделитесь в комментах, сталкивались ли вы уже в своей работе с этими отчетами, как оно вам?
@product_lev
#финансы #аналитика #милыймойбухгалтер #PnL #cashflow #ODDS #BalanceSheet #productmanagement #pm #business
1🔥14❤7👍6
Словарик продакта: DDD (Domain-Driven Design)
На прошлой неделе снова была серьезная встреча с серьезными участниками.
Коллега 1,5 часа рассказывал про схему работы над системой в серьезном государственном проекте.
Встреча началась с предложения посмотреть на DDD схемы, коллега сказал: «Все конечно знают что такое DDD».
Конечно, знали не все :) Я мельком поGPTил, чем с вами и поделюсь.
Продолжаю собирать #словарикпродакта со встреч.
Основные элементы DDD:
1) Модель домена: Отражает ключевые элементы и процессы бизнеса, упрощая общение и разработку.
2) Единый язык(Убиквитарный язык): Создаёт общий язык для технической команды и бизнеса, облегчая согласование требований.
3) Контексты ограничений: Управляет сложностью, выделяя уникальные термины и процессы в разных контекстах.
4) Агрегаты и сущности: Представляют бизнес-объекты и их взаимосвязи, поддерживая ясность модели.
Пример с онлайн-магазином:
В онлайн-магазине DDD помогает создать модель с сущностями "Книга", "Покупатель" и "Заказ". Это позволяет сосредоточиться на бизнес-логике, например, обработке заказов и управлении корзиной покупок, и легко адаптироваться к изменениям, таким как новые акции или программы лояльности.
Делаю вывод: DDD дает ориентиры, как управлять сложными системами, обеспечивая прозрачность коммуникации и целеполагания.
В упрощенном порядке DDD заменяет системного аналитика на продакта без проджекта.
Знающие люди, киньте в меня камнем в комментариях, пожалуйста, если какой-то важный артефакт упустил.
@product_lev
#словарикпродакта #DDD #УбиквитарныйЯзык #pm
На прошлой неделе снова была серьезная встреча с серьезными участниками.
Коллега 1,5 часа рассказывал про схему работы над системой в серьезном государственном проекте.
Встреча началась с предложения посмотреть на DDD схемы, коллега сказал: «Все конечно знают что такое DDD».
Конечно, знали не все :) Я мельком поGPTил, чем с вами и поделюсь.
Продолжаю собирать #словарикпродакта со встреч.
Основные элементы DDD:
1) Модель домена: Отражает ключевые элементы и процессы бизнеса, упрощая общение и разработку.
2) Единый язык(Убиквитарный язык): Создаёт общий язык для технической команды и бизнеса, облегчая согласование требований.
3) Контексты ограничений: Управляет сложностью, выделяя уникальные термины и процессы в разных контекстах.
4) Агрегаты и сущности: Представляют бизнес-объекты и их взаимосвязи, поддерживая ясность модели.
Пример с онлайн-магазином:
В онлайн-магазине DDD помогает создать модель с сущностями "Книга", "Покупатель" и "Заказ". Это позволяет сосредоточиться на бизнес-логике, например, обработке заказов и управлении корзиной покупок, и легко адаптироваться к изменениям, таким как новые акции или программы лояльности.
Делаю вывод: DDD дает ориентиры, как управлять сложными системами, обеспечивая прозрачность коммуникации и целеполагания.
В упрощенном порядке DDD заменяет системного аналитика на продакта без проджекта.
Знающие люди, киньте в меня камнем в комментариях, пожалуйста, если какой-то важный артефакт упустил.
@product_lev
#словарикпродакта #DDD #УбиквитарныйЯзык #pm
1❤12👍5🔥5
Метрики пользовательского опыта и удовлетворенности
Регулярный сбор UX-метрик помогает понять, насколько продукт решает задачи пользователя, где он буксует и где есть потенциал для роста. Без системного подхода клиенты уходят молча, а вместе с ними — обратная связь и деньги.
Для количественной оценки чаще всего используют четыре метрики: CES, CSAT, NPS и CSI. Каждая — про свой аспект взаимодействия.
CES (Customer Effort Score)
Вопрос: Насколько легко клиенту взаимодействовать с продуктом?
Пример: «Насколько вам легко было получить заказ в ПВЗ?»
Когда: После ключевых взаимодействий — покупки, обращения в поддержку.
CSAT (Customer Satisfaction Score)
Вопрос: Насколько клиент доволен продуктом или сервисом?
Пример: «Насколько вы удовлетворены нашим сервисом (от 1 до 5)?»
Когда: После важной точки контакта или завершения транзакции.
NPS (Net Promoter Score)
Вопрос: Насколько вероятно, что клиент порекомендует продукт другим?
Пример: «Какова вероятность, что вы порекомендуете нас друзьям?»
Когда: Регулярно — чтобы отслеживать динамику лояльности.
CSI (Customer Satisfaction Index)
Вопрос: Каков общий уровень удовлетворенности клиентским опытом?
Пример: Комплексный опрос по основным аспектам взаимодействия.
Когда: Раз в квартал или год — для анализа долгосрочных трендов.
Помним, что метрика — не цель, а инструмент. Без интерпретации, поиска причин и действий по результатам — это просто воровство времени у пользователя и цифра в дашборде.
Поделитесь, вы собирали такие метрики в своих продуктах? А я скину кейс сбора обратной связи эффективного менеджера:)
👍 - периодически проводим CSI
🤔 - первый раз слышу про CES
@product_lev
#ux #метрики #productmanagement #pm
Регулярный сбор UX-метрик помогает понять, насколько продукт решает задачи пользователя, где он буксует и где есть потенциал для роста. Без системного подхода клиенты уходят молча, а вместе с ними — обратная связь и деньги.
Для количественной оценки чаще всего используют четыре метрики: CES, CSAT, NPS и CSI. Каждая — про свой аспект взаимодействия.
CES (Customer Effort Score)
Вопрос: Насколько легко клиенту взаимодействовать с продуктом?
Пример: «Насколько вам легко было получить заказ в ПВЗ?»
Когда: После ключевых взаимодействий — покупки, обращения в поддержку.
CSAT (Customer Satisfaction Score)
Вопрос: Насколько клиент доволен продуктом или сервисом?
Пример: «Насколько вы удовлетворены нашим сервисом (от 1 до 5)?»
Когда: После важной точки контакта или завершения транзакции.
NPS (Net Promoter Score)
Вопрос: Насколько вероятно, что клиент порекомендует продукт другим?
Пример: «Какова вероятность, что вы порекомендуете нас друзьям?»
Когда: Регулярно — чтобы отслеживать динамику лояльности.
CSI (Customer Satisfaction Index)
Вопрос: Каков общий уровень удовлетворенности клиентским опытом?
Пример: Комплексный опрос по основным аспектам взаимодействия.
Когда: Раз в квартал или год — для анализа долгосрочных трендов.
Помним, что метрика — не цель, а инструмент. Без интерпретации, поиска причин и действий по результатам — это просто воровство времени у пользователя и цифра в дашборде.
Поделитесь, вы собирали такие метрики в своих продуктах? А я скину кейс сбора обратной связи эффективного менеджера:)
👍 - периодически проводим CSI
🤔 - первый раз слышу про CES
@product_lev
#ux #метрики #productmanagement #pm
1❤12👍8🤔2
Модель Кано: как понять, что действительно важно для пользователей
В продолжение анализа пользовательского опыта решил поделиться одним из ключевых инструментов приоритизации — моделью Кано. Это must-have для каждого продакта, особенно когда нужно понять, какие фичи реально влияют на пользовательскую удовлетворенность.
Что это вообще такое?
Модель Кано — это фреймворк, разработанный профессором Нориаки Кано. Она показывает, что разные функции продукта влияют на удовлетворенность по-разному — и часто нелинейно.
Типы пользовательских потребностей:
🟥Обязательные (Must-have / Basic Needs)
Пользователи ожидают их по умолчанию.
➕ Есть — никто не радуется.
➖ Нет — все недовольны.
🟧Ожидаемые (One-dimensional / Performance Needs)
Чем лучше реализованы, тем выше удовлетворенность.
➕ Есть — круто.
➖ Нет — разочарование.
🟩Восхищающие (Delighters / Excitement / Attractive Needs)
Никто не ждет, но если есть — восторг!
➕ Есть — вау-эффект.
➖ Нет — никто не расстроится.
⬜Нейтральные (Indifferent Needs)
Есть или нет — без разницы.
Лучше не тратить ресурсы.
🚫Обратные (Reverse Needs)
То, что нравится одним, может раздражать других.
Важно учитывать сегментацию аудитории.
🧪 Как собирать данные по Кано?
Проводится опрос, где на каждую фичу задается 2 вопроса:
• Функциональный: Как вы отнесетесь к тому, что эта функция есть?
• Дисфункциональный: А если её не будет?
Оба — с пятью вариантами ответа: от нравится до не нравится
Ответы анализируются по специальной матрице (в картинке к посту), и так определяется, к какому типу относится каждая функция.
💡 Что важно помнить?
• Фичи могут "мигрировать" между категориями. То, что сегодня вау, завтра станет обязательным.
• Качество данных критично. Лучше регулярно обновлять опросы.
🎯 Что даёт модель Кано?
✅ Понимание, какие функции действительно важны
✅ Оптимизацию расходов — убираем то, что не влияет
✅ Базу для стратегического роста продукта
✅ Повышение удовлетворенности и лояльности пользователей
Ставь ❤️, если считаешь, что модель Кано — мастхэв, что для продакта, что для маркетолога
Ставь 😈, если вместо Кано выбираешь Скорпиона или Нуб Сайбота
@product_lev
#модельКано #productmanagement #pm #пользовательскийопыт #ux #удовлетворенность #кАно
В продолжение анализа пользовательского опыта решил поделиться одним из ключевых инструментов приоритизации — моделью Кано. Это must-have для каждого продакта, особенно когда нужно понять, какие фичи реально влияют на пользовательскую удовлетворенность.
Что это вообще такое?
Модель Кано — это фреймворк, разработанный профессором Нориаки Кано. Она показывает, что разные функции продукта влияют на удовлетворенность по-разному — и часто нелинейно.
Типы пользовательских потребностей:
🟥Обязательные (Must-have / Basic Needs)
Пользователи ожидают их по умолчанию.
➕ Есть — никто не радуется.
➖ Нет — все недовольны.
🟧Ожидаемые (One-dimensional / Performance Needs)
Чем лучше реализованы, тем выше удовлетворенность.
➕ Есть — круто.
➖ Нет — разочарование.
🟩Восхищающие (Delighters / Excitement / Attractive Needs)
Никто не ждет, но если есть — восторг!
➕ Есть — вау-эффект.
➖ Нет — никто не расстроится.
⬜Нейтральные (Indifferent Needs)
Есть или нет — без разницы.
Лучше не тратить ресурсы.
🚫Обратные (Reverse Needs)
То, что нравится одним, может раздражать других.
Важно учитывать сегментацию аудитории.
🧪 Как собирать данные по Кано?
Проводится опрос, где на каждую фичу задается 2 вопроса:
• Функциональный: Как вы отнесетесь к тому, что эта функция есть?
• Дисфункциональный: А если её не будет?
Оба — с пятью вариантами ответа: от нравится до не нравится
Ответы анализируются по специальной матрице (в картинке к посту), и так определяется, к какому типу относится каждая функция.
💡 Что важно помнить?
• Фичи могут "мигрировать" между категориями. То, что сегодня вау, завтра станет обязательным.
• Качество данных критично. Лучше регулярно обновлять опросы.
🎯 Что даёт модель Кано?
✅ Понимание, какие функции действительно важны
✅ Оптимизацию расходов — убираем то, что не влияет
✅ Базу для стратегического роста продукта
✅ Повышение удовлетворенности и лояльности пользователей
Ставь ❤️, если считаешь, что модель Кано — мастхэв, что для продакта, что для маркетолога
Ставь 😈, если вместо Кано выбираешь Скорпиона или Нуб Сайбота
@product_lev
#модельКано #productmanagement #pm #пользовательскийопыт #ux #удовлетворенность #кАно
1❤11😈4🔥3
This media is not supported in your browser
VIEW IN TELEGRAM
Факапы: истории из жизни
В кулуарах всегда интересно обсудить, какие факапы случались на практике.
На собеседованиях такие кейсы тоже любят — особенно важно, как ты их решал и что сделал, чтобы избежать повторения.
Вот пара моих историй:
Факап 1: недоступные постаматы
Я был владельцем продукта самовывоза в Яндекс.Маркете — это 3 000 постаматов и 12 000 ПВЗ.
На видео как раз один из постаматов, а я радуюсь, что корректно настроили команды для открытия ячеек.
В один прекрасный зимний вечер, примерно в 19:00 по Мск, операционная команда заметила, что некоторые постаматы не выходят на связь.
С каждой минутой ситуация ухудшалась: устройств, с которыми терялась связь, становилось всё больше. Подключиться к ним удалённо не получалось.
Пробовали прозванивать вручную, искали закономерности, подключили подрядчика (у них уже была глубокая ночь) — безрезультатно.
В итоге, если не ошибаюсь, около тысячи постаматов пришлось перезагружать вручную.
Причина? Минорное обновление. Одна строка кода.
Что сделали после:
• Перепроверили процесс тестирования с подрядчиком, чтобы не допустить повторения критичных багов.
• Добавили мониторинг синхронизации постаматов, чтобы сразу получать оповещения, а не надеяться на визуальный контроль.
Факап 2: публичный фидбек
С командой ездили по ПВЗ перед Новым годом — высокий сезон, всё кипит.
Оценивали и сравнивали опыт получения заказов у разных маркетплейсов.
День был бодрый: нас было семеро, катались на фургоне, перекусывали в Макдаке.
После одного из визитов я решил закинуть фидбек в чат. Немного поругался в тексте и в последний момент убрал мат.
И слава богу — потому что... я случайно отправил сообщение в официальный паблик наших ПВЗ, где несколько тысяч человек.
Удалил через минуту, но скрины, появились в комментариях — интернет всё помнит.
Что сделал:
• Попросил исключить меня из админов канала
• Передал всю публичную коммуникацию редактору
(Кстати, вчера сюда в канал случайно отправил картинку с ROI. Удалил быстро, но была одна отписка. Екатерина, прости 🙏)
А какие факапы были у вас?
Поделитесь в комментариях: как решали?
Как не допустили повторения или применили опыт в других процессах?
@product_lev
#pm #postmortem #факап #собеседования #истории #андон
В кулуарах всегда интересно обсудить, какие факапы случались на практике.
На собеседованиях такие кейсы тоже любят — особенно важно, как ты их решал и что сделал, чтобы избежать повторения.
Вот пара моих историй:
Факап 1: недоступные постаматы
Я был владельцем продукта самовывоза в Яндекс.Маркете — это 3 000 постаматов и 12 000 ПВЗ.
На видео как раз один из постаматов, а я радуюсь, что корректно настроили команды для открытия ячеек.
В один прекрасный зимний вечер, примерно в 19:00 по Мск, операционная команда заметила, что некоторые постаматы не выходят на связь.
С каждой минутой ситуация ухудшалась: устройств, с которыми терялась связь, становилось всё больше. Подключиться к ним удалённо не получалось.
Пробовали прозванивать вручную, искали закономерности, подключили подрядчика (у них уже была глубокая ночь) — безрезультатно.
В итоге, если не ошибаюсь, около тысячи постаматов пришлось перезагружать вручную.
Причина? Минорное обновление. Одна строка кода.
Что сделали после:
• Перепроверили процесс тестирования с подрядчиком, чтобы не допустить повторения критичных багов.
• Добавили мониторинг синхронизации постаматов, чтобы сразу получать оповещения, а не надеяться на визуальный контроль.
Факап 2: публичный фидбек
С командой ездили по ПВЗ перед Новым годом — высокий сезон, всё кипит.
Оценивали и сравнивали опыт получения заказов у разных маркетплейсов.
День был бодрый: нас было семеро, катались на фургоне, перекусывали в Макдаке.
После одного из визитов я решил закинуть фидбек в чат. Немного поругался в тексте и в последний момент убрал мат.
И слава богу — потому что... я случайно отправил сообщение в официальный паблик наших ПВЗ, где несколько тысяч человек.
Удалил через минуту, но скрины, появились в комментариях — интернет всё помнит.
Что сделал:
• Попросил исключить меня из админов канала
• Передал всю публичную коммуникацию редактору
(Кстати, вчера сюда в канал случайно отправил картинку с ROI. Удалил быстро, но была одна отписка. Екатерина, прости 🙏)
А какие факапы были у вас?
Поделитесь в комментариях: как решали?
Как не допустили повторения или применили опыт в других процессах?
@product_lev
#pm #postmortem #факап #собеседования #истории #андон
❤12🔥8😁7👍3👎1
Увидел жалобу на тестовое задание в Школу менеджеров Яндекса (ШМЯ).
Кто-то выложил видео: мол, «как так, для чего, почему — собрать 20 человек, выстроить их в форму звезды и сфоткать?»
Моё мнение — задание топовое. Оно круто проверяет мотивацию, харизму и базовые организаторские навыки. Если не смог собрать 20 человек ради поступления в одну из лучших менеджерских школ — дальше будет сложнее.
У меня тоже было такое задание, делюсь своей звездой!
Думаю, напишу отдельный пост, как проходил все этапы отбора в ШМЯ. Возможно, кому-то пригодится.
📢 И да, осталась всего неделя до закрытия набора в ШМЯ 2025. Если задумывались — самое время подать заявку! 👉 yandex.ru/yaintern/schools/management
💛 До сих пор общаюсь с одногруппниками из ШМЯ. Теперь это уже синьоры, лиды, организаторы новых наборов. Крутое комьюнити, которое остаётся с тобой надолго!
@product_lev
#менеджер #Productmanagement #начало #карьеры #pm #ШМЯ #SHMYA
Кто-то выложил видео: мол, «как так, для чего, почему — собрать 20 человек, выстроить их в форму звезды и сфоткать?»
Моё мнение — задание топовое. Оно круто проверяет мотивацию, харизму и базовые организаторские навыки. Если не смог собрать 20 человек ради поступления в одну из лучших менеджерских школ — дальше будет сложнее.
У меня тоже было такое задание, делюсь своей звездой!
Думаю, напишу отдельный пост, как проходил все этапы отбора в ШМЯ. Возможно, кому-то пригодится.
📢 И да, осталась всего неделя до закрытия набора в ШМЯ 2025. Если задумывались — самое время подать заявку! 👉 yandex.ru/yaintern/schools/management
💛 До сих пор общаюсь с одногруппниками из ШМЯ. Теперь это уже синьоры, лиды, организаторы новых наборов. Крутое комьюнити, которое остаётся с тобой надолго!
@product_lev
#менеджер #Productmanagement #начало #карьеры #pm #ШМЯ #SHMYA
1❤32🔥16👏9👍2🤡1💯1
Как я поступал в Школу Менеджеров Яндекса(ШМЯ)
Давно хотел поделиться советами и эмоциями!
💬 Контекст
Я поступал в ШМЯ в конце последнего семестра университета в 2019 году, параллельно писал диплом. Было дико насыщенно, но и безумно радостно: и диплом с отличием, и поступление, и потом само обучение — одно из самых ярких переживаний за всё студенчество.
📚 Этап 1: Подготовка до старта набора
За несколько месяцев я начал готовиться:
1) Пересмотрел все открытые лекции с прошлых школ.
2) Делал заметки на A4, помечал непонятное, искал объяснение в интернете.
3) Поговорил с выпускниками: нашёл по хэштегам, расспросил про каждый этап.
Научился этому навыку в универе, каждый семестр начинал с подробного расспроса нескольких ребят с курса старше - получая для себя записки Принцев полукровок:)
4) Прочитал рекомендованную выпускниками книгу про то, как стать менеджером — вот мой отзыв и ссылка на книгу, в комментах можно найти свежую версию.
5) Подписался на рассылку о старте школы и сам мониторил — боялся, что начнут без меня.
🧠 Этап 2: Тестовое задание
Когда тестовое пришло:
1) Разобрал каждое задание по предложениям — чтобы точно понять смысл.
2) Каждый день возвращался, дописывал идеи.
3) Раз в неделю — структурировал собранные идеи, убирал лишнее.
4) Просил фидбек у друзей, выпускников, родителей, у меня очень креативный папа, точно помню, что от него была классная идея в дополнение по одному из заданий.
5*) Задание со звёздочкой: позвал подругу с камерой, собрал незнакомых ребят между парами, так как мои одногруппники уже не ходили - готовились к диплому.
6) Таблички делегировал моему другу Юре— не стал усложнять себе жизнь, из комментариев кураторов было понятно, что можно сделать по-менеджерски.
🎤 Этап 3: Видео и офлайн-собеседования
1) Видео-вопросы: формат — вопрос → минута на подготовку → минута на ответ.
Подготовился по вопросам из прошлых лет, прогонял голосом с друзьями.
2) Финальное оффлайн-собеседование: сильно волновался, слушал людей, выходящих из офиса, не говорят ли про собесы, пересматривал видео про интервью. Настоящее оффлайн интервью - это был июнь 2019, ещё до пандемии.
🎉 Финал
Помню, днём в общаге лёг поспать — проснулся от письма: «Вы поступили». Выбежал на балкон, орал, смеялся и плакал от радости. Это был настоящий момент счастья.
💌 Удачи тем, кто сейчас готовится
Верить в себя, идти шаг за шагом, и подпитываться от желания быть в профессии — этого уже очень много!
Если будут вопросы — пишите, рад помочь 🙌
@product_lev
#менеджер #Productmanagement #начало #карьеры #pm #ШМЯ #SHMYA
Давно хотел поделиться советами и эмоциями!
💬 Контекст
Я поступал в ШМЯ в конце последнего семестра университета в 2019 году, параллельно писал диплом. Было дико насыщенно, но и безумно радостно: и диплом с отличием, и поступление, и потом само обучение — одно из самых ярких переживаний за всё студенчество.
📚 Этап 1: Подготовка до старта набора
За несколько месяцев я начал готовиться:
1) Пересмотрел все открытые лекции с прошлых школ.
2) Делал заметки на A4, помечал непонятное, искал объяснение в интернете.
3) Поговорил с выпускниками: нашёл по хэштегам, расспросил про каждый этап.
Научился этому навыку в универе, каждый семестр начинал с подробного расспроса нескольких ребят с курса старше - получая для себя записки Принцев полукровок:)
4) Прочитал рекомендованную выпускниками книгу про то, как стать менеджером — вот мой отзыв и ссылка на книгу, в комментах можно найти свежую версию.
5) Подписался на рассылку о старте школы и сам мониторил — боялся, что начнут без меня.
🧠 Этап 2: Тестовое задание
Когда тестовое пришло:
1) Разобрал каждое задание по предложениям — чтобы точно понять смысл.
2) Каждый день возвращался, дописывал идеи.
3) Раз в неделю — структурировал собранные идеи, убирал лишнее.
4) Просил фидбек у друзей, выпускников, родителей, у меня очень креативный папа, точно помню, что от него была классная идея в дополнение по одному из заданий.
5*) Задание со звёздочкой: позвал подругу с камерой, собрал незнакомых ребят между парами, так как мои одногруппники уже не ходили - готовились к диплому.
6) Таблички делегировал моему другу Юре— не стал усложнять себе жизнь, из комментариев кураторов было понятно, что можно сделать по-менеджерски.
🎤 Этап 3: Видео и офлайн-собеседования
1) Видео-вопросы: формат — вопрос → минута на подготовку → минута на ответ.
Подготовился по вопросам из прошлых лет, прогонял голосом с друзьями.
2) Финальное оффлайн-собеседование: сильно волновался, слушал людей, выходящих из офиса, не говорят ли про собесы, пересматривал видео про интервью. Настоящее оффлайн интервью - это был июнь 2019, ещё до пандемии.
🎉 Финал
Помню, днём в общаге лёг поспать — проснулся от письма: «Вы поступили». Выбежал на балкон, орал, смеялся и плакал от радости. Это был настоящий момент счастья.
💌 Удачи тем, кто сейчас готовится
Верить в себя, идти шаг за шагом, и подпитываться от желания быть в профессии — этого уже очень много!
Если будут вопросы — пишите, рад помочь 🙌
@product_lev
#менеджер #Productmanagement #начало #карьеры #pm #ШМЯ #SHMYA
1❤14👍5🔥5👏1
Что почитать?
Бизнес с нуля: Как превратить идею в успешный стартап, Эрик Рис
Кому: менеджерам для знакомства с концепцией бережливого производства
Кол-во страниц: 320
Оценка от меня: 5 MVP из 5
Отзыв:
Недавно перечитал "Бизнес с нуля" во второй раз, не сразу вспомнил, что читал её раньше. Когда читал первые главы, подумал: "Как классно, уже разбираюсь в бережливом производстве, знаю все примеры!". Потом понял, что просто перечитываю эту книгу повторно.
Интересно, что первый раз я читал её лет 6-7 назад, и получается, что моё понимание дизайн-мышления и бережливого производства базируется именно на этой книге.
Было любопытно сверять свои знания с теорией — и я не заметил нигде лжи или натяжек: всё объяснено честно, ясно и последовательно.
Основная идея книги — не строить продукт в вакууме. Нужно как можно раньше запускать минимально жизнеспособный продукт (MVP), собирать обратную связь от пользователей и итеративно его улучшать через цикл Создать → Измерить → Научиться.
Эта книга отлично подходит:
Новичкам — чтобы получить системное понимание принципов бережливого старта.
Опытным менеджерам — чтобы переосмыслить свою картину мира и ещё раз проверить, не застряли ли они в старых неэффективных паттернах.
Книга оставляет после себя ощущение "делай меньше, но умнее", что очень ценно в продуктовой разработке.
Книжная полка доступна на канале по хэштегу #чтопочитать@product_lev
#чтопочитать #бизнесснуля #LeanStartup #ЭрикРис #productmanagement #пивот #литература
Бизнес с нуля: Как превратить идею в успешный стартап, Эрик Рис
Кому: менеджерам для знакомства с концепцией бережливого производства
Кол-во страниц: 320
Оценка от меня: 5 MVP из 5
Отзыв:
Недавно перечитал "Бизнес с нуля" во второй раз, не сразу вспомнил, что читал её раньше. Когда читал первые главы, подумал: "Как классно, уже разбираюсь в бережливом производстве, знаю все примеры!". Потом понял, что просто перечитываю эту книгу повторно.
Интересно, что первый раз я читал её лет 6-7 назад, и получается, что моё понимание дизайн-мышления и бережливого производства базируется именно на этой книге.
Было любопытно сверять свои знания с теорией — и я не заметил нигде лжи или натяжек: всё объяснено честно, ясно и последовательно.
Основная идея книги — не строить продукт в вакууме. Нужно как можно раньше запускать минимально жизнеспособный продукт (MVP), собирать обратную связь от пользователей и итеративно его улучшать через цикл Создать → Измерить → Научиться.
Эта книга отлично подходит:
Новичкам — чтобы получить системное понимание принципов бережливого старта.
Опытным менеджерам — чтобы переосмыслить свою картину мира и ещё раз проверить, не застряли ли они в старых неэффективных паттернах.
Книга оставляет после себя ощущение "делай меньше, но умнее", что очень ценно в продуктовой разработке.
Книжная полка доступна на канале по хэштегу #чтопочитать@product_lev
#чтопочитать #бизнесснуля #LeanStartup #ЭрикРис #productmanagement #пивот #литература
1❤7🔥3👍2🤔1
Андон: сигнал к действию в IT-командах
Андон (с японского лампа или бумажный фонарь) — концепция, пришедшая из бережливого производства Toyota. Изначально это был физический шнур, который мог дёрнуть любой рабочий, чтобы остановить конвейер при обнаружении дефекта. Цель — не наказание, а моментальная реакция и устранение проблемы на месте и вовремя, до того как результат проблемы дойдет до потребителя.
В IT-реалиях андон — это право каждого члена команды остановить «поток» ради качества. Примеры: разработчик ставит «на паузу» релиз из-за плавающей ошибки, или дизайнер бьёт тревогу при риске ухудшения UX. Это может быть метка в тасктрекере, алерт в чате или регулярный ритуал «андон-ревью».
Например, в Amazon андон-корд (cord - шнур с англ.) стал цифровым инструментом для поддержки клиентского опыта. Любой сотрудник службы может «дернуть шнур», если замечает проблему, способную повлиять на покупателя. При активации карточка товара временно скрывается с сайта до разбирательства. Практика, введённая по инициативе Джеффа Безоса, подчёркивает приоритет клиента и культуру немедленного реагирования на сбои.
На практике у меня были инцидент-чаты, которые мог инициировать дежурный сервиса. Они создавались с разными уровнями проблем, куда для разбора автоматически добавляли дежурных и ответственных.
Это повышает качество продукта, уменьшает накопление технического долга и формирует доверие в команде.
Добавление такого инструмента помогает сбалансировать гибкие подходы к разработке.
📌 Установите андон-точки в своих процессах: где и как команда может сказать «стоп» — и быть услышанной. Это не про торможение, а про зрелость.
👇Как вы реализуете андон в своих командах? Поделитесь в комментариях:)
@product_lev
#Productmanagement #андон #agile #lean #productculture #pm #Тойота
Андон (с японского лампа или бумажный фонарь) — концепция, пришедшая из бережливого производства Toyota. Изначально это был физический шнур, который мог дёрнуть любой рабочий, чтобы остановить конвейер при обнаружении дефекта. Цель — не наказание, а моментальная реакция и устранение проблемы на месте и вовремя, до того как результат проблемы дойдет до потребителя.
В IT-реалиях андон — это право каждого члена команды остановить «поток» ради качества. Примеры: разработчик ставит «на паузу» релиз из-за плавающей ошибки, или дизайнер бьёт тревогу при риске ухудшения UX. Это может быть метка в тасктрекере, алерт в чате или регулярный ритуал «андон-ревью».
Например, в Amazon андон-корд (cord - шнур с англ.) стал цифровым инструментом для поддержки клиентского опыта. Любой сотрудник службы может «дернуть шнур», если замечает проблему, способную повлиять на покупателя. При активации карточка товара временно скрывается с сайта до разбирательства. Практика, введённая по инициативе Джеффа Безоса, подчёркивает приоритет клиента и культуру немедленного реагирования на сбои.
На практике у меня были инцидент-чаты, которые мог инициировать дежурный сервиса. Они создавались с разными уровнями проблем, куда для разбора автоматически добавляли дежурных и ответственных.
Это повышает качество продукта, уменьшает накопление технического долга и формирует доверие в команде.
Добавление такого инструмента помогает сбалансировать гибкие подходы к разработке.
📌 Установите андон-точки в своих процессах: где и как команда может сказать «стоп» — и быть услышанной. Это не про торможение, а про зрелость.
👇Как вы реализуете андон в своих командах? Поделитесь в комментариях:)
@product_lev
#Productmanagement #андон #agile #lean #productculture #pm #Тойота
2❤10👍5🔥5
SLI, SLO, SLA! Показатели качества обслуживания.
Если вы работаете с IT-продуктами, например в сервисах с высоким аптаймом, вы наверняка сталкивались с аббревиатурами SLI, SLO и SLA. Чем выше время, когда система работает без перебоев (аптайм), тем надёжнее сервис в глазах пользователя, особенно если сбои в работе могут повлиять на бизнес клиента.
SLI (Service Level Indicator) — метрика, которая показывает текущее состояние качества сервиса. Это может быть доступность, задержка ответа, ошибка запроса, время отклика и т.д. Примеры: 99.95% успешных запросов, среднее время отклика — 300 мс.
SLO (Service Level Objective) — целевое значение SLI, к которому вы стремитесь. Это внутренняя договорённость команды о том, каким должен быть уровень сервиса. Пример: «Не менее 99.9% запросов должны быть успешны в течение месяца». SLO помогает отслеживать стабильность и предотвращать деградацию качества.
SLA (Service Level Agreement) — внешний договор с клиентом. Это формализованное обязательство: если вы его нарушаете, наступают последствия (например, штраф или возврат части оплаты). SLA часто основывается на SLO, но может быть немного мягче, чтобы избежать частых штрафов за незначительные отклонения.
📌 Пример:
Вы запускаете облачную платформу для хранения данных.
SLI: выбрали доступность сервиса (uptime) — 99.95%.
SLO: целевой показатель — не ниже 99.9% в месяц.
SLA: в договоре с клиентом указано, что при доступности ниже 99.9% вы возвращаете часть оплаты, а во внутренних инструкциях снижение часового uptime до 99,9 триггерит андон.
🛠 Кто отвечает за установку метрик?
SLI — формулируется техническими командами, DevOps или QA с участием владельца продукта. Они определяют, что и как измерять: ошибки, задержки, аптайм и т.д.
SLO — зона ответственности продукта совместно с инженерами. Продукт задаёт бизнес-ориентированные цели (насколько надёжным должен быть сервис в глазах пользователя), а команда помогает установить реалистичные технические границы.
SLA — согласуется на уровне бизнеса: продукт, аккаунт-менеджеры, юристы, иногда с участием CTO. Здесь важно учитывать ожидания клиентов, риски и стоимость потенциальных компенсаций.
💡 Из моей практики:
Мы с командой разработки и тестирования выстроили процесс работы с этими метриками: пересмотрели существующие технические борды, выделили на них SLI, зафиксировали по ним SLO и подробно прописали SLA-договорённости. В том числе — как и с каким приоритетом мы отрабатываем инциденты. Если происходит критическое отклонение — срабатывает андон (подробнее писал в предыдущем посте), и команда оперативно реагирует.
Ставь ❤️, если считаешь, что полезно пересматривать с командой SLA, чтоб они были реалистичными, но челленжевыми
Ставь 😈, если формула простая: SAL = SLI / 2
@product_lev
#SLI #SLA #SLO #PO #uptime #андон #pm
Если вы работаете с IT-продуктами, например в сервисах с высоким аптаймом, вы наверняка сталкивались с аббревиатурами SLI, SLO и SLA. Чем выше время, когда система работает без перебоев (аптайм), тем надёжнее сервис в глазах пользователя, особенно если сбои в работе могут повлиять на бизнес клиента.
SLI (Service Level Indicator) — метрика, которая показывает текущее состояние качества сервиса. Это может быть доступность, задержка ответа, ошибка запроса, время отклика и т.д. Примеры: 99.95% успешных запросов, среднее время отклика — 300 мс.
SLO (Service Level Objective) — целевое значение SLI, к которому вы стремитесь. Это внутренняя договорённость команды о том, каким должен быть уровень сервиса. Пример: «Не менее 99.9% запросов должны быть успешны в течение месяца». SLO помогает отслеживать стабильность и предотвращать деградацию качества.
SLA (Service Level Agreement) — внешний договор с клиентом. Это формализованное обязательство: если вы его нарушаете, наступают последствия (например, штраф или возврат части оплаты). SLA часто основывается на SLO, но может быть немного мягче, чтобы избежать частых штрафов за незначительные отклонения.
📌 Пример:
Вы запускаете облачную платформу для хранения данных.
SLI: выбрали доступность сервиса (uptime) — 99.95%.
SLO: целевой показатель — не ниже 99.9% в месяц.
SLA: в договоре с клиентом указано, что при доступности ниже 99.9% вы возвращаете часть оплаты, а во внутренних инструкциях снижение часового uptime до 99,9 триггерит андон.
🛠 Кто отвечает за установку метрик?
SLI — формулируется техническими командами, DevOps или QA с участием владельца продукта. Они определяют, что и как измерять: ошибки, задержки, аптайм и т.д.
SLO — зона ответственности продукта совместно с инженерами. Продукт задаёт бизнес-ориентированные цели (насколько надёжным должен быть сервис в глазах пользователя), а команда помогает установить реалистичные технические границы.
SLA — согласуется на уровне бизнеса: продукт, аккаунт-менеджеры, юристы, иногда с участием CTO. Здесь важно учитывать ожидания клиентов, риски и стоимость потенциальных компенсаций.
💡 Из моей практики:
Мы с командой разработки и тестирования выстроили процесс работы с этими метриками: пересмотрели существующие технические борды, выделили на них SLI, зафиксировали по ним SLO и подробно прописали SLA-договорённости. В том числе — как и с каким приоритетом мы отрабатываем инциденты. Если происходит критическое отклонение — срабатывает андон (подробнее писал в предыдущем посте), и команда оперативно реагирует.
Ставь ❤️, если считаешь, что полезно пересматривать с командой SLA, чтоб они были реалистичными, но челленжевыми
Ставь 😈, если формула простая: SAL = SLI / 2
@product_lev
#SLI #SLA #SLO #PO #uptime #андон #pm
1❤12👍3😈3
Почему все говорят про Time to Market?
Time to Market (TTM) — это время от ИДЕИ до запуска. В условиях конкуренции и меняющегося рынка, TTM становится критически важным: чем быстрее ты выведешь продукт, тем выше шанс занять нишу и получить обратную связь раньше конкурентов.
Высокий TTM может быть не только из-за долгой разработки, но и из-за медленных решений, неопределённости и слабой приоритизации.
Часто TTM путают с Lead Time и Cycle Time:
— Lead Time — это общее время от появления запроса (например, фичи) до его релиза.
— Cycle Time — это время активной работы над задачей, от начала до завершения.
Главные заблуждения:
1) «Скорость — это только про разработку»
На деле — это и про выбор приоритетов, и про продуктовые решения. Зависания на согласованиях или неясных требованиях часто тормозят больше, чем сама разработка.
2) «Можно ускориться, просто добавив людей»
По закону Брукса — больше людей = больше координации и сложностей. Особенно на поздних стадиях.
3) «Главное — запустить идеально»
Перфекционизм убивает скорость. Лучше запустить MVP и быстро учиться.
Что важно помнить:
— Быстрый запуск ≠ плохой продукт. Он просто быстрее попадает к пользователю.
— Обратная связь — часть стратегии. Чем раньше получишь — тем быстрее адаптируешься.
— Улучшать TTM нужно системно: от идей до процессов.
Time to Market — это не про спешку, а про готовность к рынку вовремя.
Ставь ❤️, если ваш СТО применяет обратный закон Брукса и отбирает разработчиков.
Ставь 😈, если всю жизнь думал, что TTM - это время от постановки задачи до релиза.
@product_lev
#закон #Брукса #TTM #PO #pm
Time to Market (TTM) — это время от ИДЕИ до запуска. В условиях конкуренции и меняющегося рынка, TTM становится критически важным: чем быстрее ты выведешь продукт, тем выше шанс занять нишу и получить обратную связь раньше конкурентов.
Высокий TTM может быть не только из-за долгой разработки, но и из-за медленных решений, неопределённости и слабой приоритизации.
Часто TTM путают с Lead Time и Cycle Time:
— Lead Time — это общее время от появления запроса (например, фичи) до его релиза.
— Cycle Time — это время активной работы над задачей, от начала до завершения.
Главные заблуждения:
1) «Скорость — это только про разработку»
На деле — это и про выбор приоритетов, и про продуктовые решения. Зависания на согласованиях или неясных требованиях часто тормозят больше, чем сама разработка.
2) «Можно ускориться, просто добавив людей»
По закону Брукса — больше людей = больше координации и сложностей. Особенно на поздних стадиях.
3) «Главное — запустить идеально»
Перфекционизм убивает скорость. Лучше запустить MVP и быстро учиться.
Что важно помнить:
— Быстрый запуск ≠ плохой продукт. Он просто быстрее попадает к пользователю.
— Обратная связь — часть стратегии. Чем раньше получишь — тем быстрее адаптируешься.
— Улучшать TTM нужно системно: от идей до процессов.
Time to Market — это не про спешку, а про готовность к рынку вовремя.
Ставь ❤️, если ваш СТО применяет обратный закон Брукса и отбирает разработчиков.
Ставь 😈, если всю жизнь думал, что TTM - это время от постановки задачи до релиза.
@product_lev
#закон #Брукса #TTM #PO #pm
❤10😈5👍4😁1
Кто такой BizDev-менеджер и зачем он нужен продакту?
🧩 Почти год назад я написал пост, где разобрал, как продакт может делегировать все свои задачи команде: кто что подхватит, если он, допустим… уехал в отпуск без интернета или решил просто «наблюдать со стороны».
Там был список специалистов, которые окружают продукт.
Но с тех пор команда расширилась, а роли — стали ещё интереснее.
На этой неделе решил дописать продолжение.
Сегодня — про BizDev-менеджера, в четверг — про SRE и DevOps-инженеров.
💼 BizDev (Business Development Manager) — это специалист, который отвечает за развитие бизнеса вне текущего продукта и рынка.
Он приходит туда, где пока нет чёткой воронки, стабильных сделок и даже готового предложения — и пробует превратить хаос в точку роста.
🛠️ Что BizDev делает:
- Строит партнёрства и совместные инициативы
- Курирует эксперименты с новыми сегментами и рынками
- Открывает точки входа в партнёрские интеграции, white-label и кастомные кейсы
- Помогает масштабировать продукт через бизнес-возможности
BizDev ≠ продавец
- Продавец закрывает спрос → BizDev его создаёт
- Продавец работает в текущем процессе → BizDev находит, где его ещё нет
BizDev ≠ аккаунт-менеджер
- Аккаунт ведёт клиента → BizDev ведёт нас туда, где клиентов пока нет
- Аккаунт — про поддержку → BizDev — про расширение
🤝 Как помогает продакту:
- Приносит рыночные сигналы, которые не найдёшь в метриках
- Помогает подумать не только «что улучшить», но и «куда ещё вырасти»
- Даёт контекст и смысл задачам, которые появляются «из внешнего мира»
📣 Что попросит у продакта:
- Собрать MVP, чтобы показать партнёру или быстро проверить интерес на рынке
- Быстрый ответ на вопрос: "реально ли это сделать?"
- Помощь в упаковке ценности — особенно, если мы выходим в новый сегмент
В команде, где есть BizDev, у продакта появляется шанс выйти за пределы фичей и итераций — и заняться ростом.
А ещё — надёжный союзник, который открывает перед продуктом новые двери в рынок. BizDev — это не про продажи. Это про рост.
Ставь ❤️, если хочешь себе BizDev'а
Ставь 😈, если твой CEO самый главный BizDev
@product_lev
#ProductManagement #BizDev #КомандаПродукта #РостЧерезПартнёрства
🧩 Почти год назад я написал пост, где разобрал, как продакт может делегировать все свои задачи команде: кто что подхватит, если он, допустим… уехал в отпуск без интернета или решил просто «наблюдать со стороны».
Там был список специалистов, которые окружают продукт.
Но с тех пор команда расширилась, а роли — стали ещё интереснее.
На этой неделе решил дописать продолжение.
Сегодня — про BizDev-менеджера, в четверг — про SRE и DevOps-инженеров.
💼 BizDev (Business Development Manager) — это специалист, который отвечает за развитие бизнеса вне текущего продукта и рынка.
Он приходит туда, где пока нет чёткой воронки, стабильных сделок и даже готового предложения — и пробует превратить хаос в точку роста.
🛠️ Что BizDev делает:
- Строит партнёрства и совместные инициативы
- Курирует эксперименты с новыми сегментами и рынками
- Открывает точки входа в партнёрские интеграции, white-label и кастомные кейсы
- Помогает масштабировать продукт через бизнес-возможности
BizDev ≠ продавец
- Продавец закрывает спрос → BizDev его создаёт
- Продавец работает в текущем процессе → BizDev находит, где его ещё нет
BizDev ≠ аккаунт-менеджер
- Аккаунт ведёт клиента → BizDev ведёт нас туда, где клиентов пока нет
- Аккаунт — про поддержку → BizDev — про расширение
🤝 Как помогает продакту:
- Приносит рыночные сигналы, которые не найдёшь в метриках
- Помогает подумать не только «что улучшить», но и «куда ещё вырасти»
- Даёт контекст и смысл задачам, которые появляются «из внешнего мира»
📣 Что попросит у продакта:
- Собрать MVP, чтобы показать партнёру или быстро проверить интерес на рынке
- Быстрый ответ на вопрос: "реально ли это сделать?"
- Помощь в упаковке ценности — особенно, если мы выходим в новый сегмент
В команде, где есть BizDev, у продакта появляется шанс выйти за пределы фичей и итераций — и заняться ростом.
А ещё — надёжный союзник, который открывает перед продуктом новые двери в рынок. BizDev — это не про продажи. Это про рост.
Ставь ❤️, если хочешь себе BizDev'а
Ставь 😈, если твой CEO самый главный BizDev
@product_lev
#ProductManagement #BizDev #КомандаПродукта #РостЧерезПартнёрства
👍9❤6😈5🔥1
А кто такие SRE и DevOps-инженеры — и зачем они нужны продакту?
🧩 В понедельник был пост про BizDev'а, сегодня — про инженеров, которые стоят на страже стабильности и скорости.
Речь про SRE и DevOps — и хотя иногда их смешивают, на самом деле это разные роли. Давайте разбираться.
💻 DevOps-инженер — это человек, который помогает команде быстро и безопасно доставлять изменения в прод. Его задача — автоматизация, пайплайны, инфраструктура, CI/CD, стабильные среды, логирование. Отвечает за Release time в TTM.
🛡️ SRE (Site Reliability Engineer) — фокусируется на стабильности и надёжности систем. Он думает не только как всё задеплоить, но и как оно будет работать 24/7. Отвечает за Uptime, Error rate, MTTR (Mean Time To Recovery).
💡 В чём разница между специалистами:
• DevOps — про скорость изменений
• SRE — про устойчивость системы
• DevOps строит процессы доставки, а SRE следит, чтобы эти процессы не сломали прод.
🤝 Как помогают продакту:
• Делают доставку фич предсказуемой и быстрой
• Дают метрики и сигналы по пласту Quality в пирамиду метрик
📣 Что попросят у продакта:
• Приоритеты: что важнее — фича, стабильность, скорость?
• Поддержку при внедрении процессов: rollback-планы, canary release(в простонародье «канарейки» - это поэтапные релизы, чтоб сразу у всех пользователей всё не сломалось)
Если в команде есть DevOps — вы не боитесь делать 10 релизов в день.
Если есть SRE — вы не боитесь, что после этих 10 релизов всё упадёт.
❤️ — если у вас релизы — праздник, а не испытание
😈 — если SRE и DevOps — это ваш бэкенд разработчик
@product_lev
#ProductManagement #DevOps #SRE #КомандаПродукта #pm
🧩 В понедельник был пост про BizDev'а, сегодня — про инженеров, которые стоят на страже стабильности и скорости.
Речь про SRE и DevOps — и хотя иногда их смешивают, на самом деле это разные роли. Давайте разбираться.
💻 DevOps-инженер — это человек, который помогает команде быстро и безопасно доставлять изменения в прод. Его задача — автоматизация, пайплайны, инфраструктура, CI/CD, стабильные среды, логирование. Отвечает за Release time в TTM.
🛡️ SRE (Site Reliability Engineer) — фокусируется на стабильности и надёжности систем. Он думает не только как всё задеплоить, но и как оно будет работать 24/7. Отвечает за Uptime, Error rate, MTTR (Mean Time To Recovery).
💡 В чём разница между специалистами:
• DevOps — про скорость изменений
• SRE — про устойчивость системы
• DevOps строит процессы доставки, а SRE следит, чтобы эти процессы не сломали прод.
🤝 Как помогают продакту:
• Делают доставку фич предсказуемой и быстрой
• Дают метрики и сигналы по пласту Quality в пирамиду метрик
📣 Что попросят у продакта:
• Приоритеты: что важнее — фича, стабильность, скорость?
• Поддержку при внедрении процессов: rollback-планы, canary release(в простонародье «канарейки» - это поэтапные релизы, чтоб сразу у всех пользователей всё не сломалось)
Если в команде есть DevOps — вы не боитесь делать 10 релизов в день.
Если есть SRE — вы не боитесь, что после этих 10 релизов всё упадёт.
❤️ — если у вас релизы — праздник, а не испытание
😈 — если SRE и DevOps — это ваш бэкенд разработчик
@product_lev
#ProductManagement #DevOps #SRE #КомандаПродукта #pm
❤8👍6🔥3😈3
Трекшн-модель продукта: Юра, мы поехали или нет?
Недавно столкнулся с этим определением, решил поделиться в канале, раньше всегда слышал и сам говорил просто: «подбить аналитику»:)
🧭 Трекшн-модель (от англ. traction — «тяга») — это модель роста продукта. Она показывает, как продукт будет набирать пользователей, деньги и ценность во времени. Иными словами: как он “поедет”.
🧱 Как собрать трекшн-модель?
1 Выбери главную метрику роста — выручка, активные пользователи, сделки.
2 Нарисуй ключевые драйверы — откуда идёт рост: каналы привлечения, повторные покупки, расширение ARPU.
3 Разбей по шагам — как пользователи проходят путь: регистрация → активация → платёж.
4 Прогнозируй рост — на базе гипотез и исторических данных: что будет, если удвоим трафик? Улучшим конверсию?
Пример: 100 новых юзеров в месяц × 30% активация × 20% платящих = 6 платящих клиентов в месяц. Дальше моделируешь изменения и смотришь на динамику.
🧠 Зачем нужна трекшн-модель?
• Понять потенциал роста: если всё пойдёт по плану — куда ты приедешь?
• Оценить гипотезу/фичу: насколько сильно она повлияет на итоговую метрику?
• Выиграть у скептиков: показать, что за “идеей” — есть математика.
• Поддержать решение о запуске / паузе / инвестировании
⏱ Когда нужна, а когда нет?
Нужна:
• На старте продукта или нового направления
• При защите гипотез и фич с высоким риском
• Когда очень сложно выбрать приоритет
• При подготовке к существенным инвестициям или защите бюджета
Можно без неё:
• В простых улучшениях с понятным эффектом
• Когда всё и так горит и растёт (но не злоупотребляй 😅)
💸 Чем отличается от Cash Flow и юнит-экономики?
Трекшн-модель показывает, как растёт продукт через ключевые метрики и конверсии на этапах воронки, в то время как Cash Flow фокусируется на движении денег, а юнит-экономика — на прибыльности одного пользователя или сделки.
Можно сформулировать так:
Трекшн — про «как зарабатывает наш таксопарк»,
Кэшфлоу — про «хватит ли бензина»,
Юнитка — про «выгодна ли каждая поездка».
🧩 Пример трекшн-модели:
На скрине к посту приложил, как может выглядеть трекшн-модель продукта.
Где протестировали гипотезу: “А что, если повысим конверсию в регистрацию с платной рекламы и партнёрок на +5 п.п.?”
Считаем руками, сколько денег это принесёт в перспективе трёх месяцев. На основе этой информации можно принимать решение о приоритизации.
❤️ — если хочешь, чтобы твой рост был предсказуемым
😈 — если еще ни разу не делал трекшн-модели
@product_lev
#ProductManagement #Growth #Трекшн #Фреймворки #DataDrivenProduct #тяга
Недавно столкнулся с этим определением, решил поделиться в канале, раньше всегда слышал и сам говорил просто: «подбить аналитику»:)
🧭 Трекшн-модель (от англ. traction — «тяга») — это модель роста продукта. Она показывает, как продукт будет набирать пользователей, деньги и ценность во времени. Иными словами: как он “поедет”.
🧱 Как собрать трекшн-модель?
1 Выбери главную метрику роста — выручка, активные пользователи, сделки.
2 Нарисуй ключевые драйверы — откуда идёт рост: каналы привлечения, повторные покупки, расширение ARPU.
3 Разбей по шагам — как пользователи проходят путь: регистрация → активация → платёж.
4 Прогнозируй рост — на базе гипотез и исторических данных: что будет, если удвоим трафик? Улучшим конверсию?
Пример: 100 новых юзеров в месяц × 30% активация × 20% платящих = 6 платящих клиентов в месяц. Дальше моделируешь изменения и смотришь на динамику.
🧠 Зачем нужна трекшн-модель?
• Понять потенциал роста: если всё пойдёт по плану — куда ты приедешь?
• Оценить гипотезу/фичу: насколько сильно она повлияет на итоговую метрику?
• Выиграть у скептиков: показать, что за “идеей” — есть математика.
• Поддержать решение о запуске / паузе / инвестировании
⏱ Когда нужна, а когда нет?
Нужна:
• На старте продукта или нового направления
• При защите гипотез и фич с высоким риском
• Когда очень сложно выбрать приоритет
• При подготовке к существенным инвестициям или защите бюджета
Можно без неё:
• В простых улучшениях с понятным эффектом
• Когда всё и так горит и растёт (но не злоупотребляй 😅)
💸 Чем отличается от Cash Flow и юнит-экономики?
Трекшн-модель показывает, как растёт продукт через ключевые метрики и конверсии на этапах воронки, в то время как Cash Flow фокусируется на движении денег, а юнит-экономика — на прибыльности одного пользователя или сделки.
Можно сформулировать так:
Трекшн — про «как зарабатывает наш таксопарк»,
Кэшфлоу — про «хватит ли бензина»,
Юнитка — про «выгодна ли каждая поездка».
🧩 Пример трекшн-модели:
На скрине к посту приложил, как может выглядеть трекшн-модель продукта.
Где протестировали гипотезу: “А что, если повысим конверсию в регистрацию с платной рекламы и партнёрок на +5 п.п.?”
Считаем руками, сколько денег это принесёт в перспективе трёх месяцев. На основе этой информации можно принимать решение о приоритизации.
❤️ — если хочешь, чтобы твой рост был предсказуемым
😈 — если еще ни разу не делал трекшн-модели
@product_lev
#ProductManagement #Growth #Трекшн #Фреймворки #DataDrivenProduct #тяга
❤9😈9👍6
MVP vs PoC: в чём разница?
Недавно с коллегами поймали себя на том, что мешаем эти термины в разговоре.
Решил зафиксировать разницу — коротко и по делу.
🔬 PoC (Proof of Concept) — Доказательство концепции
Цель: понять, можно ли это реализовать технически.
Делается для команды/руководства, а не пользователей.
Пример: Основатели BlackBerry (тогда RIM) создали прототип, который позволял отправлять бесплатные текстовые сообщения между двумя пейджерами через сотовую сеть, минуя платные SMS. Это был технический PoC: проверили, можно ли передавать данные поверх сотовой сети — без платных SMS
🚀 MVP (Minimum Viable Product) — Минимально жизнеспособный продукт
Цель: запустить рабочую версию, чтобы проверить идею на рынке.
Пользователи получают ценность, даже если фич минимум.
Пример: Airbnb начинался как MVP: сайт с фото одной квартиры.
🧭 Главное отличие:
PoC проверяет “можно ли”,
MVP — “нужно ли это кому-то”.
❤️ — если у тебя были споры про MVP и PoC
😈 — если продавал PoC как готовый продукт
@product_lev
#ProductManagement #MVP #PoC #LeanStartup #pm
Недавно с коллегами поймали себя на том, что мешаем эти термины в разговоре.
Решил зафиксировать разницу — коротко и по делу.
🔬 PoC (Proof of Concept) — Доказательство концепции
Цель: понять, можно ли это реализовать технически.
Делается для команды/руководства, а не пользователей.
Пример: Основатели BlackBerry (тогда RIM) создали прототип, который позволял отправлять бесплатные текстовые сообщения между двумя пейджерами через сотовую сеть, минуя платные SMS. Это был технический PoC: проверили, можно ли передавать данные поверх сотовой сети — без платных SMS
🚀 MVP (Minimum Viable Product) — Минимально жизнеспособный продукт
Цель: запустить рабочую версию, чтобы проверить идею на рынке.
Пользователи получают ценность, даже если фич минимум.
Пример: Airbnb начинался как MVP: сайт с фото одной квартиры.
🧭 Главное отличие:
PoC проверяет “можно ли”,
MVP — “нужно ли это кому-то”.
❤️ — если у тебя были споры про MVP и PoC
😈 — если продавал PoC как готовый продукт
@product_lev
#ProductManagement #MVP #PoC #LeanStartup #pm
❤9👍9😈5
CustDev-интервью — какие бывают и чем отличаются?
Недавно обсуждали с UX-исследователем, почему одни интервью дают инсайты, а другие — только очевидные ответы на очевидные вопросы.
Решил собрать мини-гайд по типам интервью в Customer Development.
🎓 Экспертное интервью
Цель: собрать мнение от людей, которые лучше всех понимают рынок или проблему.
Фокус: не один пользователь, а широкая перспектива.
Когда использовать: на старте, при входе в новую сферу, при стратегических решениях.
Пример вопроса: «Какие тренды вы видите в подходах к обучению преподавателей?»
🧠 Глубинное интервью
Цель: разобраться в контексте, мотивации, поведении пользователя.
Фокус: не столько проблема, сколько мышление и поведение.
Когда использовать: при разработке новых продуктов или для сегментации.
Пример вопроса: «Как проходит ваш рабочий день? Как принимаете решения по X?»
🔍 Проблемное интервью
Цель: понять, есть ли у пользователя вообще проблема.
Фокус: на прошлом опыте, боли, обходных решениях.
Когда использовать: до появления идеи, чтобы не решать несуществующую проблему.
Пример вопроса: «Когда в последний раз вы пытались настроить бэкап? Что пошло не так?»
🛠 Решенческое интервью
Цель: проверить, откликается ли предложенное решение.
Фокус: реакция на прототип, концепт, фичу.
Когда использовать: есть идея — хочется понять, стоит ли её развивать.
Пример вопроса: «Если бы такой инструмент был, как бы вы им пользовались? Какие проблемы закрывает?»
💬 Один тип интервью ≠ все ответы. Часто лучше делать микс (если есть ресурсы и нет накопленных знаний): начать с глубинного, уточнить проблемное, потом протестить решение.
🧭 Как выбирать подход:
Ищешь взгляд сверху и понимание рынка? — зови на экспертное
Нужен контекст и поведение пользователя? — подойдет глубинное
Исследуешь сигнал, есть ли боль? — делай проблемное
Хочешь проверить идею или фичу? — иди в решенческое
❤️ — если спросил маму
😈 — если хоть раз проводил интервью без четкой цели
@product_lev
#ProductManagement #CustDev #UXResearch #Interviews #ProductDesign #LeanProduct #pm #кач
Недавно обсуждали с UX-исследователем, почему одни интервью дают инсайты, а другие — только очевидные ответы на очевидные вопросы.
Решил собрать мини-гайд по типам интервью в Customer Development.
🎓 Экспертное интервью
Цель: собрать мнение от людей, которые лучше всех понимают рынок или проблему.
Фокус: не один пользователь, а широкая перспектива.
Когда использовать: на старте, при входе в новую сферу, при стратегических решениях.
Пример вопроса: «Какие тренды вы видите в подходах к обучению преподавателей?»
🧠 Глубинное интервью
Цель: разобраться в контексте, мотивации, поведении пользователя.
Фокус: не столько проблема, сколько мышление и поведение.
Когда использовать: при разработке новых продуктов или для сегментации.
Пример вопроса: «Как проходит ваш рабочий день? Как принимаете решения по X?»
🔍 Проблемное интервью
Цель: понять, есть ли у пользователя вообще проблема.
Фокус: на прошлом опыте, боли, обходных решениях.
Когда использовать: до появления идеи, чтобы не решать несуществующую проблему.
Пример вопроса: «Когда в последний раз вы пытались настроить бэкап? Что пошло не так?»
🛠 Решенческое интервью
Цель: проверить, откликается ли предложенное решение.
Фокус: реакция на прототип, концепт, фичу.
Когда использовать: есть идея — хочется понять, стоит ли её развивать.
Пример вопроса: «Если бы такой инструмент был, как бы вы им пользовались? Какие проблемы закрывает?»
💬 Один тип интервью ≠ все ответы. Часто лучше делать микс (если есть ресурсы и нет накопленных знаний): начать с глубинного, уточнить проблемное, потом протестить решение.
🧭 Как выбирать подход:
Ищешь взгляд сверху и понимание рынка? — зови на экспертное
Нужен контекст и поведение пользователя? — подойдет глубинное
Исследуешь сигнал, есть ли боль? — делай проблемное
Хочешь проверить идею или фичу? — иди в решенческое
❤️ — если спросил маму
😈 — если хоть раз проводил интервью без четкой цели
@product_lev
#ProductManagement #CustDev #UXResearch #Interviews #ProductDesign #LeanProduct #pm #кач
❤8👍7😈5