- «Нам нужен MVP за 2 месяца».
- «Что именно вы хотите им проверить?»
- «Поймем, взлетит ли идея».
- «А технология вообще работает?»
- «Пока не знаем. Но экраны уже рисуем».
Я слышу это регулярно. Проблема обычно не в скорости команды, а в том, что одним словом называют три разных шага. У каждого своя задача, свой срок и своя цена ошибки.
Сначала называем самый дорогой риск
Если упростить, у нового продукта почти всегда три зоны тумана:
- технологическая - можно ли собрать решение с нужным качеством
- сценарная - поймет ли человек, как пройти путь до результата
- рыночная - будут ли этим пользоваться и платить
Дальше логика простая: PoC проверяет реализуемость, прототип - сценарий и UX, MVP - спрос, активацию и раннюю экономику.
У нас был B2B SaaS для разбора договоров. Клиент хотел кабинет, роли, историю файлов и оплату. Мы остановили это на первой неделе и собрали узкий тест ядра на Node.js 20 + NestJS, PostgreSQL 16 и LLM API. Точность извлечения полей держалась на 62%. В такой точке полноценный MVP просто сжег бы 2-4 месяца.
Самая дорогая ошибка на старте - проверять не тот риск. Интерфейс не спасает продукт, у которого не тянет ядро.
PoC нужен не всем
PoC имеет смысл, когда есть реальная техническая неопределенность. AI, OCR, RAG, интеграции со старой ERP, жесткие требования по отклику, безопасности, цене запроса - здесь я почти всегда начинаю с короткой проверки.
В прошлом году мы делали поиск по корпоративным документам для юридического отдела. Около 180 тыс. файлов, часть - плохие сканы. Стек был такой: Python 3.12, FastAPI, PostgreSQL 16 + pgvector, OpenSearch 2.15, внешняя OCR-служба. За 3 недели получили цифры: задержка 3.8 сек, top-3 accuracy 78%, цена запроса $0.012. Этого хватило, чтобы сузить первый сценарий до текстовых PDF и не строить лишнее.
Если ценность держится на:
- качестве AI-ответа
- точности поиска
- времени отклика
- стоимости запроса
сначала PoC
Если ценность держится на:
- понятности сценария
- скорости выполнения задачи
сначала прототип
Результат хорошего PoC обычно звучит сухо: работает, не работает или работает в узком диапазоне. Для бизнеса это и есть нужный ответ.
Прототип экономит недели переделок
Когда технология понятна, код часто только мешает. В этот момент нужен прототип - от схемы в FigJam до кликабельного сценария в Figma. Я обычно делю это так:
- черновой прототип (low-fidelity) - схема шагов и логика
- кликабельный прототип (mid-fidelity) - кликабельный сценарий
- детальный прототип (high-fidelity) - визуально почти продукт, но без реальной логики
На проекте в закупках команда настаивала на большом дашборде с графиками и статусами. Мы за 8 дней собрали прототип и провели 6 интервью. Выяснилось, что людям нужен короткий путь «создать заявку за 2 минуты», а аналитика нужна другой роли и позже. Первый релиз после этого сократился примерно на 30%.
Был и обратный опыт. Несколько лет назад мы согласовали красивые экраны для внутреннего HR-сервиса и слишком рано пошли в разработку. На третьем шаге сценарий подачи заявки развалился, потому что порядок согласования был неверный. Потеряли 7 недель на то, что можно было поймать прототипом за несколько дней.
MVP имеет смысл, когда базовые ответы уже есть
MVP - это уже проверка рынка, а не способ разобраться во всем сразу. Если проблема еще плавает, сценарий спорный, а технология не проверена, «сразу MVP» превращается в раннюю большую разработку под другим названием.
Я обычно держу перед командой такую таблицу:
| Главный вопрос | Первый шаг | Обычный срок |
|---|---|---|
| Это вообще можно собрать? | PoC | 1-4 недели |
| Люди поймут сценарий? | Прототип | 1-3 недели |
| Готовы пользоваться и платить? | MVP | 6-12 недель |
Когда вы уже дошли до MVP, смотрите на активацию, возврат и конверсию в PostHog, Mixpanel или Amplitude. Один работающий сценарий почти всегда ценнее десяти полумертвых разделов.
Как не перепутать шаг на ближайшем созвоне
Перед стартом я прошу команду письменно ответить на один вопрос: какая ошибка сейчас дороже всего в рублях и неделях. Если ответа нет, проект почти наверняка стартует раньше времени.
В ближайшие 6-12 месяцев это станет еще заметнее в AI-продуктах. Команды, которые начнут с узкого PoC на один сценарий, будут выходить в рынок быстрее тех, кто снова перепутает проверку спроса с разработкой интерфейса. Самый полезный экран в начале проекта - таблица рисков, а не главная страница будущего сервиса.
