製品運用翻訳（運用の観点から見たToB製品のニーズ）

運用面から見たToB製品の需要

編集者注: To B 製品は他の製品とは異なります。企業向けであり、運用時に注意すべき点も異なります。この記事では、To B 製品の需要を 4 つの角度と運用の観点から検討します。お役に立てれば幸いです。

製品オペレーション業務を行う際には、製品の需要に対応することが不可欠です。もちろん、オペレーションが製品の需要について決定を下さないことは不適切です。これがプロダクトマネージャーの役​​割です。オペレーションは提案権を行使し、提案すべき内容は「顧客の実情や市場動向を踏まえた合理的な提案」です。

同時に、業務システム全体における業務の位置づけは、過去と未来を繋ぎ、内と外を結びつけることです。日常業務において、情報伝達や評価の意思決定においては、オペレーション側は考え方を調整し、常に最終目標を念頭に置き、製品ニーズの効果的な伝達と価値の実現を確実に行う必要があります。

そのため、B面業務を行い、商品需要に関わる場合には、まず業務目標と仕事の姿勢を明確にする必要があります。

私が提唱する運用目標は「パフォーマンス」、つまり注文の実施、注文の更新、購入の増加です。

会社に利益をもたらすこと以外、他の派手な用語には実質的な意味はありません。したがって、「運用」の観点から製品の需要を判断することは、最終的には「パフォーマンス」、つまり、この需要が顧客のお金に見合う価値があるかどうかによっても決まると私は考えています。購入代金をすぐに支払うことができる場合は、急いで支払う必要があります。履行できず、相手側が契約を解除したり返金を求めたりした場合は、さらに考慮する必要があります。

製品開発チームが考慮する必要がある技術的なソリューションと投資コストについては、製品運用部門が理解する必要がありますが、判断を下す際の第一の要素ではありません。さらに、現実には、製品運営側がどれだけ「性能」という要素を追求しても、技術的な枠組みやコストといった極めて現実的な問題が手綱を引いてブレーキをかけてしまうことになる。

したがって、あなたの判断が不適切であるとか、あなたが追求する目標があまりにも功利主義的であるとか心配する必要はないと思います。結局のところ、あなたは提案する権利を行使しているだけで、最終決定を下すわけではないのだから、何を恐れているのですか?必要なときに話し、必要なときに理論を使用します。プロダクトマネージャーと議論するのは普通のことであり、沈黙を続けることはお勧めできません。

自分の立場を理解し、製品の需要にどのように影響を与えるかを考えてみましょう。

回答: 統一された評価基準を確立した後、ニーズの優先順位を調整します。

私の仕事経験と、これまで扱った製品要件文書によると、多くの人が要件を 3 つのレベルに分けるのが習慣になっています (中国人の趣味でしょうか)。これは次のように表現されます。

• 数字「1、2、3」
• 文字「A、B、C」
• テキスト「高、中、低」;
• 他には「高、中、普通」などがあり、形は異なりますが意図は似ています。

「1、2、3」という数字は人々を混乱させる可能性があります。優先順位が最も高いのは 1 と 3 のどちらですか?

テキストのレベルは「高、中、低」の3つしかないため、拡張が困難です。

だから私は「A、B、C」という文字を使うことが多いです。では、「A、B、C」はどのように意味を表すのでしょうか?

私が言いたいのは、「緊急性」と「重要性」を組み合わせることで優先度を評価できるということです。

その中でも、To B ビジネスの顧客はいつでもあなたの製品を使用しているため、問題があればできるだけ早く解決する必要があるため、緊急度を優先します。結局のところ、「安定こそが全てに優先する」のです。そして、「重要な」ニーズは、効率性の向上、コストの削減、競合他社への攻撃など、どこに重点が置かれているかによって異なります。それとも、KA の顧客が言及したから、非常に重要だと思われるだけでしょうか?判断する次元が多すぎるということは、特に「重要」ではないということなので、「重要」よりも「緊急」を優先すべきだと思います。

同様に、製品要件の優先順位の配置原則は次のスキームを参照できます。

優先度評価基準を整理した後、特定の需要を具体的にスケジュールする際にはどのように評価すればよいでしょうか。

以下の6つの次元を参照できます。

製品の需要を判断するには、まず「あるかどうか」という問題を解決するかどうかを見て、競合相手の要素も考慮します。

顧客がこの要求を明確に提起するのは、既存の製品機能とサービスではこの問題を解決できず、開発する必要があるためです。また、市場で唯一のサービスプロバイダーである場合、顧客には選択の余地がなく、顧客はそれを使用しているため、待って様子を見るしかありません。何もできません。

しかし、現実には、利益を生む事業を行っている会社は複数あるはずです（特殊な業界でない限り）。顧客には選択肢があり、競合他社にはこの機能がありますが、あなたにはそれがないので、この市場で存在感を示すことはできません。

したがって、「かどうか」という問題を解決することが最優先事項であり、通常は A または B にランク付けされます。

