Как выбираешь эффективное решение из альтернативных вариантов?

Как выбираешь эффективное решение из альтернативных вариантов

Выбор между альтернативами — это главное, чем занимается PM. Каждый день: "Option A или Option B?". Вот мой систематический подход.

Шаг 1: Определить контекст и ограничения

Перед тем как вообще смотреть на варианты, уточняю:

• Какая проблема мы решаем? (точно, не расплывчато)
• Какие ограничения есть? (время, бюджет, люди, технология)
• Какой результат = успех? (метрика, не "всем понравится")

Пример плохого контекста: Улучшим UX

Пример хорошего контекста: 20% юзеров не до конца заполняют профиль. Причины неясны. Нужно: увеличить completion rate с 70% до 90% за месяц. Ограничения: 1 разработчик, 1 дизайнер на 2 недели. Успех = День 7 retention вырастет на 5%+

Шаг 2: Сформулировать альтернативы чётко

Не просто "А или Б", а конкретные решения:

Для проблемы профилей выше:

Вариант А: Упростить форму

• Убрать 5 не-обязательных полей
• Оставить только имя, фото, описание
• Effort: 3 дня
• Предположение: юзеры бросают из-за complexity

Вариант Б: Пошаговый ввод (wizard)

• День 1: имя + фото
• День 2: дополнить описание
• День 3: добавить социальные сети
• Effort: 7 дней
• Предположение: юзеры заполнят по частям

Вариант В: Сделать необязательным всё

• Только имя (обязательно)
• Остальное = опционально
• Effort: 1 день
• Предположение: хоть что-то лучше чем ничего

Вариант Г: Ничего не делать + аналитика

• Добавить события в аналитику
• Effort: 2 дня
• Предположение: нам неясна реальная проблема

Шаг 3: Собрать оценки по каждому варианту

Матрица оценки:

По матрице: Вариант Г выигрывает (самый низкий риск + много учимся).

Шаг 4: Проверить предположения

Каждый вариант стоит на предположении. Они верны?

Вывод: Вариант Г проверяет наше незнание, это самое важное.

Шаг 5: Выбрать лучший вариант + backup

Primary (основной):

• Вариант Г: 2 дня на аналитику
• Почему: самый безопасный, даст нам факты

Secondary (если Г не даст ответов):

• Вариант В: 1 день на упрощение
• Почему: быстро, низкий риск, может быстро улучшить метрику

Tertiary (если первые два не сработают):

• Вариант А: 3 дня на упрощение формы
• Почему: дольше чем В, но более целенаправленно

Шаг 6: Установить критерии успеха/неудачи

Перед тем как начать, определи:

Вариант Г будет успешным, если за 2 дня узнаем:

• На каком этапе формы юзеры выпадают
• Сколько юзеров вообще пытаются заполнить профиль
• Есть ли pattern: мобильные юзеры выпадают больше?

Если этого не получим, переходим к варианту В

Шаг 7: Быстрая реализация + измерение

Вариант Г: 2 дня

День 1: Добавить события, запустить на 10% пользователей День 2: Проанализировать данные, провести интервью, написать выводы

Результат: Узнали: мобильные юзеры бросают на 50% чаще потому что экран узкий

Вывод: Вариант А был бы неправильным решением!

Шаг 8: Применить научный метод

Для каждого варианта: от гипотезы к тесту

Гипотеза: Если сделать форму мобильной, то completion rate вырастет с 70% до 85%.

Тест:

• A/B тест: 50% юзеров видят старую форму, 50% новую
• Длительность: неделя
• Success metric: completion rate difference больше 5%

Инструменты для выбора решения

Техника 1: Decision Matrix

Оценивают impact, effort, risk, learning по шкале 1-10, затем взвешивают по важности.

Техника 2: Reversible vs Irreversible

• Reversible (можно отменить): выбирай быстрее, можно экспериментировать
• Irreversible (трудно отменить): выбирай медленнее, больше анализа

Примеры reversible: UI изменение, фича с feature flag Примеры irreversible: смена архитектуры БД, выход из маркета

Техника 3: Pre-mortem

Перед выбором: "Давайте представим, что вариант А прошёл неудачно. Почему?"

Это открывает глаза на риски, которые не видны.

Практический пример: API vs SDK

Контекст: Нужно дать разработчикам способ интегрировать наш сервис

Вариант А: REST API

• Effort: 2 недели
• Flexibility: высокая
• Adoption: медленнее
• Maintenance: высокая

Вариант Б: SDK (JavaScript)

• Effort: 3 недели
• Flexibility: средняя
• Adoption: быстрее
• Maintenance: ниже

Анализ:

• Кто нам нужен? 70% запросов от JS разработчиков
• Какой риск больший? Вариант Б может оставить без API для других

Решение: Вариант Б (SDK для JS) + обещание API позже

Почему: 70% целевой аудитории покрыли, быстрее к запуску

Антипаттерны (что НЕ делать)

Не выбирай по интуиции без данных Не пытайся реализовать все варианты сразу Не игнорируй мнение экспертов команды Не забудь про "не выбирать вариант А"-вариант

Заключение

Выбор эффективного решения — это не интуиция и не случайность. Это систематический процесс:

1. Понять контекст
2. Сформулировать альтернативы
3. Собрать оценки
4. Проверить предположения
5. Выбрать лучший + backup план
6. Установить критерии успеха
7. Реализовать и измерить

PM, который так выбирает, — это PM, которому доверяют.