顧客共同デザインの運用：厳選アカウントとの機能共同デザインの進め方

ほぼすべてのCSチームには、いずれかの形で以下の両方が存在します。上位顧客が戦略的方向性について意見を述べるアドバイザリーボードの一連の会話と、新機能を構築する際に顧客を関与させるという大まかな慣習です。問題は、両者の間に明確な線を引いているチームが非常に少ないことです。先四半期のアドバイザリーボードに参加していた顧客が、積極的に関与しているという理由でプロトタイプレビューに引っ張られます。デザインインプットが欲しいPMが5社のアカウントとの「アドバイザリーセッション」をスケジュールし、Figmaモックを見せながら進めます。語彙が曖昧になり、期待が曖昧になり、成果も曖昧になります。

区別は哲学的なものではなく、運用上のものです。顧客カウンシルとアドバイザリーボードは戦略的な方向性についてのものです。より広い顧客グループが参加し、四半期ケイデンスで実施され、次の12〜18ヶ月で製品がどこへ向かうべきかについてのインプットを生み出します。共同デザインは特定の機能についてのものです。3〜6社のアカウントが参加し、4〜8週間にわたって実施され、ビルドレベルでその機能がどのように機能すべきかについての直接的なインプットを生み出します。時間のコミットメント、顧客の期待、セッションのフォーマット、成功の定義がすべて異なります。

両者を混同すると2つの失敗モードが生まれます。アドバイザリーボードが実際に持っていない共同デザインの影響力があるように位置付けられ、ロードマップが参加者の承認なしに変化したときに期待の負債が生まれます。共同デザインのエンゲージメントが戦略的な会話に膨らみ、単一の機能では満たせない領域にスコープが広がります。どちらの失敗も関係資本を消費し、どちらも運用上の規律によって防止できます。

この記事は共同デザインの進め方についてです。第11条はアドバイザリーボードをカバーします。両者の境界線がこの記事が最初に明確に引くものです。

顧客共同デザインの運用モデルは、このコレクションの第11条（より広いグループに対して四半期ケイデンスで戦略的な方向性を扱うアドバイザリーボード）と明確に区別されています。共同デザインは戦略的ではなく運用的です。ビルドパイプライン内の特定の機能を3〜6社のアカウントと4〜8週間にわたって形成します。このモデルには4つの運用上の規律があります。(1) スコープ規律：共同デザインは製品の方向性ではなく1つの機能をカバーします。(2) コホート規律：最も忠実または最も大きいアカウントではなく、問題を最も深刻な形で抱えるアカウントを3〜6社。(3) ロール規律：Productがビルドの意思決定をリードし、CSがセッションをファシリテートし、エンジニアリングが観察します。(4) 期待規律：顧客は「何を」共同デザインし、エンジニアは「どのように」を担い、Productが最終的な意思決定を行います。すべての共同デザインの失敗は、これら4つの規律のいずれかの違反に起因します。

アドバイザリーボードと共同デザイン：必要な区別

顧客中心のB2B組織の構築に関するMcKinseyの調査によると、戦略的なアドバイザリーインプットと特定の機能の共同デザインを混同する企業は、どちらの質問に対しても精確に答えられない顧客データを抱えることになります。区別は哲学的なものではなく運用的なものであり、混同は十分よくあることなので正確に述べる価値があります。

**顧客アドバイザリーボード**は、より広い顧客グループ（通常8〜15名の上位顧客担当者）が戦略的な方向性についてインプットを提供するために集まります。質問は「次の1年で製品をどこへ持っていくべきか？まだ解決していない問題として予測しているものは何か？競合他社にある優位性で我々に縮めてほしいものはどれか？」です。アドバイザリーボードは前向きで幅広いものです。個別の機能を形成しません。ロードマップを動かすプロダクトビジョンを形成します。ケイデンスは四半期です。アウトプットはPMチームのための戦略的コンテキストです。

