成功するプロダクトを作りながら学んだ50の教訓［翻訳記事］

1. 小規模チーム（6人以下）でも優れたプロダクトは作れるが、目標設定、ロードマップの優先順位付け、メトリクスの選定、ユーザーとのコミュニケーション、高速なコードデプロイなど、あらゆる裁量を与えなければならない。

2. プロダクトの成功は、それを作る人にかかっている。採用基準を高く設定することが重要で、優秀な人材の力は積み上がるからだ。間違った採用は、どんな要因よりもチームのスピードを大きく鈍らせる。

3. 優れたプロダクトを作るには信頼が不可欠だ。信頼不足はチームにおける最大級のボトルネックの1つであり、たいていは基準に満たない人材を採用したか、その人に改善のためのフィードバックをきちんと与えなかった結果である。

4. 信頼は透明性によっても築かれる。オープンに仕事をし、議論は開かれた場で行い、作業内容を文書化しよう。そうすれば全員が必要なコンテキストを共有でき、多くの会社で起こる政治的な争いをなくせる。

5. プロセスではなく、信頼とフィードバックに依存しよう。これは私たちのコアバリューの1つだ。人々が求めるものを作って育てることは繊細な問題なので、社員の判断を信じる。うまくいかなければ率直にフィードバックを与える。

6. 経営陣は会社の目標を共有し、プロダクトチーム（エンジニア）はそれを達成するために何を作るかと自分たちの目標を決める。双方とも、メトリクスとユーザーフィードバックを通じて実際の影響を見直すべきだ。

7. プロダクトは理想顧客プロファイル（ideal customer profile, ICP）に従属する。ICPこそが作る対象であり、何を作るかを決める最も重要な要素だ。正確なICPは、ターゲット顧客だけでなく、プロダクトと市場参入戦略のあらゆる側面を定義する。

8. ICPを見つけるには、まず仮説を立ててテストしよう。登録時に質問し、継続率を比較し、パワーユーザーを特定し、NPSアンケートを実施する。情報と確信が蓄積したら、細部を加えていけばよい。

9. プロダクト原則を作ろう。私たちは「成功の評価に必要なすべてのツールを提供すること、先手を打つこと、顧客およびプロダクトデータの単一の真実の情報源であること」を原則にしている。これは、アイデアの議論や意思決定のための共通言語になる。

10. ユーザーが欲しがりうるものをすべてマッピングしよう。ロードマップの優先順位付けで必要になる。そうすることで、地平線の向こうにある優れたアイデアを見落とさずに済む。

11. プロダクトは単なる機能の集まりではない。ブランドであり、他者に与えるプロダクト体験そのものだ。各機能への投資規模、採用する人材、ビルドの判断、主導機能、顧客とのコミュニケーション、価格設定のすべてが独自性を作る。

12. Webサイトはプロダクトの第一印象だ。退屈でテンプレート的なサイトは、その先にあるプロダクトやチームが弱いというシグナルを送る。自分たちならではの独自サイトを理想顧客プロファイルに合わせて作れば、それを防ぎ、ユーザー流入を促進できる。

13. ときにはプロダクトの問題ではなく市場の問題である。たとえばMonzoの創業者でありYCパートナーでもあるTom Blomfieldが、大学の友人向けに割り勘請求サービスを作っていたとき、「作るのをやめてユーザー獲得に集中せよ」と助言された。4週間コールドコールを続けて1人しか獲得できなかった時点で、ピボットすべきだと悟った。

14. ピボットするなら大規模にやろう。Stewart Butterfieldは2つのゲーム会社をFlickrとSlackへと変えた。LinkedIn共同創業者のReid Hoffmanは、スタートアップ創業者が失敗から成功へピボットするには、事業の残りを「slash and burn」しなければならないと言う。似て見えるなら、もっと遠くまで行け。

15. 37signalsのJason Friedが言うように、「アイデアは検証できない。まだ存在しないのだから、実際に作らなければならない。市場がそれを検証してくれる。」

16. 計画は有用だが、厳密に従うためのものではない。優れた実行とは、特定の計画を遂行することではなく、最も重要なことを繰り返し行うことだ。「計画順守」ではなく、成果物、デプロイ頻度、影響で人を評価しよう。

