The agile product manager

アジャイルプロダクトマネージャーに関して知るべき (聞きにくい) すべてのこと

Sherif Mansour Sherif Mansour

アジャイルの世界では、製品とフィーチャーは流動的であると考えられています。小さなかけらがあり、常に回転し続ける食器洗浄機のようなものではなく、 ラバライトのように安定的に、目に見えて変化し続けます。 それでは、ソフトウェアの進化にあり、ラバライトの変化にないものはなんでしょうか?「戦略」です。プロダクトマネージャーの役割はそこにあります。

One of the exciting things I get to do as part of being a product manager for Confluence, Atlassian's wiki software, is talk to a lot of customers. I hear about what works for them and the challenges teams face as they journey on their mission to build great products.

Ok: almost any means. I definitely don't recommend doing anything illegal. Or creepy. Anyway...

アジャイルの世界では、顧客の問題を把握することをどのように捉えているのでしょうか?アジャイル手法では「従来」の方法にこだわる必要はないことを思い出しましょう。プロダクトマネージャーは、顧客のストーリーを設定するために必要な労力を惜しんではなりません。さまざまな実験や探究を経て、コンテキストを想定し、自分自身とチームにとって最適な行動をとりましょう。これは次のことを意味します。

  • 話し合いを行って、紙切れにスケッチを作成できるなら、そうしましょう。

  • 部屋にいる全員 (顧客を含む) を集め、ユーザーストーリーマッピング演習を行ったらどうなるでしょうか?それで問題が十分に伝わるなら、それ以上何かを行う必要はありません。

  • 顧客を訪問して、製品を使用しているコンテキストを観察できるならどうでしょうか?エンジニアやデザイナーを同席させ、顧客の意見や問題点を聞くことができますか?

  • Instrumenting your product with analytics hooks give you aggregate, concrete data about how customers as a whole are using your product. 

  • 製品を中心とする 3 つの役割担当者 (プロダクトマネージャー、エンジニア、デザイナー) による簡単なスタンドアップで、その場でスケッチ、話し合い、意思決定を行うことも可能です。

  • さらに詳細を求めるなら、主な利害関係者を集めてワークショップを開き、ホワイトボードによる図表化や文書上のプロトタイピングを行って、問題とその解決方法を探りましょう。

You get the idea. In the past, product management and requirements documentation have been almost synonymous. And no wonder! Writing 20-, 50-, even 100-page PRDs will unavoidably dominate your 9-to-5. But in the agile world, it’s important that we consider writing a requirements document as just one of many ways we can help define and communicate customer problems.