共同デザインは小さなコホート（3〜6社）が既にビルドパイプラインに入っている特定の機能についての運用的なインプットを提供するために集まります。質問は「このワークフローは実際にこのタスクをこなす方法と一致しているか？このフローのどこで問題が発生するか？このチームのやり方を変えるに十分なほど有用にするために何が必要か？」です。共同デザインは現在進行形で狭いものです。今まさに構築されている特定の機能を形成します。ケイデンスは短いエンゲージメントにわたって集中的です。アウトプットは実行可能なビルドレベルのフィードバックです。

共同デザインが必要な場合とアドバイザリーインプットで十分な場合。 「この種の機能を構築すべきか？」が質問であれば、アドバイザリーインプットで十分です。「その機能のこの特定の実装は対象ユーザーが実際に使えるものか？」が質問であれば、共同デザインが必要です。アドバイザリーインプットは正しい方向性で構築しているかを示します。共同デザインは構築しているものが実際に機能するかを示します。

実際の判断：共同デザインが正当化されるのは、特定の機能に十分な設計上の曖昧さがあり、間違えるとローンチ後に大部分を再構築する必要があり、かつ提案されたソリューションを評価できる特定のユースケースとドメイン専門知識を持つ顧客が存在する場合です。

キーファクト：共同デザインプログラムの成果

• アドバイザリーインプットのみで開発された機能と比較して、構造化された顧客共同デザインセッションを経て開発された機能はGA後90日の定着率が41%高いです（Pendo、2024年）。
• PM主導の共同デザインセッションはCS主導のセッションと比べて35%少ない批判的なフィードバックを生み出します。評価しているものを構築した人物が部屋にいると、参加者が批判を和らげるためです（UserTesting、2024年）。
• 正式なクローズアウトセッションなしに終わった共同デザインエンゲージメントは、構造化されたデブリーフコールを含むエンゲージメントと比較して、GAローンチ時の参加者の期待失望率が2.1倍高くなります（Gainsight、2024年）。

共同デザインに招待する人（招待しない人）

選定基準はベータプログラムやアドバイザリーボードよりも具体的であり、間違った場合のコストは高くなります。アドバイザリーボードの選定を誤ると曖昧な戦略的インプットが生まれます。共同デザインの選定を誤ると誤ったユースケースに基づくビルドレベルの意思決定が生まれます。

「アドバイザリーインプットのみで開発された機能と比較して、構造化された顧客共同デザインセッションを経て開発された機能はGA後90日の定着率が41%高いです。」（Pendo、2024年）

問題の深刻度フィルター。 第一の基準：このアカウントは機能が解決しようとしている特定の問題を抱えているか、そして提案されたソリューションについて意味のあるフィードバックを提供できるほど深刻に抱えているか？「この問題の一般的なカテゴリーに遭遇するか」ではなく「この問題が現在、実際の運用上の制約になっているか？」です。理論的に問題を抱えるアカウント（「チームが成長したらこの問題が発生するかもしれない」）は、毎日運用上に問題を抱えるアカウントと同じ特定性でソリューションを評価できません。

CSヘルスゲート。 ヘルススコアが緑または黄色のみ。赤のアカウントとの共同デザインは協力ではなく搾取です。アクティブなサポート危機、予算対立、停滞した実装を管理している顧客は、誠実な製品フィードバックを提供するだけの精神的余裕がありません。自分自身の状況を管理しています。そして共同デザインの経験が（初期段階の機能作業はよく困難を伴います）フラストレーションを与えると、すでにストレスのある関係をさらに悪化させます。CS & Product アラインメント用語集ではヘルススコアの層とCSとProductがこのゲートを一貫して適用するために必要な共通語彙を定義しています。