17. 何かを「あと1週間だけ」先延ばしするのは、ほぼ常に悪い考えだ。こうした態度が何カ月も積み重なると、勢いは大きく失われる。ユーザーの手に早く渡すほど、その価値を学んで改善できる。

18. 進行中の作業を減らそう。PRは1日以内に終えるべきで、1日は他人のレビュー依頼への対応から始め、いつでもマージして機能フラグの裏でデプロイし、本番環境でテストしよう。これらすべてが作業コンテキストの負荷を減らす。

19. 高速デプロイは私たちのプロダクト開発哲学の中核だが、トレードオフもある。技術調達、計画ミーティング、アジャイルの儀式、メトリクスレビューは後回しになる。非同期作業はそれをさらに可能にする。

20. プロダクトに新技術を導入するのは、過大なコスト、スケーリング問題、顧客要件のような差し迫った問題があるときだけにしよう。解決技術は、チーム内や他チームに、彼らがそれをどう解いたかを聞けば見つかる。

21. 人為的な締め切りはチームを速くしない。むしろ技術的負債の山とバーンアウトを招く破滅のループを引き起こす。チームを遅くするプロセスを取り除き、小規模チームに高速デプロイの裁量を与えよう。

22. より速くデプロイするもう1つの方法は、デザインをデフォルトでなくすことだ。デザインシステムを動かしたうえで、エンジニアに実装を任せよう。必要ならデザインレビューで、すでにデプロイされたものを磨けばよい。

23. 機能フラグは、プロダクトエンジニアが変更を素早くデプロイし、本番環境でテストし、実際のユーザーフィードバックを得られるようにする。想定どおりに動かないときにはキルスイッチとして機能し、リスクも下げる。

24. PostHogでは、最高のコミュニケーションはプルリクエストだ。メッセージやイシューと違って、フィードバックを即座に影響へ変えられる。行動優先の志向に合っており、よりタイトなフィードバックループを作る。

25. オーナーシップを明確にしよう。そうすれば、何を作るかを決めることがはるかに明確かつ迅速になる。オーナーシップを避けるチームは、デプロイの代わりに計画、ブレインストーミング、会議、プロジェクト管理に時間を浪費する。

26. エンジニアには何を作るかを決める能力がある。技術的制約を理解し、機能のパターンを見抜き、問題をどう解くかを知っているからだ。ただし、ユーザー要望に関する情報のボトルネックはありうる。

27. エンジニアを統制する代わりに、プロダクトマネージャーはプロダクト分析、ユーザーリサーチ、競合調査などを通じて、プロダクトチームにコンテキストを提供すべきだ。

28. たいていの人はSteve Jobsではない。最初から「わかっていて」作れるようなビジョンは持っておらず、大きな絵を描けるわけでもない。だからこそ、デプロイし、ユーザーに届け、フィードバックを繰り返す。この速度が速いほど、プロダクトは良くなる。

29. プロダクトエンジニアを採用し、信頼しよう。彼らはプロダクト作りに必要なフルスタックのスキルと、顧客への執着を兼ね備えている。ユーザーとの会話、インタビュー、新機能テストの募集、フィードバック収集、サポート対応、インシデント対応まで担うべきだ。

30. The Mom Testを読もう。潜在ユーザーの問題について会話する方法を教えてくれる。重要なのは、ユーザーインタビューには2種類あるということだ。問題探索とソリューション検証である。前者は将来のプロダクト判断を導き、後者は今やっている仕事の改善に役立つ。

31. ユーザーインタビューで最大の効果を得るには、ユーザー（ICP）が誰なのか、プロダクトをどう使っているのか、次に何を作るのかを事前に把握しておこう。そうすればインタビューは次のステップへの焦点を明確にし、混乱を招かない。

32. 作る候補のうち、サポートリクエストが最も「現実的」だ。特定のユーザーが具体的な問題に直面しているため、それを解決すればプロダクトはすぐに改善される。他の変更はこれほど直感的ではない。

33. エンジニアがサポートを担当すると、アイデア創出から実装、継続的な保守まで、プロダクトのライフサイクル全体のオーナーシップが促される。各段階は、実際の顧客の痛みや、その問題の背後にあるコードのコンテキストと結びつきながら積み上がっていく。

