需要を実用的な製品ソリューションに変える方法!

ここでは、企業がすでに一定規模のユーザーを抱えており、ユーザーポートレートを確立していると想定します。

また、コアユーザーグループに何が必要かを判断するために需要分析も行いました。

1. 主要な指標を決定する - 行動する前に考える

分析: この要件の重要なポイントは何ですか?出力製品ソリューションが適切かどうかを判断するにはどうすればよいでしょうか?

そのため、アウトプットの前に成果に対する評価指標を確立する必要がある。

まず、重要な指標を出して、以下の点を明確にする必要があります。

ユーザー特性は何ですか?
どのようなシナリオでユーザーはこのような要求をするのでしょうか?
このシナリオでは、ユーザーの懸念は何でしょうか?
このシナリオにおけるユーザーの目標は何ですか?

1に関しては、企業や製品によってユーザー層や特徴が異なるため、製品の品質の評価基準も異なります。例えば、ゲーム会社のユーザーは、主に10代の若者、学生、会社員です。骨董品や不動産の電子商取引商品の利用者は、主に中高年層です。

2に関して、どのようなシナリオでユーザーはこの需要を持つのでしょうか？シナリオが異なれば、ユーザーの操作行動や要件も変わります。例えば、タクシー配車サービスの場合、ユーザーは買い物に疲れたときや、なじみのない場所への旅行中にこの需要を持つでしょう。例えば、ショートビデオサービスの場合、ユーザーは地下鉄に乗っているときやバスを待っているときにこの需要を持つでしょう。

3 に関しては、ユーザーの焦点はシナリオによって異なり、焦点が異なれば製品設計の焦点も異なります。たとえば、電子商取引製品では、ユーザーが製品を閲覧しているときは製品の品質、外観、価格などの情報に注目しますが、支払いプロセスでは、ユーザーは住所情報、割引情報、財務セキュリティ、消費リスクなどの機能に注目します。

4 に関しては、ユーザーはさまざまなシナリオでさまざまな目標を持っています (ここでは、ユーザーの心理的な事前設定目標であるユーザー目標と製品目標を明確に区別する必要があります)。たとえば、電子商取引製品では、製品を閲覧する際のユーザーの目標は、興味のある、見た目が良く、楽しく、費用対効果の高い製品を見ることです。また、支払いプロセスでは、ユーザーの目標は、購入操作をスムーズに完了し、資金の安全性を確保することです。

これらの質問を分析して回答した後、この機能のリリース後のデータ（ユーザー数、日次アクティブユーザー数、月間アクティブユーザー数）の予備的な予測が得られます。

2. 製品ソリューション設計 - 単なるコピーではない

このニーズを満たす機能がすでに市場に存在するかどうかを調査し、Baidu や Tieba などのチャネルで競合製品を探します。

すでにユニコーン製品がある場合は、Tieba でその製品のユーザーレビューと評判を確認する必要があります。

最後に、分析の主な競合相手として、評判の良い製品とユニコーンを選択しました。

1. 競合製品分析

この機能に関して競合他社製品の製品構成をリストアップし、比較した上で共通機能と相違機能を整理し、つまり「基本機能」と「ハイライト機能」を取得します。

「基本機能」として、私たちの製品にもそれがなければなりません。ユーザーの否定的なレビューに基づいて最適化します。

「目玉機能」は各製品の目玉であり、運用促進やユーザー獲得・維持の鍵となるため、自社製品の「目玉機能」についても考える必要があります。ハイライト機能の設計には、前述の「主要なパフォーマンス」を考慮し、会社の既存のリソースと組み合わせて検討する必要があります。

競合製品の分析を終えて、製品計画の概要はすでに頭の中にあります。

市場にこの機能を備えた競合製品がない場合、おめでとうございます。MVP を作成し、反復的な最適化を経て徐々に拡張し、プロダクトマネージャーの能力を十分に発揮することができます。

2. ビジネスプロセス図を出力する

職場のリーダーの多くはプロトタイプを直接出力することを要求しますが、私の経験では、このステップはプロダクトマネージャーの論理的思考能力のテストになります。その理由は次のとおりです。

1) プロトタイプを作成するときは、ビジネスプロセス図や製品構造図を頭の中で構築する必要があり、インタラクション設計やインターフェース要素のレイアウトなども考慮する必要があります。プロトタイプが完成したら、それについて話し合う会議が開かれます。このときに問題が見つかった場合、プロダクトマネージャーは仕事に戻らなければならないだけでなく、全員の時間を無駄にすることにもなります。

