Словарик продакта: DDD (Domain-Driven Design)

На прошлой неделе снова была серьезная встреча с серьезными участниками.
Коллега 1,5 часа рассказывал про схему работы над системой в серьезном государственном проекте.

Встреча началась с предложения посмотреть на DDD схемы, коллега сказал: «Все конечно знают что такое DDD».
Конечно, знали не все :) Я мельком поGPTил, чем с вами и поделюсь.
Продолжаю собирать #словарикпродакта со встреч.

Основные элементы DDD:
1) Модель домена: Отражает ключевые элементы и процессы бизнеса, упрощая общение и разработку.
2) Единый язык(Убиквитарный язык): Создаёт общий язык для технической команды и бизнеса, облегчая согласование требований.
3) Контексты ограничений: Управляет сложностью, выделяя уникальные термины и процессы в разных контекстах.
4) Агрегаты и сущности: Представляют бизнес-объекты и их взаимосвязи, поддерживая ясность модели.

Пример с онлайн-магазином:
В онлайн-магазине DDD помогает создать модель с сущностями "Книга", "Покупатель" и "Заказ". Это позволяет сосредоточиться на бизнес-логике, например, обработке заказов и управлении корзиной покупок, и легко адаптироваться к изменениям, таким как новые акции или программы лояльности.

Делаю вывод: DDD дает ориентиры, как управлять сложными системами, обеспечивая прозрачность коммуникации и целеполагания.
В упрощенном порядке DDD заменяет системного аналитика на продакта без проджекта.
Знающие люди, киньте в меня камнем в комментариях, пожалуйста, если какой-то важный артефакт упустил.
@product_lev
#словарикпродакта #DDD #УбиквитарныйЯзык #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

Модель Кано: как понять, что действительно важно для пользователей
В продолжение анализа пользовательского опыта решил поделиться одним из ключевых инструментов приоритизации — моделью Кано. Это 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: недоступные постаматы
Я был владельцем продукта самовывоза в Яндекс.Маркете — это 3 000 постаматов и 12 000 ПВЗ.
На видео как раз один из постаматов, а я радуюсь, что корректно настроили команды для открытия ячеек.
В один прекрасный зимний вечер, примерно в 19:00 по Мск, операционная команда заметила, что некоторые постаматы не выходят на связь.
С каждой минутой ситуация ухудшалась: устройств, с которыми терялась связь, становилось всё больше. Подключиться к ним удалённо не получалось.
Пробовали прозванивать вручную, искали закономерности, подключили подрядчика (у них уже была глубокая ночь) — безрезультатно.
В итоге, если не ошибаюсь, около тысячи постаматов пришлось перезагружать вручную.
Причина? Минорное обновление. Одна строка кода.
Что сделали после:
• Перепроверили процесс тестирования с подрядчиком, чтобы не допустить повторения критичных багов.
• Добавили мониторинг синхронизации постаматов, чтобы сразу получать оповещения, а не надеяться на визуальный контроль.

Факап 2: публичный фидбек
С командой ездили по ПВЗ перед Новым годом — высокий сезон, всё кипит.
Оценивали и сравнивали опыт получения заказов у разных маркетплейсов.
День был бодрый: нас было семеро, катались на фургоне, перекусывали в Макдаке.
После одного из визитов я решил закинуть фидбек в чат. Немного поругался в тексте и в последний момент убрал мат.
И слава богу — потому что... я случайно отправил сообщение в официальный паблик наших ПВЗ, где несколько тысяч человек.
Удалил через минуту, но скрины, появились в комментариях — интернет всё помнит.
Что сделал:
• Попросил исключить меня из админов канала
• Передал всю публичную коммуникацию редактору
(Кстати, вчера сюда в канал случайно отправил картинку с ROI. Удалил быстро, но была одна отписка. Екатерина, прости 🙏)

А какие факапы были у вас?
Поделитесь в комментариях: как решали?
Как не допустили повторения или применили опыт в других процессах?

@product_lev
#pm #postmortem #факап #собеседования #истории #андон

Как я поступал в Школу Менеджеров Яндекса(ШМЯ)
Давно хотел поделиться советами и эмоциями!

💬 Контекст
Я поступал в ШМЯ в конце последнего семестра университета в 2019 году, параллельно писал диплом. Было дико насыщенно, но и безумно радостно: и диплом с отличием, и поступление, и потом само обучение — одно из самых ярких переживаний за всё студенчество.

