product-reviews

効果的なプロダクトレビュー

厳密なアラインメントセッションを実施し、品質基準を引き上げ、意思決定を加速させましょう。

Lenny's Podcast と Newsletter に登場した12人のゲストや投稿から得た知見を活用し、効果的なプロダクトレビューを支援します。

支援内容

1. レビュー文化を評価する - 現在のレビュー形式を評価し、品質基準におけるボトルネックや不足点を特定します。
2. フレームワークを選ぶ - プロジェクトの複雑さやライフサイクルに応じて、適切なレビュー段階やテンプレートを提案します。
3. レビュー資料を作成する - 問題の提示方法を整え、選択肢の範囲を可視化し、事前資料の準備を支援します。
4. セッションを進行する - 意見の傾向を把握し、異論に対処し、明確な決定事項を記録する手法を提供します。

基本原則

解決策ではなくフレームワークを評価する

「Figma のプロダクト構築方法」より：「私が両方について勧めているのは、まず『選択肢の範囲』を提示することです。考えられるすべての解決策や問題をマッピングするフレームワークを用意し、それを使って大局的なトレードオフや考え方の違いを話し合うのは、とても効果的です。」

質の高い意思決定は、単一の提案だけを切り離して議論するのではなく、考えられる解決策の全体像を可視化することで生まれます。

透明性のある定例スケジュールを設ける

「Duolingo のプロダクト構築方法」より：「プロダクトレビューの会議は毎週火曜日と木曜日に開催し、合計で2時間です。この2時間を20分の枠に分け、プロダクトチームが発表枠を予約します。会議では、プロダクトチームが最初の5〜10分で提案する変更について発表し、残りの時間でレビュアーが質問やフィードバックを行います。」

短時間の定期的なレビュー枠を設けることで、フィードバックのボトルネックを防ぎ、組織全体で品質の基準に対する共通認識を築けます。

問題と解決策を分ける

「Miro のプロダクト構築方法」より：「プロダクトレビューでは、プロダクト開発のライフサイクルにおけるさまざまな段階に焦点を当てることができます。P-Strat：長期的な戦略とビジョン。P0：取り組む機会と問題。P1：提案する解決策。P2：リリースしたものとその成果。」

レビューを明確に段階分けすることで、チームが高精度なデザイン作業に着手する前に、リーダーシップが問題と戦略的な方向性に合意できるようにします。

品質に関する合言葉を実践に落とし込む

「Miro のプロダクト構築方法」より：「あるプロダクトリーダーが『モナ・リザの原則』を考案しました。簡単に言えば、リリースするものはすべて、モナ・リザの絵画のように、自分たちの名前を付けて誇りに思えるものであるべきだということです。……毎月、リリースしたものすべてを見直し、品質が高いものとそうでないものを評価します。」

シンプルなたとえや原則を用いてチーム内の直感を育み、常に監督しなくても、全員が卓越性の基準を理解できるようにします。

売り込みではなく、認識を合わせる

「Snowflake のプロダクト構築方法」より：「プロダクトレビューの目的は、リーダーシップチームに新たな投資を『売り込む』ことではありません。顧客の要件を詳しく説明し、ビジネス上の優先順位を相対的に整理し、これらの課題にどう対処するかを明確に示すことです。」

レビューは社内向けの宣伝やリーダーシップへのアイデアの売り込みではなく、一貫した意思決定に焦点を当てた協働の場として構成します。

問題を厳密に明確化することに注力する

Tomer Cohen：「実際にあなたがどう考えているのか、議論を呼ぶ可能性のある意見は何かを、私は強く問いかけます。優れた原則には明確な指針が必要です。だから、『シンプルなプロダクトを作るべきだ』と言われても、私には意味がありません。シンプルなプロダクトを作りたくない人なんているでしょうか？」

レビューでは、具体的な問題と原則に基づく意見を深く掘り下げます。戦略的な価値のない、表面的な進捗報告に終始することは避けます。

テンプレートとフレームワーク

• プロダクトレビューの各ステージ（P-Strat、P0、P1、P2）（Miro のプロダクト開発方法） - プロダクト開発ライフサイクルに沿った4段階のプロダクトレビューフレームワーク。各段階に、定義済みのテンプレートとレビュー基準があります
• 不確実性 × インパクトの2x2レビュー頻度基準（マネージャーをうまく管理するための5つの原則） - 不確実性とインパクトに基づいて委任したプロジェクトのレビュー頻度を決めるため、直属ではないリーダーが使う2x2マトリクスです
• 選択肢の幅（Figma のプロダクト開発方法） - 特定の方向性について議論する前に、発表者が考えられるすべての解決策や問題を図示するプロダクトレビューフレームワーク。これにより、よりよい議論が可能になります
• アラインメントスケールウィジェット（Yuhki Yamashata） - レビュー担当者がクリックして自分のアバターを配置するスペクトラムを表示する FigJam/Figma ウィジェット。プロダクトレビュー中のアラインメントをすばやく確認できます
• Snowflake のプロダクトレビュー文書（シックスペイジャー）（Snowflake のプロダクト開発方法） - プロダクトレビューの1週間前に共有する6ページの文書。顧客の問題、提案するソリューション、リーダーシップによるレビューに必要な主要データをまとめます
• Notion の4段階プロダクトレビュープロセス（Notion のプロダクト開発方法） - プロダクト開発の4つの重要なマイルストーンで行う、体系的なチェックインプロセス。非構造的な作業セッションに代わるもので、主に非同期で進めつつ、同期的な形式へ移行します
• トークトラックを使った非同期プロダクトレビューワークフロー（Miro のプロダクト開発方法） - プレゼンテーションを非同期に移行し、会議での議論に集中することで、プロダクトレビューの効率を高めるワークフローです
• プロジェクトの集中査読（Nabeel S. Qureshi） - 新規プロジェクトのためのピアレビュー手法。2ページの計画書を、社外の有識者が厳しく批評します。

詳細を含む全リストについては、references/artifacts.mdを参照してください。

ユーザーを支援するための質問

• 「このプロジェクトは、現在プロダクト開発ライフサイクルのどの段階にありますか？」
• 「考えられる解決策の全範囲を整理しましたか？それとも、単一の方向性を提示していますか？」
• 「解決しようとしている具体的で微妙なニュアンスを含む問題の定義は何ですか？」
• 「このプロジェクトは、不確実性とインパクトのマトリクスでどのように位置づけられますか？」
• 「このレビューで明らかにすべき、チーム内の異論はありますか？」
• 「チームがこの議論に持ち込む、原則に基づいた見解は何ですか？」

指摘すべきよくある間違い

• レビューを進捗報告として扱う - リーダーの時間を無駄にし、戦略上の障害や品質上の問題に対処できません。
• プロセスの終盤でレビューする - チームが解決策に固執するようになり、リーダーからのフィードバックが指針ではなく、意欲をくじく障害だと受け取られてしまいます。
• アラインメントではなく合意を求める - 全員の同意を待つことで開発が遅れ、製品に関する決定が骨抜きになることも少なくありません。
• 問題について合意する前に解決策を議論する - 関係者が異なる目標を最適化しようとして、議論が堂々巡りになります。

詳細

12人のゲストから得た12件の情報については、references/guest-insights.mdを参照してください。

関連スキル

• エグゼクティブコミュニケーション
• 上司との関係構築
• 会議の進行
• 文書によるコミュニケーション