Сразу ли отдается в разработку придуманный большой проект

Ответ

Нет, определённо нет. Отправить большой проект сразу в разработку — это один из самых частых способов потратить месяцы работы на что-то, что никому не нужно. У меня есть тройной фильтр перед тем, как идея попадает в спринт разработки.

Почему опасно отдавать идею сразу в разработку

Истории ошибок из моего опыта:

На финтех платформе я был очень уверен в идее Персональные инвестиционные портфели — автоматический подбор портфеля на основе профиля риска юзера. Казалось очевидным решением для новичков. Отправил в разработку, инженеры работали 6 недель.

Результат: функция была готова, но юзеры просто её не использовали. Оказалось, что люди хотели выбирать акции сами (даже если делали ошибки), потому что это была часть игры для них. Потраченные 6 недель инженерных часов в пустую.

Мой трёхуровневый фильтр

Уровень 1: Discovery & Validation (1-2 недели)

Когда у меня есть гипотеза, я начинаю с небольших исследований:

• Провожу 5-10 интервью с целевыми пользователями (не более 20 мин каждое)
• Спрашиваю: Есть ли у вас эта проблема? Как вы её решаете сейчас?
• Ищу pattern: решают ли 7+ из 10 людей эту проблему одинаково

На HR SaaS я предположил, что компаниям нужна система анализа зарплат конкурентов. Провел интервью с 8 HR-директорами. Выяснил:

• 2 не волновалась о зарплатах конкурентов вообще
• 3 уже используют Glassdoor и Payscale
• 2 сказали что это было бы полезно, но не платили бы за отдельный инструмент
• 1 сказала: Да, дорого!

Вывод: нет product-market fit для отдельного инструмента.

Уровень 2: Concept Validation (2-3 недели)

Если интервью показали что проблема реальная, я перехожу на следующий уровень:

• Рисую низкоуровневый wireframe (5-10 экранов)
• Показываю его юзерам и смотрю их реакцию
• Тестирую ключевые assumptions с прототипом/mockup

На маркетплейсе электроники я предположил что нужна функция сравнить цены у разных продавцов. Создал figma prototype с 3 экранами. Показал 5 пользователям.

Результат:

• Все сразу поняли как это работает (хороший дизайн)
• 4 из 5 сказали да, пригодилось бы
• 1 сказал мне нужна история цен на месяцы, чтобы понять тренд

Вывод: идея работает, но нужно добавить ещё функционал.

Уровень 3: Proof-of-Concept с реальными пользователями (2-4 недели)

Только после двух фильтров, я создаю MVP и даю его группе бета-пользователей:

• MVP — это самая простая версия (может быть с чёрным экраном и кнопками, не красивое, но работающее)
• Даю 50-100 активным пользователям на 2 недели
• Смотрю на Usage: кто открывает, как часто, какие пути они проходят
• Собираю qualitative feedback

На консьюмер-приложении для здоровья я хотел добавить Challenges — соревнования между друзьями. Создал MVP за 1 неделю.

Результаты на 100 бета-пользователях:

• Adoption: только 12% открыли feature хотя бы раз
• Из тех 12%: средняя сессия была 3 минуты
• Feedback: Интересно, но скучно без вознаграждений

Вывод: идея не работает в текущем виде. Нужно добавить систему вознаграждений и лучше онбордить людей.

Я переделал MVP, добавив:

• На-борд с 30-секундным видео
• Система очков и бейджей
• Weekly leaderboard

На втором раунде:

• Adoption выросла до 35%
• Среднее время: 12 минут
• DAU (daily active users в feature): 8% от DAU приложения

Только потом я сказал инженерам: OK, давайте разработаем это как полноценную фичу.

Когда идея идёт прямо в разработку

Есть случаи, когда можно пропустить несколько фильтров:

1. Если это fix известной проблемы

• У нас есть данные что 30% пользователей complain про X
• Мы знаем что решение Y поможет
• Можно идти прямо в разработку

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

2. Если это competitive feature

• Конкурент выпустил X, и мы теряем юзеров
• Это прямое copy-paste от конкурента
• Можно идти в разработку

Пример: конкурент запустил dark mode, мы потеряли 5% юзеров которые жаловались. Мы добавили dark mode за 3 недели.

3. Если идея от крупного клиента (B2B)

• Крупный клиент говорит: У нас есть проблема X, если вы добавите Y, мы подпишемся на $50K/год
• Это деньги на столе, можно идти в разработку

Структура процесса

Большой проект (месяцы разработки):

1. Discovery интервью (1-2 недели)
2. Wireframe и concept validation (2-3 недели)
3. MVP и beta-testing (2-4 недели)
4. Анализ результатов (1 неделя)
5. Итерация на основе feedback (1-2 недели)
6. OK, отправляем на разработку (6+ недель)

Итого: 13-16 недель перед full development

Средний проект (2-4 недели разработки):

1. Интервью пользователей (1 неделя)
2. Wireframe (3-4 дня)
3. Прямо в разработку

Маленький проект (несколько дней разработки):

1. Обсуждение в команде (1 встреча)
2. Прямо в разработку

Ключевой урок

Мне нужно было потерять месяцы разработки на идеи, которые не сработали, чтобы понять: It's cheaper to validate early than to build and fail.

Инженеры видят это как waste — мы пишем код, потом его удаляем. Но это не waste, это инвестиция в то чтобы не потратить 6 месяцев на неправильное направление.