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

Рассмотрим пример. Допустим, я владелец продукта в компании, которая создает ПО для крупных сетевых магазинов. Мне очевидно, что мои продукты будут работать на основе большой базы данных в Oracle. Но также я знаю, что иметь дело с разработчиками базы данных – сущее наказание: они рассматривают, как под микроскопом, каждый мой шаг. Порой, чтобы внести самое простое изменение, требуется неделя работы, а то и больше. Это, разумеется, значительно замедляет работу моей команды. Конечно, ребят, работающих с базой данных, можно понять, ведь от этой базы зависит работа всех других приложений и пропустить какие-то проблемы с ней слишком рискованно. У них есть хорошо налаженный процесс оценки и внесения изменений в базу, он просто занимает слишком много времени.

Самая рискованная часть для меня – убедиться, что мы делаем правильный продукт. Поэтому мы и создаем ранние версии ПО, используя простые базы данных, хранящие данные в памяти. Конечно, они не способны масштабироваться, и поэтому мы никогда не смогли бы выпустить ранние версии для широкой аудитории. Но проводимые на начальных стадиях эксперименты с минимально жизнеспособными продуктами (сейчас мы их даже не называем так) позволяют проверить наши идеи на небольшом количестве пользователей, задействуя в то же время реальные данные. После серии итераций с пользователями, найдя решение, которое, по нашему мнению, будет работать, мы вносим изменения в реальную базу данных и отключаем приложение от базы с данными в памяти. Специалистов по базам данных такой способ тоже устраивает, ведь они знают, что мы вносим изменения лишь после того, как убедимся в верности своего решения.