2012年9月11日
開発者がプロダクトマネージャーの記事の翻訳になる
古き良き時代には、プログラミングで生計を立てていました。 それは私の人生で最高で最も気楽な段階の一つでした。 コードを書く以外に、私には他の責任はほとんどありませんでした。 会社が給料のどこからお金を受け取ったのか、私は知りませんでしたし、顧客がどのように私たちの製品について知るのか分かりませんでした。 上司がX / Y / Zの機能をプログラムするように頼んだ理由については考えていませんでした-私はコードを書きました。 私の時間は興味深い技術的な問題の解決に費やされ、一般に、私の人生はプログラミングを中心に展開しました。
実世界
時間が経つにつれて、私はエンジニアリングチームの外に、まったく異なる世界、つまり「ビジネス」の世界、または私が今呼んでいる「現実の」世界があることに気付き始めました。 この世界では、投資が集められ、製品が宣伝および販売され、顧客にサービスが提供され、給与が削減されます。 常にプロダクトマネージャーが
エンジニアリングチームではなく、この現実の世界で過ごします。 テクノロジースタートアップでは、プロダクトマネージャーの役割がCEOによってしばしば果たされます。 大企業では、製品マネージャーはミニCEOです。 （プロダクトマネージャーが持つ影響について詳しく知りたい場合は、Marissa Mayerの記事をご覧ください。Googleでのプロダクトマネージャーの役割について説明しています。）
プロダクトマネージャーのタスクは、エンジニアリングチームの作業が会社のビジネス目標と一致する方向に進むようにすることです。 明らかな目標の1つは、販売部門が販売できる製品を作成することです。この部門では、マーケティング部門が潜在的な顧客に興味を持ち、技術サポート部門がサポートできます。 それほど明白ではない目標には、競争上の脅威の緩和、製品の戦略的な位置付け、投資家の希望の充足、および長期的な株主利益の創出が含まれます。 これらの概念はかなり曖昧ですが、製品マネージャーによる毎日の意思決定のコンテキストを決定するのに役立ちます。
プロダクトマネージャーの日常生活を一言で表すとしたら、それは「NO」という言葉です。 製品が発売されると、改善方法（別名「新機能」）に関するアイデアの数は、それらを実装するチームの能力を大きく上回ります。 NewRelicでは、改善要求を2年間追跡しました。 それらの数が1000に達したとき、私たちは停止し、頭に傷をつけ、それらをすべて取り除きました。 新しいリクエストの個別の追跡を停止し、カウントを開始しました。 このような状況では、プロダクトマネージャーは、ビジネスで最大の利益をもたらす少数のケースに焦点を当て、他のすべての要求にはノーと言うことができます。 （これを達成するための簡単な方法の1つは、将来の作業の優先リストを保持することです。）そして、これらの避けられない2つから3つの要求が1日に来ると、それらはトップ10リストと比較でき、このリストに分類されます（そして、他のものに取って代わります）、または彼らはそこに着かないでしょう。
目標を定義する
ビジネス目標は企業によって異なる場合がありますが、通常、すべてのプロジェクトに共通するのは、「何か」を行う「誰か」のための製品を作成する必要があることです。 この人はファッショナブルな用語「人」と呼ばれています。 製品に一人の人しかいないこともあれば、カップルがいることもあります。 そして、これらの人々が誰であるかを理解することは非常に重要です。 理解していなくても、誰かのために何かを構築するにはどうすればよいですか？ プログラマーはしばしばこのレーキを踏んで、自分のような人のために製品を作っていると信じています。 （まあ、結局のところ、ユーザーもコンピューターを使用しますよね？） Salesforceを例に挙げましょう-これらの人は、営業担当者、セールスマネージャー、トップマネジメントなど、製品の担当者を正確に理解しています。
製品は特定の「問題」または「痛み点」を解決するように設計されている可能性が高いため、「何か」が重要です。 たとえば、製品がパフォーマンス監視ソリューションである場合、顧客が製品を使用してアプリケーションのパフォーマンスの問題を解決することが重要です。 2番目に頻繁に使用される式（「NO」の後）は、「これはどのような問題を解決しますか？」です。 直面しなければならない実際の状況の例を次に示します。 デザイナーはWebページのレイアウトが気に入らず、変更を要求します。 この変更は製品を改善するので、問題はないはずですよね？ しかし、危険は2つの場所にある可能性があります。a）ユーザーは既存のレイアウトで問題を経験しませんb）ユーザーは他の設計問題を経験します-そして、最終的に、これらの問題の解決は延期されます。
私の製品のどの問題が最も深刻であり、これらの問題を正確に解決するためにチームを派遣するかを自問すると、これはバックログの正しい優先順位付けになります。 そして、「問題」についての最後のポイント-彼らは時々「機会」のような他のものとして自分自身を隠す。 たとえば、ユーザーはアプリケーションのインストールに時間がかかりすぎることを通知しません。 明らかな問題はありません。 ただし、賢い人としては、インストールプロセスを高速化すると売り上げが増加することを認識できます。 ユーザーのアテンションスパンが短いため、アプリケーションのインストール時間が長いことが問題になります。 別の例はApple iPodです。 iPodは新しい機能を市場に提供しませんでしたが、シンプルでスタイリッシュなファッショナブルな製品でした。 一目見ただけで問題は解決しません。人々はただファッショナブルになりたいだけです。 しかし、ファッショナブルな製品を市場に提供することで、大勢の人々の欲求（問題を解決する）を満たすことができます。
プログラミングが見逃されることもありますが、製品管理を交換する準備ができていません。 私は、NewRelicの成功に重要な役割を果たしたいと思っています。そして、NewRelicの成功が好きです！