フレームワーク活用ガイドひとことで言うと#
プロダクトの意思決定をPM（ビジネス）・デザイナー（UX）・エンジニア（技術）の3者が一緒に行うチームモデル。PMが一人で考えて「これ作って」と渡すのではなく、3つの視点で問題を探索し、最適な解決策を見つける。
押さえておきたい用語#
- プロダクトトリオ（Product Trio）
- PM・デザイナー・エンジニアの3職種で構成される最小意思決定ユニットのこと。テレサ・トーレスが提唱し、ディスカバリーの中核を担う。
- ディスカバリー（Discovery）
- 「何を作るべきか」を探索する課題発見・仮説検証のプロセスのこと。トリオが共同で行うことで視野の偏りを防ぐ。
- デリバリー（Delivery）
- 検証済みの解決策を実際に開発・リリースする実行プロセスのこと。ディスカバリーと並行して回すデュアルトラックが理想。
- 情報の非対称性（Information Asymmetry）
- チーム内で特定の人だけが情報を持ち、他のメンバーに共有されていない状態のこと。トリオモデルはこの解消を最大の目的とする。
- OST（Opportunity Solution Tree）
- 成果目標から逆算して機会と解決策をツリー状に整理するテレサ・トーレスの思考フレームのこと。トリオの議論を構造化するために使う。
プロダクトトリオモデルの全体像#
こんな悩みに効く#
- PMが仕様を決めてデザイナーとエンジニアに渡す「ウォーターフォール」になっている
- デザイナーやエンジニアが「言われたことを作るだけ」でモチベーションが下がっている
- 技術的に無理な仕様が後から判明し、手戻りが多い
基本の使い方#
それぞれが持ち込む専門性を明確にする。
- PM（プロダクトマネージャー）: ビジネス価値の視点。「顧客にとって価値があるか？ ビジネスとして成立するか？」
- デザイナー: ユーザー体験の視点。「ユーザーが使えるか？ 使いたいと思うか？」
- エンジニア（テックリード）: 技術的実現性の視点。「技術的に実現可能か？ 保守可能か？」
ポイント: 3者は上下関係ではなく対等。それぞれの専門知識が意思決定の質を高める。
3者が一緒に顧客の課題を探索する。
- ユーザーインタビューに3者で参加する（全員が顧客の声を直接聞く）
- データ分析の結果を3者で議論する
- 課題の定義とソリューションの方向性を3者で合意する
ポイント: エンジニアが「顧客の声を聞いたことがない」状態を解消するのが最初の一歩。全員が顧客を知る。
週に1回、トリオで30〜60分のミーティングを行う。
- 今週発見した顧客のインサイトを共有する
- 解決策のアイデアを3つの視点でブレスト・評価する
- 仮説の検証結果をレビューし、次のアクションを決める
ポイント: デイリースタンドアップとは別に、ディスカバリー専用の時間を確保する。デリバリーの話に押されてディスカバリーが消えないように。
最終的な意思決定の方法を明確にする。
- 3者の合意を目指すが、合意できない場合のルールを決めておく
- ビジネスリスクはPM、ユーザーリスクはデザイナー、技術リスクはエンジニアが最終判断
- 決定事項とその理由を記録し、チーム全体に共有する
ポイント: 「全員が納得するまで議論する」と時間がかかりすぎる。**「各領域の専門家の判断を尊重する」**ルールで素早く決める。
具体例#
Before（PM中心モデル）:
- PMが顧客ヒアリング → 仕様書作成 → デザイナーがUI作成 → エンジニアが実装
- 実装段階で「これ技術的に厳しい」が判明し、仕様変更が頻発
- デザイナーは「PMの考えた仕様をUIにするだけ」でやりがいを感じていない
After（プロダクトトリオモデル）:
| 活動 | やり方の変化 |
|---|---|
| ユーザーインタビュー | PMだけ → PM・デザイナー・テックリードの3者で参加 |
| 課題定義 | PMの仕様書 → 3者でOpportunity Solution Treeを作成 |
| ソリューション設計 | PM→デザイナーへの一方通行 → 3者でブレスト。技術制約も初期段階で共有 |
| 意思決定 | PMが決める → 3者で議論。各領域の専門家の判断を尊重 |
| 週次MTG | なし → 毎週水曜30分のトリオセッション |
結果: 実装段階での仕様変更が月8件→2件に減少（手戻り75%削減）。デザイナーとエンジニアのエンゲージメントスコアが向上し、ユーザーインタビューから機能リリースまでの期間が平均2週間短縮された。
フィットネスアプリ（DAU 1.2万人）で、新規ユーザーのDay 7リテンションが18%と低迷。従来はPMが仕様書を書いてデザイナーに渡す流れだったが、トリオモデルに切り替えた。
トリオでの取り組み:
| 役割 | 貢献内容 |
|---|---|
| PM | 離脱ユーザー30人のインタビューを企画・実施 |
| デザイナー | インタビューに同席し、行動観察からUX課題を5つ特定 |
| エンジニア | ログデータから「初日にワークアウト完了した人の88%がDay 7に残る」マジックナンバーを発見 |
3者で合意した施策:
- 初回起動時に5分で完了するサンプルワークアウトを提供（エンジニア提案）
- ゴール設定を1画面に集約しステップ数を7→3に削減（デザイナー提案）
- 初回ワークアウト完了後にプッシュ通知の許可を取る（PM提案）
結果: Day 7リテンションが18%→34%に改善。PMだけでは発見できなかったマジックナンバーとUX課題が、トリオの多角的視点で初めて見つかった。
従業員15名の不動産テックスタートアップ。専任デザイナーがいないため、「PM＋エンジニア＋CS（カスタマーサクセス）」の変則トリオを編成。
工夫:
- CSがデザイナーの代わりに「ユーザー体験の代弁者」を担う
- 週1回30分、物件検索機能の改善に特化したトリオセッションを実施
- 隔週でユーザー3名に15分のオンラインインタビュー（3者で参加）
3ヶ月の成果:
| 指標 | Before | After |
|---|---|---|
| 物件検索→問い合わせ転換率 | 2.1% | 4.8% |
| 仕様変更による手戻り | 月5件 | 月1件 |
| 機能リリースサイクル | 6週間 | 3週間 |
結果: 専任デザイナー不在でも、CSがユーザー視点を持ち込むことでトリオは機能した。完璧な3職種が揃わなくても「3つの視点を持つ人」が揃えば十分に効果がある。
やりがちな失敗パターン#
- トリオの時間を確保しない — デリバリー（実装）に追われてディスカバリーの時間がなくなる。カレンダーにトリオの定例を固定する
- PMが結局一人で決める — 形だけトリオにしても、PMが事前に答えを決めていたら意味がない。探索段階から3者で考えることが本質
- トリオ以外のメンバーを疎外する — トリオの決定がチームに共有されず、他のメンバーが「蚊帳の外」になる。決定事項と背景を必ず全体共有する
- ディスカバリーなしでデリバリーだけ回す — トリオを編成しても「何を作るか」が事前に決まっていたらウォーターフォールと変わらない。仮説検証のプロセスをトリオで回すのが本来の使い方
まとめ#
プロダクトトリオモデルは、PM・デザイナー・エンジニアの3つの視点を融合させて意思決定の質を高めるチーム設計。「PMが考えて、残りが作る」モデルからの脱却が本質。3者が一緒に顧客を理解し、一緒に解決策を考え、一緒に判断する。手戻りが減り、チームのモチベーションが上がり、最終的にユーザーにとって良いプロダクトが生まれる。