製品マーケティングとプロモーション計画（私の製品計画プロセスを共有します。皆さんにも役立つことを願っています）

私の製品計画プロセスを共有します。皆さんにも役立つことを願っています

この記事では、著者が自身の製品企画プロセスを整理して分解し、各プロセスに対する著者自身の考えを述べて、読者の皆さんにインスピレーションを与えたいと考えています。

最初に製品の開発に取り組み、需要計画を立て始めたとき、プロトタイプを描き、ドキュメントを書き始めたことを覚えています。執筆の過程で、特定のやり取りについて十分に考えていなかったり、ロジックの一部を見逃していたり​​することに気づいたので、戻って修正したり、ギャップを埋めたりしました。このように長い間行ったり来たりして、ようやく完全な計画が完成しました。再度確認したところ、ある部分が抜けており、工程に問題があったため、再度変更しました。何度も努力を重ね、ようやく第一弾が完成しました。

その後、要件のレビューになると、技術担当者からのさまざまな質問に直面して緊張し、多くのロジックと詳細を見逃していたことがわかりました。要件のレビューが終わる頃には、私は要件によって死ぬほど苦しめられていました。

この問題が発生するのは、まず第一に、製品ソリューションの設計を始めたばかりで、基本的な製品インタラクション仕様に十分精通していないためです。もう 1 つの理由は、全体的な要件や機能について明確に考えずにタスクを完了することを急いでおり、ソリューションと機能自体の実装に集中しすぎていることです。

その後、より多くの要件に対応するにつれて（そしてより多くの落とし穴に遭遇するにつれて）、私は過去に開発した製品ソリューションで遭遇した問題のいくつかをゆっくりと修正していきました。また、同僚とコミュニケーションを取り、自分にとってより適した製品設計プロセスを組み立てました。すべてのシナリオに適しているわけではないかもしれませんが、現時点で私が最も頻繁に使用しているプロセスです。

競合製品を見ると、多くの人の最初の反応はそれを真似することでしょうか?需要計画に取り組み始めるとき、一般的な手順は、関連する競合他社や製品をいくつか選択し、特定の機能をコピーして、最終的な計画を作成することです。

現時点では、私たちの注目はまだソリューションや機能の実装そのものにあり、その背後にある内部ロジックや動機について深く考えていません。学生時代と同じように、私はクラスメイトの宿題を手に取って、答えの計算過程を考えずに、答えをそのまま書き写して提出していました。しかし、生徒の皆さん、宿題をコピーすることはできますが、コピーした答えがなぜそのようになっているのかを理解しなければならないと言う教師もいます。

競合製品にも同じ原則が適用されます。需要計画の立案を開始する際には、競合する製品の機能や関連機能を見つけ、関連機能を深く体験し、機能全体のロジックとプロセスを理解し、機能とのやり取りの感覚を体験し、機能の効果について予備的な判断を下します。

同時に、記録をしっかり残し、競合他社の良い点やキーポイントの実装ロジックを収集して記録し、異なるプラットフォームでの同じ機能またはモジュールの実装方法やキーポイントに関する情報をできるだけ多く収集し、論理的な思考と説明をできるだけ多く行う必要があります。このステップを完了すると、要件の全体的な実装ロジックとプロセスを予備的に把握し、次のステップを開始できるようになります。

簡単な例、ログインと登録機能の計画を見てみましょう。同じログインおよび登録機能でも、製品によってビジネス ロジックやプロセスが異なる場合があります。登録しきい値、登録プロセス、登録情報、ログインシナリオなどの違いはすべて、特定の製品の需要シナリオと特性に関連しています。

競合製品の調査が完了したら、独自のニーズを計画し始めることができます。ビジネスロジックや機能フローを大まかに把握していることを前提に、自社製品の現状や実際のシナリオと合わせて全体から詳細へ進めていきます（全体から詳細への体系的な思考といえば、多くの人が読んだことがある「ピラミッド思考」という書籍がおすすめです）。

需要背景、需要目的、機能フロー、機能リスト、関連要件などから全体的なアイデアを整理し始めます。機能リストと機能フローは、競合他社の調査に基づいて全体的なアイデアを思いつくのが最も簡単なモジュールです。それらは製品の機能設計そのものです。ただし、製品機能自体は需要計画の一部にすぎず、需要のすべてではないことに注意する必要があります。

