B2B SaaSのデザインパートナーを見つけるには、学ぶ必要のあるワークフローを定義し、そのワークフローを実際に経験している組織を特定したうえで、実際のユーザーと社内スポンサーに範囲を限定した協業を依頼します。双方が何を提供するか、いつ結果を振り返るかを合意してください。有益なパートナーシップは繰り返し利用されることの証拠を生み出します。デモでの熱意は出発点にすぎません。
本当に必要な関係性を選ぶ
ある組織が、複数回のプロダクト改善にわたってあなたと協業します。学びたい問い、関連するワークフローへのアクセス、実際にその業務を行う人との定期的なレビューについて合意します。
個人が初期リリースを試し、何が起きたかを報告します。より長期的な組織としてのコミットメントなしに、ユーザビリティやオンボーディングを集中的に確認したい場合は、ベータユーザーのガイドを参照してください。
組織が合意したプロダクトやサービスを購入します。デザインパートナーが顧客になることもありますが、学び、自立した利用、支払いは記録上それぞれ別の項目として扱ってください。
1つのワークフローと接点のある組織から始める
- 不確実な点を1つ書き出します。たとえば「アカウントマネージャーは、創業者の立ち会いなしに、実際のクライアント引き継ぎの場面で当社の引き継ぎチェックリストを使えるか？」です。これによりパートナーシップに具体的な目的が生まれます。
- 関連する企業ページ、公開されている業務プロセスの説明、またはその業務を知る人からの紹介を通じて、そのワークフローを運用している組織を特定します。情報源と日付を記録してください。役職名だけでは課題の存在を裏付けられません。
- 紹介者に、そのワークフローを実際に担当している人をつないでもらいます。最初の会話では、その人に最近の具体的な事例、現在の代替手段、そしてトライアルの承認が必要な人を説明してもらいます。
- パイロットを提案する前に、短いスコーピングの会話を提案します。現時点で何ができているか、どのようなサポートを提供できるかを説明してください。営業シーケンスに押し込むことなく、組織が断れる余地を残します。
パートナー適格性評価ワークシートをコピーする
組織ごとに1件の記録を作成します。各回答に「観察済み」「推測」「不明」のいずれかを付け、その情報源と日付を残してください。実際の利用を妨げる不明点は、その組織をパイロットに招く前に解決すべき問いです。
- 組織とセグメント：[名称]、[他の見込み顧客と共通するワークフロー]、[代表的だと言える理由]。
- 現在の業務：[直近の事例]、[代替手段]、[現状のままにした場合の結果]、[情報源/日付]。
- 関係者：[実際のユーザー]、[社内スポンサー]、[購入を承認できる人]、[未確認のままの役割]。
- アクセス：[組織が共有できそうなサンプル入力]、[環境]、[権限の管理者]、[ブロックされている前提条件]。
- コミットメント：[ワークフローを試す人]、[レビューの頻度]、[確保できる時間]、[次に合意した打ち合わせ]。
- 創業者の負担：[セットアップの工数]、[サポートの上限]、[プロダクトの方向性から外れるカスタム要望]。
- 判断：[招待・確認・辞退]、[最も有力な反証]、[未回答の問い]、[見直し日]。
架空の2つの候補：熱意だけでは不十分
以下は、小規模エージェンシーのクライアント引き継ぎを調整するプロトタイプを題材にした、架空の教育用の例です。Soloopの顧客でも、測定された結果でもありません。
アカウントマネージャーが最近の引き継ぎミスを順を追って説明でき、匿名化したチェックリストを共有する許可も得ています。オペレーション責任者は定期レビューに参加できます。ワークフローはプロトタイプと合致しています。購入権限はまだ不明なため、次の会話ではその点を確認しますが、支払いが約束されたものとしては扱いません。
熱心な役員が、プロトタイプが対応していないワークフロー向けのカスタム連携を求めています。参加できるアカウントマネージャーはおらず、サンプル入力も入手できません。創業者は要望を記録したうえで辞退します。役員の関心は、実際に機能する協業の代わりにはなりません。
1ページのパイロット学習概要書をコピーする
適格性評価の後、双方で一緒に記入します。これは業務計画のための文書であり、契約書のテンプレートではありません。双方が無理なく続けられる期間と頻度を選んでください。以下の例はスケジュールの一案であり、普遍的な基準ではありません。
- 問いと範囲：[1つの仮説]、[1つのワークフロー]、[プロトタイプのバージョン]、[対象外とするもの]。
- 参加者とアクセス：[ユーザーとスポンサー]、[承認済みのサンプル入力]、[アクセスの範囲]、[ブロックされた前提条件を解決する人]。
- 日程：[開始日]、[終了日]、[レビュー日]、[初回利用に立ち会う人]。たとえば、週1回のレビューを伴う3週間の学習期間などです。
- 提供するもの：[パートナーによる試行とフィードバック]、[創業者によるセットアップとサポート]、[カスタム作業の時間上限]。
- 証拠：[試したタスク]、[自力で完了したか支援を受けて完了したか]、[障害]、[次の試行]、[メモの保存場所]。
- 終了レビュー：[有料プロダクトを提案するために必要な証拠]、[範囲を限定した延長に値する不確実性]、[終了の条件]、[アクセスと共有資料の取り扱いについての合意内容]。
学びを記録し、次の段階・見直し・終了を判断する
各レビューでは、機能要望について話す前に、ユーザーに直近の試行を見せてもらいます。創業者の支援が必要だった箇所を記録してください。すべての引き継ぎをあなたが手作業で補修したからこそ完了したワークフローは、まだプロダクト単体の価値を示しているとは言えません。
繰り返しの利用が想定したジョブを解決しており、購入者がプロダクトの提案について話し合いたいと考えています。範囲、価格、次のステップは別途合意してください。支払いは実際に発生してから記録します。
未解決の具体的な障害が1つあり、次の意味のある試行を妨げています。変更内容、観察方法、終了日を合意した場合にのみ延長してください。無期限の無償カスタム開発の取り決めは避けます。
Cedarは学習期間を終え、アカウントマネージャーは支援なしで引き継ぎを実行します。その後、購入者から、チームでアカウント担当者が変わることはまれで、既存のチェックリストを使い続けると説明を受けます。「学習完了、購入なし、継続的なニーズ不足」と記録します。パイロットを終了し、引き継ぎがより頻繁に発生する組織を調査します。
情報源と次のリサーチステップ
暫定的なパートナー像と未解決の問いをSoloopに持ち込み、Soloopが対応する、範囲を絞ったリサーチタスクについて相談してください。進める前にそのアクションカードを確認してください。リサーチレポートは候補リストの参考になりますが、会話を行い、パートナーシップを管理するのは引き続きあなた自身です。
a16zは、緊急性、対応余力、代表性の観点からデザインパートナーを評価し、学習のための関係と最終的な支払いを切り分けて扱っています。上記のワークシートと架空のシナリオは、Soloop編集部による例です。
a16z: A Framework for Finding a Design Partner