Профессия:
AR или VR: выбор венчурного инвестора
Коротко: AR
Я бы вложился в AR, а не в VR. Не потому что VR плохой, а потому что AR лучше позиционирован для массового рынка в ближайшие 5-10 лет.
Почему VR застревает
1. Барьер входа слишком высокий
Результат:
2. Use cases ограничены
Вывод: VR = специализированная платформа для gamer'ов и энтузиастов. Не для всех.
Почему AR выигрывает
Как вы работаете с инженерами? Опишите ваш подход
Взаимодействие PM с инженерами это центр разработки продукта. Плохое взаимодействие = срывы deadline, низкое качество, текучка.
Ключевой принцип: Уважение
Я уважаю инженеров потому что:
Самая большая ошибка PM: думать что они главнее инженеров. Неправда. Мы партнёры.
Мой подход по фазам
Что я делаю:
Что я НЕ делаю:
Посчитайте количество настройщиков пианино в Москве
Это типичный Fermi Estimation вопрос. Показывает能力 делить большую проблему на части и делать обоснованные допущения.
Подход: Разбиение проблемы
Шаг 1: Сколько пианино в Москве?
Население Москвы: ~12 млн людей
Средний размер семьи: 3 человека
Семей: 12М / 3 = 4М семей
% семей, у которых есть пианино:
Пианино в музыкальных школах, залах:
Пианино в студиях звукозаписи, театрах, ресторанах:
Общее количество пианино: 60,000 + 750 + 400 = ~61,000 пианино
Шаг 2: Как часто нужна настройка?
Расскажите о случае, когда вы получили жёсткую обратную связь от руководителя. Как отреагировали
Ситуация
Когда: Q3 2021, я был PM платформы для SaaS analytics
Что произошло: Я потратил 3 спринта (6 недель) на разработку нового dashboard для "Advanced User Segments". Это была красивая фича, с ML recommendations, которое я считал game-changer.
Выпустили. И... ничего.
На weekly standpop мой CEO (Директор) сказал прямо:
"Это была траты 6 недель разработки и дизайна. Вы не валидировали гипотезу. Вы не говорили с пользователями. Вы построили красивый продукт, который никому не нужен. В другой компании вас уволили бы."
И он был ПРАВ. Это был удар.
Как я отреагировал (неправильно сначала)
Как вы разрешаете конфликты на работе?
Конфликты в product management неизбежны: PM vs. Engineering про scope, PM vs. Design про UX, PM vs. Marketing про messaging. Важно не избежать конфликт, а разрешить его конструктивно.
Мой подход к разрешению конфликтов
Принцип 1: Understand before judging
Принцип 2: Separate people from problem
Принцип 3: Data > opinion
Принцип 4: Win-win solutions
Конкретный пример из практики
В чём разница между продакт-менеджером и проджект-менеджером?
Это часто путаемые роли, но они принципиально отличаются в целях, ответственности и горизонте планирования. Рассмотрю оба подхода.
Product Manager (Продакт-менеджер)
Что делает:
Горизонт планирования:
Ключевые обязанности:
Как приоретизировать когда идей много
Это классическая проблема: вы получаете 50 идей, а реализовать можете только 5. Как выбрать? Я разберу системный подход, который использовал на всех своих проектах.
Золотое правило: раньше ясности, потом приоретизации
Не начинайте ранжировать идеи если вы их не поняли. Потратьте время на то чтобы:
Это фильтрует 30% идей сразу (выясняется что они дубликаты или невалидные).
Шаг 1: Категоризация
Примерно так я разбиваю идеи:
Вот что просят вернуться пользователей / рост MRR
Удержание / Retention
Качество / Stability
Новые пользователи / Growth
Эксперимент
Отношение к карьерным предложениям
Основной принцип: открыт, но избирателен
Да, я рассматриваю интересные предложения, но я не в активном поиске. Для меня важны несколько критериев:
Критерии оценки новой роли
1. Impact и масштаб
2. Команда и руководство
3. Возможность роста
4. Компенсация и условия
Признаки хорошего Product Manager
Главные качества
1. Обсессия с результатами, не процессами
Хороший PM измеряет себя не количеством meetings и документов, а тем, сколько value добавил продукт:
Плохой PM фокусируется на процессе (красивая доска, подробная документация), хороший — на результате.
2. Глубокое понимание пользователей
Хороший PM:
Плохой PM полагается только на аналитику или интуицию, без реальной эмпатии.
3. Структурированное мышление в условиях неопределённости
Как происходит приоритизация задач
Приоритизация — это один из самых важных навыков PM, потому что ресурсы всегда ограничены, а идей бесконечно. Я применяю многоуровневый подход, который комбинирует данные, стратегию и pragmatism.
Уровень 1: Стратегическое выравнивание
Перед тем, как приоритизировать конкретные задачи, я убеждаюсь, что все они выравнены со стратегией:
Вопросы, которые я задаю:
Если задача не соответствует стратегии, она идёт в backlog (может быть, кому-то её даст) или отклоняется.
Пример: Если стратегия: "Увеличить retention новых пользователей", то задача "добавить 50 новых эмодзи" не приоритет, даже если это просит много пользователей.
Уровень 2: Фреймворк приоритизации
Обязанности Product Manager
Как PM, я отвечал за полный lifecycle продукта, от стратегии до метрик. Вот мой спектр ответственности.
Стратегия и планирование
Видение продукта:
Roadmap:
Работа с требованиями и спецификациями
Feature Definition:
Backlog Management:
Три любимых продукта и улучшение одного из них
Три продукта, которые я люблю
1. Figma Люблю за: инновационный подход к дизайну (cloud-first вместо desktop), отличную collaboration, и то, что они постоянно слушают пользователей.
2. Slack Люблю за: простоту, которая скрывает сложность. Они решили сложную проблему (асинхронная коммуникация) элегантно.
3. Notion Люблю за: универсальность и гибкость. Один продукт может быть и todo, и wiki, и database — это требует отличного PM видения.
Выбор: Slack — как я бы его улучшил
Я выбираю Slack потому что это базовый инструмент для большинства команд, и я вижу реальные pain points, которые остались нерешенными.
Pain point 1: Информационная перегруженность
Проблема: После отпуска на неделю у тебя 500 сообщений. Ты не знаешь:
Slack указывает на @mention, но это не решает проблему.
Чем я занимаюсь: день в жизни IT Product Manager
Это хороший вопрос, потому что много людей имеют неправильное представление о том, чем мы занимаемся на самом деле. Я расскажу честно, без романтизации.
Мой типичный день
08:30 — Просмотр новостей и слаков
Пришли ночью вопросы от инженеров, фидбек от клиентов через саппорт, метрики с предыдущего дня. Я читаю все и определяю приоритеты.
09:00 — Встреча с дизайнером
Обсуждаем макеты новой фичи. Дизайнер спрашивает: это для всех пользователей или только для power users? Я проверяю данные и даю рекомендацию.
09:45 — Встреча с tech lead
Он говорит, что на фичу нужно 3 недели. Я спрашиваю почему и мы ищем компромисс: может быть, MVP за 1 неделю?
10:30 — Интервью с пользователем
Звонок с клиентом. Спрашиваю как он использует фичи и есть ли боли. Выясняется, что он использует не так, как я ожидал. Это дает новую идею.
11:15 — Работа с аналитикой
Методы тестирования гипотез в Product Management
Иерархия тестирования
Не все гипотезы требуют масштабного A/B теста за миллион рублей. Я использую пирамиду тестирования: сначала самые дешёвые и быстрые методы, потом переходу к дорогим, только если есть уверенность.
Качественные методы (самые быстрые)
User Interviews — беседы с 5-10 пользователями. За 2-3 дня можно понять, имеет ли гипотеза смысл. Не нужна статистика, нужны инсайты. Пример: "Если мы добавим экспорт в PDF, будут ли люди это использовать?" — спросим 10 активных юзеров.
Contextual Inquiry — наблюдение за пользователем в его естественной среде. Как он работает с продуктом? Где возникают боли? Дешево, быстро, честно.
Concept Testing — показываем макет или wireframe и смотрим реакцию. Нарисовал в Figma, отправил 20 пользователям, собрал feedback. За неделю понимаем, стоит ли двигаться дальше.
Что сдерживает Slack и что нужно строить
Контекст: Slack в 2026
Успех:
Проблема:
ЧТО СДЕРЖИВАЕТ SLACK
Slack pricing:
Проблема:
Откуп 100-person компании:
- Slack: 100 × $8.99 × 12 = $10,788/год
- Teams: 100 × $6 (через Office 365) = $7,200/год
- Discord: free + premium опционально
Slack дороже на 50%.
Для компании с 50 тыс сотрудников:
- Slack: 50,000 × $8.99 = $449.5K/месяц = $5.4M/год
- Teams: встроено в Office365 (доп платы нет)
Теперь Teams это no-brainer.
Самый интересный проект: Переформулирование Крупного Legacy Продукта в AI-native Solution
Этот проект был для меня точкой разворота в карьере, потому что заставил переосмыслить всё, что я знал о PM. Расскажу как это было.
Контекст: До проекта
Компания: SaaS для управления контентом (B2B, ~50M ARR, 200K пользователей)
Проблема:
Мой момент осознания: На встречу с ключевым клиентом (который был готов уйти) я пришел с обычным pitch. Он сказал: "Ваш продукт хороший, но я не хочу работать в 2015-м году. Мне нужен AI copilot, который будет помогать мне."
Этот момент был золотым. Я понял: не нужно улучшать старый продукт — нужно создать новый.
Этап 1: Discovery (Месяц 1)
Плюсы и минусы автозапуска видео в соцсетях
Это вопрос о balance между engagement и user experience, а также ethical considerations.
Плюсы автозапуска видео
1. Увеличенный engagement
Метрики улучшаются:
2. Лучше содержание discovery
3. Более smooth UX
4. Монетизация
Как вы измеряете успех продукта
Введение
Успех продукта — это не одно число. Это системный взгляд на три измерения: пользователи получают ценность (Product), компания зарабатывает деньги (Business), и команда доставляет качество (Execution).
Я измеряю успех через четыре слоя, от стратегического к тактическому.
Слой 1: СТРАТЕГИЧЕСКИЙ
Вопрос: Движемся ли мы в нашего долгосрочного видения?
Примеры видения:
Как измерять:
Слой 2: БИЗНЕС (Финансовый уровень)
Вопрос: Быстро ли растёт компания?
Как решать, какие фичи внедрять, а какие нет
Это один из самых важных вопросов в Product Management. Ежедневно я получаю десятки предложений: от пользователей, от команды, от CEO. Нужна система выбора, иначе будешь разрываться.
Расскажу свой процесс и frameworkы, которыми я пользуюсь.
1. Источники идей и первичная фильтрация
Откуда приходят идеи:
Первичная фильтрация (за 5 минут):
Есть простые вопросы, которые сразу отсеивают 80% идей:
Это решает проблему пользователей или это vanity feature?
Это входит в наш vision продукта?
Проект, который не пошёл по плану
Расскажу реальную историю из своего опыта, где красивый план столкнулся с реальностью. Это был хороший урок в смирении и адаптивности.
Контекст: запуск Premium плана
Что было запланировано: Три года назад я работал на B2B SaaS компании, которая предоставляла аналитику для e-commerce брендов. Было:
Что пошло не так
Неделя 1-3: разработка идёт нормально Основные фичи разработаны, прототипы выглядят хорошо.
Неделя 4: первые красные флаги Показали новые фичи потенциальным клиентам. Реакция:
Методология выбора первой проблемы для работы
Как я выбираю проблему
1. Определение важности для пользователей
В первую очередь я бы выясил:
Если проблема частая, острая и затрагивает большую часть базы, это высокий приоритет.
2. Анализ влияния на бизнес
3. Сложность решения
Я выбираю проблему, которую:
Даже если проблема очень важна, но требует 6 месяцев разработки, я могу отложить ее.
4. Возможность измерения успеха
Определение основной боли аудитории: Стратегия PM
Понимание pain points вашей аудитории — это фундамент для build продукта который люди действительно хотят. Без этого understanding вы строите вслепую.
Этап 1: Определение целевой аудитории
Создайте user personas:
Для каждого key segment:
Пример persona для e-commerce:
Segment по pain points:
Как принимал решение какую фичу делать
Решение о том какую фичу разрабатывать — это одна из главных ответственностей PM. Это не личное мнение, это структурированный процесс на основе данных, стратегии и рисков. Я расскажу как я это делаю.
1. Где берутся идеи фич
Прежде всего, откуда вообще идеи:
Источник 1: Пользователи
Примеры:
Источник 2: Конкуренты
Как найти суть проблемы в основе поведения пользователей
Это, пожалуй, самый важный навык PM — поиск истинной причины. Люди часто говорят на поверхностном уровне, но проблема глубже. Вот мой систематический подход основанный на years практики и техниках как "Five Whys" и "Root Cause Analysis".
Принцип: Surface vs Root Cause
Что видим на поверхности:
Что может быть истинной причиной:
Я должен копать глубже и найти корень.
Методология: Five Whys
Это классический подход от Toyota Production System. Спрашиваю "Why?" пять раз:
Пример 1: Пользователи не используют new feature
Повер-юзер: "Я не использую функцию Reports"
Почему я меняю работу
Моё решение о смене работы — это осознанный шаг, основанный на нескольких ключевых факторах, которые раскрывают мое видение профессионального развития и амбиции.
Основные причины
1. Жажда новых вызовов
На моей текущей позиции я достиг определённого плато в развитии. Я успешно реализовал основные инициативы:
Теперь я ищу позицию, где смогу работать с более сложными проблемами: масштабированием на новые рынки, входом в adjacent markets, или трансформацией бизнес-модели.
2. Стремление к влиянию на более высоком уровне
В текущей компании я — один из PM-ов, отвечающий за свой продукт. Я хочу позицию, где смогу:
Проблема, которую я увидел и решил
Контекст
Работа: SaaS для управления задачами (как Asana, но дешевле).
Клиенты платили $50/месяц, но 40% уходили после первого месяца. Остальные 60% были довольны и платили годами.
Проблема: чему учить? Почему 40% уходят в месяц 2?
Шаг 1: Я заметил паттерн (observation)
Сырые данные:
Месяц 1: 1000 новых customers
Месяц 2: 600 остались (60% retention)
Месяц 3: 580 остались (платили до конца, но 20 ушли в месяц 3)
Но это мало информации. Я начал копать глубже.
Анализ по типам клиентов:
Small teams (1-5 людей):
- Day-1 adoption: 80% (они используют)
- Month-1 retention: 30% (они уходят!)
Medium teams (6-30 людей):
- Day-1 adoption: 40% (никто не использует первый день)
- Month-1 retention: 70% (они остаются)
Large teams (30+ людей):
- Day-1 adoption: 20% (никто не начинает)
- Month-1 retention: 80% (но они редкие, 5% клиентов)
I took a high risk decision when I was PM at a SaaS company. Our onboarding was too long (30 minutes, 10 steps) with poor D7 retention of 35%. I proposed to completely rebuild it in just 2 weeks - risky because of tight timeline and core feature. But I had data showing the problem and a mitigation plan with fallback. The results were great: onboarding time dropped to 5 minutes, D7 retention jumped to 55%, and it generated 10 million in additional annual revenue. This taught me that high-risk decisions are justified when you have good data, capable team, and mitigation plan. I calculate risks carefully - its not gambling, its smart risk-taking.
Сколько iPhone продаётся ежегодно в США
Этот вопрос проверяет мою способность оценивать рынок, делать расчёты и давать обоснованный estimate. Это не просто знание цифры, а понимание как к ней прийти.
Расскажу мой способ расчёта.
Метод 1: Top-down (от населения к пользователям)
Шаг 1: Население США и смартфон users
Шаг 2: iPhone users
Шаг 3: Upgrade cycle
Плюс: New customers
Total: 44 млн + 14 млн = 58 млн iPhones в год в США
Метод 2: Bottom-up (от доходов Apple)
Шаг 1: Revenue Apple
Как расширить Duolingo на обучение математике
Стратегия
Duolingo успешна на языках. Математика — естественное расширение (education platform, не language platform).
Phase 1: Research
Customer Discovery (интервью с родителями, учителями):
Key Insights:
MVP: Duolingo Math (фаза 2)
Core Experience:
Short lessons (5-10 минут, как языки)
Gamification:
Как определить ключевые метрики для приложений знакомств, например Tinder?
Приложения знакомств это сложный продукт потому что success зависит от балансировки двух сторон маркетплейса: мужчины и женщины (или любые два гендера), и от качества matches.
Бизнес модель Tinder
Трехуровневая монетизация:
Иерархия метрик
Tier 1: Retention (здоровье продукта)
Если люди не возвращаются — всё остальное не важно.
Метрика 1.1: DAU/MAU ratio (стикость)
Что мерим: Daily Active Users / Monthly Active Users
Типичные значения:
- Хорошо: DAU/MAU > 40% (40% от пользователей приходят каждый день)
- Нормально: 25-40%
- Плохо: < 20%
Для Tinder: скорее всего 30-35% (люди проверяют несколько раз в неделю, не каждый день)
Как улучшить микроволновую печь
Этот классический вопрос для Product Management интервью проверяет структурированное мышление, способность определять проблемы и предлагать решения. Расскажу, как я бы к этому подошел как PM.
Шаг 1: Определение целевой аудитории и контекста
Разные люди используют микроволновку по-разному. Нужно понять, о ком мы говорим:
Основные сегменты:
Для анализа сфокусируюсь на основном пользователе: офисный работник и студент, которые используют микроволновку 1-2 раза в день.
Шаг 2: Выявление главных болей
Основные проблемы с текущей микроволновкой:
Как вы проводите Customer Development интервью?
Customer Development интервью — это один из самых мощных инструментов PM для понимания настоящих проблем пользователей. Я практикую структурированный подход на основе методологии Стива Бланка и Норманна Розен.
Фаза 1: Подготовка (до интервью)
1.1 Определение гипотезы
1.2 Выбор интервьюируемых
Что делать после выявления проблемы: процесс решения
Это фундаментальный процесс в product management. Много людей ищут проблемы но не знают что делать дальше. Давайте разберем пошагово.
Реальный пример
Вы выявили проблему: "Users frustrated потому что не могут find важный feature в app."
Теперь что?
Шаг 1: Validate проблему (день 1-3)
Перед тем как начать работать, убедитесь что проблема реальна и не edge case.
Что делать:
Говорите с пользователями (5-10 people)
Смотрите на данные
Определить: это проблема для нас или для них?
Результат шага 1:
Мой нынешний роль и ответственность
О роли
Я Product Manager на [current stage компании] в [industry].
Мой scope:
Ключевые responsibilties
1. Strategy & Planning
2. Product Development
Компания где я сейчас/последняя работал
И сейчас работаю в EdTech компании, которая запустилась 5 лет назад и сейчас имеет $50M ARR. Расскажу чем они занимаются и мою роль.
Бизнес компании
Миссия: Сделать quality education доступным для всех, несмотря на географию и доход
Что делают:
Компания — это онлайн платформа для профессионального обучения в tech (программирование, data science, дизайн, продукт менеджмент и т.п.).
Продукты:
B2C: Self-paced курсы (основной бизнес)
B2B: Learning management system (LMS)
Выводы при росте покупок на 10% после изменения дизайна
Рост на 10% — это положительный сигнал, но делать окончательные выводы на основе этого показателя рано и опасно. Необходимо провести тщательный анализ, чтобы отделить влияние дизайна от других факторов.
Что НЕЛЬЗЯ утверждать:
1. Прямая причинно-следственная связь
2. Долгосрочный эффект
Что НУЖНО сделать для анализа:
Статистическая значимость
Кто принимает финальное решение по запуску эксперимента: структура и governance
Это важный вопрос о decision-making authority и governance. В разных компаниях это может быть по-разному, но я расскажу о моем подходе и о том, как я видел это работать в лучших организациях.
Зависит от типа эксперимента
Low-risk эксперименты (большинство A/B тестов)
Командная работа: как я работаю как team player
Попадание в вопрос о team work очень важно, потому что PM — это не solo role. Весь мой результат зависит от способности работать через людей, мотивировать их и создавать психологическую безопасность в team.
1. Я ставлю team выше себя
Принцип: Team's success = My success
Когда я в team meeting, я:
Пример: Инженер предложил architecture решение, которое было лучше чем мое. Я сказал: "Это brilliantly thinking. Давайте это делать." И потом на meeting'е с leadership я сказал: "Инженер предложил отличное решение, которое сэкономит нам 20% development time."
2. Я transparent и honest
Принцип: No hidden agendas, no politics
Самое важное достижение в карьере Product Manager
Большинству PM вопрос о главном достижении задают на собеседованиях. Правильный ответ показывает способность думать о бизнесе-результатах, а не просто о фичах.
Структура хорошего ответа
Оптимальный ответ содержит:
Пример достижения
Контекст: В моей последней роли в FinTech стартапе я был PM мобильного приложения для переводов денег.
Проблема: Conversion rate на стадии верификации учётного записи был 35% — теряли 65% новых пользователей. Это был главный bottleneck для роста.
Профессиональные цели PM на ближайшие 3-5 лет
Философия целеполагания
Я верю в SMART цели (Specific, Measurable, Achievable, Relevant, Time-bound), но с добавлением soul — это не просто метрики, это результаты, которые делают разницу для людей.
Мои цели разделены на три горизонта: 1 год (тактика), 3 года (стратегия) и 5 лет (vision).
1-летние цели (Ближайший год)
Это конкретная, измеримая цель. Не просто "растить продукт", а достичь определённой финансовой метрики.
Как я буду это мерить:
Почему это важно: в рамках этой цели я научусь:
Коммуникационные стратегии для повышения engagement в мобильном приложении
Повышение frequency пользования — одна из ключевых задач PM. Расскажу о системном подходе к коммуникациям, включая типы, timing, и примеры.
1. Стратегический подход: от понимания поведения
Прежде чем отправлять push-уведомления, нужно понять:
Мой подход:
2. Типы коммуникаций
Push-уведомления (наиболее эффективное)
Timing-based push (отправляю в "лучшее" время для пользователя)
Какие обязанности я хочу выполнять как PM
Философия роли
ПМ — это не диктатор, который раздаёт приказы. PM — это лидер, который видит полную картину: клиента, бизнес, технологию, команду. Я хочу выполнять те обязанности, которые максимально влияют на успех продукта и благополучие команды.
1. Понимание клиента и проблем (Customer Discovery)
Это сердце моей работы. Я хочу:
Слушать клиентов напрямую. Не через отчёты аналитиков, а сидя рядом, наблюдая за тем, как они используют продукт. Интервьюировать на Zoom, ходить в офисы к enterprise клиентам, читать в соцсетях.
Понимать их боль. Не просто записывать фидбек, а копать глубже: почему они это говорят? Какие проблемы скрываются за их словами? Это JTBD подход — jobs to be done.
Выявлять потребности, которые они даже не знают, что имеют. Именно это отличает хорошего PM от среднего.
Я готов тратить 30-40% времени на customer discovery. Это инвестиция в правильность стратегии.
Приоритизация фич: система и методология
Приоритизация — это одна из главных задач Product Manager. Расскажу о методике, которая позволяет принимать обоснованные решения в условиях ограниченных ресурсов.
Правило 1: Не всё вдруг
Основной принцип:
Я всегда говорю команде: "Приоритизация — это искусство сказать "нет"".
Фреймворк приоритизации
Я использую комбинированный подход из нескольких методик:
Каждую фичу оцениваю по четырём параметрам:
Reach (охват)
Валидация гипотез в продукте: от идеи к доказательству
Контекст: почему валидация критична
Luckiest problem PM'ов: потратить миллионы на разработку фичи, которая никому не нужна. Валидация гипотезы — это страховка. Я всегда тратил 10% времени на подтверждение гипотезы перед разработкой, чтобы не потратить 90% зря.
Сценарий: гипотеза о проблеме с retention
Этот сценарий из моего опыта. Был SaaS продукт для управления проектами, и я заметил странное:
Это плохо. 2/3 пользователей не возвращаются через месяц.
Могло быть несколько причин падения retention:
Путь монетизации мобильного приложения до production: полный чеклист
Контекст: почему монетизация сложнее, чем кажется
Монетизация мобильного приложения — это не просто добавить кнопку "Купить". Это экосистема из платёжных систем, регуляции, аналитики, фрауда и пользовательского опыта. Неправильный подход = потеря денег, бана из App Store, судебные иски.
Фаза 0: Подготовка (неделя -4)
Прежде всего нужно выбрать, как именно монетизировать:
Вариант 1: In-App Purchases (IAP)
Вариант 2: Freemium + Подписка
Вариант 3: Реклама
Что означает Retention 3%: анализ метрики
Retention 3% это очень специфичная метрика которая требует контекста. Разберу что это может означать и как это интерпретировать.
Вариант 1: Day-1 Retention = 3%
Это означает что из 100 пользователей которые установили приложение вчера, сегодня вернулось только 3. Это ОЧЕНЬ плохо. Это указывает на критические проблемы с UX или value proposition. Бэнчмарк для мобильных приложений это 20-30% на Day-1. 3% это красный флаг.
Причины:
Вариант 2: Day-30 Retention = 3%
Это означает что из пользователей которые установили месяц назад, 3% все ещё активны. Это также очень плохо. Нормальный бэнчмарк для приложения это 20-40% на Day-30. 3% значит продукт не держит пользователей.
Любимая технология: Large Language Models (LLM) — и почему это меняет PM профессию
Выбираю LLM как наиболее трансформационную технологию 2020-х. Объясню почему — как с точки зрения бизнеса, так и с точки зрения PM роли.
Почему LLM (ChatGPT, Claude, Gemini)?
LLM — это первая технология, которая может решать задачи сразу в десятках индустрий:
Сравните с другими:
LLM имеет максимальный потенциал рынка.
Как улучшить Google Maps для работы с плохим интернет-соединением
Problem
Regions: India, Africa, SE Asia (2B+ people with slow/intermittent internet)
Current pain: Google Maps crashes, freezes, doesn't work offline
Solution: Google Maps Lite Mode
Metrics
Как расставлять приоритеты в бэклоге продукта
Это один из самых важных навыков PM. Каждый день я получаю больше идей, чем способна разработать команда. Нужна система приоритизации, иначе бэклог станет хаосом.
Уровень 1: Триаж (быстрая фильтрация)
Вопросы триажа:
После триажа:
Уровень 2: Категоризация
1. Critical Bugs & Security
2. High-Impact Features
3. Maintenance & Tech Debt
4. Nice-to-have & Polish
Мой вклад в ключевые проекты
Контекст
В разных компаниях я возглавлял или участвовал в различных проектах. Опишу несколько ключевых.
Проект 1: Переход на новую ценовую модель (SaaS B2B)
Ситуация: Компания имела простую flat pricing ($100/месяц для всех). Это была боль: small customers нежелательны (margin thin), enterprise customers хотели кастомные цены.
Мой вклад: