Web 3.0. Практика

Владимир Попов

«Web 3.0. Практика» – третья книга серии, которая повествует о том, как сделать ДАО, криптостартап или dApp с точки зрения бизнеса. Также на страницах найдёте ответы на самые каверзные вопросы токеномики и других важных аспектов работы децентрализованных сервисов.

Шаг №0. От идеи к реализации

Для себя я давно выделил 4 необходимые стадии любого продукта: MVP, альфа, бета и релиз. Но ещё можно обозначить 5-ю стадию: PoC — Proof-of-Concept. На этой стадии надо не только выдвинуть смелую гипотезу, но умудриться её верифицировать, проверить, как говорится, не отходя от кассы.

И это не так просто, как думают те, кто приходит из классических рынков и проектов. Расскажу, почему…

Проблемы PoC / MVP-стадии

Для начала — понятия. PoC — proof-of-concept, или стадия, когда у вас ещё нет продукта и вы через custom development пытаетесь проверить гипотезу: путём опросов, прямых интервью, неформальных встреч и другими методами.

MVP (minimum viable product_ — версия продукта, собранная быстро, что называется, «на коленке». А теперь, собственно, о проблемах стадии.

Самая большая проблема — деньги. Во-первых, их настолько много на каждом бычьем цикле, что многие просто отказываются в это верить. И всё же цифры — неумолимый судья: криптоинудстрия уже достигала триллионов долларов, и это не предел.

Да чего там: самому не раз приходилось платить за газ десятки и даже сотни долларов (реальные цифры во избежание стресса у читателя писать не буду, т. к. они в разы больше), чтобы просто быть на острие прогресса и попробовать нечто первым. И да, это дорого: сколько бы денег у тебя ни было, если их не ценишь, всегда будет мало.

Из-за обилия денег возникают 4 связанные проблемы.

1. Проекты часто приходят сырыми: так было в хайп первых продуктов, собранных на коленке в 2011—2013 гг., так было в хайп ICO (2013—2017 гг.), так было и в хайп DeFi / NFT в 2021—2022 гг.

2. Многие не обладают нужным опытом и знаниями и проваливаются на элементарных вещах: FTX, 3AC, Celsius, Terra — примеры ровно об этом.

3. Слишком большие деньги развращают даже слаженные команды: не всегда, но часто, и в итоге это приводит к дефициту бюджета и сокращению штата в медвежьем цикле (Coinbase и иже с ними в 2022—2023 гг.)

4. Наконец, деньги получают не самые технологичные, интересные, инновационные, идейные проекты, а самые громкие, что в итоге приводит индустрию к банальному копипасту.

Каждую проблему рассмотрим отдельно. Но сейчас хочу расписать алгоритм — о том, что делать, чтобы не попасть в ловушку «слишком быстрого роста».

Во-первых, многие приходят (ко мне) за советом по токеномике, и первое, на что обращаю внимание: а как распределена ликвидность?

Проект реализует токены (по SAFT, airdrop или иным способом) под ликвидность. И распределение ликвидности для проекта важнее на ранних стадиях, чем распределение токена, который ещё не набрал силу и не оброс нужным функционалом.

Отсюда вывод: пишите не только токеномику IDO, но токеномику всего жизненного цикла проекта, а также уделяйте внимание стандартной unit-экономике, с помощью которой и распределяется ликвидность.

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

• Если у вас будет торгуемый токен, то необходимо выделить на торги ликвидность, и неважно, будет ли это CEX — централизованная биржа (Binance, Coinbase, etc.) — или DEX — децентрализованная (в виде AMM — автоматического маркетмейкера: Uniswap, Pancakeswap, etc.; или классическая — навроде Kyber, Bancor, DyDx) — не так важно. Обычно речь идёт о 10-ти и более процентах ликвидности.

• Многие забывают о том, что криптомаркетинг (о нём тоже расскажу отдельно) — дорогая и непростая вещь. И ликвидность, на него направленная, важна настолько же, насколько и работа с комьюнити, а порой и больше.

• Ликвидность часто нужна и там, где вы не ждали: например, в ряде хакатонов и грантов, при реализации через бутстрэппинг сервисов и во многих других случаях, поэтому на резерв тоже оставить надо процентов 10.

И вот, пусть вы собрали $1 000 000, что для криптоиндустрии — ничто, но дорожите им.

По тезисам выше у вас выходит: 10% +10% +10% — уже 30%. То есть на «зарплаты» себе, разработчикам, биздев-команде и другим у вас всего $700 000. А это даже не миллион. И это — только начало. О том, что ждёт дальше, читайте в главе «Тонкости токеномики», а пока двинемся дальше: проблема ликвидности не единственная на стадии PoC / MVP.

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

Опять же начну с примера: menaskop.ru — обменник, собранный мной за несколько вечеров в 2009 году. Увидел нишу, работая в небольшом агрегаторе платежей, взял учебник по PHP и начал верстать сайт: вышел он неказистым, но в итоге за 8 лет работы обороты превзошли миллион долларов. Если бы подошёл к этому процессу «как надо» (снял бы отдельный офис, нанял разработчиков, продажников, маркетологов и прочих специалистов, сделал бы красивый сайт и т. д.), то потерял бы главное: скорость. И ещё — работал бы всегда в убыток: ведь фича была в том, что маржа моя составляла не более 1%. Плюс к этому на мелких переводах вообще не зарабатывал бы и даже работал в убыток, зато на крупных мог сразу получить большой куш и покрыть все расходы.

Не нравится мой пример? Посмотрите на опыт Snapchat, 1inch и любой другой. Главное, чтобы поняли, что MVP надо делать быстро. Можете за ночь? Сделайте! В любом случае больше, чем 4—6 недель, закладывать не стоит.

В этом смысле помогала всегда, даже когда не был с ней знаком, философия кайдзен: каждый день делай то, что умеешь, чуть лучше. Ещё и ещё лучше. И неважно: суши это, сложный dApp или полёт на самолёте. Главное — вставай рано, действуй уверенно и строй свой храм.

Здесь позволю себе отступление, ибо притчами полнится род человеческий. Слышал её много раз сам, но поразила она меня, когда в интервью Бориса Дьяконова Олегу Тинькову прозвучали такие слова: «Мужчины ворочали большие камни под палящим солнцем. „Что ты делаешь?“ — спросил прохожий у одного из рабочих, который медленно тащил булыжник. „Ты что, не видишь — камни таскаю!“ — зло ответил тот. Тут странник заметил другого рабочего, который волок телегу с большими камнями, и спросил: „Что ты делаешь?“ „Я зарабатываю на еду для своей семьи“, — получил он ответ. Странник подошел к третьему рабочему, который занимался тем же, но работал энергичнее и быстрее. „Что делаешь ты?“ „Я строю храм“, — улыбнулся тот».

Так вот: неважно, что вы делаете, но если в этом нет любви, вы делаете это зря. Это не значит, что вы на этом не сможете заработать. Сможете! Практика доказывает, что ещё как сможете, но пользы это никому не принесёт, а себе вы принесёте только вред. Я категоричен? Возможно, но обозначить позицию, уверен, стоит. А теперь следуем дальше.

Третья проблема — команда. Получив большие деньги, многие команды начинают набирать какое-то безумное количество сотрудников. Но количество редко переходит в качество: вы должны нанимать не просто человека, но специалиста, то есть его компетенции. С другой стороны, недаром сейчас так важны пресловутые soft skills: без команды продукт всегда будет куцым, какое бы количество фрилансеров над ним ни корпело.

И да, вы верно догадались: речь о команде тоже пойдёт ниже, но здесь отмечу два важных аспекта.

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

2. В отличие от биздева и разработки, маркетинг можно отдавать на аутсорс, но тактический и операционный, а не стратегический. Стратегическому лучше поучиться у Роберта Брэнсона, Генри Форда, Евгения Чичваркина, Олега Тинькова и прочих мультипредпринимателей. А делать самому.

А теперь — подсказка.