Сколько человек должно встретиться с проблемой чтобы начать ее фиксить?

Порог для начала работы над проблемой: метрики и контекст

Формула определения порога

Нет универсального ответа "Нужно встретить X людей". Это зависит от:

1. Размера пользовательской базы

• Если у вас 1000 пользователей, и 50 жалуются — это 5% (довольно много)
• Если у вас 1 миллион пользователей, и 5000 жалуются — это 0.5% (мало)

Процент важнее абсолютного числа.

2. Влияния на revenue и retention

• Если проблема заставляет 10% пользователей уходить = очень срочно
• Если проблема раздражает, но люди остаются = можно подождать

3. Стадии компании

• На ранней стадии (Series A) нужно быстро тестировать: достаточно 10-15 жалоб
• На зрелой стадии (IPO) можно требовать больше данных: 1-2% пользовательской базы

4. Типа проблемы

• Если проблема критическая (баг, который ломает функцию) — нужна 1 жалоба
• Если это улучшение UX (медленный экспорт) — нужно больше данных

Практические пороги

Критические проблемы (срочно исправить)

• Приложение крашится: 1 жалоба достаточно
• Потеря данных: 1 инцидент
• Невозможно использовать ключевую фичу: 5-10 жалоб
• Платящие пользователи в панике: 1 жалоба

Важные проблемы (включить в ближайший спринт)

• 5% пользователей сталкиваются регулярно
• Или: 50+ жалоб в месяц
• Или: 30+ людей в интервью упомянули проблему
• Или: это стоит 2-5% revenue/retention

Интересные улучшения (добавить в бэклог)

• 1-2% пользователей сталкиваются
• Или: 10-20 жалоб в месяц
• Или: 10-15 людей упомянули в интервью
• Или: это может повысить NPS на 0.5 пункта

Мелкие идеи (обсудить, но не спешить)

• Менее 1% пользователей затронуты
• Или: 1-5 жалоб в месяц
• Или: 2-3 люди упомянули

Данные, которые я бы собрал

Прежде чем решить, достаточно ли людей сталкиваются с проблемой:

1. Количественные данные

- Сколько support tickets на эту тему в месяц?
- Какой процент от всех обращений?
- Растет ли число жалоб или стабильно?
- В какой географии / сегменте пользователей острее всего?

2. Качественные данные

- Интервью: сколько людей упомянули спонтанно?
- Жалость пользователя: очень больно или просто раздражает?
- Workaround: люди нашли способ обойти проблему?

3. Анализ impact

- На сколько процентов это влияет на retention?
- Какой процент пользователей отходит из-за этого?
- Какой revenue мы теряем?

Пример из реальной жизни

Сценарий 1: Медленный экспорт PDF

• 12 жалоб в месяц
• 2% пользователей это используют
• Никто не отходит (есть workaround — экспортировать по частям)
• Вывод: добавить в бэклог, но не срочно (нужно 20-30 жалоб)

Сценарий 2: Забыли пароль не работает

• 150 жалоб в месяц
• 15% обращений в support
• 5% людей не может вернуться (они сдаются)
• Это 50K потерянных юзеров
• Вывод: СРОЧНО, начать разработку прямо сейчас

Сценарий 3: Красивый градиент на кнопке

• 0 жалоб
• 3 человека в интервью предложили
• Не влияет на retention
• Вывод: может быть в sprint backlog для "nice to have"

Формула для PM

Приоритет = (% пользователей × боль × влияние на revenue) ÷ сложность

Если числитель большой, даже 5 жалоб достаточно. Если числитель маленький, нужно 100+ жалоб.

Вывод

Нет магического числа. Я бы начал работу над проблемой, если:

1. Критическая проблема: 1 жалоба (особенно от платящего юзера)
2. Важная проблема: 5% пользователей или 20-30 жалоб в месяц
3. Стоит внимания: 1-2% пользователей или 10-15 жалоб

НО главное — это не числа, а контекст: влияет ли это на retention и revenue. PM, которая ждет 1000 жалоб от 0.1% пользователей, — плохой PM. PM, которая реагирует на каждый жалобу 1-2 человек из миллиона, — тоже плохой PM.