B エンド製品の需要収集、分析、反復的な発売の方法は、C エンド製品の場合と似ています。ただし、B エンド製品のユーザーの役割の多様性と部門間のコラボレーション プロセスの複雑さにより、B エンド製品の需要管理には C エンド製品よりも多くの落とし穴があります。

B サイド製品オペレーターとして、次のような問題に直面し、対処したことがありますか。

• 営業の苦情: 顧客は新しい機能を購入せず、本当に解決する必要がある問題は解決されません。
• 顧客は怒っています。よく使われる機能が突然棚から取り除かれ、使用が中断されたり、機能が約束されていたが、予定通りに反復され、リリースされなかったりします。
• カスタマーサービススタッフは、製品機能の配置が分散しているため、顧客トレーニングの効率に影響している、機能が突然開始されたが、顧客から問い合わせがあったときに初めて知った、と怒って苦情を述べました。
• オペレーションは悲鳴を上げている: 顧客、営業、サービス、リスク管理、法務などの部門から要求があり、収集、分析、管理が混乱している。

私は上記のすべての問題に遭遇しており、同じ落とし穴に陥ったケースが数多くあります。この過程で、私はこの記事を整理して、自分自身に思い出させるようにしました。要約に間違いがあれば、指摘してください〜

B サイドの製品需要管理の落とし穴は、主に需要の収集、分析、反復的な発売の 3 つの段階に分かれています。

1. 要件収集

落とし穴回避ガイド: ステップ 1: 需要収集チャネルを収集し、共有需要フィードバック プールを確立し、需要の種類と反復ステータスに応じて需要を分類および管理することで、需要収集を漏れなくタイムリーに記録し、需要計画と進捗状況を明確に把握できるようにします。

B 側の需要源は社内と社外に分かれており、以下のように分類されます。

需要の発生源が多く、フィードバック情報が複雑で、需要収集の効率が低く、誤りや漏れが発生しやすくなります。上記のチャネルからフィードバックされた問題や要望を運用部門ですべて処理すると、困難でストレスがたまります。重要な要望が見逃されると、顧客からの苦情にもつながります。これに基づいて:

1) 各チャネルごとに統一された連絡担当者を確立します。たとえば、SMB 顧客からのフィードバックはカスタマー サービスに集約され、KA 顧客からのフィードバックはカスタマー サクセスに集約され、販売ニーズは販売サポートに集約されます。

2) 要件は各チャネルの担当者によって共有文書で共同管理され、要件プールが確立され、適時に記録されます。新しいレビューラウンドが開始されると、需要側に通知され、漏れを防ぐために補足されます。

3) 開始された要件、テストされた要件、保留中の要件、および現在のイテレーションで確認された要件については、管理用に個別のテーブルを作成できます。

4) 需要プールを頻繁に見直して優先順位を再設定し、新しい変数の出現に基づいて需要プール全体の優先順位を再設定します。

各リンクの進捗状況は、参考までに次の表に示されています。

この表のプロセスは、主に需要側、製品側、運用側をカバーしており、技術側（レビュー時間、UI、各側の開発時間、テスト提出時間など）については言及していません。

落とし穴を避けるためのヒント 2: ニーズの初期スクリーニングのルールをビジネス側に推進します。ニーズが初めて言及されたときに、フィードバックを提供する人またはニーズと連絡を取る人が、ニーズを最初にスクリーニングして顧客に応答できます。

顧客の要求を単に受け入れ、原則なしにサポートを約束するだけでは、必ずしも顧客の承認を得られるとは限りません。一方で、顧客が要求を提起するとき、彼らは解決策について話していますが、私たちが本当に必要としているのは、顧客の問題点を理解し、実現可能な解決策を提供することです。

一方、機能が顧客を即座に満足させることができるかどうかは、必ずしも顧客がその機能にお金を払う根本的な理由ではありません。要求が最初に提案されるとき、ビジネス担当者は、R&D 側のように Y モデルや 5W2H などの要求分析手法を習得する必要はありませんが、初期段階で多くの不合理な要求を除外するのに役立つ基本的な初期スクリーニング ルールを提供できます。

さらに、ビジネス側であろうと研究開発側であろうと、リクエストを拒否する際は言葉遣いに注意を払う必要があります。

1. 相手の考えに直接反対するのではなく、相手の視点から問題を考えて解決策を提案します。
2. 選択肢が多数ある場合は、顧客の興味を喚起するために、顧客に利益をもたらす最も重要な 3 つのポイントから始めることができます。
3. 計画を提示するときは、相手に不快感を与えないように、明確な情報を述べ、簡潔かつ要点を押さえ、何度も修正してはいけません。

2. 需要分析

落とし穴回避ガイド姿勢3: 顧客のニーズに注意深く耳を傾けるが、それに従う必要はない。5W1H1V法を使って顧客のニーズを深く掘り下げる

