Что будешь делать если идей много?

Как приоретизировать когда идей много

Это классическая проблема: вы получаете 50 идей, а реализовать можете только 5. Как выбрать? Я разберу системный подход, который использовал на всех своих проектах.

Золотое правило: раньше ясности, потом приоретизации

Не начинайте ранжировать идеи если вы их не поняли. Потратьте время на то чтобы:

• Понять что на самом деле просят
• Почему это нужно
• Кому это нужно
• Что будет успехом

Это фильтрует 30% идей сразу (выясняется что они дубликаты или невалидные).

Шаг 1: Категоризация

Примерно так я разбиваю идеи:

Вот что просят вернуться пользователей / рост MRR

• Это платят деньги? Учитывайте это.

Удержание / Retention

• Идеи которые помогают пользователям остаться дольше.

Качество / Stability

• Баги, tech debt, performance. Обычно это меньше exciting но важно.

Новые пользователи / Growth

• Идеи для привлечения новых.

Эксперимент

• Что-то совсем новое что мы хотим протестировать.

Эта категоризация показывает баланс: много ли вы делаете на growth vs. retention vs. quality?

Шаг 2: Матрица Impact/Effort

Для каждой идеи я оцениваю:

Impact: низкий, средний, высокий

• Низкий: затронет 1-5% пользователей или даст минимум ROI
• Средний: затронет 5-25% или даст хороший ROI
• Высокий: затронет 25%+ или критичен для стратегии

Effort: низкий, средний, высокий

• Низкий: 1-3 дня работы инженера
• Средний: неделя-две работы
• Высокий: месяц+ или требует архитектурных изменений

Затем я показываю это на 2x2 матрице:

Высокий impact, низкий effort  → ДА СРАЗУ (quick wins)
Высокий impact, высокий effort → планируем на следующий квартал
Низкий impact, низкий effort   → может быть если есть время
Низкий impact, высокий effort  → нет (пустая трата времени)

Обычно 20% идей попадают в "высокий impact, низкий effort". Это должны быть ваш приоритет.

Шаг 3: Alignment с OKR

Если у вас есть цели квартала (OKR), используйте их. Например:

OKR: Увеличить retention на день 7 с 50% до 60%

Тогда все идеи которые помогают этому OKR получают bonus приоритет. Идеи которые help другим OKR могут подождать.

Без OKR вы приоретизируете в пустоте. С OKR у вас есть компас.

Шаг 4: Валидация с данными

Для big impact идей я беру данные:

Сколько пользователей просят это?

• 1 пользователь просит → может быть edge case
• 10 пользователей просят → может быть тренд
• 100 пользователей просят → точно нужно

Сколько пользователей это затронет?

• Может быть 10 просят но это затронет только их, тогда impact низкий

Какой ROI?

• Если это платная фича, сколько она принесет дохода?
• Если это retention фича, на сколько улучшится retention?

Даже rough estimates помогают. "Может быть +10% retention" vs. "может быть +0.5% retention" это huge разница.

Шаг 5: Cross-functional check

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

Инженеры: "Это правда 1 неделя работы или больше?"

Дизайн: "Это требует большого дизайна или маленького?"

Sales/CS: "Наши клиенты это просят или это edge case?"

Маркетинг: "Это помогает нашему messaging или нет?"

Часто выясняется что я неправильно оценил effort. Инженер говорит: "На самом деле это требует переделать БД". Тогда idea опускается в приоритет.

Шаг 6: Мой личный framework

После 10 лет я использую вот это:

1. Обязательные идеи (должны делать)

   • Критичные баги
   • Идеи которые обещали инвесторам/клиентам
   • Идеи которые align с квартальными OKR

2. Быстрые победы (quick wins)

   • Высокий impact, низкий effort
   • Занимают 20-30% спринта

3. Стратегические инвестиции

   • Долгие идеи (3+ недели)
   • Но высокий impact
   • Это 30-40% спринта

4. Tech debt / качество

   • Рефакторинг
   • Performance
   • Bugfixes
   • Это ВСЕГДА 20% спринта (неменьше)

5. Experimentation / новое

   • Может быть 10% спринта
   • Риск который мы берем на неизвестное

Пример из моей практики

В одном стартапе пришло 30 идей на месяц. Я применил framework:

• 3 идеи были обязательные (обещаны клиентам)
• 8 идей были quick wins (например исправить текст, улучшить button размер)
• 5 идей были стратегические (новый раздел в продукте)
• 4 идеи были баги/tech debt
• 10 идей я отложил на next quarter

Время спринта: 40 часов

• 8 hours на обязательные
• 8 hours на quick wins
• 16 hours на стратегические
• 8 hours на tech debt

Это была ясная картина. Команда знала почему я выбрал эти идеи. Нет обиды, все transparent.

Как сказать "нет" идее

Когда я отклоняю идею, я объясняю почему:

Вариант 1: "Это хорошая идея, но она не align с нашим квартальным OKR. Давайте рассмотрим в Q3."

Вариант 2: "Это low impact для количества effort. Если effort упадет, мы вернемся к этому."

Вариант 3: "Это просил один пользователь. Давайте соберем больше evidence что это необходимо."

Главное: всегда объясняйте reasoning. Люди могут не согласиться но они уважают честность.

Красные флаги (когда приоретизация сломана)

Если вы видите это:

1. Roadmap меняется каждую неделю → нет ясных критериев приоретизации
2. Инженеры жалуются на постоянное переключение → too many приоритетов
3. Вы делаете ideas которые никто не просил → нет процесса валидации
4. Все сказано "это очень приоритетное" → слово потеряло смысл

Это сигнал что приоретизация сломана. Нужно переделать.

Финальный совет

Лучше сделать 5 идей очень хорошо чем 50 идей как-то.

Лучше иметь ясный процесс приоретизации который люди не любят но понимают, чем random chaos.

И самое главное: приоретизация это не one-time activity. Это continuous. Каждый спринт вы пересматриваете. Новые данные появляются, рынок меняется, приоритеты меняются. Это OK.