能力フィルター。 この顧客は提案されたソリューションがその問題を実際に解決するかどうかを評価するドメイン専門知識を持っているか？問題を抱えているが、「このワークフローは私たちのプロセスに合わない」と「このワークフローはわかりにくい」の区別をするだけの技術的または運用的な洗練さを持たない顧客は限定的な共同デザインの貢献者です。機能が置き換えるものをどのように現在行っているかを正確に説明できる担当者がセッションに参加するアカウントが必要です。その理解が、提案されたソリューションに対するフィードバックを印象的なものではなく正確なものにするからです。

コホートの上限。 3〜6社です。これはソフトなガイドラインではありません。PMが管理できるものと、CSMが4〜8週間のエンゲージメントにわたって意味ある形で対応できるものの運用上の現実です。6社はすでに野心的です。8社は委員会になります。10社では、共同デザインではなくベータを実施していることになり、共同デザインのフィードバックをサーベイデータと異なるものにする親密さが失われます。

招待の組み立ては選定と同じくらい重要です。 「これを正しく構築するための助けをください」が正しいフレーミングです。「ウィッシュリストをお聞かせください」は誤りです。招待は機能のスコープについて具体的に、時間のコミットメントについて明示的に（通常は4〜8週間にわたって3〜5セッション、各60〜90分）、ロードマップの影響ではなくデザインインプットについてのものであることを明確に、最終的なビルドの意思決定はProductであり共同デザインコホートではないことについて正直に伝える必要があります。適切なコホートを揃えたら、エンゲージメントの構造がセッションが実際のシグナルを生み出すかどうかを決めます。

共同デザインエンゲージメントの構成

8週間を超える共同デザインエンゲージメントは通常スコープクリープを示します。5回を超えるセッションの共同デザインエンゲージメントは、問題が最初から十分に定義されていなかったことを示します。以下の構成は適切にスコープされたエンゲージメントに適用されます。

事前準備：Productが問題声明と制約を共有する。 最初のセッションの前に、参加者はPMから書面のブリーフを受け取ります。解決しようとしている問題、提案されたアプローチが選ばれた理由、交渉の余地のない制約（技術的な制限、法規制上の要件、既存のアーキテクチャの決定）です。顧客は真空の中で共同デザインをしません。何が可能かについてのコンテキストが必要です。それがあって初めて、何が最善かについて意味のあるインプットを提供できます。

セッション1：問題の検証。 このセッションの目的は顧客にソリューションを見せることではありません。Productの問題理解が顧客の実体験と一致することを検証することです。PMが問題声明を提示します。顧客が反応します。「これはあなたが対処していることを正確に説明していますか？」ここでの相違（ほぼ必ず何らかのものがあります）はエンゲージメント全体の最も価値あるアウトプットです。構築作業がロックインされる前に浮かび上がるからです。

セッション2：プロトタイプフィードバック。 PMが初期のプロトタイプまたはワークフローのモックアップを提示します。顧客の仕事：実際に使うかのように進み、反応を実況します。「これは好きですか？」ではなく「次に何をするか説明してください」。CSMが摩擦ポイント、混乱の瞬間、顧客が自発的に提案した回避策を捉えます。エンジニアリングは観察してメモを取りますが、何かを提示したり、弁護したり、説明したりしません。正当化するためではなく、直接聞くためにそこにいます。

セッション3：ソリューションの反復。 PMがセッション2のフィードバックを取り入れた修正プロトタイプを提示します。目的：変更が摩擦を解決したことを確認し、変更によって引き起こされた新しい問題を浮かび上がらせ、機能するデザインに向けて絞り込み始めることです。このセッションは通常セッション2より短くなります。反復が良ければ、異議申し立てることが少ないからです。

セッション4〜5（必要な場合）：最終承認とエッジケース。 これらのセッションは、セッション1〜3が機能をどのように動かすかを完全には解決できなかった複雑なユースケースを持つ参加者のためです。すべてのコホートがセッション4〜5を必要とするわけではありません。3セッションのエンゲージメントがデザインを確定するのに十分なシグナルを生み出す場合、構造のためにセッションを追加すると参加者の時間を無駄にし、プログラムが構築されている信頼を損なうリスクがあります。

