Y コンビネーター

シードのアクセレータープログラム

プロダクトの作り方(1):マイケル・サイベル、エメット・シアー、スチーブ・ハッフマン Part 2

7:55 ~

<スティーブ>
そして、その具体的な問題、というのは本当に小さなものだったりするのです。

<エメット>
そうそう。私たちの抱えていた最も大きな問題の一つは、Team Liquid StarCraft (StarCraftというゲームのプロゲーマーファンサイト)にTwitchの名前がなかったことです。そのせいで3,000人ほどの配信者を失いました。ファンサイトにTwitchを載せてもらうようメールでお願いしていました。小さな問題のように思われると思いますが、ユーザーにとっては重要なことだったのです。

<スティーブ>
ユーザーと話してみないと、簡単な問題に何年も遅れて気がつくこともあります。

<マイケル>
ところで、MVP(実用最小限の製品)について話す人は多いと思います。実際、みなさんの中でMVPという用語を聞いたことがある人はどれだけいますか?

YCの抱えている問題の一つは、あなたたちのような人がYCに入ったときに、未完成品を発表すべきであると知っていても、そうしないことです。その結果、ユーザーが動きが小さくなります。そのため、YCに入れなかったり、ユーザーと話せなかったりするのです。

なので、Justin TVやRedditは未完成のMVPとして良い例であると思っています。少し、お二人の製品が最初はどのような機能をしていたのか、いや、むしろギリギリで機能していたのか教えてくれますか?

<スティーブ>
そうですね、私が最初にRedditのコードを書いたのは2005年の6月3日か4日だったと思います。そして、6月の22日に発表しました。しかし、別に私が発表したわけではありません。

ポール・グラハムが私に相談もせずに彼のブログに載せてしまったのです。

(笑い)

その時までの私たちには良くも悪くもRedditの今後へのビジョンがありませんでした。しかし、発表されたときから、とりあえず毎日ユーザーの行動をみて、ユーザーのためになにができるのか考えることで、道が見えてきました。ユーザーのためののものをひたすら作っていったら、ロイヤリティの高いユーザーが増えました。発表をせずにアパートに引きこもったまま改善を行なっていたら、絶対にそのような結果は生まれていなかったことでしょう。

特に、発表がされたあとの6ヶ月間、大量の機能が追加されましたが、そのうち数日以上残った機能は25%ほどです。悪いアイデアばかりだったからからではありません。例えば、6月にカテゴリーの機能を追加しました。アレクシスを共同創業者にして、一晩中Redditに投稿された全てのリンクをカテゴリーわけしたのです。しかし、その次の朝には、その機能の不必要性に気がつきました。

もし発表が遅れていたら、11月くらいまでその機能を残したまま、なぜその機能がうまくいっていないのか悩んでいたことでしょう。

<エメット>
Amazonが、実用最小限の製品に関してつかう言葉があります。製品を開発するときに、目標は「すばらしく最小限の製品」なのだそうです。必要なものが全てそろっている、完璧に自立した製品を目指すべきではありません。完全な製品にするには、時間がかかりすぎます。

まだまだ手が必要な製品で良いのです。必要なのは、あなたの製品でなにかしらがうまくいっていることです。少なくとも世界で一人はあなたの製品を重宝してくれることを目標にしたいのです。しかし、そんなことは、実際に発表して使ってもらわなければわかりません。だからこそ、早めに発表する必要があるのです。例えをするならば、YCで大成功を収めたDropboxでしょう。彼らはバックアップシステムを開発していて、バックアップシステムというのは、データを失ってしまえば一貫の終わりです。なので、バックアップのソフトウェアを開発していて絶対に避けたいことは、未熟なまま発表することです。一度失った信用は、二度と戻りませんからね。

そこで、Dropboxにおけるすばらしく最小限の製品は、動画でした。つまり、こんなすごいものを開発しているんだよってプロモーションの動画を創り、ニュースレターを配信したのです。結果は大成功です。Dropboxがどのようなものになるのかという視覚的なイメージはとても魅力的だったのです。

