С какой первой сгенерированной проблемой начнешь работать

Методология выбора первой проблемы для работы

Как я выбираю проблему

1. Определение важности для пользователей

В первую очередь я бы выясил:

• Насколько часто пользователи сталкиваются с этой проблемой? (частота)
• Насколько сильно она их раздражает? (интенсивность боли)
• Скольких пользователей она затрагивает? (масштаб)

Если проблема частая, острая и затрагивает большую часть базы, это высокий приоритет.

2. Анализ влияния на бизнес

• Может ли решение этой проблемы увеличить revenue? (более дорогие планы, меньше churn)
• Может ли это снизить затраты на поддержку? (меньше ticket'ов)
• Повысит ли это вероятность рекомендации продукта? (NPS)

3. Сложность решения

Я выбираю проблему, которую:

• Можно решить в разумные сроки (2-4 спринта)
• Не требует полного переписания архитектуры
• Команда может выполнить с достаточным качеством

Даже если проблема очень важна, но требует 6 месяцев разработки, я могу отложить ее.

4. Возможность измерения успеха

Мне нужно выбрать проблему, где я смогу:

• Четко определить метрики успеха ДО разработки
• Провести A/B тест или хотя бы собрать baseline
• Увидеть результаты через 2-4 недели

Практический пример

Предположим, я получил три проблемы:

Проблема A: Юзеры забывают свой пароль (50% обращений в поддержку)

Проблема B: Экспорт данных работает медленно (5 жалоб в месяц)

Проблема C: Интерфейс сложный для новичков (30% users выходят на 3-м шаге)

Я выбрал бы Проблему A:

• Частая (50% обращений)
• Острая (люди не могут использовать продукт)
• Масштабная (все пользователи могут забыть пароль)
• Просто решается (добавить забытый пароль, двухфакторная аутентификация)
• Метрики измеримы (количество обращений в поддержку)

Проблема B хоть и имеет решение, но затрагивает мало людей. Проблема C важна для growth, но требует переделки UX (дольше).

Процесс работы

1. Постановка гипотезы: "Если мы добавим восстановление пароля через SMS/email, количество обращений в поддержку снизится на 30%"

2. Определение метрик:

   • Primary: количество обращений "забыл пароль" в месяц
   • Secondary: время восстановления доступа, удовлетворенность users

3. Дизайн и разработка: создаю PRD, согласовываю с дизайнерами, разработка

4. Запуск и мониторинг: выпускаю фичу, собираю данные 2-3 недели

5. Анализ результатов: была ли гипотеза верной? На сколько процентов снизились обращения?

Почему это подход работает

Так я:

• Решаю проблемы, которые действительно болят пользователей
• Не трачу ресурсы на несущественные улучшения
• Быстро видим результаты и учимся
• Строю доверие в команде (они видят, что PM делает их работу значимой)
• Создаю темп разработки (каждые 2 недели релиз с результатами)

Вывод

Первую проблему я выбираю по формуле: Влияние на пользователей × Влияние на бизнес ÷ Сложность разработки. Это обеспечивает быстрые win'ы, которые мотивируют команду и доказывают ценность Product Management.