ユーザーフィードバックの方向性、戦略、運用（「PRD」優れた戦略的製品要件ドキュメントの書き方）

優れた戦略的製品要件ドキュメントの書き方

プロダクトマネージャーの仕事において、要件定義書 (PRD) は最も頻繁に目にする文書の 1 つであり、日常的に最も頻繁に作成および修正する必要がある文書でもあります。この記事では、C エンド PRD とは異なる、戦略的プロダクト マネージャーが作成した PRD ドキュメント構造を紹介します。皆様のお仕事に役立てば幸いです。

戦略的な製品は、Dazhongchang チームの魂です。コンテンツの推奨と配信の面では、コンテンツを消費するユーザーを満足させます。地域ビジネスの観点から、乗客、商人、利用者のニーズをバランスよく満たしています。ライフサービス事業においては、ユーザーとPOIを正確に接続し、その過程でパス体験を継続的に最適化します。

優れた戦略製品には、定量的および定性的な方法から十分に検討された出力が必要です。明確な実行と客観的な評価を伴うドキュメント化が重要です。

次に、優れた戦略 PRD の基本構造をリストアップしてみましょう。

戦略関連のアクションには通常、コンプライアンスとビジネスの背景があり、戦略の変更は上流と下流のビジネス、運用、アルゴリズム、およびその他のチームの調整を引き起こすためです。一般的に、この情報は文書全体が整理された後に記述されます。関係者が戦略に対する関係性や位置づけを素早く把握するのに便利です。

参照用の基本的な形式は次のとおりです: 部門、担当者、RACI、および提案 (既知か、合意および確認済みか)。

RACI モデルは、責任者、説明責任者、相談者、情報提供者という 4 つの主な役割からその名前が付けられています。このモデルは、規模の大小を問わず、あらゆるプロジェクトやプロセスに使用できます。

背景部分は実は本体の重要な部分です。通常、新しい戦略の背景にある理由、何をすべきか、そして対象となる問題は何かを読者に理解してもらうために、文書の冒頭で述べる必要があります。

一般的に、プロジェクトの規模に応じて、背景セクションでプロジェクトとチームの目標について包括的な紹介を行うのが最適です。

たとえば、プラットフォームチームの目標はコンテンツエコロジーであり、プロジェクトの目標はMCNを導入することでコンテンツの豊かさと多様性を導くことです。では、需要の背景が、なぜ私たちがこれを実行するのかを説明するのでしょうか?それは競合製品、業界全体のルール、あるいはプラットフォーム上の消費者の要求である可能性があります。

需要背景そのものを踏まえて、何をすべきかを一文で明確に説明することができます。優れた 1 文の要件には、少なくとも、対象ユーザー (主題)、実行する内容または機能 (アクション)、期待される効果 (目標)、特別な状況があるかどうか (従うべきルール) が含まれている必要があります。

コンテンツエコシステムに導入されるMCNの供給の観点から見ると、この要求は「コンテンツエコシステムを充実させるために（課題）、プラットフォーム上で認証されたMCN組織（行動）が多様なコンテンツ（目標）を提供し、異なるユーザーのニーズを満たし、ユーザーエクスペリエンスを向上させるためのプラットフォームを構築する必要がある」となる可能性がある。

必要性について議論する部分は、オンラインの問題を解決する必要がある理由、どの観点からどのような要件があるかなど、複数の視点を取り上げながら、複数の視点を中心に記述するのが最適です。解決されない場合、フォローアップにどのような影響が及ぶか - 戦略はどの程度拡張可能か。一般的に言えば、戦略的ニーズは主に、偶発的な傷害、省略、コンプライアンス、透明性、特別なグループの保護、肥満と減量など、いくつかの観点を満たしており、もしあれば、それらに頼ることができます。

これらの指標についてはあまり詳しく説明しません。しかし、指標を列挙する際には、指標の定義、その基準は何か、そして予想されるオンライン戦略指標は上昇しているのか下降しているのかを議論し、明確にする必要があります。

前回は主にそれが何であるかについて説明しましたが、本編ではそれをどのように実装するかに焦点を当てています。これには、フロントエンド変換のコスト、バックエンドのロジックソリューション、バージョン追跡の必要性の有無が含まれます。

フロントエンドの変革を明確に導入するにはどうすればよいでしょうか?一般的に、それは 3 つの側面から紹介されます。まず、現在の状況です。第二に、予想される状況。 3 番目は、ページのインタラクション: 前提条件 (ページのトリガーとなるアクション)。ユーザーがクリックする前後のインタラクションと表示効果。ページ要素によって取得されたデータ リンク。要素のアクティブ化のためのフィルター条件（プロンプト情報）異常状態に関する迅速な情報提供。

ここでのバックエンド設計とは、フロントエンドを支えるリンクプロセスを指すのではなく、ルール、識別、想起、検討から最後の認識ステップまでの戦略全体の条件判断とプロセス計画を指します。通常含めるべき要素としては、フローチャート、条件判定、異常判定、廃棄リンクなどです。

一般的に言えば、クライアント上の新規ユーザーに対するポップアップ要件などの大きな制約がない限り、戦略的な製品に対する需要にはコピーは含まれません。したがって、この部分の実際の執筆プロセスでは、漏れを避けるために、フロントエンドの同僚によってフロントエンドページが完成されているかどうかをクライアントの同僚に確認する必要があります。

戦略を実際にグレースケールで開始する場合、その大部分は事前のデータ分析を必要とします。ただし、ユーザーからのフィードバックを通じて微調整が必​​要な戦略の場合は、検証を開始する前に AB テストを実施するのが最適です。

AB デザインでは、次のことに重点を置いています。

1. 介在変数が少ないほど良い
2. サンプリングはランダムに行う
3. 実験グループの観察量は、全ユーザーの5％から開始し、観察効果をコアテストとして徐々に増加することができます。

その後のデータ指標によって、完全なリリースと利点の評価の時期が決まります。実験を開始する前に明確に検討して、その後の作業の重複やロールバック操作を減らすことが最善です。

ポリシー環境では、レビュー プラットフォームはさまざまな情報をカバーします。新しいポリシーが開始された場合、ケースの配布の詳細を完全に追跡するには、チーム部門間のコラボレーションが必要になる可能性があるレビュー プラットフォームでポリシーの適用効果を同時に構成することが最善です。

上記は完全な戦略文書です。ご使用後のご感想をお待ちしております。

コラムニスト

誰もがプロダクトマネージャーであるコラムニストのBlue Lotus zx氏。コンテンツ戦略、コンテンツ背景、コンテンツタグ、アカウント戦略などの分野に重点を置いています。読書が好きで、面白い人になりたいです。

この記事はもともと「Everyone is a Product Manager」に掲載されました。無断転載禁止

タイトル画像はCC0プロトコルに基づいたUnsplashからのものです

この記事で述べられている意見は著者自身の意見のみを表しており、人人士品夢家プラットフォームは情報保存スペースサービスのみを提供します。