📚 Этап 1: Подготовка до старта набора
За несколько месяцев я начал готовиться:
1) Пересмотрел все открытые лекции с прошлых школ.
2) Делал заметки на A4, помечал непонятное, искал объяснение в интернете.
3) Поговорил с выпускниками: нашёл по хэштегам, расспросил про каждый этап.
Научился этому навыку в универе, каждый семестр начинал с подробного расспроса нескольких ребят с курса старше - получая для себя записки Принцев полукровок:)
4) Прочитал рекомендованную выпускниками книгу про то, как стать менеджером — вот мой отзыв и ссылка на книгу, в комментах можно найти свежую версию.
5) Подписался на рассылку о старте школы и сам мониторил — боялся, что начнут без меня.

🧠 Этап 2: Тестовое задание
Когда тестовое пришло:
1) Разобрал каждое задание по предложениям — чтобы точно понять смысл.
2) Каждый день возвращался, дописывал идеи.
3) Раз в неделю — структурировал собранные идеи, убирал лишнее.
4) Просил фидбек у друзей, выпускников, родителей, у меня очень креативный папа, точно помню, что от него была классная идея в дополнение по одному из заданий.
5*) Задание со звёздочкой: позвал подругу с камерой, собрал незнакомых ребят между парами, так как мои одногруппники уже не ходили - готовились к диплому.
6) Таблички делегировал моему другу Юре— не стал усложнять себе жизнь, из комментариев кураторов было понятно, что можно сделать по-менеджерски.

🎤 Этап 3: Видео и офлайн-собеседования
1) Видео-вопросы: формат — вопрос → минута на подготовку → минута на ответ.
Подготовился по вопросам из прошлых лет, прогонял голосом с друзьями.
2) Финальное оффлайн-собеседование: сильно волновался, слушал людей, выходящих из офиса, не говорят ли про собесы, пересматривал видео про интервью. Настоящее оффлайн интервью - это был июнь 2019, ещё до пандемии.

🎉 Финал
Помню, днём в общаге лёг поспать — проснулся от письма: «Вы поступили». Выбежал на балкон, орал, смеялся и плакал от радости. Это был настоящий момент счастья.

💌 Удачи тем, кто сейчас готовится
Верить в себя, идти шаг за шагом, и подпитываться от желания быть в профессии — этого уже очень много!

Если будут вопросы — пишите, рад помочь 🙌

@product_lev
#менеджер #Productmanagement #начало #карьеры #pm #ШМЯ #SHMYA

Что почитать?

Бизнес с нуля: Как превратить идею в успешный стартап, Эрик Рис
Кому: менеджерам для знакомства с концепцией бережливого производства
Кол-во страниц: 320
Оценка от меня: 5 MVP из 5

Отзыв:
Недавно перечитал "Бизнес с нуля" во второй раз, не сразу вспомнил, что читал её раньше. Когда читал первые главы, подумал: "Как классно, уже разбираюсь в бережливом производстве, знаю все примеры!". Потом понял, что просто перечитываю эту книгу повторно.
Интересно, что первый раз я читал её лет 6-7 назад, и получается, что моё понимание дизайн-мышления и бережливого производства базируется именно на этой книге.
Было любопытно сверять свои знания с теорией — и я не заметил нигде лжи или натяжек: всё объяснено честно, ясно и последовательно.

Основная идея книги — не строить продукт в вакууме. Нужно как можно раньше запускать минимально жизнеспособный продукт (MVP), собирать обратную связь от пользователей и итеративно его улучшать через цикл Создать → Измерить → Научиться.

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

Книжная полка доступна на канале по хэштегу #чтопочитать@product_lev
#чтопочитать #бизнесснуля #LeanStartup #ЭрикРис #productmanagement #пивот #литература

Андон: сигнал к действию в IT-командах

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

В IT-реалиях андон — это право каждого члена команды остановить «поток» ради качества. Примеры: разработчик ставит «на паузу» релиз из-за плавающей ошибки, или дизайнер бьёт тревогу при риске ухудшения UX. Это может быть метка в тасктрекере, алерт в чате или регулярный ритуал «андон-ревью».

