Michael Seibel
この授業は素晴らしいプロダクトの作り方に関する4回にわたる授業のうちの1回目です。ごめんね、ここにいる人達は誰もこの話題の知識がないので（笑）。私の名前はMichaelです。YCのCEOで、みなさんがご存知の通りのYCにするため各期の運営やプログラム作成を手伝っています。ここにいるのはRedditのCEOで共同創業者のSteveと、TwitchのCEOで共同創業者のEmmettです。軽く自己紹介をしてくれますか？
Steve Huffman
今紹介してくれましたが、もう一度。RedditのCEOそして共同創業者のSteveです。コンピューターサイエンスを勉強し、2005年にバージニア大学を卒業しました。Redditに5年間ほどいて、5年間離れていたのですがここ1年半ほど古巣に戻っています。
Emmett Shear
私の名前はEmmettです。2005年にイェール大学のコンピューターサイエンス専攻を卒業しました。卒業後はすぐに初めての会社を創業しました。Google Calendarが存在する前に、Google Calendarの下手なコピーのようなものを作って...
Steve Huffman
Google Calendarにコピーされたんですね。
Emmett Shear
その通り。次にJustin.tvという、最終的にTwitchになった会社を始めました。2006年からはずっとこれに取り組んでいます。
Michael Seibel
二人ともそれぞれ、どれでもいいのでトラッキングしているKPI指標とその大体の数値を教えてくれますか。観客に、なぜお二人が良いプロダクトを作ることにおいてエキスパートなのか理解してもらいたいので。
Steve Huffman
特に良い指標の一つは月間アクティブユーザー数で、先月3億を超えました。
Emmett Shear
すごいね。
Michael Seibel
良い数字ですね。
Emmett Shear
私達が気にする指標の一つは「ユーザー全体の視聴時間を1分で区切った数値」です。つまりTwitchで毎月視聴されている動画が何分ぶんなのかなのですが、今年初めて30億分を突破しました。ワクワクしますね。
Steve Huffman
[不明瞭]
Emmett Shear
いや、月ごとです。
Michael Seibel
うわあ。
Steve Huffman
すごい。
Emmett Shear
ユニークユーザーよりもこっちを見ますね。
Michael Seibel
今日は何をするかというと、この二人に聞く質問を12個ほど用意しています。これを何個聞けるか様子を見て、最後の10分はスタートアップやYCなど皆さんが聞きたいことについて何でも質問できるようにします。私としては主に創業のかなり早期段階に関するアドバイスをお伝えしたいと思っています。
ここにいる二人は現在、みなさんとは全くかけはなれた事をしていますが、創業した頃にして良かった、また悪かった点について話してくれると思います。
まずはYCでの教義の一つ、ユーザーと話す事です。このことは何度か話に出しますがあまり詳細は教えていません。二人がどうやってユーザーと話しているか少し教えてくれますか？やって良かった事や失敗した事など。
顧客との話し方
Steve Huffman
もちろん。今日僕がするアドバイスには二つの観点があります。RedditとHipmunkです。二つは全く似ていない会社だし違う道を歩んで来ました。
この話をする時の最初のアドバイスとして、会社は皆違っていて通れる道も沢山あるという事を覚えていてください。一つの会社でうまくいった事もよそでは使えないでしょう。
Redditではユーザーと話すこと自体がプロダクトの要素でした。組み込まれていたんです。早期段階ではコメントもコミュニティもなかったので、メールを沢山もらっていました。最初の6ヶ月間はメールでユーザーとやりとりしていました。しかしコメント機能を付けた後は、ユーザーと話さない選択肢すらありませんでした。
次に課題になったのは、どのユーザーの話を聞きたいか、また彼らは何を言っていて実際にはどういう意味なのか。言いたかった事と言っている内容が違うという事はよくありますからね。
Hipmunkでは航空券の販売やホテル予約をしていたので全く違いました。ユーザーとつながれる掲示板もなかったのでOlarkというJavaScriptが埋め込まれたチャットを使ったのですが、これが必要不可欠でした。今でも使っています。ユーザーが困ったら私達に助けを求められますし、褒め言葉や苦情も言えます。
RedditのメールでもHipmunkのOlarkでも、怒ったユーザーにちゃんと対応できれば忠誠心の高いユーザーになってくれる事が多いです。感情というものは強いので、不満を持ったユーザーを見つけて良い対応をしたら、忠実なユーザーに変わってくれるでしょう。私達にもこのサイクルの貴重さが分かりました。
Emmett Shear
私が面白いと思うのは、TwitchもJustin.tvも似ているプロダクトですよね？どちらもチャット付きのライブ動画です。Justin.tvでは自分達がユーザーになっていました。テレビ番組を作るためのプロダクトを作り、その後はきちんとユーザーに話す事もありませんでした。なのでもちろん、良いアイデアは全て自分達のためにプロダクトを作っている際に思いついたものでした。
ここで最初に言いたいのは、特にアーリーステージでは自分のためにプロダクトを作る事ができるという事です。本当に自分が使えるものを作る事にも意味があります。絶対に他の人に話を聞きに行く必要があるわけではないです。自分以外の人について知る必要もそのうち出て来ますが、最初の3ヵ月間はただ自分が欲しいという物を作る事だってできます。
でも本当に欲しいものじゃないといけません。自分に嘘をついているのは良くないです。ただかっこいいと思っているものでもなく、自分自身が毎日使いたいと心底から思うものではないといけません。
そこから長い間、ユーザーと話さず自分達でプロダクトを使わず、特に価値のあるものも作らずふらふらしていた時期がありました。Twitchでして良かったと思うのは、面と向かってユーザーと話したことです。以前からアンケートやメールでユーザーの話を聞いていましたが、Skypeを通じて、または直接話す事でより深くユーザーを理解できる事が分かりました。
もう一つ言えるのは、どのユーザーを特に気にかけるのかを決めました。そして配信者、しかもただの配信者ではなく人気を集めている配信者に焦点を当てる事にしました。視聴者が2人しかいないような人ではなく、200人いる人と話したかったのです。そのような人が大事なんだと考え、沢山のTwitch配信者と話して来ました。
もう一つ有益だったのは、現在私達のサービスを使っている人達だけでなく私達がサービスを使って欲しいと思う人達について考えた事でした。Twitchではなく他の配信サービスを使っている人達にも話を聞きに行きました。自分のプロダクトを見て「使えない」と思い他のものを使っているような人は、プロダクトの欠点を知っているので、一番話を聞くべき人たちです。
アーリーステージに最も有益な情報をくれたユーザーには、Justin.tv、Ustream、OWN3D、Youtubeなどを試した上で、私達のプロダクトを選ばないことについての首尾一貫した理由がありました。私達がどこで間違えているか詳細を教えてくれたので、とても貴重でした。
Steve Huffman
思っているよりも細かい問題が多かったりしますしね。
Emmett Shear
特に覚えているのは、大きな問題の一つがTeam LiquidのStarCraftファンサイトに掲載されていなかったという事です。そのせいで配信者を3000人くらい失ったので、Team Liquidにメールして再掲載をお願いしないといけませんでした。小さな問題ですがユーザーには重要なことだったのです。
Steve Huffman
ユーザーの話を聞いていなければ、何年間も会社を経営した後に「こんなくだらない問題、早く直しておけば良かった」と気付くような状況に簡単に陥ります。
MVPの作り方
Michael Seibel
よくMVP、つまり実用最小限（minimum viable products）のプロダクトも話に出ますよね。ここにMVPという用語を聞いた事がある人は何人いますか？
よく私が直面する難題の一つは、みなさんがYCに応募して受かった後、出来の悪いものでもローンチするべきだ、と頭では理解していても実際にやらない事です。結果としてユーザーが減り、YCに入れなくなったりユーザーと話す機会をなくしてしまったりします。
興味深いのは、Justin.tvもRedditも不出来なMVPの良い例だという事です。なので、それぞれの初期プロダクトにどのような機能があったのか、もしくはどのように機能するべきだったのか話してくれますか？
Steve Huffman
はい。私がRedditのコードを書き始めたのは2005年6月3日か4日だと思いますが、6月22日にはローンチしていました。それも私がローンチした訳でもなく、Paul Grahamが私に言いもせず自身のブログにリンクを貼ったのです。そこから始まりました。
結果的にとって良かった事なのですが、実は私達にはRedditのビジョンというものがなく、今後それが私達に沢山の影響を与えていきました。しかしローンチした途端に道が見えて来ました。毎日ユーザーをトラックし、ユーザーや私達にとって何が一番いいか考えてその方向に進んだのです。
おかげでユーザーの忠誠心を築けたので、もしずっと部屋に引きこもったままでローンチをしていなければこれは実現しなかったでしょう。ローンチした後の6ヵ月間は新しい機能を追加し続けましたが、そのうち一日、二日以上もったものは25％ぐらいしかありませんでした。
例えば、カテゴリー化すると良いんじゃないかと思った時期が7月頃にありました。共同創業者のAlexisに徹夜でRedditに投稿されたリンクを全てカテゴリー化させたのですが、翌日の朝にローンチした後「やっぱり効果がない、取り下げよう」と決めました。あの時ローンチせずに11月ぐらいまで待ってからローンチしても、失敗の原因が分からなかったかもしれません。
Amazon は MVP ではなく MRP
Emmett Shear
AmazonにMVPについての良い言い回しがあります。あそこでは目指すものを注目に値する最小限のプロダクト（Minimum remarkable product）と呼んでいて、その方が達成したいことをより良く表現していると思います。
「実用最小限」という表現だと、生きるための最小限のサポートを全て手に入れた生命体のようなものを想像してしまいます。しかしそれは目指しているものではありません。自立して生きていけるものを立ち上げようとしているなら、長い間待ちすぎです。立ち上げる時にはみなさんがその生命を維持させないといけません。
立ち上げる時に、プロダクトに何か一つでも良い点がある事が大切です。世界中で最低でも一人の役に立てるようなものを作るべきであって、早期に立ち上げないとその地点にたどり着いたかさえ分かりません。
例えばDropboxはYCの大成功例の一つですが、データを失わないためのバックアップデータを作っていたためプロダクトを即時ローンチしませんでした。バックアップのソフトを作る際に一番やりたくないのは、急いで作ったプロダクトで顧客のデータを失くしてしまうことですからね。一度失った信用は得られないので。
なのでDropboxの注目最小限のプロダクトは、「ほら、うちではこんなすごいものを作っていますよ」と宣伝するビデオをつくってニュースレターに登録してもらうことでした。Dropboxを説明するビジュアルに説得力があったのでこれは成功しました。
でもJustin.tvではうまくいかなかったでしょう。即時に顧客のところに何かを提供する必要があったし番組も作らなければいけなかったので、ネットに番組を載せるための必要最低限、もしくはそれ以下の事しかしませんでした。ローンチした時はチャンネルも1つだけでした。放送するためには、Mac MiniでParallelsというWindows XPの仮想環境を実行し、放送ソフトウェアの...
Steve Huffman
Adobe何とか？
Emmett Shear
今はAdobeに買収されています。OnFlix? Onlot？思い出せません。とにかくWindowsのシェルスクリプトで自動化し、正しいカメラのインプットを拾い、ダウンしたら再起動させるようにしました。よくダウンしていたんです。お粗末なソフトウェアだったので。
こんな仮装備でも、動画をインターネットに載せられました。これを何千本の動画の規模にする事は不可能でしたが、せめてネットユーザーを一人でも引きつけられる物を作れたことは私達にも意味がありました。これ以前は何も学べていなかったので、重要な一歩となりました。
Steve Huffman
Hipmunkは2010年6月に始まりました。共同創業者に、私達のMVPに関する最後通告を言い渡していました。誰かに損害を与えないためには実際のデータが必要でした。本物のデータが入り、顧客がフライトを買うと私達に収益が入ること。あと3ヶ月でそれが出来たらこの会社を続けるが、それが無理だったら諦めよう、と私は言いました。それが私にとってのMVPでした。もし顧客がお金を払ってくれるなら、それは何か正しいことをしたという事です。
残念ながら3ヶ月以内に達成してしまったので、4、5年間それに取り組むことになってしまいました。自分自身で締め切りや達成したい節目を決めておく事で、正しい方向に向き続けられるでしょう。
何の指標をトラックするべきか
Michael Seibel
もう一つよく聞かれるのは、YCに入れた会社が直面する問題なのですが...私達はよく、何を解析しトラッキングしているのかを聞きます。これもMVPと似ていますね。皆やるべきだと分かっているのに、一番に省略されてしまいます。
早期段階のスタートアップがどのように指標を見て、どのような解析ツールを使うべきか教えてくれますか？一般的にどのようにトラッキングをプロダクト開発に組み込みますか？
Steve Huffman
私には二つの正反対の回答があるので、現実はこの二つの間のどこかにあるでしょう。Redditでは何もしませんでした。何年間もアクセス数も何も測らず、長い間直感に頼って商品開発をしていましたが、うまくいきました。ユーザーが正確には何人いるのか今も分かっていません、それで現在それが頭の痛い問題になっています。
Michael Seibel
ユーザー数が？
Steve Huffman
3億を超えたら、ほら、その後はもうどうでも...
Emmett Shear
私達も、毎月何人のユニークユーザーがサイトを使っているか分からないんです。
Steve Huffman
恐らく2.5億から3.2億の間のどこかでしょう、なんにせよ。Hipmunkでは初期からうまくやっていました。ユーザーから即時のフィードバックをもらえなかったので、そのぶんテストや解析、測定などをしっかり管理していました。これをしなければ会社はこれほど生き延びなかったでしょう。
もしもう一度できるなら、MVPを作る際に省略できたと思う事がたくさんあります。技術や企業としてのあり方に間違いがあっても機能を果たしていなくても、ユーザーは気にしません。でもデータをでっち上げる事はできないので、データがないと苦労します。
いつかは直感に裏切られる日がくるので、実用最小限のデータは何なのか考えておきましょう。見なくてもいいですが、必要となった時に見られるよう記録しておきましょう。
Emmett Shear
この点についてですが、ユーザー行動について過去の情報があると後で役立ちます。「この機能を使う人は何人いるのだろう」と考えても、現在の数字が分かってもそれが増えたのか減ったのかも分かりません。傾向が分からないと、基準値を定めるために3ヶ月から6ヶ月も待たないといけないので大変です。
実はMixpanelをやっているSuhailにこれに関して一番いいアドバイスをもらったんですよ。彼は私達にMixpanelを試せと説得してきました。といってもうまくいかなかったんですが、というのもMixpanelはまだ6ヶ月目のプロダクトで、サイトに入れようと思ったときに使えなかったんです。でも結局あとで私たちも使うようになったんですが。
Steve Huffman
自分のところで使うという結論に到るから、Mixpanelを使うべきだと説得してくれてありがとう。
Emmett Shear
どういたしまして。(笑)
Michael Seibel
今はとても機能が良くなっていますね。
重要な行動を5～7選んで記録する
Emmett Shear
今は、断然いいです。私達も出戻りしました。今でもMixpanelを使っていますよ。Mixpanelだけでは足りないので他のものも使っていますが。
Suhailがくれたアドバイスは、ソフトウェアの種類やMixpanelを使うことよりも... まあMixpanelも良いソフトウェアではありますが...それよりも、重要なユーザー行動を5から7個選んで、それだけを記録すべきだということです。全てを記録する必要はないのです。
みなさんのプロダクトでユーザーがする事のほとんどはどうでもいい事です。実際にできることは5個ぐらいしかありません。
例えばRedditでは、投票、コメント、ストーリーの投稿、ページの読み込みなどになるでしょうか、ほんとにリストにしても長くならない量です。重要なのはこれらであって、他のものは全て無視できます。
私達の場合は、動画を一分見る、チャットメッセージを送る、配信をフォローする、チャンネル登録をする、の4つの行動が、今までには手になかった顧客への大きな洞察をくれました。
Steve Huffman
もし過去に戻って30分間だけ自分にアドバイスをあげるて会社の軌道に大きく影響できるなら、このトピックについてにするでしょうね。
もし私がみなさんくらいの場所にいたら、半日くらい時間をとって出来事を収集し蓄積するための最善の方法について勉強をするでしょう。
Emmett Shear
またもう一つお勧めできるのはサードパーティのサービスを使う事です。
もちろん自分でも記録をしておくべきですよ。いつかサードパーティのサービスでは出来ない事をしたくなった時に、データが第三者の手元にしかなければ厄介になってしまうので。記録はしておくべきですが、初期段階では解析ツールを作る暇はないし、MixpanelやGoogle Analyticsなど何でもいいので使うべきです。今必要なものはもうそこに揃っているんです。いつかもっと複雑なものが必要になるとしても、今はいりません。
大きなデザイン変更と再設計
Michael Seibel
会社の早期段階で顧客と話す時によく発覚する問題は、顧客が必要していると思っていた事と実際に顧客が必要としている事に大きなずれがあったという事です。YCではこれが大体いつも”Big Redesign”（デザインの大きな見直し）というものにつながります。
これは「サイトの全てが間違っているから、顧客を満足させるために最初から全てまたは大きな要素をを作り直さないといけない」という考え方です。これは言うまでもなく...どう表現すれば良いかな...邪魔であまり実りのない行動です。フィードバックをもらって方向性を変えないといけないと気づいた時、この困難にどう立ち向かえば良いのでしょうか。
Steve Huffman
大きな問題ですね。技術についての話なのかプロダクトについてなのか明確にしておく必要があります。前にも言った通り、ユーザーは技術については関心ありません。もし放置してもいい問題なら、後日対応しましょう。プロダクトを再デザインするなら...難しいですね。
顧客が気に入らないようなプロダクトを作るに至った時の考え方を改めなければ、また同じようなプロダクトを作る羽目になるでしょう。私も何回もやり直しを経験しました。Hipmunkではホテルやフライト情報を何回も書き直しましたし、Redditでも技術部分を何回もやり直しました。今もより良い習慣づけやデータ取得のためにUIとUXをやり直しています。
何か新しい知識を得る事は大事ですが、もしその状況に立たされたら、新しいMVPは何なのかも考えます。技術面ではセカンドシステム症候群というものがありますよね。プロダクト面でも一緒で、「ビジョンを考えたから、今までの間違いを全部一斉に直して完璧にしよう」と考えても絶対に成功しません。もう一度今までの行動を繰り返したり一からMVPを作ってやり直せるなら、その方がいい線行けそうな反面、難しいので忍耐力を必要とします。
Emmett Shear
私達もプロダクトを一から作り直すような再設計を何回も行いました。その結果も良かったり悪かったりです。大成功した時もあり、確か3年ほど前にTwitchでモバイルアプリの再設計をしました。前はJustin.tvのアプリをコピーした初期バージョンだったのですが、全く新しいバージョンになりました。立ち上げた時には顧客ごとのエンゲージメントが35、40％上がりました。ここまで大きな変化をもたらす再設計はとても珍しいです。
Steve Huffman
普通そんな数字がでたら、データエラーですね。
問題は一つ一つ解決していくもの
Emmett Shear
そう、普通はエラーだけど今回は違いました。今回は本当に使用率が上昇しました。再設計は大きな変化をもたらす事ができます。私達も、現在のプロダクトでは前に進めないから再設計をしたわけではありません。ナビゲーションのトップレベルに何があるべきなのかの意見をいただいたので、3クリックしないと届かなかったものをトップレベルに持ってきたんです。3タッチと言うべきですね。
大きな再設計をする人のほとんどは、エンジニアやプロダクトマネージャーがよく陥る罠に入ってしまっています。「この8つの問題を解決しないといけないけど、全部一斉に解決した方が簡単だ」と考えてはいけません。一つ一つ解決していくべきです。プロダクトにおかしいところが8つもあるなんて素晴らしいではないですか。そのリストから一つずつ効率的に修正していけば良いのです。
一つの大きな再設計よりも小さな変更をしていく方が速いです。特に早期段階のスタートアップにとって、大きな再設計は会社を方向転換させるようなものなので、基本的にはお勧めしません。
Steve Huffman
プログラマーの一種のサボりとも言えますよね。何をしたらいいか分からないから、大きなプロジェクトを始める。ライブラリは使わない、自分で作れる、って。よくある話です。まったく、ライブラリを使うべきなんだよ。
意思決定の合意のための秘訣
Michael Seibel
少し意思決定の話をしましょう。ユーザーの話は聞いたけれど何を作るか決めていない時、大体いつも共同創業者の間で一致した意見を形成させる必要がありますよね。合意を築くための秘訣はありますか？また大事なのが、反対意見の人に対応する方法は？意見の対立がある中で決断を迫られた時、何をしたら良いですか？
Emmett Shear
まず、最初に言っていたことは大切ですね。私が強く主張したいことです。ユーザーと話した後プロダクトについてのアイデアを考えましょう。ほぼ皆順番を逆にしていて、これはプロダクトの妥当性確認(product validation) と言われてます。
「私のアイデアが妥当か確認するためにユーザーと話そう」という考えかたは、完全に軌道から外れてしまっています。
順番を変えましょう。
アイデアの妥当性を確認するためにユーザーと話すのではなく、ユーザーと話してからプロダクトのアイデアを考えるのです。
プロダクトデザインに意見を出したい人にはこのルールを教えます。彼らもユーザーと話してデータを見るべきです。そうするまでは、プロダクトについて意見を持つ権利さえありません。今までやるべきことをやってきた人にしか意見を出す権利はないのです。アイデアを持つのは良くても、決断できるのは彼らです。
もしもユーザーと話してデータを見た上でまだ何を作れば良いかの意見が合わないなら...これは珍しいですが。ユーザーと話して実際にデータを見れば合意に行き着く事は比較的簡単ですが、意見が合わない場合もあるでしょう。
私は、責任者を一人決めてしまった方が簡単だと気づきました。CEOがいてその人の判断が正しいと皆信頼しているなら、最終的にはその人に判断をしてもらうのです。対立を避けるのではなく、話し合い、議論しましょう。でも最終判断をしてくれる人がいないと、スタートアップにとっては意思決定の時間がかかりすぎてしまいます。
Steve Huffman
私がいつも責任者だからかもしれませんが、あまり意見の対立がない気がします。
Emmett Shear
CEOだからね。
数値が得られるか、優先順位が高いか
Steve Huffman
私の場合は、この二つのどちらかをよく言います。「テストできるなら言い合いはしたくない」と、「これについて驚かされるのも構わない。私は多分正しいが、今日心配すべきことのトップ3には入っていないから、とりあえず様子を見よう」。様子を見られるだけのリソースがあれば良いのですが。
でも、今までのAlexisと私やHipmunkでのAdamと私を見て分かるのは、Emmettと同じように、プロダクトについて大きな意見の相違が稀にしかなかった事です。これは今作るべきか、何を優先するべきかなどタイミングの問題はありましたが、使っている基本的な技術やその目的についてはいつも合意していました。戦略は変わっても、詳細はほぼ感情の問題でした。
もし感情的になるようなら、何か他に構造上おかしい所があるのでしょう。あえて難しい道を選んでいるかも。よくあります。去年Redditで起こった対立の話ですが、モバイルウェブからアプリに移行してもらうような宣伝をしたのですが良い気分がしませんでした。
うまくいきましたし使用者も増えましたが、ユーザーにとっての最善を考えたものではなかったんです。「会社にとっては良くても顧客にとっては良くないかも」という状況になった時によく対立が起こり、機能についてではなく期間の問題、また会社と顧客の優先度についての議論になります。それでも何度も角を突き合わせると、技術や顧客と対立しないような納得できる解決案にいつかたどり着きます。
プロダクトの理想的な開発サイクル
Michael Seibel
二人のプロダクトについての話は聞きたいんですが、その前に話したいトピックが一つ。立ち上げた後に、ユーザーと話してデータを見て、意思決定をし、プロダクトを作ってローンチし、反響を見てプロダクト開発を続けるというサイクルが始まります。
サイクルを作り上げる方法、理想的な周期、避けるべき落とし穴などについて早期段階のスタートアップにできるアドバイスは何ですか？
Steve Huffman
まず最初に一歩離れてみましょう。数字が上がるにつれて感情が高ぶってしまうスタートアップをよく見ますが、それではこの過程を活用できません。成長が問題を覆い隠してしまうし、成長が止まった時に知見が何もありません。また、初期にうまくいかないせいで落ち込み自信をなくしてしまうスタートアップも見られます。
実際は、これらの中間にいるべきです。データが良くても悪くても、とりあえずデータを確認しましょう。実際の過程については、会社によって違いますし規模が上がるにつれて変わってきます。仕事のやり方を決めておきましょう。
明確な目標が欲しければ...私はよく、1年後にどこにいたいか考えて、そこから現地点まで直線を描き、1年間でそこにたどり着くためにはどうしたら良いか仮説を立てます。いつ何をして、その後に何をするか、という風にね。そうすれば一直線ができるはずです。
私は2週間ごとのサイクルが好きです。予定通りに進んでいるか、今していることは正しいか、自分達の仮定は今でも合っているかを毎週確認して、もし違うものがあればやることリストに追加しましょう。アーリーステージのスタートアップなら13日、成長したスタートアップなら9日で直すように伝え、そこから続けましょう。これが私には効果的でした。
Emmett Shear
私が考えるに、ユーザーと話す目的は2週間ごとの軌道修正ではありません。私はTwitchの初期段階にものすごい数のユーザーと話し、ユーザーが必要としているものが何なのかを考えようとしました。
ユーザーに話す理由は他にもあったのですが、実は6ヶ月間彼らと話さなくてもユーザーが必要としているものは分かっていました。それは、利益を上げることです。配信者は利益を上げてより多くの視聴者とつながり、良い社会的評価をもらうことを望んでいたのです。
何をするにしても、配信者がどのくらい良い反応をしてくれるか考えていました。誰と話さなくても、何が必要なのかはわかります。しかし定期的にユーザーと話すことで、サービスで困っている点の詳細が分かるしよそで行われている良いサービスについても知れます。
ユーザーと話す目的はどのような機能を作るべきか教えてもらうためではありません。彼らはそういう事は下手ですし、どんな機能が良いのか分かっていないので。ユーザーと話す目的は彼らを理解するためです。そんなに彼らはコロコロ変わらないので。
私は顧客と密な時間を過ごして長い会話をするのが好きです。その後、作りたいものの大きさにもよりますが、すぐプロダクトを作り始めて指標だけを観察し、次の半年間はユーザーと話さないかも知れません。みんなもっと利益を上げたいんだと分かっているなら、半年間販売率や広告の数を最大限にする事に集中していれば良い結果になると信じて良いでしょう。
難しいのは信念を持って貫くこと
Steve Huffman
実行するのが難しい典型的なアドバイスは、勇気を持って信念を貫く事です。何を作るか決めて、そこから完成するまで半年間かかるかもしれません。Redditではユーザーに公開状態でそれを行うのでユーザーからの批判が多いですが、もう慣れているから大丈夫。しかしプロダクト担当の人達に「このまま突き進め」といつも伝えなければいけません。毎週少しずつ進められば、半年後には達成できます。
同時に真逆のアドバイスとしては、自分の間違いを認識できるようにしましょう。「皆の言う事は間違っている、私が正しい」と言えることも大事ですが、「いや、君が正しかった」と言う日も来るでしょう。自尊心と謙虚さのバランスを保つようにしましょう。私もいつも考えるようにしています。「僕が間違っている？いや、やっぱり向こうが間違ってるな」って。
数字の裏を理解する
Emmett Shear
ユーザーと毎週話す必要は全くありません。でもデータは毎週見ておくべきです。毎日見るのも意味がなく、単なる自己満足にしかならないので不要ですが、週ごとには見るべきです。上がっているか下がっているか見て理由を追求しましょう。
プロダクト設計においての究極の目的は、数字の上下を見てその理由を本当に理解することです。今でも苦労しています。理解したと思った時があっても、経営が複雑になるにつれてまた分からなくなるのです。
それでもいつも、詳細部まで説明できるようにしています。「今週使用率が20％上がった理由は新しい機器をこれだけ増やしたからで、機器の保持率はこれで顧客転換率はこれで、このページのこの機能によって顧客転換率がこれだけ上がったことが計算すると分かるから、使用率が上がった」というようにね。
これができれば怖いもの無しです。とても難しいですが、直感を鍛えずに毎週見ているだけではいつまでもそこにたどり着けません。
とある機能を実装した背景
Michael Seibel
質問タイムにはいるまで5分あるので、それぞれのウェブサイトで現在見られる機能について一つ話してくれますか？良いものでも悪いものでもいいですが一つ選んで、どのようにそれが生まれたか教えてください。
Steve Huffman
沢山あります。お気に入りのものの一つについて話しましょう。これはアーリーステージのRedditの話です。
その頃のRedditには外部リンクしかありませんでした。そのだいたい半年後にコメント機能を付けました。最初のコメントは、「ここがRedditの終わりです」でした。私達が出した全てのプロダクトにこのコメントを最初に付けました。
するとユーザーが面白いことをし始めました。投稿では、リンクにクリックするかコメントを見るためにコメントページにクリックできました。投稿のIDはカウンターしかなく、これがURLに入っていました。
するとユーザーが、自分が投稿するURLのコメントページになるURLを投稿してきたのです。最新の投稿を見てカウンターを一つ増やしそのURLを投稿することで、自身のコメントページにリンクする投稿ができました。すごいと思い、これを「セルフポスト」と名付けました。
ユーザーがこれをするのを見て素晴らしいと思った事を覚えています。自分では思いつかなかったでしょう。たまに間違えて他人のコメントページを投稿している人もいました、面白かったです。
当時のユーザーベースはかなり技術系だったので、リンクを投稿するときにURL部分に”self”と入力すれば自動的に一周してくれるようにしました。これがセルフポストの始まりです。今はこれが全ての投稿の6割を占めます。毎日何百万ほど。ユーザーを観察していなければこの機能を作る事はなかったでしょう。
今こうやって説明できていますが、この機能が存在する前に説明しようとしても何を言ってるか分からなくなったでしょう。ユーザーも最初は理解してくれませんでした。「コメントがこのサイトを滅ぼしている」「リンクさえもない、コメントしかないじゃないか」とね。
私が思うに、一番良いプロダクトのアイデアは、ユーザーがどうせそのうち始めるだろうことをもっと簡単にできるようにしてあげることなんです。先ほど話したように、あえて逆流にむかって泳いでいるか、全部がうまくいっているように感じる方向にいくかの違いですね。これはうまくいっているという感じがありましたし、おかげでサイトが完全に変わりました。
Emmett Shear
私が一番好きな話は、面白い事に広告についてかもしれません。ユーザーには「私達は広告を表示して配信から収入を得たい」とはっきり言われていました。皆が望んでいた事です。
しかし同時にライバルのサイトで皆が本当に嫌がっていたのは、配信に被さって広告が表示されるためにユーザー体験を邪魔されてしまう事でした。この意見をもらって面白いと思いました。皆広告を入れる事を希望していても、同じ人から他所のサービスについて「広告のせいで私の視聴者がイライラしている」と言われることがあるので。
両方の問題を解決することは難題です。プロダクトマネージャーとして、諦めて片方を選ぶ事などできません。私が誇りに思っている解決案はボタンを作る事でした。配信者がそのボタンを押す事で広告を表示できるようにしたのです。
面白い事に、例えばFacebook投稿だと友達に広告を見せるボタンをわざと押そうとなんて思いませんが、収入に関係してくることで皆にボタンを押す動機を与えたのです。配信中のダウンタイムに広告を表示して収入を得る配信者が増えました。この解決案はかしこかったと思います。
これは一般的にプロダクトをデザインする際にとても大切な原則を指していると思います。それは、前提の逆から考えるという事です。広告の問題には長い間悩まされていました。ユーザー体験の邪魔はしたくなかったのですが、自動的に広告を挿入する良い方法が分からなかったので。
それでも配信中に広告を入れる必要がありました。どこに広告を入れるか決めないといけない、と勝手に前提してしまっていたのですが、その前提をなくす事で何をすべきか、より明確になりました。この決断に関しては本当に誇りに思っています。配信者を満足させられたし、ボタンを押せばいいだけなのでね。
Michael Seibel
現在ではそのボタンは毎日何回押されているのですか？
Emmett Shear
良い質問ですね。すぐには数字が分からないのですが、頻繁にクリックされていますよ。「クリックしたら15ドル儲けられるボタン」なので。
しかし同時に、ボタンを押しすぎると視聴者が不満になると言う交換条件も理解しています。それを配信者に操作させる事で、状況に最適な回数を決めてもらう事ができるのです。
Q&A
Michael Seibel
私の質問はこれで終わりです。みなさんとの対話に移りましょう、プロダクトの話でもYCの話でも何でも。どうぞ。
プロダクトマーケットフィットについて
Speaker 4
プロダクトマーケットフィットを発見したのはいつでしょう、ローンチ時を振り返って。これを超えるとユーザーが自分のプロダクトを継続的に使ってくれるようだろうとわかるにはどんなプロセスがありましたか？
Michael Seibel
質問は、プロダクトマーケットフィットがある事がどうやって分かったのか？ですね。
Steve Huffman
Redditでは良かったです。自分の会社やユーザー、経営、プロダクト、よくダウンする理由などについてあまり理解しないまま成長していました。これは良い時の話です。
Hipmunkはなにも努力しない状態のままではユーザーは0人でした。プロダクトマーケットフィットがあったのかもわかりません。Hipmunkを気に入る人もいましたが、ユーザーひとりひとりの確保のために奮闘していました。会社全体で難しい道を通っていたんだと思います。
それに気付いた日を覚えています。なぜHipmunkを使っているのかアンケートを実施しました。当時はプロダクトにかなりの努力を払っていたので良いプロダクトだと思っていましたし、実際にHipmunk上では競争相手に比べてかなり速くフライトを見つけられました。
なのに回答の35％はロゴが良かったから、50％は価格が低かったから、でした。実際は低くなかったのに。会社は5年間続きましたし、十分な値段でに売れてくれました。でも実際ユーザー獲得に本当に大変な労力がかかりました。
Michael Seibel
ちなみに、これはよくある間違いです。YCに応募する会社のほとんどにはプロダクトマーケットフィットがありません。Demo Dayに至ってもまだプロダクトマーケットフィットはありません。プロダクトマーケットフィットを得る前にほとんどの会社はなくなります。
多くの人は経る過程のどこかにプロダクトマーケットフィットがある前提で話をします。エンジェル投資家の資金をもらってオフィスを作り、人を雇ったらプロダクトマーケットフィットが見つかる、とね。
実際にはレアですよ。プロダクトマーケットフィットとは、「圧倒されるほどの需要がプロダクトにある」ということなので。
PMFしたときの特徴は「転がり落ちる岩を追いかける」
Emmett Shear
はい。プロダクトマーケットフィットが見つかった時は明らかです。ある悪いプロダクトがあって、それには欠点が7つ以上、追加しないといけない機能もたくさんあるにも関わらず急激に成長しているという事は、プロダクトマーケットフィットがあるという事です。
プロダクトが爆発的に売れると、規模が大きくなったことに対する調整をしているからプロダクトの欠点には手が回らなくなります。
私はよくスタートアップをシーシュポスの神話に例えます。上り坂で大岩を押し上げ押し上げ押し続けて、山頂までたどり着いた時がプロダクトマーケットフィットです。
仕事は楽にはなりませんが、大きく変わります。
今度は山を転がり落ちる大岩を追いかけないといけないので。岩に追いつこうと全速力で走ることは辛いですが前と全く違う感覚です。前は、SteveがHipmunkについて言っていたように、一歩一歩のために奮闘する必要がありました。今度は必死に追いつかないとこのまま逃げられてしまいます。全く違う気分ですよね。いつか分かります。
Steve Huffman
また面白いのは、いつか落ちる岩に追いついた後、またその岩を押し上げている事に気付いてしまう事です。
Emmett Shear
確かにそうですね、これは不可避なことです。まるで「恋に落ちた時ってどうやって分かるの？」と聞くようなものですね。ただ分かるんです。
Steve Huffman
そう。
Michael Seibel
YC参加企業で起こる大きな問題の一つは、どのようにしてプロダクトマーケットフィットが見つかるまでの取引や経営費、請求書などを最小限に抑えるかです。典型的な間違いは、エンジェル資金や数百万ドルの残高をプロダクトマーケットフィットと勘違いする事です。本当によくあります。他に質問は？
アーリーアダプターの見分け方
Speaker 5
どのように最初のユーザーグループを見分けたら良いですか？
Michael Seibel
最初のユーザーグループの見分け方、ですね
Steve Huffman
Redditでは簡単でした。Alexisや私のような人達です。Emmettがプロダクト設計の時の直感について話していましたね。私達も長い間そうしていました。ユーザーも私達と同じPaul Grahamのブログを読んでいましたし、私のようなプログラマーだったので、非常に簡単でした。
Hipmunkではユーザーの特徴を完全に見間違えていました。この問題を私達が完全に解決できたかもわかりません。並置することにして、私達のようにある程度旅行をしていて自分で旅行に必要なものを予約する技術者の目線で作りました。しかし現実では出張者にアピールしないとお金を稼げない事がわかりました。出張者ぐらいしか年に何回も旅しないので。
しかし出張をするような人はHipmunkやKayakではなく、American ExpressやConcurを使いますよね。これに気付くまでに数年かかりました。「しまった」と思いましたね。
Emmett Shear
スタートアップにも2種類あると思います。一つは、自分達のためにものを作っていて顧客を簡単に特定できるところ。自分のような人達ですね。次にあるのは、第三者のためにものを作り、解析データや問題分析から顧客を特定するところです。
Twitchは解析をする方のスタートアップでした。というのも私はゲーム実況配信を観るのが大好きでしたが私自身は配信者でなかったので。
Justin.tvを見ていると、視聴分数の8割が上位200人の配信者から来ている事がわかりました。「この人達が最重要だから、彼らを失えば全てを失う。あと200人獲得できれば倍に成長できる」と考えました。
このように、解析データから適切なユーザーや顧客を特定できました。自分の会社はこの2種類のどちらなのか知っておくべきです。また覚えておくべきなのは、もし自分が使うために何かを作っているわけではなく、大して大きい会社でもないのであれば、絶対に解析データを使うべきです。会社それぞれによって違いますが。
Steve Huffman
はい。
Emmett Shear
それでも、よく考えておいてください。
Steve Huffman
はい。自分のためでないなら、直感を疑うべきです。
Emmett Shear
そう。
Steve Huffman
絶対に。
Emmett Shear
そう。
Steve Huffman
そしてデータで補足するべき。
Emmett Shear
そう。
Steve Huffman
それかユーザーと話すか。
Michael Seibel
なんと、ちょうど時間ぴったりです。今日来てくれたお二人に感謝を、ありがとうございました。
記事情報
この記事は原著者の許可を得て翻訳・公開するものです。
動画: How to Build a Product I, Michael Seibel, Steve Huffman, Emmett Shear - CS-183F (2017)
トランスクリプト: How to Build a Product I with Michael Seibel, Emmett Shear and Steve Huffman