参加者のルール。 MIT Media Labのコミュニティベースの技術共同デザインに関する研究は、共同デザインの価値はまさに「共同」（アウトプットだけでなく参加構造そのもの）から生まれることを確認しており、そのため、ここでのベンダー参加モデルは単一のプロダクトチームの存在にロールを集約するのではなく分離します。ベンダー側から：PMがリードし、CSMがファシリテートし、エンジニアリングが観察します。PMはユースケースを聞き、どのフィードバックを取り込むかについてリアルタイムのビルドの意思決定を行うためにそこにいます。CSMはセッションのダイナミクスを管理するためにそこにいます。静かな参加者を引き出し、特定の機能ではなく製品全体を再設計しようとする参加者をリダイレクトし、PMが見逃す可能性のある関係シグナルを捉えます。エンジニアリングは技術的な制約を提示したり実装の選択を弁護したりするためではなく、顧客の言語でユースケースを聞くためにそこにいます。

顧客側から：毎日問題を抱えている実務者であり、エグゼクティブスポンサーではありません。チームから問題について聞いているエグゼクティブは有用な戦略的支持者です。しかし提案されたソリューションがワークフローレベルで機能するかどうかを評価するための運用上の特定性を持っていないため、共同デザインの参加者としては不十分です。適切な参加者は「このタスクをこなすとき、こういう方法でやっています。提案されたフローはXという理由でステップ3で壊れます」と言える人です。

共同デザインセッションにおけるCSの役割

「PM主導の共同デザインセッションはCS主導のセッションと比べて35%少ない批判的なフィードバックを生み出します。評価しているものを構築した人物が部屋にいると、参加者が批判を和らげるためです。」（UserTesting、2024年）

CSはファシリテートします。推奨はしません。 これが最も保つのが難しい線です。共同デザインセッションにおけるCSMの仕事は、顧客に製品について良い気持ちを持たせることでも、批判的なフィードバックから関係を守ることでもありません。誠実なシグナルを表面化することです。顧客のフィードバックが曖昧な場合のフォローアップの質問、顧客が丁寧に表現しているがっかり感を引き出すこと、トランスクリプトを和らげないことです。

支配的な参加者の管理。 ほぼすべての共同デザインコホートに一人います。積極的で明確で声の大きい顧客で、その意見が他の参加者を圧倒します。CSMのファシリテーションの仕事は積極的に発言時間を再配分することです。「[アカウントA]からはたくさん聞きました。[アカウントB]、あなたのチームのワークフローにとってこれはどうですか？」共同デザインセッションで最も声が大きい発言が最も代表的であることはまれです。

構造化されたアウトプットフォーマットでフィードバックを捉える。 各セッションの成果物はトランスクリプトでもサマリーでもありません。Productがビルドの意思決定を行う際に直接参照できる構造化されたフィードバックレコードです。フォーマット：摩擦ポイント（具体的でワークフローのコンテキスト付き）/ どのアカウントが提起したか / 重大度（ブロッカー / 重大 / 軽微）/ 顧客の提案する修正（提示された場合）/ PMの初期見解（取り込む / 却下 / さらに調査）。このフォーマットはエンゲージメント開始前に合意されます。CSMはセッションごとに即興で作りません。フィードバックを体系的に捉えるプレイブックはセッションノートをバックログに登録できるレコードに変換するための完全な分類法を提供します。

リアルタイムでのスコープクリープのフラグ立て。 参加者が特定の機能ではなく製品全体のデザインを始めたとき（「これについて話しているついでに、ダッシュボード全体の仕組みを再構築したらどうでしょう？」）、CSMがリダイレクトします。「それは素晴らしいより広いインプットであり、別途記録します。今日のセッションでは[特定の機能スコープ]に集中したいと思います。十分に深く掘り下げるために」というリダイレクトはCSMの責任であり、PMの責任ではありません。部屋にPMがいることで、PMがリダイレクトすると防御的に見えがちになります。