2) ビジネスプロセス図ではプロセスを表示できるため、統合や短縮が必要なプロセスが一目でわかるため、後続の機能モジュールの分割や同じページ（キーページ）の設計の統合に便利です。ユーザーが常に新しいページを入力する必要がなくなり、R＆Dおよび設計チームの作業負荷が増加することを防ぎます。

3) ビジネスプロセス図は、異常なプロセスを明確に整理して完了することができます。異常なプロセスの処理も非常に重要です。発売初期段階での製品の評判に影響を与えます。WeChatの初期のユーザーレビューを見ると、異常な状況に関する否定的なフィードバックが多くあります。これにより、チームはユーザーを取り戻すために迅速に反復して最適化する必要があり、多くの残業をしなければなりません。

そのため、プロダクトマネージャーはビジネスプロセス図を注意深く出力し、繰り返し熟考することをお勧めします。（競合製品を分析するときにこの方法を採用することをお勧めします。多くのメリットがあります）プロセスのレベルに応じて、複数のビジネスプロセス図を出力できます。一部のクローズドループ機能は、別の図で詳細化し、メイン図のモジュールに直接置き換えることができます。

3. 出力機能構造図

ビジネスプロセス図が整理されると、機能構造図がすぐに作成されます。

機能構造図の鍵は、各モジュールのアプリケーション境界を明確にすることです。これにより、後続の反復で新しい機能が生成されたときに機能の帰属が混乱し、ユーザーの理解が困難になり、エクスペリエンスが悪くなるのを防ぐことができます。

4. 主要データ指標の設計

製品デザインのプロトタイプが完成したら、主要なプロセスとページの埋め込みポイントの設計について検討する必要があります。

もちろん、まずは定量化する必要のある指標とその計算方法を考え、次にポイントを埋め込む必要のある場所とカウントする必要のあるフィールドを推測する必要があります。

1) 主要ノードの統計

記事冒頭の「ポイント」に基づいてデータ指標を設計します。たとえば、電子商取引製品の取引量がキーノードである場合、このノードのPV、UV、注文量、支払い量などのデータを収集する必要があります。最後に、収集されたデータに基づいて、ユーザー品質、製品品質、ARPUなどの指標が計算されます。

2) 主要プロセスの統計

例えば、学習プラットフォームのログインや登録プロセスは、新規ユーザーを獲得するための重要な測定プロセスであるため、ユーザーの操作のあらゆるステップでデータを収集し、減衰グラフを作成して、ユーザー離脱の原因となる行動を分析・特定し、その位置を最適化する必要があります。

データの定量化は、その後の製品イテレーションの重要な基礎となります。これにより、欠点を定量化し、重要な指標を科学的に改善することができます。製品を設計する際には、皆さんが計画を開始することを願っています。

5. プロトタイプ画像の出力

構造図に従ってモジュールを区別し、フローチャートに従ってキーページを整理し、インタラクションのスムーズさと要素配置の合理性を重視します。ユーザーは複数の業務ラインからキーページにアクセスするため、キーページには特別な注意を払う必要があります。

私の経験では、プロトタイプの設計は動的にも静的にもできます。一般的に、顧客へのプレゼンテーションには、忠実度の高い動的プロトタイプが必要です (2B)。

チーム内の R&D 同僚にプロトタイプを見せるとき、特定のコミュニケーションと会社の規制が必要です。R&D 同僚の中には、静的かつ説明的なプロトタイプを好む人もいます。

6. 出力prd

prd の出力は、会社の規定に従って出力できます。プロトタイプ図 + ロジック記述のみが必要な会社もありますが、インターフェイスでは記述できないバックエンドロジックが多い会社もあり、prd が必要になります。

3. 製品ソリューションのデモンストレーション - 技術を急いで見つけない

プロダクトマネージャーがテクノロジーを探すソリューションを採用する場合、後戻りできない戦線に乗り出すことになるため、注意が必要です。

私自身の経験に基づいて、この段階の自己検査方法をお伝えします。

自己テストの質問:

設計された機能はニーズを満たしていますか?
このデザインはユーザーに好まれる選択肢でしょうか?
この機能を使用することを選択した場合、ユーザーに費用はかかりますか?
この機能はユーザーにリスクをもたらしますか?

1については、設計当初の意図が達成されているかどうかを振り返ります。最初の「要点」の要件を振り返ってみてください。ユーザーのニーズを解決できれば合格です。

