Julie ZhuoはFacebookプロダクトマネージャーで、ニュースフィードとモバイルアプリを開発しています。 製品をアイデアの墓地にしない方法に関する記事。
新しいものすべてには、楽しくてエキサイティングなものがあります。 Googleで画像を検索すると、その意味がわかります。 「新しい」という言葉は、完全に大文字で（叫んでいるかのように）書かれており、しばしば明るい星型の図に配置され、感嘆符によって強調されています。 これ以上エキサイティングなものはありません。 「新しい」と叫ぶ：「私を見て、輝いて手招きをする！ 私が開いた機会に満ちた未来に注意してください！ たぶん私はあなたの人生を変えるでしょう！ 少なくとも私はあなたの時代遅れのワードローブ/家/ライフスタイル/製品に新しい命を吹き込みます。」
「新しい」は必要な薬であり、隠れた希望のようなものです。 新しいものは常に優れていると思うので、次の大規模な発売までの日数を数えたり、最近追加された機能に焦点を当てたり、最新のトレンドについて話し合ったりします。 毎日、オフィス、会議室、テニスボールのようなカフェで新しいアイデアがどのように飛ぶかを見て、聞いています。 私たちが追加したならそれは素晴らしいことです...私は本当に私たちの製品にこの新しい機能を持たせたいです...私は本当にあなたがチームをまとめて行うと何億ドルを稼ぐことができると思います...
誤解しないでください、新しいアイデアのフラッシュが大好きです。 私は、良いハッカソンの創造的なエネルギーと衝撃的な気分が好きです。 私はテクノロジーの分野で働いているのが好きです。そこでは、子供のおもちゃのような良いアイデアがあります。お風呂に入れた小さなカプセルで、巨大な恐竜のスポンジが成長する様子を観察します。 その重要性の認識は、新しい変革的なアイデアの成功した形成と実装に基づいています。 それで、企業は生まれて台無しになります。 これが業界全体の基盤です。 同意します。製品に可能な限り多くの良いアイデアを実装しようとしないのは愚かなことです。
そしてまだ。 あまりにも頻繁に考え始めると、すべてを台無しにします。 それは、優れたシンプルな製品が反対の品質を獲得する方法です。 さまざまなオブジェクトをそれ自体に引き付けるKatamariボールのように、製品はますます多くの機能を獲得し、ある日、ユーザーはアプリケーションを開き、4つの異なるツールバーと50のアイコンがユーザーインターフェイスに散らばるのを見るでしょう。 または、彼はあなたのサービスのリストを見て、7ページで32ポイントを読まなければなりません。 または、クリックしてメニューを開き、20の異なるオプションを取得します。 あなたのアプリケーションは、お母さんに私に電話して、それをどう使うか尋ねさせるものの一つです（「 ハニー、「リリースと信頼送信者」とはどういう意味ですか？」）。
iA Writerは、ヘビー級のWordに比べて新鮮な空気のように見え、「Mac App for the Year」になり、ほぼ完璧なレビューを収集し、執筆友人の間で急速に人気を得たのかもしれません。 ユーザーによる製品の完全な理解はその利点です-使いやすさは多くのあいまいな機能を理解する必要性と対照的です。
製品に新しい機能を導入するのは大変な負荷です。 私はこれに特に注意を払いたいです。 おそらく、新しい機能は簡単に実装できます。 数日しかかからず、数人しか必要ありません。 おそらく、すべては来週までに準備が整うでしょう。 おそらく、ユーザーの追加の認知的負荷は低くなります。もう1つのアイコンまたは追加のメニュー項目だけです。 しかし、新しい関数が利用可能になるとすぐに、それは実際の人々が使用する実際のツールを表し始めます。
おそらくあなたはそれを開発し、改善し続けるでしょう。 たとえそうでなくても（起動して先に進むことを計画しているだけかもしれませんが）、この機能が存在するという事実により、必然的に追加の作業が作成されます。 ユーザーからリクエストとエラーメッセージを受け取ります。 あなたはそれを改善する方法について無分別に考えることに時間を費やすでしょう。 おそらく、次の再設計またはコード更新のコンテキストでポップアップします。
もちろん、関数が期待したほど成功していない場合は、削除することを検討してください。 ただし、ユーザーが好んで使用しているもののごく一部を削除することは非常に困難です。 何かを削除してさらに実装することを決定するには、かなりの時間とエネルギーが必要です。 これは不可能ではありませんが、実装よりもはるかに複雑です。 Googleリーダーの廃止にどれほど積極的に反対しているかを見てください。 「この奇妙な関数はどこから来たのか」という質問に対して何回考えればよいのでしょうか。「以前のバージョンから」という答えが得られます。
それではどうしますか？ 正しいことは、将来のイノベーションの拒否や、中途半端なアイデアのすべての実装ではないことは明らかです。 イノベーションが必要です！ ただし、製品に新機能を追加する場合は、次の2つの重要な側面について考慮する必要があります。
1.「青信号」の基準の定義と、少数の聴衆の間でイノベーションをテストするためのその使用。 ユーザーをより幸せにし、生産性を高めると思う新しいアイデアはありますか？ ユーザー数を増やしますか？ 会社の収益を増やしますか？ それを実装し、テストしてください。 視聴者のごく一部に対して小さなテストまたはベータ版を実行し、完全な起動の実現可能性/時間を示す基準を決定します。 これは、本当に肯定的なフィードバック、X％+の成長の増加、Y％+の収入の増加を得ることができます。
これらの基準を可能な限り早い段階で（理想的には起動前に）定義することで、重要な瞬間に客観的になることができます。 懸命に取り組んだものを完全に起動しないことを決定するのは困難です。 ただし、合理的な基準に従ってテストすることは、その実装のコストを決定する前に、あなたのアイデアがあなたが想像したとおりのものであることを確認する唯一の方法です。
これはFacebookのかなり標準的な慣行です。 ハッカソンやチームブレーンストーミングセッションの結果として生じるさまざまな興味深いアイデアをテストします。たとえば、 将来のために投稿を保存する機能は、急いでいる人に役立ち、回答したい投稿や後で読みたい記事を見るのに役立ちます。 十分な数のユーザーがこの機能を利用して有用であると判断した場合にのみ、この機能を起動します。 これが発生しない場合、すべてのパブリケーションで別の参照アクションとして場所を占めるべきではありません。 テストにより、実際にこの機能を使用したのは少数のユーザーグループのみであることがわかったため、実装しないことにしました。
2.プロジェクトを完了するための基準の決定 場合によっては、小さなグループでアイデアをテストすることは実用的ではなく、不可能な場合もあります。 次に、実装後に関数または製品を削除するのが賢明な状況を自問する必要があります。 また、前日に客観的になりやすい。
失敗について誰も考えたくありませんが、確かなことがあるとすれば、それはいくつかのアイデアが失敗するということです。 これは、将来への投資が時間の無駄であるということではありません。将来の失敗から学んだ教訓は、成功への道においてしばしば重要だからです。 同時に、停滞している失敗した関数をすぐに取り除くよりも、失敗した関数を残す方がはるかに危険です。
大声ではっきりと言ってください。「機能Xを起動しています。それは[必要なものをここに挿入]するだろうと信じているからです。 Nか月の最大限の改善に投資します。 その後、関数Xを毎日使用する人がY％未満の場合、それを削除します。」 これは成功のビジョンを示し、X機能が「隅にほこりを集める」だけでなく、会社とユーザーの注意をそらすことを確実にします。
Facebookでは、2007年に発売されたバーチャルギフト機能にこのアプローチを採用しました。 3年後、バーチャルギフトビジネスは期待した結果をもたらさず、他のことに集中するために、バーチャルギフトストアを閉鎖し 、チームは他のプロジェクトに切り替えました。 （2年後、この経験により、プレゼントを贈る機会をもう一度提示することができましたが、今では仮想ではなく本物です！）
イノベーションに対する熱意に問題はありません。 可能であれば、グローバルに、最大限にグローバルに夢を見てください。 良いアイデアを実装し、実装します。可能性のあるアイデア、夜に目を覚まし続けるアイデア、それらを実現するためにできるだけ早くベッドから出たいので。
自分の後片付けを忘れないでください。 決してゴミを出さないルームメイトにならないでください。 新しいアイデアが適切に機能しない場合は、その負担をやめます。 最も重要なことは、製品が少しずつ、センチメートルごとに不必要に複雑にならないようにして、認識されなくなり、私の母のような人々を怖がらせる怪物になってしまうことです。
最悪の死は、数千の小さな刺し傷による死です。
トルストイサマーキャンプスタートアップスクールの一環として翻訳