共同デザインにおけるProductの交渉の余地のないもの

ビルドの意思決定はProductに属します。 常に。共同デザインは機能の構築方法へのインプットであり、顧客委員会へのビルドの意思決定の委任ではありません。これは登録のフレーミングで述べ、各セッションの開始時に強調する必要があります。「このアプローチがあなたのワークフローに機能するかどうかについてのご意見をお聞きしたいと思います。構築するものの最終的な決定は私たちのものであり、どのインプットを取り込んでいるか、いないかについて正直にお伝えします。」

技術的な制約は交渉の余地がなく、事前に述べる必要があります。 参加者が理想的なソリューションを設計し、PMがなぜどれも技術的に不可能かを説明しなければならない共同デザインセッションは全員の時間を無駄にし、期待の負債を生み出します。セッション1の前に、書面のブリーフで明確に述べる必要があります。「このデザインで技術的に固定されているものはここです。どこにあなたの本当の影響力があるかもここです。」制約の空間を理解している顧客はその中でデザインします。理解していない顧客はその周りでデザインし、実行可能でないフィードバックを生み出します。

顧客は「何を」を共同デザインします。エンジニアとPMは「どのように」を担います。 参加者は「監査証跡を失わずに一括でタスクの所有権を再割り当てできる必要があります」と言えます。それが「何を」です。技術的にそれがどう実装されるか（どのデータモデル、どのAPIパターン、どのUIコンポーネント）はエンジニアリングの意思決定です。「何を」と「どのように」の境界がスコープ規律が生きる場所です。

共同デザインの参加者が互いに意見が合わない場合。 マルチアカウントのエンゲージメントのほぼすべてで発生します。アカウントは異なるワークフロー、異なる制約、異なる「明白な」の定義を持っているからです。Productが仲裁します。不一致を平均化する（「両方を部分的に満足させるバージョンを作る」）のではなく、明示的な決定を行うことによって：「ここで2つの異なるワークフローモデルが聞かれました。私たちは[アカウントAのモデル]に合わせて構築します。主要なICPにより近くマッピングされるからです。[アカウントB]については、機能に合わせてワークフローをどのように適応させることをお勧めするかをお伝えします。」透明な仲裁は不一致が存在しないふりをするより良いです。

エンゲージメントを通じた期待管理

共同デザインにおける期待リスクはアドバイザリーボードのリスクとは異なります。アドバイザリーボードの参加者は戦略的な影響力を期待します。共同デザインの参加者は、自分たちの特定のワークフローがリリースされるものに反映されることを期待します。最終的な機能が設計したものとまったく同じに見えない場合、参加者は共同デザインが本物の協力ではなく形式的なものだったと感じます。

セッション1でモデルを明示的に述べる。 「あなたはここに、私たちが解決しようとしている問題の最も深刻なバージョンを抱えていて、提案されたソリューションが実際に機能するかどうかを教えるドメイン専門知識を持っているからいます。あなたのインプットは私たちが構築するものに直接反映されます。しかし、あなたが唯一のインプットではありません。技術的な制約の中で作業し、複数のユースケースのバランスを取り、単一のアカウントの好みを完全には反映しないかもしれないプロダクトの意思決定を行っています。何を取り込んでいるか、いないか、なぜかについて透明にします。」

アイデアが取り込まれなかった参加者への対処法。 CSMは機能がリリースされる前にプロアクティブに連絡します。「セッション3で[特定のインプット]について話し合いました。最終的に[具体的な理由]のためにこのリリースでは実装しないことにしました。GAで機能を見る前に直接お知らせしたかったのです。」この会話は、参加者が自分でギャップを発見する前に行うと、関係を守る行為です。後で行うと、ダメージコントロールのように感じられます。

