Частые ошибки: разработка MVP
MVP заказывают не ради продукта, а ради ответа на вопрос: пользуются ли этим люди и готовы ли платить. Отсюда главное отличие предложения от обычного КП на разработку — в нём должна быть названа проверяемая гипотеза и то, по каким признакам заказчик поймёт, подтвердилась она или нет. Без этого разговор быстро сворачивает к списку функций, каждая из которых кажется обязательной, и первая версия разрастается до размеров, при которых проверять уже нечего: деньги и время потрачены до первой встречи с пользователем.
Гипотеза не сформулирована. В работу берётся список функций, объём растёт, а после запуска непонятно, по каким признакам считать проверку удавшейся или провальной.
Нет раздела о том, что не делается. На приёмке заказчик перечисляет отсутствующие возможности как недоработки, хотя их исключение обсуждалось устно и осознанно.
Ручные операции заказчика не описаны. Первая версия предполагает, что заявки проверяет человек, но об этом нигде не сказано, и после запуска работа встаёт.
Сбор событий отложен на потом. Продукт запускается без данных о поведении пользователей, и решение о развитии принимается по ощущениям, а не по наблюдениям.
Компромиссы ради скорости не названы. Заказчик считает первую версию основой для масштабирования и воспринимает необходимую переработку как ошибку команды.
Блоки, смета с расчётом и условия уже готовы — останется вписать свои цены. Клиент открывает ссылку в браузере, а вы видите, кто её открыл и докуда дочитал.