私がよく陥る落とし穴は、需要プロセスと実装そのものに焦点を当て、他の需要ポイントや需要に関連する事項を無視してしまうことです。例えば、新たな需要ソリューションが既存のニーズに与える影響、新旧バージョン間の互換性の問題、財務や運用などの各種プロセスの変更、機能の推進など、これらすべてを実際のニーズの背景に基づいて事前に検討し、計画する必要があります。

見落とされがちなもう一つの点は、需要価値と効果の測定です。製品開発に取り組み始めた当初は、需要全体をどう満たすかということに重点を置くという問題によく遭遇しました。私はその需要の価値と効果についてほとんど考慮しませんでした。いろいろやりましたけど、その価値は見直しませんでした。これは、作業のレビューと製品の理解に非常に悪影響を及ぼしました。

フレームワークとプロセスを整理したら、上司や関係する同僚と事前にコミュニケーションを取り、大まかな方向性や考え方が一致した時点で要件定義書の作成に取り掛かります。アイデアとフレームワークに一貫性がない場合は、プロトタイプを描き、ドキュメントに直接取り組み始めることができます。後でアイデアやフレームワークを調整する必要がある場合は、すぐに修正することができます。

上記の例を続けると、ログインおよび登録モジュールの要件の実装に関しては、競合製品の調査を完了した後、独自の製品特性に基づいて機能モジュールとプロセスを決定できます。たとえば、コンテンツベースの製品の場合、初期段階でログインしきい値を下げ、サードパーティのログインを直接使用して、ユーザーの基本情報と登録アカウントを同時に取得することができます。

フレームワーク プロセスが整ったので、最終的なインタラクション デザインを完了し、要件ドキュメントを作成するという 3 番目のステップを開始できます。明確に整理されたこれまでのアイデアとプロセスに基づいて、プロトタイプを描き、ドキュメントを書き始めることができます。プロセス全体が比較的スムーズになり、多くの迂回を回避できます。

インタラクション設計と要件ドキュメントの作成は、製品の基本的なスキルと見なされます。フレームワーク プロセスが完了したら、プロトタイプの作成と要件の検討を開始できます。多くの人が初めて要件ドキュメントを作成し始めるとき、プロトタイプを描くために何を使用するか、プロトタイプは高忠実度である必要があるか、ドキュメントの形式はどうあるべきかなどについて混乱するかもしれません。

要件ドキュメントの作成に初めて取り組んだとき、どのプロトタイピング ツールを使用すればよいのか私も混乱しました。 Axure をよく使用していますが、Moknife も試してみるべきでしょうか?プロトタイプはあまりにも醜いです。もっと見栄えを良くすることはできますか?要件ドキュメントは、プロトタイプ注釈に直接出力するか、標準ドキュメントとして出力するか、どのように出力すればよいですか?また、参考や模倣のために、インターネットでさまざまなドキュメントを検索します。

その後、私はさまざまなチームで働いてさまざまなスタイルの要件ドキュメントを作成し、プロトタイプやドキュメントの形式について心配しなくなりました。ドキュメントは、アイデアやソリューションを伝える媒体であり、開発およびテスト チームとのコミュニケーションの媒体でもあります。また、記録 (誰が責任を負うべきか) を残すことも非常に重要なポイントです。出力形式とドキュメントのスタイルに関しては、チームのスタイルと個人の習慣によって異なります。チームのスタイルに沿っている限り、最も効率的な方法で実行してください。

要件ドキュメントは、継続的な反復的な最適化のプロセスでもあります。実際の経験から言うと、完璧な要件文書を一度に書くことは不可能です。要件進化のプロセスでは、要件のレビュー、開発、テストを伴い、継続的な最適化と調整が必要です。情報の非同期による機能エラーを回避するには、タイムリーな変更記録を作成し、関連する同僚と迅速に同期する必要があります。

この時点で、要件ドキュメントのセットがようやく完成しました。ほっと一息ついて、要求PKフェーズ（喧嘩フェーズ）に入り、喧嘩と責任転嫁の道を暴走し始めることができます。ようやく要件がオンラインになり、ほっと一息ついたと思ったら、さらに多くの要件と書類が待っています...

著者：Ronie、個人WeChatアカウント：qinfengrec

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

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