Как принимал решение какую фичу делать?

Как принимал решение какую фичу делать

Решение о том какую фичу разрабатывать — это одна из главных ответственностей PM. Это не личное мнение, это структурированный процесс на основе данных, стратегии и рисков. Я расскажу как я это делаю.

1. Где берутся идеи фич

Прежде всего, откуда вообще идеи:

Источник 1: Пользователи

• Support tickets: люди просят что-то в письмах
• Feature request форма: есть встроенная возможность предложить фичу
• User interviews: я провожу 1 раз в неделю минимум
• Analytics: вижу что люди пытаются делать, но не могут
• Reviews и комментарии в App Store

Примеры:

• Support: "20 писем/месяц просят экспорт в CSV"
• Interviews: "Я вынужден пользовать другой инструмент чтобы это делать"
• Analytics: "40% юзеров нажимают на пустую кнопку"

Источник 2: Конкуренты

• Что делают они, а мы нет?
• Это не значит копировать, но нужно отслеживать
• Может быть, они нашли solution к популярной проблеме

Примеры:

• Figma запустила "Auto Layout" → это важно, может быть нам нужно?
• Notion запустила "AI assistant" → тренд, может быть для нас?

Источник 3: Тренды и рынок

• Новые технологии (AI, WebGL, blockchain)
• Изменение поведения пользователей (remote work → collaboration features)
• Новые платформы (Apple Vision Pro → нужны VR фичи?)

Источник 4: Наши данные и метрики

• Где больше всего drop-off в funnel?
• Где люди теряют время?
• Что correlates с churn?

Примеры:

• 50% юзеров бросают на stage "создание проекта" → фича улучшить этот процесс
• Люди что используют feature X + Y вместе → может быть интегрировать?

Источник 5: CEO и бизнес

• Стратегия: "Мы хотим быть лучше в collaboration"
• Partner запросы: "Нам нужна интеграция с Slack"
• Investor feedback: "Конкурент X растёт быстрее, нужна эта фича"

2.框架 для оценки фич

У меня есть структурированный процесс для оценки каждой идеи. Я использую несколько框架:

Framework 1: Impact vs Effort (быстрая оценка)

Для каждой фичи я спрашиваю:

• Impact: Как много людей это затронет? Настолько ли сильно? (1-10 scale)
• Effort: Сколько времени на разработку? (days estimate)
• Score: Impact / Effort = приоритет

Фичи для оценки:

Фича А: Экспорт в PDF
- Impact: 7/10 (40% просят, экономит 5 мин/месяц)
- Effort: 3 дня
- Score: 2.3 (высокий)

Фича B: Интеграция Slack
- Impact: 4/10 (15% просят)
- Effort: 30 дней
- Score: 0.13 (низкий)

Фича C: Массовое редактирование
- Impact: 6/10 (25% нужна, экономит 2 часа/неделю для них)
- Effort: 10 дней
- Score: 0.6 (средний)

Приоритет: А (2.3) > C (0.6) > B (0.13)

Framework 2: Strategic Alignment (стратегия)

Даже если фича имеет высокий score, я проверяю: соответствует ли она стратегии?

Наша стратегия на год:

• O1: Удвоить DAU
• O2: Улучшить retention (особенно новых юзеров)
• O3: Расширить в enterprise (B2B2B)

Для каждой фичи я спрашиваю:

• Какой OKR она поддерживает? (1 = прямо, 0.5 = косвенно, 0 = не поддерживает)
• Есть ли конкурентный риск? (если не сделаем, потеряем к конкуренту?)
• Есть ли network effect? (каждый юзер привлекает больше юзеров?)

Оценка alignment:

Фича А: Экспорт в PDF
- OKR support: O2 (retention) = 0.5 (слабо)
- Конкурентный риск: низкий (все это делают)
- Network effect: нет
Alignment score: низкий

Фича B: Интеграция Slack
- OKR support: O2 (retention) = 0.8 (люди больше времени в нашем приложении если integrated)
- OKR support: O3 (enterprise) = 1.0 (enterprise хочет Slack)
- Конкурентный риск: высокий (конкурент уже имеет)
- Network effect: да (если друг использует, тоже захочет)
Alignment score: высокий

Framework 3: Financial Impact (ROI)

Для каждой фичи я пытаюсь посчитать ROI:

Формула: (Revenue increase + Cost savings) / Development Cost

Фича А: Экспорт в PDF
- Revenue increase: $0 (это feature, не платная)
- Cost savings: $5K/месяц (меньше support)
- Development cost: $10K (3 дня инженера + дизайнер)
- ROI: $5K / $10K = 0.5x (нужно 2 месяца чтобы окупилось)

Фича B: Интеграция Slack
- Revenue increase: +$50K/месяц (enterprise клиенты платят больше)
- Cost savings: $0
- Development cost: $100K (30 дней инженера)
- ROI: $50K / $100K = 0.5x месячно (окупается за 2 месяца, потом +$50K/месяц)

Фича C: Массовое редактирование
- Revenue increase: $0
- Cost savings: $2K/месяц (меньше support + меньше churn)
- Development cost: $30K
- ROI: $2K / $30K = 0.067x (окупается за 15 месяцев, marginal)

Framework 4: User research (validation)

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

Методы:

1. Интервью с potential users (5-10 человек)

   • "Если бы была фича X, ты бы её использовал?"
   • "Как часто тебе это нужна?"
   • "Готов ли ты платить за это?"

