/note/tech

プロダクトマネージャーがプロダクト企画についてエンジニアと話すときに、あらかじめ...

プロダクトマネージャーが用意するリスト

  • 目的の概要(なぜそれをやる?)※もっともだいじ。これが無いとかなりキツイ。
    • 誰のための企画?(基本はエンドユーザーになる。)
    • その人のどういう課題を解決したい?
    • その課題はどうやって導いた?(根拠となる情報やデータなど)
  • 企画内容の概要(なにを提供する?)
    • どういったソリューション(機能など)を検討している?(実装前の現段階ではただの仮説。細かい仕様はむしろ無いほうがいいが、UI の手書きラフスケッチくらいはあるとやりたいことがイメージしやすくなる)
    • どのへんの既存機能に手が入りそう?とかもあるとよさげ
    • 現状なぜそのソリューション(仮説)が妥当だと考えてる?(根拠となるデータや情報、市場分析や競合分析結果など)
  • 戦略との整合性(なぜそれをやる?の追加情報)
    • プロダクト戦略や、事業戦略との関連性はなにか?(ダイレクトに効いてくる?周辺領域?)
    • ソリューションが実現された場合の想定インパクトは?(どんなメトリクスにどれくらい寄与する?ざっくり。取らぬ狸の皮算用だが、投資価値があるかどうかのざっくり判断などにつかう)
  • スコープやスケジュール(いつ、どれだけ提供する?)
    • ソリューションに対するスコープの選択肢は?(特にミニマムスコープ。「これさえあれば課題を解決できる!」という削ぎ落とされたソリューションの範囲は?)
  • スケジュール特性は?(早さよりも、期日を設定してそれを守ることが重要?もしくは その逆?)

こういったものがあると、できるようになる話

  • 技術的実現性やリスク
    • そもそも実現可能かどうか
    • 懸念やリスクについて
      • 技術的難易度が高そうなところ(高コストになりそうなところ)
      • 考慮漏れしそうな部分、既存仕様と競合しそうな部分(慎重に考慮したほうがいいところ)
  • 代替手段やスコープの案
    • もっと簡単にその課題を解決する方法
    • こういったミニマムスコープもありそう、みたいなもの
  • ざっくりとした見積もり
    • やるべきかの判断のための、ざっくり開発規模感(Not 納期の約束。この時点ではとてもじゃないけどできません)