Как определить состав MVP и не строить лишнее

Начните с аудитории, ситуации и предполагаемой пользы. Например: сотрудники смогут оформлять повторяющийся запрос без переписки, если получат понятный самостоятельный маршрут. Это проверяемее, чем желание «сделать платформу для всех».

Уточните, какие наблюдения подтвердят или опровергнут предположение. Договоритесь о способе измерения и о том, какие внешние факторы могут повлиять на результат.

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

Разделите обязательное, полезное позже и намеренно исключённое. Для спорной функции спросите: без неё нельзя проверить гипотезу или она лишь делает будущий продукт привлекательнее?

В начале некоторые операции можно выполнять вручную: проверять заявку, готовить отчёт или подключать клиента. Это позволяет проверить спрос до автоматизации. Но нужны ответственный, доступное время и понятный предел нагрузки.

Не обещайте пользователю мгновенное автоматическое действие, если за ним стоит ручной процесс. Интерфейс должен честно показывать ожидаемый результат и способ продолжить работу.

После запуска возможны несколько исходов: развивать сценарий, изменить предложение, устранить конкретное препятствие или остановиться. Список пожеланий пользователей важен, но не заменяет проверку исходной гипотезы.

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