需要分析とは、問題から解決策へ、またはユーザーのニーズから製品機能への変換を指します。シノベーション・ベンチャーズの会長である李開復氏はかつてWeiboでこう述べた。「多くのエンジニアや製品マネージャーは、顧客が実際に製品を購入するのではなく、タスクを完了したり問題を解決したりするために製品を使用する必要があることを理解していません。」

「顧客はドリルを買うのではなく、穴を買う」という有名な格言があります。さらに言えば、ユーザーが買いたいのは穴ではなく、穴の背後に反映されたより深いニーズです。ユーザーのニーズの背後には目標と動機があり、さらにその奥には深い価値観と人間のニーズ、つまりマズローのニーズがあります。

したがって、中間業者によって伝えられる情報エラーを回避するために、製品オペレーションは、要求を受ける際に顧客と直接コミュニケーションをとる必要があります。顧客が提案するソリューションを出発点として、5W1H1V法を使用して問題を分析する必要があります。まず、これらの6つの質問をリストアップします。答えを得た後、いくつかの小さな質問をリストアップすることを検討し、問題について包括的な分析と調査を行い、より新しい創造的なアイデアや決定を生み出します。

1) 何 — この製品または機能で何ができるのか?それはどんな問題を解決するのでしょうか?

2) 場所 - この製品または機能はどこで使用されますか?

3) 理由 (目的) — この製品または機能はなぜ必要なのでしょうか?他の製品との違いは何ですか？

4) いつ — この製品または機能はいつ使用されますか?

5) 対象者 — 製品または機能は誰を対象に設計されていますか?誰が使うのでしょうか？

6) 方法 - この製品または機能をどのように使用しますか?

7) 価値 — 製品の価値は何ですか?

落とし穴回避ガイド姿勢4：コミュニケーション後に要件に変更があった場合は、会議の議事録をタイムリーに保管し、関連文書を更新します。要件評価段階では、すべての関連部門がレビューと受け入れ計画に参加する必要があります。

顧客の要望フィードバックが断片化されることを避け、要望コミュニケーションの効率性を高めるためには、顧客が製品を十分に体験し、欠陥があれば指摘するように導く必要があります。要求の伝達後、変更があった場合は、履歴文書による誤った開発を避けるために、文書を適時に修正する必要があります。ソリューションがユーザーのニーズを満たさず、リソースの無駄が発生するのを避けるために、プロトタイプ段階で顧客と可用性を決定する必要があります。

また、B エンド製品には複数のユーザー ロールがあります。機能の設計、レビュー、リリースの際には、複数の関係者が情報を確認する必要があります。以下に例をいくつか示します。

1) リスク管理やコンプライアンスに関わる事業の場合、関連機能の立ち上げには、レビューメカニズムや機密語ライブラリの確立が含まれます。

2) 既存の顧客が認識できる製品の変更については、カスタマー サービスと同期し、製品の発売時に顧客に必ず通知する必要があります。

3) 顧客のカスタマイズされたニーズに対して、設計が一般的なニーズ向けである場合、ビジネスにコンサルティングと処理のプレッシャーがかかります...

3. 反復的なリリース

落とし穴回避ガイド5: ピーク使用時間帯に製品の発売を避ける

リリース期限に間に合わせるためだけに、要件のリリースを金曜日や仕事が終わる時間近くにスケジュールしないでください。問題が発生すると、顧客体験に影響し、解決のために人員を集めることが難しくなります。オンライン時間は、金曜日以外や製品の使用頻度が高くない時間帯にできるだけ固定する必要があります。

落とし穴回避ガイド姿勢6：需要側がオンライン受け入れに参加する

テストと製品の承認に加えて、オンライン要件の欠落や使用上の問題を回避するために、運用側と需要側は、製品をオンラインにして顧客に使用を案内する前に、まず製品を受け入れる必要があります。

落とし穴回避ガイド7: 導入準備と効果評価

オンライン化する前に、関連するチームトレーニングを実施し、オンラインアナウンスと使用ガイドラインを準備します。オンラインで同時にプロモーションを展開する必要がある場合は、事前にオンラインプロモーションのコンテンツや活動資料を準備し、展開前後の商品データ分析、チャネルフィードバックなどを通じて効果評価を行う必要があります。

需要管理はチーム全体で実行されます。製品の需要管理は、需要を記録するだけでなく、需要の計画、実装、効果評価も必要です。各チームによって需要管理の方法が異なり、最も適した方法論が最善です。あなたも落とし穴に陥ったことがあれば、ぜひメッセージを残して共有してください〜

著者:製品運用と原則

出典:製品運用と原則

関連記事:

プラットフォームのB側をうまく操作するにはどうすればいいですか?

Bサイドの業務活動のレビュー：目的とユーザーの特定

優れた B サイド操作の 6 つの指標!

B サイド操作の場合、プライベート ドメイン トラフィックを生成するにはどうすればよいでしょうか?