これは、製品の需要の実現とそれが顧客の最終的な利益に与える影響によって決まります。一般的に、収益の増加、コストの削減、効率性の向上、ブランド価値の付加など、いくつかの影響があります。私はソフトウェア開発の分野で働いており、これらが私が接する主な影響です。

優先順位は次のとおりです。

• より少ない費用でより多くの収益を得られるものを優先するため、マーケティング関連の機能やサービスは特に重要であり、AまたはBにランク付けされます。
• 作業負荷の軽減は製品ユーザーが最も気にかけていることですが、顧客をなだめるためにそれを「引き延ばす」ことで少し後回しにしてしまう可能性があります。操作体験が本当にひどい場合を除き、通常は C にランク付けされます。
• ブランド付加価値に関しては、サービス提供者の影響力を見ることが前提となります。国内企業の多くはOracleやSAPを利用する傾向にあります。これらの製品は本当に適切ですか?不確か。しかし、使ってみると、「このお金は価値がある！」という無形のブランド付加価値効果があります。

私が言及した「利便性」とは、顧客が製品を使い始めるのがいかに簡単であるかを指します。

「この製品は機能は良いのですが、操作が簡単ではありません。使い方を覚えるのに時間がかかりました。」

顧客がこのように言う場合、理由は 2 つしかありません。1 つは、製品の設計が不合理であることです。もう 1 つは、アフターセールス トレーニングが実施されていないことです。

顧客は間違っていません。おそらく彼は理解力に偏りがあるか、あるいは他の操作方法に慣れているのかもしれません。しかし、製品が使いにくいというフィードバックをし続ける限り、彼は間違いなく製品を使い続ける自信を持てないでしょう。彼が買ったものが、使わないのなら、どうして役に立つのでしょうか?

そのため、「利便性」の第一条件として「始めやすい」ことが第一位となります。

「美観」、つまり見た目が良いかどうかについては、ある程度の犠牲を払うことができます。

なぜなら、To B 製品はまず顧客に使用され、継続的な使用によって結果が得られなければ、顧客はサブスクリプションを更新するかどうか (または支払うかどうか。結局のところ、「トライアル」というものがある) を検討しないからです。

「見た目が良い」ということは、顧客の使用が安定していて、競争圧力が大きくない場合にのみ考慮されるものです。

もちろん、醜いことは絶対に受け入れられません。この種の要求は一般的に D ランクになります。

バックログ製品の要求の多くは、半年または 1 年前に何度も議論されている可能性があり、この状況には特別な注意が必要です。多くのToBビジネスでは年会費を請求するため、長い間蓄積されてきた問題が解決されておらず、後から請求することが困難になります。

これはサービスプロバイダーの技術的能力の問題ではなく、サービス姿勢と運用メカニズムの問題です。したがって、緊急でなくても、B または A に切り替える必要があります。

ただし、製品のバグを処理する場合は、その逆を行う必要があります。数か月前に提出されたバグに解決策がない場合は、新しく提出されたバグの解決を優先してください。顧客に与える印象は、「常に問題を解決できない」というよりも、「常に問題を解決している」というものであるべきです。これは主に、最前線の同僚がアフターサービスを提供しやすくなるようにするためです。

もちろん、製品の要件/バグが長期間存在し、大規模な問題である場合は、A に転送して、製品開発チームに解決するための特別なグループを設置するように依頼することもできます。

対象範囲は、数量、業界（カテゴリ）、地域など、いくつかの次元に分けることができます。

同じ製品の需要に対して、10 社が言及し、100 社が言及した場合、需要がますます緊急になっていることを意味します。これら 10 社のみが言及している場合は、優先度は低くなり、一般的には C にランク付けされます。

一部の要件は特定の業界でのみ使用されます。例えば、私は現在、AIチャットロボットの製品需要分析を行っています。アパレルの顧客はサイズの推奨に関して高い要求を持っています。間違ったサイズが推奨された場合、購入者は商品を返品または交換する必要があり、店舗の運営コストが増加します。したがって、パターン関連の要件やバグは、サイズ推奨機能は常に実行されているため、通常は B または A に配置されます。そうでない場合は、オフにする必要があります。

To B 製品の顧客基盤は、一般的に集中している傾向があり、同じ業界の経営者や管理者がサークルを形成していたり​​、家族であったりすることもあります。自社製品の機能の品質を自ら宣伝する必要はありません。人々は非公開の話し合いを通じて合意に達することができます。

もうひとつの状況は、特定の地域や分野にベンチマークとなる顧客が存在する場合です。この顧客がどのような製品を使用していても、この地域の顧客もそれに従うでしょう。したがって、製品要件を確認するときは、この要件を提案したのは誰かを明確にする必要があります。影響はどうですか?

競争要因に関しては、製品の需要を分析する際に参照すべき 2 つの主要な原則があります。