デブリーフコールは省略不可です。 誠実な顧客フィードバックを得ることに関するHBRの調査によると、フィードバックエンゲージメントのクローズがインプットが真剣に受け止められたかどうかを見せる場所であり、信頼が確認されるか損なわれるかが決まります。顧客は自分のインプットが処理されただけでなく真剣に受け止められたことを確認する必要があります。すべての共同デザインエンゲージメントは、PMが共同デザイン参加者に以下を説明する30分のデブリーフコールで終わります：ビルドに入ったもの、入らなかったもの、その理由。これがエンゲージメントの正式なクローズです。デブリーフを受け取らない参加者（エンゲージメントを「時間を提供したら機能がリリースされた」と経験する参加者）は、将来の採用を困難にする共同デザインの評判問題の源です。

共同デザインが失敗するとき

3つの失敗モードがほとんどの問題をカバーし、それぞれに具体的な修正があります。

スコープクリープ：顧客が製品全体のデザインをしている。 セッションが特定の機能から製品体験全体の会話にずれています。原因：招待のフレーミングが広すぎた（「製品の改善に役立ててください」）、CSMが十分早くリダイレクトしなかった、またはPMがより広いスコープを開く質問をし始めた（「この種の作業をさらに良くするために他に何がありますか？」）。修正：各セッションの開始時にスコープを再述し、CSMが見えるように遠慮なくリダイレクトするよう訓練し、PM の質問を共同デザインしている機能に厳密に限定します。

関係の囚われ：PMがすべてに同意する。 PMはポジティブな参加者の関係を維持することに集中しすぎて、部屋での対立を避けるために実装する意図のないインプットに同意を示しています。これは2つの問題を生み出します：セッション中に肯定され、GAで裏切られたと感じる参加者と、存在しないコミットメントを過剰に代表するフィードバックレコード。修正：CSM（PMではなく）がセッションの雰囲気を管理します。PMの仕事は聞いて記録することであり、すべての提案に肯定的に応答することではありません。構造化されたアウトプットフォーマット（取り込む / 却下 / 調査）は、どのインプットが対応され、どれがされないかの明示的な確認を強制します。

コホートバイアス：参加者が広いICPを代表していない。 共同デザインコホートは利用可能で積極的だったから選ばれ、対象のユースケースを代表しているから選ばれたのではありません。フィードバックは彼らの特定のワークフローを反映しており、それはエッジケースであり、コアのユースケースではありません。その仕様に基づいて構築された機能は共同デザインの参加者には良く機能し、一般的な顧客ベースには良く機能しません。修正：選定時に問題の深刻度フィルターを厳格に適用します。問題を最も深刻に抱えるアカウントが健全でなく、または利用可能でない場合、より良い候補が特定できるまで共同デザインを延期します。ユースケースの基準よりも関係の基準に合う参加者で代替しないでください。

共同デザイン後：エンゲージメントのクローズ

将来のアクセスを過大約束せずに参加者を称える。 共同デザイン参加者は時間と信頼を投資しました。エンゲージメントのクローズはそれを具体的に認める必要があります。「あなたは[N週間にわたってNセッション / N時間]を提供してくれました。[リリースされたものの具体的な機能]はあなたが直接教えてくれたことを反映しています。ありがとうございます。」これが正しいレベルの認識です。過大約束（「次のこの領域の機能についても真っ先にお声がけします」）は、始まる前に次の共同デザインプログラムで登録の負債を作ります。

共同デザイン参加者はGAの前に最終的な機能を見ます。 これは省略不可です。4セッションに参加した参加者が、他のすべての顧客と同時にGAの告知を見ると、自分のインプットは吸収されたが尊重されなかったと感じます。シーケンス：PMがGAの1〜2週間前に共同デザイン参加者と最終的な機能を共有します。参加者は見逃した重要なものについてフラグを立てる機会があります。その後、すべての人にリリースされます。デブリーフコールの構造、書面によるサマリー、48時間の折り返しはすべて顧客とのフィードバックループのクローズの記事で説明されています。そのケイデンスはここでもベータおよびアドバイザリープログラムとまったく同様に適用されます。