2. Prototype test (если сложная фича)

   • Делаю wireframe или clickable prototype
   • Юзеры тестируют и дают feedback
   • Выясняю: нужна ли эта фича так как я думаю?

3. Landing page test (для платных фич)

   • Делаю landing page с описанием фичи
   • Гоню на неё трафик
   • Смотрю: какой % кликают "купить"?

Результаты:

Фича А: Экспорт в PDF
- Интервью: 7 из 10 сказали "да, это полезно"
- Но: "не готов платить, это должно быть в базе"
Вывод: фича нужна, но как value-add не как новое

Фича B: Интеграция Slack
- Интервью: 9 из 10 enterprise клиентов сказали "если это сделаете, подпишемся"
- Специально просили: все team notifications в Slack
Вывод: фича имеет продажное значение

3. Процесс принятия решения

Шаг 1: Сбор идей (Continuous)

• Я веду backlog всех идей в Notion
• Каждую неделю добавляю 3-5 новых идей из разных источников
• Уже исходящие идеи обновляю по data

Шаг 2: Быстрая фильтрация (Impact/Effort)

• Раз в месяц смотрю на все идеи
• Убираю obvious bad ideas (очень высокий effort, низкий impact)
• Остаток = candidates для детальной оценки

Шаг 3: Детальная оценка (2-3 недели)

• Беру top 10 candidates
• Для каждого: user research, ROI анализ, alignment check
• Документирую всё в specs

Шаг 4: Presentation к stakeholders (1 неделя)

• Делаю presentation для CEO, Lead Engineer, Design lead
• Показываю: impact, effort, ROI, user feedback, strategic alignment
• Обсуждаем trade-offs

Шаг 5: Final Decision (1-2 дня)

• На основе discussion, выбираем 1-2 фичи для следующего квартала
• Документирую решение и reasoning
• Коммуникирую команде

4. Типичная дискуссия со stakeholders

Сценарий: нужно выбрать между фичей А (экспорт) и B (Slack интеграция)

CEO: "Какая даст больше рост?"

Я: "Экспорт нужен 40% юзеров, но не привлекает новых (не платная). Slack интеграция нужна 15% (enterprise), но даёт +$50K/месяц revenue и привлекает enterprise клиентов.

Если рост = главный OKR, Slack better. Но экспорт быстрее (3 дня vs 30), может быть сделать оба?

Lead Engineer: "30 дней это很多. У нас есть технический долг."

Я: "Понимаю. Вариант 1: делаем MVP Slack (15 дней) и потом расширяем. Вариант 2: откладываем на q3. Какой лучше?"

Design lead: "Если делаем Slack, нужны новые UI компоненты. Это + 5 дней. Но экспорт это 1 день дизайна."

Я: "Спасибо за информацию. Лучше знать costs перед решением. В таком случае, экспорт: 3 дня dev + 1 день design = 4 дня effort. Slack MVP: 15 дней dev + 5 дней design = 20 дней.

Моё предложение: делаем экспорт в этом спринте (4 дня работы), потом Slack MVP в следующем спринте (20 дней). Оба нужны.

Все согласны.

5. Как я разоблачаю плохие идеи

Плохая идея #1: "Это сделал конкурент, нам нужна"

• Нет данных что юзеры её просят
• Нет ROI анализа
• Это просто FOMO
• Я говорю: "Дай мне 1 неделю провести user research. Если люди просят, делаем"

**Плохая идея #2: "Мне нравится эта фича"

• Это мнение одного человека
• Я говорю: "Давай проверим. Сколько юзеров просят? Какой будет impact?"

**Плохая идея #3: "Это улучшит metrics" (без доказательств)

• Я требую: user research или A/B test на similar фичу
• Иначе это gambling

6. Реальный пример из практики

Контекст: B2B SaaS для управления проектами. Есть 50K юзеров.

3 фичи для выбора на квартал:

Решение:

• Спринт 1: Экспорт в Excel (4 дня, fast win)
• Спринт 1-2: Slack интеграция MVP (20 дней, strategic)
• Спринт 3: Automation rules (улучшить platform, потом можно монетизировать)

7. Ошибки которые я делал (и теперь избегаю)

Ошибка 1: Слушал CEO больше чем юзеров

• CEO хотел фичу, я делал, 3% используют
• Теперь: ВСЕГДА user research перед решением

Ошибка 2: Недооценивал усилие

• Думал 5 дней, оказалось 30
• Теперь: спрашиваю engineer estimate, добавляю буфер 30%

Ошибка 3: Делал фичу без плана как её монетизировать

• Выпустили cool feature, но revenue $0
• Теперь: для каждой фичи есть clear monetization plan

Ошибка 4: Не заканчивал фичу (делал MVP и забывал)

• MVP имел NPS 5/10 ("не сделано")
• Потом юзеры ненавидели
• Теперь: план для полировки включен в original estimate

Ключевые выводы

Я принимаю решение какую фичу делать через:

1. Impact/Effort анализ — быстрая фильтрация
2. Strategic alignment — соответствие целям года
3. Financial ROI — экономическое обоснование
4. User research — валидация с людьми
5. Stakeholder discussion — с инженерами и дизайном
6. Final decision — документирую reasoning

Это не мнение, это процесс. Спорить можно, но должны быть данные и логика, не gut feeling.