Например, в Amazon андон-корд (cord - шнур с англ.) стал цифровым инструментом для поддержки клиентского опыта. Любой сотрудник службы может «дернуть шнур», если замечает проблему, способную повлиять на покупателя. При активации карточка товара временно скрывается с сайта до разбирательства. Практика, введённая по инициативе Джеффа Безоса, подчёркивает приоритет клиента и культуру немедленного реагирования на сбои.

На практике у меня были инцидент-чаты, которые мог инициировать дежурный сервиса. Они создавались с разными уровнями проблем, куда для разбора автоматически добавляли дежурных и ответственных.
Это повышает качество продукта, уменьшает накопление технического долга и формирует доверие в команде.
Добавление такого инструмента помогает сбалансировать гибкие подходы к разработке.

📌 Установите андон-точки в своих процессах: где и как команда может сказать «стоп» — и быть услышанной. Это не про торможение, а про зрелость.
👇Как вы реализуете андон в своих командах? Поделитесь в комментариях:)

@product_lev
#Productmanagement #андон #agile #lean #productculture #pm #Тойота

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

Почему все говорят про 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

Кто такой 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 #КомандаПродукта #РостЧерезПартнёрства

А кто такие 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

Трекшн-модель продукта: Юра, мы поехали или нет?

Недавно столкнулся с этим определением, решил поделиться в канале, раньше всегда слышал и сам говорил просто: «подбить аналитику»:)
🧭 Трекшн-модель (от англ. traction — «тяга») — это модель роста продукта. Она показывает, как продукт будет набирать пользователей, деньги и ценность во времени. Иными словами: как он “поедет”.

🧱 Как собрать трекшн-модель?
1 Выбери главную метрику роста — выручка, активные пользователи, сделки.
2 Нарисуй ключевые драйверы — откуда идёт рост: каналы привлечения, повторные покупки, расширение ARPU.
3 Разбей по шагам — как пользователи проходят путь: регистрация → активация → платёж.
4 Прогнозируй рост — на базе гипотез и исторических данных: что будет, если удвоим трафик? Улучшим конверсию?
Пример: 100 новых юзеров в месяц × 30% активация × 20% платящих = 6 платящих клиентов в месяц. Дальше моделируешь изменения и смотришь на динамику.

🧠 Зачем нужна трекшн-модель?
• Понять потенциал роста: если всё пойдёт по плану — куда ты приедешь?
• Оценить гипотезу/фичу: насколько сильно она повлияет на итоговую метрику?
• Выиграть у скептиков: показать, что за “идеей” — есть математика.
• Поддержать решение о запуске / паузе / инвестировании

⏱ Когда нужна, а когда нет?
Нужна:
• На старте продукта или нового направления
• При защите гипотез и фич с высоким риском
• Когда очень сложно выбрать приоритет
• При подготовке к существенным инвестициям или защите бюджета
Можно без неё:
• В простых улучшениях с понятным эффектом
• Когда всё и так горит и растёт (но не злоупотребляй 😅)

💸 Чем отличается от Cash Flow и юнит-экономики?
Трекшн-модель показывает, как растёт продукт через ключевые метрики и конверсии на этапах воронки, в то время как Cash Flow фокусируется на движении денег, а юнит-экономика — на прибыльности одного пользователя или сделки.
Можно сформулировать так:
Трекшн — про «как зарабатывает наш таксопарк»,
Кэшфлоу — про «хватит ли бензина»,
Юнитка — про «выгодна ли каждая поездка».

🧩 Пример трекшн-модели:
На скрине к посту приложил, как может выглядеть трекшн-модель продукта.
Где протестировали гипотезу: “А что, если повысим конверсию в регистрацию с платной рекламы и партнёрок на +5 п.п.?”
Считаем руками, сколько денег это принесёт в перспективе трёх месяцев. На основе этой информации можно принимать решение о приоритизации.

❤️ — если хочешь, чтобы твой рост был предсказуемым
😈 — если еще ни разу не делал трекшн-модели
@product_lev
#ProductManagement #Growth #Трекшн #Фреймворки #DataDrivenProduct #тяга

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

CustDev-интервью — какие бывают и чем отличаются?
Недавно обсуждали с UX-исследователем, почему одни интервью дают инсайты, а другие — только очевидные ответы на очевидные вопросы.
Решил собрать мини-гайд по типам интервью в Customer Development.

🎓 Экспертное интервью
Цель: собрать мнение от людей, которые лучше всех понимают рынок или проблему.
Фокус: не один пользователь, а широкая перспектива.
Когда использовать: на старте, при входе в новую сферу, при стратегических решениях.
Пример вопроса: «Какие тренды вы видите в подходах к обучению преподавателей?»