1) 相手が持っているものは何でも、私も持っていなければなりません。たとえ実用性があまり高くなくても、顧客にお金を払ってもらえるような機能を開発することが重要です。 To B の動作はパフォーマンスに依存します。市場が他社に奪われてしまったら、どうすればいいでしょうか？あなたは自分の立場を守らなければなりません。

2) 差別化は避けられないので、常に先頭に立っていなければなりません。誰もが同じタイプの顧客にサービスを提供しており、差別化戦略を採用しているかもしれませんが、受注競争になると、コア機能が比較の対象となることは間違いありません。現時点では、どちらの会社の機能の方が実用的で、メリットがより明らかであるかによって異なります。したがって、競合製品への影響を考えると、自社製品のコア機能とセールスポイントが最優先される必要があります。

「運用」の役割を担い、需要スケジュールを整理できる場合は、製品マネージャーと優先順位を調整する必要があります。具体的なコミュニケーションと配信のプロセスでは、争いを避け、コミュニケーションの効率を高めるために、次の 5 つの原則を習得する必要があります。

特に、最前線の担当者や顧客とのコミュニケーションにおいては、人為的な閾値を設定しないでください。

平易な言葉に翻訳できないさまざまな専門用語や名詞については、注釈を追加し、例を挙げる必要があります。

あなたの製品のターゲット ユーザーは高校卒業生かもしれませんが、特定の機能に英語で名前を付けることにこだわると、トラブルを招くことになるのではないでしょうか。

「顧客から出された要求は必ずしも合理的な要求ではない」ということは誰もが言えることです。そのため、多くの運用チームはまず自分たちで判断し、不合理だと思われる要求を直接除外することを好みます。その結果、製品マネージャーや研究開発チームはそれらを受け取ることができず、顧客は非常に不安に思う可能性があります。

正しいアプローチは、顧客の元の言葉を記録し、それを作業指示書または要求概要シートに保存することです。この要求は合理的ではないかもしれないし、短期間で達成できないかもしれないが、提起された以上、実施できる他の解決策がある場合に備えて、少なくとも記録を残しておくべきではないだろうか。

したがって、実際には、製品開発チームに連絡するときに、「まだサポートされていません」というメモを追加するだけです。プロダクトマネージャーに時間があれば、また話し合うことができます。

各機能およびサービスに使用される文言は、多様化したり理解が難しくなったりすることなく、一貫性を保つ必要があります。

アカウントは最初から最後までアカウントです。これは製品 A にも製品 B にも当てはまります。この場所は「設定」と呼ばれ、あの場所は「構成」と呼ばれていますが、これは間違いなく機能しません。

これは製品設計だけでなく、需要の説明や製品の外部パッケージにも当てはまります。一貫性を保つことによってのみ、全体的な調子を形成することができます。

この要件は以前に一度処理されており、製品マネージャーによって拒否されたか、後でスケジュールされた可能性がありますが、無視できるという意味ではありません。

需要の源は顧客ですから、あなたが覚えていなくても、顧客は覚えているのです。多くのプロダクトマネージャーは物事を忘れがちで、蓄積された多くの要求をスケジュールする時間がなく、結局は未解決のままになってしまいます。

運用の観点から見ると、この現象は明らかに不合理です。要件の提出時期を定期的に確認し、最後までフォローアップする必要があります。

逆の場合も同様です。製品開発チームは長い期間懸命に努力し、ついに製品を発売しました。運用チームは、実装の効果と顧客からのフィードバックをフォローアップする必要があります。これは、バックエンドチームの作業成果の重要性と認識を示すものでもあります。

企業の企業価値がどれだけ「顧客第一」を重視していたとしても、多くのプロダクトマネージャーは依然として世間と乖離した習慣を持っています。

最も典型的な例は、顧客が「これこれこれが必要です」と言い、製品マネージャーが「私たちのデザインはこれこれです。あなたはこれこれこうすべきです...」と言うというものです。

誰がそのルールを作ったのですか?なぜ顧客はあなたの言う通りにしなくてはならないのですか?

現時点では、オペレーションは顧客側に立つ必要があります。なぜなら、To B ビジネスでは、寡頭政治家でもない限り、顧客を教育するために製品設計に頼ることはできないからです。たとえば、Alibaba はこれを実行できますが、あなたは Alibaba ではありません。しかし、アリババの第一の価値観は「顧客第一」です！

まとめると、これは最近の製品ニーズに関する私の新たな理解と再編成です。そこに含まれる内容と原則は時間の経過とともに変化する可能性があり、場合によっては最初からやり直す必要が生じることもあります。

しかし、物事を行う際には基準が必要です。そうでないと、ただ盲目的に行うことになります。これらの内容がその後の作業において実用的かつ合理的であるかどうかについては、さらなる実践と議論を重ねて検証する必要がある。

この記事はもともと @段琛 によって Everyone is a Product Manager に掲載されました。無断転載禁止

タイトル画像はCC0ライセンスに基づいてUnsplashから引用しています