34. エンジニアによるサポート対応は、ユーザーの問題とデプロイされた修正とのループを短くする。サポート担当者、プロダクトマネージャー、計画プロセスが邪魔をしない。おまけに、ユーザーはそれをとても喜ぶ。

35. 自社プロダクト利用（dogfooding）は、デプロイ速度の向上、ユーザーに届く前の問題の遮断、プロダクトへの深い理解、ユーザーへの共感形成に役立つ。ただし、ユーザーとの対話、実際のフィードバック、利用メトリクスの追跡を置き換えるものではない。

36. 私たちのプロダクトチームがインタビューポップアップで自分たちの要求を解決したように、自社のニーズを解決することはユースケース検証に有効だ。自社プロダクトを使うべきなのに使っていないなら、それは何かがおかしいシグナルなので直そう。

37. 偉大なプロダクトビルダーは、常にプロトタイピングと実験をしている。MVPや概念実証を作り、未完成の作業をデプロイし、フィードバックを集め、失敗したらピボットすることに慣れていなければならない。インフラからデザインまで、ゼロから作るあらゆるスキルも必要だ。

38. 成功するA/Bテストには、何を、なぜ試すのかを説明する良い仮説が不可欠だ。テストのコンテキスト、変更点、メトリクス、期待される結果を含めよう。

39. プロダクト実験では、失敗して削除される可能性があることを理解しておこう。機能フラグで削除しやすく設定し、完璧に保守・スケールする版ではなく、「十分に良い」版をデプロイしよう。成功してから改善すればよい。

40. プロダクト実験は、思っているよりずっと「雑」にやってよい。機能全体を作る代わりに、fake doorテストを試そう。何もないオプションやボタンを追加して、クリックされるかどうかを見る方法だ。

41. プロダクト実験の失敗は世界の終わりではない。Googleでは実験の80〜90%が「失敗」する。時間の無駄に見えるかもしれないが、大規模では10%の成功がすべての失敗を埋め合わせる。たとえばBingの見出し表示に関するA/Bテストは、収益を12%（1億ドル超）押し上げた。

42. 成長に集中するときは、グロースエンジニアのように考え、優先順位を付けよう。対象領域を特定し、代表メトリクスを選び、改善仮説を立て、可能な限り最小の実験でテストを実装する。

43. 分析導入は、ほとんどいつも「早すぎる」ことはない。ローンチ前のプロダクトならともかく、「早すぎる」と言って分析なしで出すのは誤った節約だ。ローンチ後は、優先順位が最速でデプロイすることから、「正しいもの」を最速でデプロイすることへ変わる。

44. 分析を始めるときは小さく始めよう。特定のプロダクトや機能を選び、autocaptureで利用を追跡し、トレンドやリテンショングラフで可視化し、それを改善する機能のデプロイを試みる。「モダンデータスタック産業複合体」は、実際以上に複雑に見せている。

45. 最初のメトリクスがわからないなら、activationを勧める。ほかのメトリクスの上流にあり、エンジニアが直接影響を与えられ、組織全体にとって有用だからだ。

46. activationに加えて、retentionはビルドの影響を理解するためのもう1つの重要なメトリクスだ。週ごとの変化を追うことで、その変更がユーザー維持に役立っているかを測れる。

47. プロダクト・マーケット・フィットを測る際は、ユーザー成長よりもユーザーエンゲージメントが指数関数的に増えているか、そしてリテンションが横ばい（0%以上）になっているかを確認しよう。その後、ICPユーザーの維持が優れているか、有料顧客がICPに属しているかを見る。

48. グロースレビューは、チームのビルドが売上、プロダクト分析、ユーザーフィードバックなどの重要メトリクスに影響を与えているかを確認する。PostHogでは、これはプロダクトマネージャーの主要な責務だ。

49. 複数のプロダクトを作る場合は、それぞれをミニスタートアップのように扱おう。独自のプロダクト判断、価格、収益、コスト、顧客接点のあるチームとの調整まで含めてだ。

50. 興味を持てるプロダクトにしがみつこう。PostHog共同創業者のJamesがプロダクト・マーケット・フィットのガイドで書いているように、「興味がないならピボットしよう。それだけだ。自分らしいと感じられる仕事にしがみつくとき、人はより大きな成果を出す。」