🧠 Глубинное интервью
Цель: разобраться в контексте, мотивации, поведении пользователя.
Фокус: не столько проблема, сколько мышление и поведение.
Когда использовать: при разработке новых продуктов или для сегментации.
Пример вопроса: «Как проходит ваш рабочий день? Как принимаете решения по X?»

🔍 Проблемное интервью
Цель: понять, есть ли у пользователя вообще проблема.
Фокус: на прошлом опыте, боли, обходных решениях.
Когда использовать: до появления идеи, чтобы не решать несуществующую проблему.
Пример вопроса: «Когда в последний раз вы пытались настроить бэкап? Что пошло не так?»

🛠 Решенческое интервью
Цель: проверить, откликается ли предложенное решение.
Фокус: реакция на прототип, концепт, фичу.
Когда использовать: есть идея — хочется понять, стоит ли её развивать.
Пример вопроса: «Если бы такой инструмент был, как бы вы им пользовались? Какие проблемы закрывает?»

💬 Один тип интервью ≠ все ответы. Часто лучше делать микс (если есть ресурсы и нет накопленных знаний): начать с глубинного, уточнить проблемное, потом протестить решение.
🧭 Как выбирать подход:
Ищешь взгляд сверху и понимание рынка? — зови на экспертное
Нужен контекст и поведение пользователя? — подойдет глубинное
Исследуешь сигнал, есть ли боль? — делай проблемное
Хочешь проверить идею или фичу? — иди в решенческое

❤️ — если спросил маму
😈 — если хоть раз проводил интервью без четкой цели
@product_lev
#ProductManagement #CustDev #UXResearch #Interviews #ProductDesign #LeanProduct #pm #кач

Раунды финансирования стартапа: от семян до акций

Продолжаю выхватывать из повседневной жизни "словечки", которые коллеги используют в обиходе.
На этот раз — что такое пре-seed и к чему это вообще относится.
Разбираемся по порядку: какие бывают раунды финансирования стартапа, на какой стадии продукт, кто обычно даёт деньги и зачем.

💡 Pre-seed — до продукта
Стадия: идея, гипотеза, первые строки кода или PowerPoint.
Цель: проверить, стоит ли вообще делать продукт.
Источники: фаундеры, друзья/семья, инкубаторы, первые бизнес-ангелы.
💬 Часто тратится на CustDev, прототип, первую команду.

🌱 Seed — посевной
Стадия: есть прототип или MVP, первые пользователи.
Цель: найти Product-Market Fit или хотя бы его признаки.
Источники: ангелы, фонды ранней стадии, акселераторы.
💬 Деньги уходят на запуск, тест гипотез, рост команды, первые каналы трафика.

🚀 Раунд A — рост
Стадия: найден PMF, есть метрики, продукт работает.
Цель: масштабировать, построить систему роста.
Источники: венчурные фонды (VC), институциональные инвесторы.
💬 Фокус — воронка, юнит-экономика, каналы, повторяемость.

📈 Раунд B и выше — масштаб и экспансия
Стадия: продукт стабилен, модель работает, рынок большой.
Цель: захват доли, выход в новые страны, запуск новых продуктов.
Источники: крупные фонды, стратегические инвесторы, корпорации.
💬 Здесь уже говорят не про "идею", а про LTV, ARR, CAC и go-to-market.

💰 IPO / Exit — выход
Компания либо становится публичной, либо её покупают.
Цель: вернуть деньги инвесторам и заработать фаундерам.
Источники: рынок, стратеги, публичные инвесторы.

🧭 Как не путаться:
• Pre-seed — это про "можно ли вообще",
• Seed — про "кому это нужно",
• Раунд A — про "как это масштабировать",
• Раунды B+ — про "как занять рынок и не сгореть".

❤️ — если слышал эти слова, но не всегда понимал контекст
😈 — если уже не раз проходил pre-seed

@product_lev
#ProductManagement #Startup #VC #Fundraising #LeanStartup #pm

Что почитать?
Формирование общественного мнения, Эдвард Бернейс
Кому: тем, кто строит бренды, двигает продукты или просто хочет понимать, как нами управляют
Кол-во страниц: 224
Оценка от меня: 4 слоя общественного сознания из 4

