おもしろいと思うか、やりにくいと思うかは人によって分かれる所ですが、私は深さと広がりの両方があるBtoBのPO（プロダクトオーナー）の仕事が好きです。

書こうと思った理由は、「BtoBのPOは業界のドメイン知識がないと無理じゃないの？」と言われていて、実際、私も以前の業務では豊富なドメイン知識に支えられながらPO業務を遂行していました。

しかし、全く知見のない業界のPOとなる機会をいただき、もうすぐ半年になろうとしています。共通していたのは、BtoB顧客をメインとしているプロダクトであることのみ。

緊張しながら日々一心不乱にがんばってきたのですが、それなりにスキルは通用する部分があり、共通項も見えてきて、やっぱりおもしろいと思ったので自分の考えを書いてみました。

ちょっと前段長いのですが、暇つぶしにでも読んでもらえると嬉しいです。

まず、そもそもPOの仕事はどう定義されているか？
ご存知の方も多いと思いますが、スクラムガイド2020より引用します。

プロダクトオーナーは、スクラムチームから⽣み出されるプロダクトの価値を最⼤化することの結果に責任を持つ。

プロダクトオーナーは、効果的なプロダクトバックログ管理にも責任を持つ。

たとえば、
- プロダクトゴールを策定し、明⽰的に伝える。
- プロダクトバックログアイテムを作成し、明確に伝える。
- プロダクトバックログアイテムを並び替える。
- プロダクトバックログに透明性があり、⾒える化され、理解されるようにする。

これらの決定は、プロダクトバックログの内容や並び順、およびスプリントレビューでの検査可能なインクリメントによって⾒える化される。

プロダクトオーナーは、多くのステークホルダーのニーズをプロダクトバックログで表している。

これ、チームで読み合わせしたり、自社なりの定義に落とし込もうとしたりしたことがあるのですが、なかなか実務への解釈がそろわない印象でした。

その理由を考えると、

・プロダクト価値の最大化の結果責任は、突き詰めると、業務範囲が極めて広く、その理解の深さが人によって異なる

・プロダクトゴールやバックログ作成をするプロセスがそもそも難しく、状況や人によってバラバラのアウトプット感になりがち

・ただの開発アイテムを並べたバックログか、プロダクト価値を最大化できる開発アイテムが並んだバックログかが成否を決めるが、その差分はどうすればできるのかが表現されていない

あたりかと思います。

私はPMFをねらうフェーズのプロダクトを担当することが多いのですが、スクラムガイドにならいつつ、自分なりの解釈も入れつつ、主たるところを書いてみました。

幹となる活動をStepにし、横には、ガイドにある主活動を記してみました。

「POが仕事してない」と言われる際は、だいたいStep1や2が弱く、Step3は一応あるが、1,2が弱いため、納得感を醸成できない場合かと思います。

技術に強いPOの場合は、Step3からのStep4をガチガチに固めすぎて、開発チームの力を最大化させられず、小さくまとまりがち、なども課題としてよく見ます。

BtoB顧客中心のプロダクトの場合は、顧客要求が強すぎると、1,2が描きづらく、3は結果的に顧客要求が並んだだけのバックログになる、と成功しないパターンです。

作ったとしても、プロダクトとして偏りすぎて使われないものになったり、もしくは「私たち、受託開発のSIerではない」とエンジニアに言われ、開発が停滞、ひいてはエンジニアの離職が進み、チーム崩壊してしまうなんてことも目にしてきました。

なかなか本題に移れませんでしたが、BtoBのPOがおもしろい理由はまさに、

・その調整が絶妙でプロダクトの成否を握っている（難しさで鍛えられる）

・顧客とうまくパートナーシップが結べれば、業界や現場の、かゆい所に手が届くプロダクトを一緒に作れる

・影響力のある顧客が使ってくれれば、とても速いスピードでプロダクトが業界に浸透する可能性がある

あたりに、ワクワクします。

Step3のプロダクト要件を考える際、私が考えている範囲も書いてみました。

ユーザーとプロダクトのみならず、

人（ユーザー）
組織（経営）　
業界　
社会

と、広がりのある知見が求められること

その中から、センターピンを見つけ出し、落とし込んでいくこと

落とし込むプロセスでは、とても多くのステークホルダーを巻き込む必要があること

つまり、
・深さと広さの両方を追い求める必要性があり、業務を通じて指数関数的に成長していけること
もおもしろいなぁと個人的には思ってます。

みなさまはどう思われますか...？