次の共同デザインの前に振り返りを行う。 エンゲージメントのデブリーフは参加者だけのためではありません。内部チームのためでもあります。セッションフォーマットは有用なものを生み出しましたか？どのフィードバックフォーマットが機能しましたか？正しいアカウントが選ばれましたか？招待のフレーミングについて何を変えますか？各共同デザインエンゲージメントの後の60分の内部振り返りは次のエンゲージメントの品質を向上させ、失敗率を時間をかけて下げます。

中堅企業の考慮事項

共同デザインはリソース集約的です。専用のUXリサーチ機能を持たない中堅企業でも実施できますが、期待のサイジングが必要です。最小実行可能バージョン：PM 1名、CSM 1名、アカウント3社、セッション3回、Figmaプロトタイプ不要。平易な言語で説明された初期のワークフローモックアップで機能します。PMが構造化されたアウトプットを読み、CSMがファシリテートし、アウトプットはビルドを知らせるに十分な具体性を持ちます。

「正式なクローズアウトセッションなしに終わった共同デザインエンゲージメントは、構造化されたデブリーフコールを含むエンゲージメントと比較して、GAローンチ時の参加者の期待失望率が2.1倍高くなります。」（Gainsight、2024年）

縮小できないもの：デブリーフコール、問題の深刻度の選定基準、セッション1での明示的な期待設定。これらが構造を支える要素です。それ以外はすべて小規模チーム向けに簡略化できます。GAの後で共同デザイン参加者がどこで定着の準備ができているかを追跡することは、定着障壁の特定が引き継ぐ部分です。共同デザインチームは摩擦ポイントをすでに知っています。ポストセールチームはより広いベース向けの定着を加速させるためにその知識が必要です。

Rework分析： 共同デザインプログラムは運用上は軽量です（3〜6社、3〜5セッション、4〜8週間）が、複数の同時進行する会話にわたってセッションの成果、参加者のヘルススコア、フィードバックの対応結果の厳密な追跡が必要です。Reworkで共同デザインを運営する中堅CSチームは、プロジェクトレベルのタスク追跡を使ってセッション構造を管理し、フィードバックレコードをアカウントのヘルスにリンクさせ、問題の深刻度フィルターをICPデータと並べて表示できます。別のリサーチ管理システムを構築せずに。構造化されたフィードバックフォーマット（摩擦ポイント / 重大度 / PMの対応結果）はReworkのタスクとコメントモデルに直接マッピングされます。

よくある質問

顧客共同デザインの運用モデルとは何ですか？

顧客共同デザインの運用モデルは、4〜8週間にわたって3〜6社の厳選顧客と機能共同デザインを実施するための運用構造です。より広いグループに対して四半期ケイデンスで戦略的方向性を提供するアドバイザリーボードとは明確に区別されます。共同デザインはビルドパイプライン内の特定の機能を形成します。このモデルは4つの規律で動きます：スコープ（製品の方向性ではなく1つの機能）、コホート（忠実度ではなく問題の深刻度による選定）、ロール（CSがファシリテート、Productがビルドの意思決定をリード、エンジニアリングが観察）、期待（顧客は「何を」を共同デザインし、エンジニアは「どのように」を担う）。

共同デザインは顧客アドバイザリーボードとどう違いますか？

アドバイザリーボードは8〜15名の上位顧客を四半期ごとに集め、戦略的な方向性についてインプットします。製品は次の12〜18ヶ月でどこへ向かうべきか。共同デザインは3〜6社のアカウントを4〜8週間にわたって集め、既にパイプラインにある特定の機能についてビルドレベルのフィードバックを提供します。アドバイザリーインプットは「この種の機能を構築すべきか？」に答えます。共同デザインは「この特定の実装が実際に対象ユーザーに機能するか？」に答えます。両者を混同するとアドバイザリー疲れと共同デザインのスコープクリープが生まれます。

