Урок 4 · Проверить идею, не потратив денег

Квадратное уродство: как продать прототип до готовности

Глава 3 из 6 · 5 мин чтения

Дальше: MVP без иллюзий: как проверить экономику до написания кода

Расчёты, налоги и право здесь по Казахстану. Фундамент, Фаундер и Инвестор от страны не зависят.

Май 2009 года. Маркус Перссон, программист из Стокгольма, выкладывает на профильном форуме сырую игру из квадратных блоков, которую писал по вечерам после работы. Графика выглядит как ошибка рендера. Через месяц он начнёт брать за неё деньги.

Главный враг начинающего Архитектора это перфекционизм. Даже после честных разговоров с клиентами, как в прошлой главе, голос в голове шепчет: «Это ещё не готово. Архитектура кривая. Если я покажу это рынку сейчас, они засмеют». Венчурные инвесторы в ответ любят цитировать сооснователя LinkedIn Рейда Хоффмана: «Если вам не стыдно за первую версию вашего продукта, вы запустились слишком поздно».

Обе позиции опасные крайности, если применять их вслепую. Грань между гениальным MVP (Minimum Viable Product — самая простая версия, на которой проверяют главную гипотезу спроса; у Перссона её уже можно было продать) и бракованным мусором видна на кейсе самой продаваемой игры в истории, Minecraft. И смотреть на него будем не как на сказку о программисте-одиночке, а как на жёсткую модель раннего денежного потока (Cash Flow).

Миф о бедном гении и квадратном уродстве

Инфобизнесмены продают историю Minecraft так: «Бедный парень не умел рисовать, сделал игру из кривых квадратов, бесплатно выложил в интернет и продал её Microsoft за $2,5 миллиарда».

Архитектор должен смотреть на факты:

Запас прочности

Маркус «Нотч» Перссон не был случайным человеком с улицы. К маю 2009 года за его плечами были годы работы программистом в игровых компаниях (в том числе King.com) и стабильная зарплата. Он не рисковал жизнью: доход покрывал его расходы и позволял тестировать гипотезы без паники.

Дизайн через ограничение

Воксельная (квадратная) графика была не следствием неумения рисовать. Это было архитектурное решение. В игре про тотальное разрушение и строительство мира блоки — это идеальная, понятная пользователю геометрия. Графика подчинялась функции.

Проверка спроса деньгами

Самая большая ошибка при анализе Minecraft — это вера в то, что Нотч выложил игру бесплатно и «ждал популярности».

Через месяц после первого релиза сырого прототипа Перссон запускает продажу альфа-версии, за деньги, за лагающий и недоделанный продукт.

Правило Архитектора: платный MVP Бесплатный пользователь — это лид. Платящий пользователь — это факт. Нотч не собирал лайки. Он собирал ранний денежный поток. Оплата за сырой, лагающий прототип была самой жёсткой валидацией рынка.

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

К моменту официального релиза версии 1.0, то есть до того, как игра была официально «закончена», Нотч уже продал миллионы копий. Он профинансировал всю разработку за счёт самих клиентов.

Сообщество вместо отдела разработки

Второй сильный ход Перссона: он развивал Minecraft не в одиночку. Он построил разработку, которую направляет само сообщество фанатов. Нотч часто выпускал обновления и маниакально читал форумы. Главные механики он задумал сам, но многие идеи и порядок работы подсказывали фанаты.

По сути, он превратил миллионы своих платящих клиентов в бесплатный отдел исследований и тестирования. Ему не нужно было угадывать тренды — рынок сам говорил ему, какой код писать на следующей неделе.

Май 2009

Первый релиз сырого прототипа на профильном форуме.

Июнь 2009

Старт продажи альфа-версии за ~10 €. Начало раннего денежного потока.

Ноябрь 2011

Релиз версии 1.0 — уже продано более 4 млн копий.

2014

Сделка с Microsoft за $2,5 млрд, более 50 млн проданных копий.

К моменту сделки с Microsoft Minecraft был не инди-поделкой, а глобальной империей.

Адаптация правила MVP: цифра против офлайна

Цитата «выпускай, пока стыдно» работает прежде всего в цифровой среде (Software), где интерфейс и второстепенные функции дёшево переделать: баг в кнопке можно исправить патчем за один день. Клиент готов терпеть «квадраты» в Dropbox, раннем Instagram или Minecraft ради уникальной функции. Но патч исправляет код, а не последствия: потерянный платёж или утёкшие данные клиента обратно не вернёшь. Стыдной может быть обёртка, а сохранность денег и данных и надёжность главной операции обязательны и в цифровом MVP.

Если ты перенесёшь это правило на реальный сектор экономики (производство, услуги, офлайн), ты уничтожишь бизнес в первый день.

Ресторан как MVP

Если твой MVP — это ресторан, где подают прокисшее мясо, ты получишь не обратную связь, а суд и санитарную инспекцию.

Логистика как MVP

Если твой MVP — это логистическая компания, теряющая грузы, к тебе никто не вернётся.

В реальном секторе MVP — это минимальный масштаб, но максимальное качество в узком сегменте. Это не «плохо написанный курс», а один идеальный вебинар вместо годовой программы. Не сеть из 10 сырых кофеен, а одна тележка с идеальным эспрессо.

Реальный кейс Проверка спросом на ярмарке Разобрать кейс

Выводы главы

Что вынести

1Бесплатный тест не доказывает бизнес-модель. MVP становится бизнесом только в тот момент, когда незнакомый человек отдаёт тебе свои деньги за твоё решение. Нотч валидировал гипотезу чеками за альфа-версию.

2Преврати клиентов в отдел разработки. Если ты строишь цифровой продукт, не пили его в гараже 2 года. Выкати работающее ядро на рынок и позволь сообществу диктовать тебе вектор развития. Это резко снижает риск сделать то, что никому не нужно.

3Разделяй цифру и офлайн. «Стыдный MVP» допустим в IT, где ошибку в интерфейсе исправляют за день, но только в обёртке и мелочах: деньги, данные и главная функция должны работать надёжно с первого дня. В реальном бизнесе с капитальными затратами (CAPEX) и физическим сервисом качество базовой услуги должно быть бескомпромиссным с первого клиента.

Резюме и переход

Прототип продан. В следующей главе проверим на нём экономику: как понять, сходится ли сделка, до того как написана первая строка кода.

Глава была полезной?

НазадКак заставить клиента сказать правду до первой строки кода ДальшеMVP без иллюзий: как проверить экономику до написания кода