PMFはトークンの前に来るべきですか？

2022年5月20日 01:23

この記事は「Should Product-Market Fit Come Before Tokens?」を日本語訳したものです。

ブロックチェーン製品は、必ずしもトークン、または製品に固有のトークンを必要としません。トークンは複雑さを増すだけでなく、製品市場適合（PMF）の主要な目標から注意をそらす可能性があります[1]。

これを考えると、質問する価値があります。トークンの導入をPMFが終了するまで延期できますか？答えは：それは依存します。一部のトークンは、製品の中核となる可能性があります。コアではない場合でも、PMFの達成に役立つ可能性があります。このような場合、PMFとトークンを分離することはできません。

全体として、トークンの製品の使用度にはさまざまなものがあります。製品がスペクトルのどこに位置するかは、トークンを導入するタイミングに影響します。この記事では、最初にスペクトルについて説明し、次にトークンを導入する方法について説明します。

製品のトークンの使用に関するスペクトル

使用量が最も少ないものから最も多いものまでの範囲は次のとおりです。

製品はトークンを使用しません。これが最も簡単です。インデックスプロトコルTheGraphは良い例です。トークンがなくても、分散制御、不変性/来歴、高可用性、検閲耐性などの別のブロックチェーンの利点を使用することで、製品は魅力的である可能性があります。または、 TheGraphなどの他のブロックチェーン製品に役立つ可能性があります。（製品がトークンを使用せず、これらのいずれにも当てはまる場合は、データベースを使用してください。）
製品はトークンを使用しますが、独自のトークンを持っていません。分散型取引所ユニスワップは良い例です。トークンダイナミクスがあるため、それらのトークンダイナミクスに関する設計と検証が必要でした。しかし、それは（まだ）新しいトークンを導入していません。
製品はトークンを使用し、独自のトークンを持っていますが、それに依存していません。貸し出しプロトコルCompoundはここでの良い例です。トークン（ガバナンス用のCOMP）がありますが、コア製品の提供（ローン）にとって重要ではありません。Synthetixは、製品のコアに近いトークンを使用します（SNXをミントに賭けます）が、代替手段を提供するため、トークンは必要ありません（ETHをミントに賭けます）。
製品は独自のトークンに依存しています。新しいトークンがないと、プロトコルは機能しません。ビットコイン、イーサリアム、アーウィーブ、MakerDAOが良い例です。これらは通常、設計が最も困難ですが、たとえばインセンティブマシンとして、ブロックチェーンテクノロジーを最も活用するため、最も「暗号ネイティブ」でもあります。

トークンの使用方法のこのスペクトルでは、最初のものが最も簡単でリスクが最も低くなります。（PMFを打つことは簡単ではないので、それでも簡単ではありません。）最後は最も暗号ネイティブですが、最も難しく、最も危険です。

トークンを導入する方法は？

PMFを主要な目標と範囲として考えると、トークンの設計にどのようにアプローチする必要がありますか？制約は次のとおりです。PMFへの到達を妨げるのではなく、トークンが役立つことを確認します。

次に、おそらく機能する可能性のある最も単純なものを構築することを目指します。このセクションでは、スペクトルに照らして、トークンの設計をシンプルに保つ方法について説明します。

シンプルさについて

スティーブ・ジョブズがかつて言ったように、「そこに着くと、山を動かすことができる」ので、シンプルさは努力する価値があります。

しかし、単純なことは難しいです。マークトウェインは私たちに思い出させます：

「私はあなたに短い手紙を書く時間がなかったので、あなたに長い手紙を書きました。」

複雑さはソフトウェア設計の課題です。トークンが複雑さを増すことを考えると、私たちは継続的に単純さを追求しなければなりません。

「入力としての複雑さ。出力としてのシンプルさ」-JackButcher [Image Rishabh Garg ]

トークンのデザインをシンプルに保つための3つの方法は次のとおりです。

トークンへの依存を最小限に抑えます。
簡単に始めましょう。完全なトークンの設計を延期します。
トークンデザインを再利用します。

それぞれをさらに詳しく見ていきましょう。

戦略：トークンへの依存を最小限に抑える

ここでの考え方は次のとおりです。スペクトル（1〜4）で、トークンの必要性を最小限に抑えるようにします。たとえば、（3）の代わりに（2）を実行できますか？

戦略：シンプルに始める

完全なトークン設計を延期します。つまり、トークンの使用を最小限に抑えた設計から始めて、後でトークンの使用をさらに増やします。スペクトルでは、（1）、（2）、または（3）から開始し、（2）、（3）、または（4）に移動します。

トークンには、合理的な評価モデルが必要です。長年にわたって、さまざまなトークンタイプの価値について多くの議論がありました。これが最近の統合です。

注入するのが最も簡単なトークンは、製品が依存しないトークンです。作業トークンはコアになる傾向があるため、挿入するのは簡単ではありません。交換ユニットのユーティリティトークンを挿入することはできますが、実際には付加価値はありません。ただし、割引トークンとガバナンストークンはより柔軟性があり、注入でき、付加価値があります。さらに、彼らは許容できる評価モデルを持っています。

