Как будешь приоритизировать гипотезы в мобильном приложении?

Приоритизация гипотез в мобильном приложении

Приоритизация гипотез—это ключевой навык PM. Неправильная приоритизация ведёт к трате времени на неважное и упущению критических улучшений. Я использую структурированный подход.

Шаг 1: Сбор гипотез

Гипотезы приходят из разных источников:

• Аналитика: метрики, фанели конверсии, drop-off точки
• User research: интервью, юзер-тесты, форумы, отзывы
• Команда: идеи от дизайнеров, разработчиков, маркетинга
• Конкуренты: что делают успешно другие
• Тренды: новые технологии, паттерны в индустрии

Пример гипотез для e-commerce приложения:

1. "Если добавить 1-click checkout, конверсия вырастет на 15%"
2. "Если показать рекомендации на главной, среднее время в приложении увеличится"
3. "Если сделать поиск быстрее (через ML), будут меньше уходить из каталога"
4. "Если добавить wishlists, покупатели вернутся чаще"
5. "Если улучшить работу на медленных сетях, установки вырастут на 10%"

Шаг 2: Фреймворк приоритизации

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

2.1 Потенциал влияния (Impact)

Насколько сильно гипотеза повлияет на основные метрики?

Оценка:

• High (9-10 баллов): улучшит конверсию на 20%+ или DAU на 15%+
• Medium (5-8 баллов): улучшит на 5-20%
• Low (1-4 балла): улучшит на <5% или влияет на редкую метрику

Как оцениваю:

• Беру текущую метрику (например, 5% checkout completion)
• Смотрю, сколько пользователей это затрагивает
• Оцениваю вероятность улучшения на основе похожих экспериментов

Пример:

• 1-click checkout: затронет 100% пользователей, которые делают покупки. Если 5% конвертятся сейчас, и улучшение на 20%, это даст +1% к основной конверсии. High impact.

2.2 Уверенность (Confidence)

Насколько я уверен, что гипотеза верна?

Оценка:

• High (80-100%): есть данные/тесты других компаний, интервью показали боль
• Medium (50-80%): есть логика, но мало доказательств
• Low (<50%): интуитивно кажется, но нет валидации

Как проверяю уверенность:

• Есть ли похожие эксперименты в литературе? (Нет → Low)
• Что говорят пользователи? ("Невозможно быстро оплатить" → High)
• Какие похожие фичи сработали у конкурентов? (Да → High)

Пример:

• 1-click checkout: Amazon, Apple показали это работает. Интервью показали, что пользователи жалуются на длинный checkout. High confidence.

2.3 Сложность реализации (Effort)

Сколько времени и ресурсов нужно?

Оценка:

• Low: 1-2 недели 1 разработчика
• Medium: 2-4 недели команды
• High: 1+ месяца, требует архитектурных изменений

Как оцениваю:

• Спрашиваю tech lead
• Есть ли технические зависимости?
• Нужны ли изменения backend, iOS и Android?

Пример:

• 1-click checkout: нужны изменения в payment системе, безопасность, тестирование. High effort (~3-4 недели).
• Wishlists: может быть сделано за 2 недели. Medium effort.

2.4 Стратегическое соответствие (Alignment)

Соответствует ли гипотеза квартальным целям?

Оценка:

• High: прямо связана с OKR
• Medium: косвенно помогает
• Low: не соответствует приоритетам

Пример:

• Q1 OKR: "Увеличить конверсию на 20%"
• 1-click checkout прямо влияет → High alignment
• Wishlists влияет на retention, не конверсию → Low alignment

Шаг 3: Матрица приоритизации

Создам таблицу:

Формула скора: Итоговый скор = (Impact × Confidence × Alignment) / Effort

Это даёт приоритет гипотезам, которые имеют высокий потенциал, мы в них уверены, они стратегичны и относительно дёшевы.

Шаг 4: Дополнительные факторы

Кроме матрицы, учитываю:

Сезонность и время на рынке:

• Если сезон пиков продаж через месяц, приоритизирую гипотезы, которые готовы раньше

Зависимости:

• Некоторые гипотезы требуют других фич. Нужно делать в правильном порядке

Риск:

• Может ли гипотеза сломать текущий функционал?
• Нужны ли значительные тесты безопасности?

Конкурентное преимущество:

• Может ли эта фича отличить нас от конкурентов?

Шаг 5: Валидация и тестирование

Не все гипотезы тестирую через A/B тесты. Используютсяещё методы:

Быстрая валидация (перед разработкой):

• Smoke test: прототип или mockup для юзер-тестирования
• Опросы: спросить пользователей, хотят ли они эту фичу
• Логический анализ: есть ли логические причины, почему это работает?

Полное тестирование (A/B тест):

• Разрабатываем фичу
• Делим пользователей на контрольную и экспериментальную группу
• Тестируем 1-2 недели (или пока не соберём статистическую значимость)
• Смотрим результаты и решаем: roll-out, roll-back или итерация

Шаг 6: Итоговая очередь

После приоритизации мой backlog для спринта выглядит так:

1. 1-click checkout (скор 34) - HIGH PRIORITY
2. ML рекомендации (скор 31) - HIGH PRIORITY
3. Быстрая загрузка (скор 27) - MEDIUM PRIORITY
4. Wishlists (скор 22) - BACKLOG
5. Социальное доп-цепка (скор 22) - BACKLOG

Ключевые принципы

Data-driven: все оценки опираю на данные, а не на личное мнение

Регулярное обновление: приоритизирую заново каждый спринт. Ситуация меняется

Вовлечение команды: скор—это начало дискуссии, не финальное решение. Tech lead может сказать "Actually, это 1 неделя, не 3" и скор изменится

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

Этот подход помогает мне быть объективной, объяснить решения заинтересованным сторонам и убедиться, что команда работает на максимум impact.