Отзыв:
Прикупил себе книг Эдварда Бернейса — он теоретик, практик и, по совместительству, крестный отца современной пропаганды и PR.
Книга — не совсем про «PR-приёмы», а больше про структуру массового сознания и роль посредника между "владеющими истиной" и толпой. Кто управляет информацией — тот управляет поведением.

Из чего состоит книга:
🧠 Что такое «общественность» — и почему это не просто сумма индивидов.
🎯 Зачем нужен PR-специалист — и почему он действует от имени тех, кто хочет влиять.
🛠 Какие инструменты у него в руках: медиа, лидеры мнений, культурные коды, символы.

Избранные идеи, которые попали в мои заметки:
– Толпа — это особое состояние сознания, когда человек добровольно сдаёт часть свободы.
→ Поэтому толпа ненавидит тех, кто предлагает новые правила — она чувствует угрозу структуре.
– Разница между пропагандой и просвещением — в точке зрения.
→ Что для одного "информационная кампания", для другого — "манипуляция".
– Новость — это отклонение от нормы в картине мира читателя.

Под итог несколько интересных фактов про Бернейса:
▪ Бернейс первым использовал фокус-группы в маркетинге.
▪ Мотивировал 4500 врачей сказать, что плотный завтрак полезен — чтоб вырастить продажи бекона.
▪ В 1924 привёл 34 кинозвезды в Белый Дом — и открыл эру пиара в политике.

Книга читается местами как манифест, местами как инструкция.
По итогу сложно не замечать, как многие механики из книги уже встроены в ежедневную реальность: ленты, воронки, лояльности, инфоповоды.

@product_lev
#чтопочитать #Бернейс #PR #массовоесознание #productmanagement #коммуникация #толпа #психология #литература

JTBD (Jobs to Be Done): на какую работу пользователи нанимают ваш продукт?

В мире продуктового менеджмента важно понимать, что движет вашими пользователями. Методы анализа, такие как JTBD, CJM, персоны предоставляют уникальные инсайты, которые помогают создать продукт, действительно решающий проблемы клиентов.

Что такое JTBD?
JTBD — методология, которая фокусируется на "работах", которые пользователи пытаются выполнить с помощью вашего продукта. Вместо того чтобы концентрироваться на функциях или характеристиках продукта, JTBD помогает понять цели и мотивации пользователей.

Основные принципы JTBD:
1) Фокус на работе, а не на продукте
Пользователи "нанимают" продукт для выполнения конкретной работы. Например, они покупают не дрель, а отверстие в стене.
2) Учёт контекста использования
Важно понять, почему и в каких условиях пользователи выбирают ваш продукт. Это помогает выявить скрытые потребности и улучшить пользовательский опыт.
3) Выявление скрытых потребностей
Анализируйте, как пользователи решают свои задачи другими способами. Это может быть не только конкурирующий продукт, но и любые альтернативные решения.

Когда использовать JTBD:
🟢 При запуске нового продукта — чтобы не влюбиться в решение, а понять проблему
🟢 При плохом ретеншене — чтобы выяснить, действительно ли решаем “ту” работу
🔴 Слишком абстрактен для проверки конкретных небольших изменений
🔴 Может смазать представление о рыночных тенденциях и конкурентном анализе

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

JTBD апеллирует к основным аспектам опыта пользователя:
Джобы: Пользователи хотят сэкономить время на готовку и уборку, чтобы больше времени проводить с семьей или заниматься другими важными делами.
Цели: Они стремятся к удобству и комфорту, хотят избавить себя от стресса, связанного с покупкой продуктов, приготовлением и уборкой после еды.
Барьеры: Высокие цены на доставку, ограниченный выбор блюд или долгая доставка могут препятствовать достижению этих целей.

Что с этим делаем:
Понимание джобов, целей и барьеров позволяет нам поднять ценность продукта для пользователя. Например, зная, что пользователи хотят сэкономить время, мы можем предложить персонализированные подписки на регулярные доставки или внедрить функции предварительного заказа. Если цена является барьером, можно рассмотреть возможности для предоставления скидок или акций.

JTBD позволяет глубже понять мотивации пользователей и создать продукт, который действительно решает их задачи, повышая удовлетворенность и лояльность клиентов.
Картинку "JTBD на карте опыта клиента" к посту взял из классной статьи.

Ставьте ❤️, если считаете, что JTBD полезен для каждого продакта.
Ставьте 😈, если считаете, что JTBD применим для каждого продукта.

@product_lev
#JTBD #productmanagement #pm

Анализ 5C: анализ компании - легко сказать, да тяжело сделать

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

Анализ 5C — это подход к анализу компании, который помогает структурировать ключевые аспекты бизнеса и его окружения. Он фокусируется на пяти элементах:

Компания (Company)
Оценка внутренних ресурсов, компетенций и стратегий продуктов компании. Это включает в себя анализ текущих процессов, технологий, финансовой устойчивости и культуры компании. Понимание этих аспектов помогает выявить сильные и слабые стороны вашего продукта и определить, какие внутренние изменения могут улучшить его конкурентоспособность.

Клиенты (Customers)
Исследование потребностей и поведения клиентов. Изучите, какие проблемы и задачи они пытаются решить, и как ваш продукт может стать для них наиболее ценным. Это также включает в себя сегментацию клиентов, изучение их предпочтений и понимание факторов, которые влияют на их решение о покупке.

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

Коллаборации (Collaborators)
Оценка партнерских отношений и возможностей для сотрудничества. Определите, кто может помочь в достижении ваших целей, будь то поставщики, дистрибьюторы или технологические партнеры. Сотрудничество может помочь расширить возможности вашего продукта и ускорить его развитие.

Контекст (Context)
Анализ внешних факторов, таких как экономические, технологические и социальные изменения, которые могут повлиять на ваш бизнес. Учтите законодательные изменения, рыночные тренды и культурные особенности, которые могут повлиять на восприятие вашего продукта.


🧩Для продактов анализ 5C может стать основой для стратегического планирования. Он позволяет глубже понять рынок и свой продукт, выявить возможности для роста и минимизировать риски, обеспечивая конкурентные преимущества.

Ставьте ❤️, если 5С охватывает все аспекты бизнеса
Ставьте 😈, если пользуетесь SWOT'ом и не паритесь
@product_lev
#5C #productmanagement #стратегия #pm #анализ

SWOT-анализ: как использовать для улучшения продуктовой стратегии

Продолжаю разбирать методологии в рамках стратегического планирования.
Один из самых простых и эффективных инструментов — это SWOT-анализ. Этот метод помогает продуктовым командам оценить внутренние и внешние факторы, влияющие на продукт.

SWOT-анализ — это методология, которая предлагает оценить ваш продукт с точки зрения четырех ключевых аспектов:

1. Strengths (Сильные стороны) Что выделяет ваш продукт на фоне конкурентов? Это может быть уникальная функция, сильная команда или высокая лояльность клиентов.

2. Weaknesses (Слабые стороны) Какие аспекты вашего продукта нуждаются в улучшении? Возможно, это устаревшая технология или слабая маркетинговая стратегия.

3. Opportunities (Возможности) Какие внешние факторы могут способствовать росту вашего продукта? Это могут быть новые рыночные тренды, партнерства или технологические инновации.

4. Threats (Угрозы) Какие внешние факторы могут негативно повлиять на ваш продукт? Это могут быть действия конкурентов, изменения в законодательстве или экономические спады.

Как использовать SWOT-анализ?
Начните с мозгового штурма по каждому из аспектов, а затем организуйте полученные данные в удобную таблицу. Это поможет вам визуализировать текущую ситуацию и выявить, где нужно сфокусировать усилия. Используйте сильные стороны и возможности для усиления продукта, а слабые стороны и угрозы — как стимул для улучшений и адаптации.

Пример:
Представьте, что вы работаете над мобильным приложением для фитнеса. Сильные стороны могут включать уникальные тренировки и персонализированные планы, слабые — недостаток интеграции с носимыми устройствами. Возможности могут быть связаны с растущим интересом к здоровому образу жизни, а угрозы — с работой конкурентов.

SWOT в рамках 5C:
SWOT-анализ отлично дополняет 5C анализ, помогая глубже понять элементы "Компания" и "Контекст". Вы можете использовать SWOT для оценки внутренних ресурсов и компетенций компании, а также для анализа внешних факторов, таких как рыночные тренды и конкурентная среда.

Ставьте ❤️, если пользуетесь SWOT'ом и не паритесь
Ставьте 😈, если PESTEL больше подходит для оценки внешних факторов

@product_lev

#SWOT #productmanagement #стратегия #pm #бизнесанализ