これも一種の製品管理ですが、別のことについてお話します。
免責事項：
以下のいずれも普遍的なアドバイスになることはほとんどありません。 私は主に、ユーザーが実際に遭遇しないサービスを扱っています。これは、仕事と私が従う規則にある種の痕跡を残します。
機能要求、良い面と悪い面。
作業している製品に非常に狭い詳細が含まれていない場合、考慮するすべての人が機能要求を送信する必要があります。 特にリソースが限られている場合、それらをフィルタリングできる必要があります。 目に涙を浮かべているデザイナーが、データ処理システムが終了することを確信している場合、インターフェイスをファッションのトレンドと一致させなければ、すべてを捨ててシステムをジョナサン・クインサーの最新の研究に似せる必要はありません。 またはその逆：ユーザーがヒントを必要としないという観点をプログラマが擁護する場合、 「すべてはすでに明白です」、これはツールチップを拒否する理由ではありません。 一般的に、あまり良いアイデアの多くは専門家の変形によって引き起こされます：UXはビジネスを損なうユーザーの世話をする準備ができており、開発者はインターフェイスよりも温かいチューブコマンドラインを好みます、一部のビジネスマンは期限とお金以外を気にしません、など これはすべて修正する必要があります。
たとえば、次のように発明されたばかりの機能をフィルタリングします。
- 率直に言って弱いまたは危険なアイデア、あなたはすぐに拒否することができます;
- 非自明な機能、追加の分析が必要です。
- 明らかに有用な機能であり、それをバックログに入れ、優先度を設定します。
各新機能は、ターゲット（この機能がないと製品の一般的な目標を達成するのが困難/不可能）またはKPI（この機能により既存の指標が改善されます）のいずれかで動作します。 これらは、関連エンティティまたは直交エンティティのいずれかです。
目標指向機能の例：
- すべてのモバイルプラットフォームに存在するように、アプリケーションをWindows Phoneに移植する
- 「今週のベスト記事」ブロックをパーソナライズして、ユーザーごとに表示されるページ数を増やします
機能がどちらか一方と一致しない場合、何か問題があります。 自分とこの機能を提案した人に「なぜ？」という簡単な質問をしてください。 多くの場合、「ファッショナブルだから！」という機能リクエストが届きます。 「なぜ？」という質問をすることで、有用なアイデアをローセンスなファッショントレンドから分離できます。 外出先で十分に考え抜かれていない考えを投げかけることができる上位のボスに同じ質問をすることを恐れる必要はありません。
それとは別に、「これは競合他社がすでにやったことだ！」という議論は、開発に完全に着手するには不十分であることに注意したい。 特定のプロジェクトが、たとえば使用されているフレームワークのローカルな制限によってそのような実装が引き起こされたことを知らずに、何かを盲目的にかなり詳細にコピーする方法を見るのは非常に面白いです。
開発を始める前に
機能を計画する場合、ユーザーには表示されないものの、プロダクトマネージャーが適切な決定を下すのに役立つものを提供することが非常に重要です。 これはユニバーサルロギングです。 これは、技術的なログだけではなく（技術的な専門家がこれをすべて処理する必要があります）、プロジェクトのビジネスロジックに関するものです。
理想的なユーザーの行動シナリオと一致しないものはすべてログに記録してください。 このシナリオに当てはまらない訪問に関するすべての情報がある場合は、いつ何が間違っているのか、何に注意を払うべきかをいつでも分析できます。 計画されたシナリオは実際のシナリオとは大きく異なる可能性があり、完全なログがなければ、そのことはわかりません。
機能の有効性をテストする方法を検討してください。 おそらく、これにはいくつかの特別なログも必要になります。 新しい機能の動作に関する情報の欠如は、プロダクトマネージャーにとって許容できない誤りです。 あなたと一緒にプロジェクトの分析に参加する人がログに簡単にアクセスできることを確認してください：大企業では、大切な知識を得るために異なる部門から5人を回る必要があるかもしれません。
ユーティリティチェック
製品管理にはこのようなアンチパターンがあります。「クールな機能を作成しましょう。 そのような場合、「... we'll see」はしばしば「まあ、すべては大丈夫だ」につながりますが、これは明らかに十分ではありません。 この問題は、特にKPI指向の機能に関連しています。
機能が開発され、実稼働環境に登場する前に、実験の実行方法、使用されるデータ、成功/失敗の基準となるものを決定する必要があります。 車輪を再発明する必要はありません;統計科学は長い間、このための理論的基礎を準備してきました。 これは、機能の有用性をテストするための最良の方法の1つであるA / Bテスト、およびその他の方法にも適用されます。 実験の計画を事前に準備していなくても、誘惑に負けて耳で結果を引き出すのは簡単です。
適切に設計された実験は、誤った因果関係からあなたを守ります。 「後」！=「代わりに」; ユーザーの成長を製品の賢明な開発と関連付けることがどれほど素晴らしいことであっても、それは季節性のような一時的な外的理由にすぎない可能性があります。 たとえば、ユーザーアクティビティの増加は、気象条件、休日、競争力のあるプロジェクトへのアクセス不能などに関連する場合があります。
結論の代わりに
製品管理のための常識とシステム以上に重要なものはありません。 各決定は、開発の一般的なラインに対応し、バランスを取り、異なる角度から検討する必要があります。 それ自体が理想的に実現された優れたアイデアであっても、製品のコンテキストでは必ずしも有用ではありません。