Justin TVでは同じようにいかなかったことでしょう。すぐにユーザーに何か届ける必要がありました。私たちのアイデアはテレビ番組をつくるという内容だったので、最小限の努力でとりあえず番組をネットに公開しました。なので発表当初には、チャンネルは一つで精一杯でした。

放送を継続して行うために、Mac Miniで ParallelsというWindows XPを仮想化するプログラムを起動し、Onflicksでしたっけ?OnLonでしたっけ?のちにAbobeに買収されたソフトなのですが、放送プログラムを使っていました。それを使い、カメラ入力を認識して、バグが多かったので壊れたら再起動する過程を自動化させていました。

しかし、動画をネットにあげるところまではできても、それをスケールさせることができなかったのです。何千ものストリーム配信を行うことは、不可能でした。しかし、少なくともオンライン上で誰か一人にとっては価値のあるものを作り出すことができ、それがとても重要なステップでした。そこから、必要な改善を始めることができたからです。

<スティーブ>
HitMonkでは、2010年6月にはじめ、共同創業者にMVPについて聞いてみました。適当にユーザーに当たるのではなく、正確で、本物のデータが必要でした。そして、ユーザーが航空券を買えば、収入が入ってくるわけです。そして私はそれを三ヶ月でつくることができるならば、やろうと言いました。三ヶ月で発表ができないようであれば、やめにすると。そして、それが私にとってMVPを定義づけるものでした。そこからユーザーがお金をくれるようであれば、それはうまくいっているという証拠だと思っていました。そして、このアイデアは三ヶ月で発表することができたので、結果5年間このアイデアで働いてきました。先に期日や目標をたてることは、集中させ、正しい方向を見失わずに済むため良い考えだと思います。

 

<マイケル>
ところで、もう一つ、YCに会社が入ってくるときに聞いていることがあります。アナリティクスはどうしているのか?何をトラッキングしているのか?です。これもMVPのように、誰もが知っているべきことだと思います。初期のスタートアップはアナリティクスについてはどのように考えるべきだと思いますか?

どのようなアナリティクスツールを使うべきでしょうか?また、製品開発にどうトラッキングを組み込むべきでしょうか?

<スティーブ>
二つの全く異なる答えがあります。なので、おそらく正解はこの間のどこかにあることでしょう。Redditでは、全くしませんでした。何年もの間、自分たちのトラフィックについて知りませんでした。なにも計っていなかったのです。

製品開発は長い間、勘でしていました。そしたら会社が成功した、という感じです。今でも正確にどれほど多くのユーザーがいるかは知りませんし、今となってはトラッキングするのはものすごく面倒なことです。

<マイケル>
実際何人くらいユーザーがいるのですか?

<スティーブ>
3億を超えるともう、数えるのも、もう...

(笑い)

<エメット>

いや、本当に、私も毎月何人のユニークユーザーがサイトを訪問してくれているのかさっぱりわかりません。

<スティーブ>
多分 2.5億から3億ですかね。

しかし、Hipmunkでは、1日目からきちんとトラッキングしていました。ユーザーから直接フィードバックを聞かなかった代わりに、ユーザーに関するデータを解析したり、検証するのが得意になりました。正直、このように解析を行なっていなかったら、あれほど長続きしなかったと思います。

本当に、MVPをつくるときはまだ完成品でなくても良いのです。一部に問題があったり、ほとんど動かなくても、ユーザーを維持することはできます。しかし、データがないことは致命傷です。データがないというのは、補うことができない問題です。そして、勘だけではいずれ間違いを犯すことでしょう。なので、実用最小限のデータは何か注意深く考えるべきでしょう。細かく分析する必要はありません。ただ、必要なときに参考となるものがあるように、備えておくのです。

~ 16:42

Part. 3 につづく

原文 : https://blog.ycombinator.com/how-to-build-a-product-part-i-with-michael-seibel-emmett-shear-and-steve-huffman/
Heap | Mobile and Web Analytics