2 に関しては、需要は存在するものの、ユーザーには多くの解決策があり、必ずしもあなたが提供する方法を選択するわけではありません。ユーザーがより効率的で好ましい方法を持っている場合、ユーザーベースは予想よりも少なくなります。

3 に関しては、多くのソリューションではユーザーがこの機能を使用することを要求しますが、ユーザーにかかるコストを考慮していません。たとえば、ユーザーは多くのソフトウェアやプラグインなどをインストールする必要があり、これは一部のユーザーが考慮する必要があるコストです。

4に関しては、ユーザーにとって金銭的、心理的、時間的、社会的リスクはありますか？現時点では、「要点」のユーザーポートレートに基づいてリスクを一つ一つ分析する必要がありますが、これらの問題がユーザーにマイナスのブランド印象を与えることは誰もが理解していると思います。

4. R&Dとのつながり - リーダーの姿勢を使わない

この作業段階では、多くの製品マネージャーにとって、R&D の同僚とのコミュニケーションも頭痛の種です。私の経験では、リーダーシップの姿勢で R&D に要件について話さないでください。

プロダクトマネージャーは次のように考えます。「長い間懸命に努力して、ようやく製品プランができました。それを彼らに渡せば、彼らはただそれに取り組むだけです。なぜ彼らは私に質問し続け、問題を起こすのでしょうか?」

しかし、R&D チームの考えは、「私たちの R&D は会社の中核です。なぜプロダクトマネージャーであるあなたが私たちに指示を出すのですか? なぜ私たちはあなたの言うことに耳を傾けるべきですか?」というものです。

このようにすると、R&D の同僚は製品計画に反対しているわけではない (製品設計が非常に悪い場合を除く) が、製品マネージャーの態度に何か問題があると考えていることがわかります。製品マネージャーの中には、リーダーの指示に従って R&D チームに強制的に実行させる人もいます。したがって、チーム内で R&D に対して大きな抵抗に直面しているプロダクトマネージャーは、R&D とやり取りする際の自身の態度を振り返る必要があります。

製品マネージャーの本来の意図に戻ると、製品が完璧に実装されることを期待しています。この目標を念頭に置くことで、よりフレンドリーな方法で R&D に出力することができます。私の経験に基づくと、方法は次のとおりです。

1) ストーリーテリング

ユーザーの苦痛やニーズの緊急性を涙ぐましく感情的に表現することで、R&D 担当者の共感を引き出し、内面からモチベーションを生み出すことができます。

2) 研究開発部門がEQを披露できるプラットフォーム

プロダクトマネージャーは、製品の成果を上司に報告しますが、R&D は裏方として、上司と接触することはほとんどありません。そのため、プロダクトマネージャーがレポートに R&D の同僚の貢献を示すスペースを増やすと、自然に少しずつ R&D との友好関係が築かれていきます。もちろん、毎日のメールでも R&D の協力を示し、感謝の意を表すべきです。

もちろん、開発プロセスでは、異常な状況も製品マネージャーと研究開発部門の間の対立の一部となります。ここでは、ビジネスプロセス図の重要性を強調する必要があります。上記を参照してください。

5. テストと発売前管理 - 細部を無視しない

開発が完了したら、プロダクトマネージャーは最前線でテストを行う必要があります。プロセスがスムーズかどうかに注意するだけでなく、次の点にも注意する必要があります。

ページのテキストとプロンプトにタイプミスがないか確認します。
コールドスタートデータが適切に準備されているかどうか。

プロトタイプにはタイプミスがなくても、デザイナーが忙しくてタイプミスに気づかない可能性があります。また、R&D 部門が直接ツールを使用してページを生成すると、オンラインになった後にユーザーの前にタイプミスが現れ、当然製品の評判に影響します。

6. データ収集 - 期待を比較し、反映する

最初はデータが良くなくても心配しないでください。運用部門と協力して、新規ユーザーの獲得とアクティベーションの促進に協力してください。データが特に良い場合は、運用活動がうまく行われている可能性があるため、興奮しないでください。

製品データは半年後まで現れません。それ以前のデータは主に運用活動の結果を示しているため、製品マネージャーは安定した状態を維持し、より多くのユーザーレビューを収集し、シードユーザーを維持し、最初のバッチのユーザーとより多くのコンタクトを取り、ユーザー調査を実施し、問題を収集し、迅速に反復する必要があります。半年から1年後には、データに製品の品質が表示されます。

予測されたデータを比較し、データの違いの理由を考え、次の点について考察します。