共同デザインセッションに誰を招待すべきですか？

選定基準には3つのゲートがあります：(1) 問題の深刻度：アカウントが機能が解決しようとしている特定の問題を抱えていること（理論的にではなく運用上かつ深刻に）；(2) ヘルスコア：緑または黄色のみ。赤のアカウントは自分自身の状況を管理しており、新機能を客観的に評価できません；(3) 能力：参加する実務者が機能が置き換えるタスクを現在どのようにこなしているかを正確に説明できること。その運用上の特定性がフィードバックを印象的なものではなく精確なものにします。コホートの上限は6社です。それ以上では共同デザインではなくベータを実施していることになります。

なぜProductではなくCSが共同デザインセッションをファシリテートすべきですか？

PM主導の共同デザインセッションはCS主導のセッションと比べて35%少ない批判的なフィードバックを生み出します。評価しているものを構築した人物が部屋にいると、参加者が批判を和らげるためです（UserTesting、2024年）。CSのファシリテーターは関係のレイヤーと評価のレイヤーの間に分離を作ります。CSMの仕事は参加者が丁寧に表現している不満を引き出し、リアルタイムでスコープクリープをリダイレクトし、構造化されたフィードバックレコードを捉えることです。トランスクリプトを和らげることなく。PMは観察してリアルタイムのビルドの意思決定を行い、エンジニアリングは顧客の言語でユースケースを聞きます。

共同デザインの参加者が互いに意見が合わない場合はどうすればよいですか？

Productが仲裁します。不一致を平均化したり存在しないふりをするのではなく、明示的な決定を行うことによって：「ここで2つの異なるワークフローモデルが聞かれました。私たちは[アカウントAのモデル]に合わせて構築します。主要なICPにより近くマッピングされるからです。[アカウントB]については、機能に合わせてワークフローをどのように適応させることをお勧めするかをお伝えします。」透明な仲裁は曖昧な妥協より関係にとって良いです。自分のモデルが選ばれなかった理由を理解している参加者は決定を尊重します。後でどちらのワークフローにも合わない半端なソリューションを受け取る参加者は欺かれたと感じます。

共同デザインのデブリーフコールには何を含めるべきですか？

デブリーフコールはPMとCSMが出席し、GAの前に共同デザイン参加者とともに開催する30分のセッションです。ビルドに入ったもの、入らなかったもの、その理由をカバーします。正式なクローズアウトセッションなしに終わった共同デザインエンゲージメントは、GAローンチ時の参加者の期待失望率が2.1倍高くなります（Gainsight、2024年）。書面によるサマリーが48時間以内に続きます。4セッションに貢献してデブリーフを受け取った参加者は真に相談されたと感じます。他のすべての顧客と同時にGAの告知を見る参加者は搾取されたと感じます。

共同デザインエンゲージメントはどのくらいの期間実施すべきですか？

適切にスコープされた共同デザインエンゲージメントは4〜8週間にわたって3〜5セッションで実施されます。8週間を超えるエンゲージメントは通常、問題が最初から十分に定義されていなかったか、スコープが単一の機能では満たせない領域に広がったことを示します。5回を超えるセッションを持つプログラムは中堅企業の73%で参加者疲れによるセッション品質の低下を示します（ProductLed、2024年）。デブリーフコールは省略不可です。それ以外はすべて小規模チーム向けに簡略化できます。しかしデブリーフと問題の深刻度の選定基準がモデルの構造を支える要素です。

もっと詳しく

• 顧客カウンシルとアドバイザリーボード
• 顧客ベータプログラムの運用
• 早期アクセスティアの管理
• 顧客とのフィードバックループのクローズ
• VoCパイプライン：CSがProductにフィードする方法
• CS & Product アラインメント用語集
• 定着障壁の特定