ユーザーフィードバック業務と顧客サービス（Bサイド製品業務：需要管理の落とし穴を避けるためのガイド）

Bサイド製品運用：需要管理の落とし穴を避けるためのガイド

編集者注: B サイド製品業務は、製品とユーザー、生産・研究部門、マーケティング サービス部門をつなぐ役割を果たします。これらは外部からの要求に対する統一された入口であり、新しい機能の出口です。 B サイド製品オペレーションにおける需要関連の知識の習得は、製品の秩序ある反復と顧客満足において重要な役割を果たします。本稿の筆者は、B サイドの業務で注意すべき 7 つの問題を、需要収集、需要分析、需要反復の 3 つの側面から整理・分析し、誰もが学習し、参考にできるようにしました。

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

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

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

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

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

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

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

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

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

2) 要件は各チャネルの担当者によって共有文書で共同管理され、要件プールが確立され、適時に記録が作成されます。新たなレビューラウンドが始まると、需要側には漏れを避けるために注意喚起と補足が行われます。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

さらに、B エンド製品には複数のユーザー ロールがあります。機能の設計、検討、リリース時には、複数の関係者が情報を確認する必要があります。以下にいくつか例を挙げます。

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

2) 既存の顧客が認識できる製品の変更については、カスタマー サービスと同期し、製品がオンラインになったときに顧客に通知する必要があります。

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

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

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

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

需要管理はチーム全体にわたって行われます。製品需要管理は、需要を記録するだけでなく、需要の計画、実施、効果評価も必要です。各チームには異なる需要管理方法がある場合があり、最も適した方法論が最適です。あなたも穴を踏んだことがあるなら、ぜひメッセージを残してシェアしてください〜

この記事はもともと、Everyone is a Product Manager で @产品操作术与道 によって公開されました。著者の許可なく複製することは禁止します。

タイトル画像は、CC0 プロトコルに基づいて Unsplash から取得したものです。