割引トークン。より良い割引を得るために、より多くのトークンを保持します。評価はキャッシュフローに比例します。割引トークンは、同じ評価メカニズムを保持しながら、単なる割引を超えて一般化します。それらは非常に柔軟性があるため、一元化された製品の一部にすることができます。Binanceは、BNB保有者に取引割引を提供します。摂氏の貸し手はより多くのCELを保有することでより多くの利子を獲得し、借り手はより多くのCELを保有することでより少ない利子を支払います。最後に、SynthetixのSNXは、ETHではなくSNXを賭けるとより高い報酬を受け取るため、割引トークンと見なすことができます。
ガバナンストークン。トークンを使用して、プロトコルの変更に投票したり（Aragonなど）、資金調達をガイドしたりします（DASH、decredなど）。ガバナンストークンは製品の中核ではありませんが、製品のエコシステムの中核です。Joel Monegroのおかげで、ガバナンストークンの評価に関する理論ができました。

製品は、初期の段階で迅速な反復が必要です。ガバナンストークンを追加すると、これらのサイクルが遅くなるため、時期尚早に追加しないように注意する必要があります。

1つの戦術は、ガバナンストークンが将来導入されることを伝え、フォロースルーすることです（例：SAFG）。おそらくその間に、トークンは何らかの形のクラブのメンバーシップを許可します。もう1つの方法は、割引トークンに焦点を当てることです。割引トークンは、製品の反復を遅くするリスクが少なく、柔軟性が高くなっています。

トークンを注入する別の方法があります。トークンを使用する補完製品を出荷します。これにより、使用できるトークンのタイプに関する制約が緩和されます。例として、Binance Chainがあります。これは、コアでBNBトークンに依存しています。Binanceチェーンは、BNBを使用した最初のBinance製品の数年後に導入されました。もう1つの例は、ANTトークンを使用する製品を追加したAragonです。

トークンの設計と合理的な評価アプローチが確立されると、チームはトークンを活用して資金を調達したり、顧客獲得を促進したりできます（流動性マイニングなど）。コンパウンドとバランサーは、ガバナンストークンを導入し、それらのトークンを流動性マイニングに使用した最近の例です。

戦略：トークンデザインを再利用する

航空宇宙エンジニアは、ジャンボジェットが空から落下することを望まないため、設計の目新しさを最小限に抑えることを目指しています。ノベルティを導入すると、失敗のリスクが大幅に高まります。ブリッジ、アナログ回路、および（ある程度）トークンベースの製品についても同じことが言えます。

したがって、ここでの考え方は、既存のトークンデザインを再利用することです。新しい設計を行わないだけで、設計を検証する必要性を回避できます。

あなたがこれで逃げることができるならば、それをしてください。DogecoinとLitecoinは素晴らしい例です。それらはビットコインとほぼ同じですが、わずかな外科的変更があります。これらの外科的変化は、特定のコミュニティに価値をもたらしました。

もう1つの例は、DeFi.spaceにあります。ここでは、ガバナンスと流動性マイニングトークンのデザインパターンが急増すると予想されます。

これを不正行為と呼ぶ人もいるかもしれません。こんなに早く何かを成し遂げたのは、ほとんど不公平だと感じるという意味です。それは良いことです！これは、ソフトウェアの「インポート」のようなものです。10倍のソフトウェアエンジニアがより迅速に考えます。100xersはインポートします（そしてそれらが付加価値を与える場所に焦点を合わせます）。

結論

この記事は尋ねました：製品市場の適合はトークンの前に来るべきですか？答えは：それは異なります。製品にトークンが必要な量によって異なります。さまざまな可能性があります。

では、どうすればこれを実行可能にすることができるでしょうか。最優先事項は、製品と市場の適合性です。次に、トークンの設計を可能な限り単純に保つのに役立ちますが、これ以上単純なものではありません。戦略には、トークンへの依存を最小限に抑え、単純に開始し、既存の設計を再利用することが含まれます。幸運と幸せなトークンエンジニアリング！

[1]付録：「製品」と「PMF」について

一部のレビューアは、主要な目標として製品市場適合（PMF）を押し戻し、代わりに「エコシステム適合」、「プロトコル市場適合」などを提案しました。明確なコンセンサスはありませんでした。「製品」の定義にも同様の論争がありました。関連して、Diffusion Digital 2020のこのパネル[ビデオ]の参加者は、それぞれ独自のPMFの定義（3:40マーク）を提供しました。

これが私がそれについてどう思うかです。PMFは依然として重要な目標です。「製品」は、トークンベースの製品では少し異なります。従来のweb2とオープンソースに最も近いものは次のとおりです。

Web2：マルチサイドプラットフォームは製品の一種です。それがPMFにヒットするためには、一度に複数の利害関係者タイプによって「何かが欲しかった」必要があります。
オープンソース：Pieter Hintjensや他の人たちが強調しているように、コミュニティは製品です。

トークンベースの製品は、マルチサイドプラットフォーム製品とオープンソースプロジェクトのアイデアを組み合わせたものです。「製品」を根本的に作り直したり、「PMF」とは違うものを追いかけたりする必要がないので、これは素晴らしいニュースです。

スタートアップ、Web2、およびオープンソースコミュニティには多くの学習があります。これらの定義と目的（製品、PMF）を可能な限り使用することで、私たちは彼らの学習を活用し、ブロックチェーンコミュニティとの対話を容易にします。

謝辞

フィードバックを寄せてくれた次の人々に感謝します：Qiao Wang、Kyle Samani、Bruce Pon、Michael Zargham、Angela Kreitenweis、Sebnem Rusitschka、Cyprien Grau、Jesse Walden、Sarah Vallon、MonicaBotez。