『Product Operations』
書籍情報
Many companies want to reap the benefits of economies of scale that comes with being a product-led company. As our businesses change shape to focus more on software, so do our ways of working. We need to make sure we’re breaking down these silos of information and capabilities that arise at scale. To react quickly and set great Product Strategies, leaders and team members alike need access to high quality data and a process to implement their decisions.
In this book, Melissa Perri and Denise Tilles explain how Product Operations helps solve many of scaling issues companies face today
なぜ読んだか
英語の勉強も兼ねて洋書を読もうと思った。どうせなら邦訳がでていないものがよいと思い、探す中でSNSでこの本を見かけた。
PM（プロダクトマネージャー）の分業ってどういうものがあるか気になって読んでみた。
内容
※注意：私の解釈が入ったり、端的に記載している部分があるため、厳密でない部分があるかもしれません。
そもそもProduct Operations (Prod Ops)とは？
Prod Opsのミッションの言語化は色々書かれていたが、これが端的でわかりやすかった。
At its core, product operations is an enablement function. It does not make the decisions, but it makes the decision-making process easier and more transparent.
つまり、「Prod Ops自体はあくまで意思決定はせずに、意思決定プロセス自体をより簡単かつ透明性あるものにする」ということだ。
PMは意思決定をする役割というイメージも強いので、この言語化だとPMとProd Opsとの違いがかなりイメージしやすくなる。
では、Prod Opsは何をするか？
何を目的とするのかはわかったが、実際にそれをどう実現するか。
それには主に3つの柱（pillar）が掲げられている。
それぞれについて以下で簡単に紹介。
Business Data & Insights
社内のデータを整理/可視化をして、意思決定に利用される形にするような意味合いで語られていた。
データはそもそも以下の図のように色々なところに分散していることが多い。これらを意味があることで統合して、ダッシュボードとして主要なKPIが正しく可視化されるようにする。
ただ、注意としてはあくまでProd Opsが深く分析をしてインサイトを出すようなことまでは責務を負ってはいなそうなこと。そういった分析はアナリスト/BIの仕事してあり、Prod Opsとしては主要なKPIを全メンバーに対して可視化しモニタリングできる状態にすることを責務に負っている形のよう。
Customer & Market Insights
ユーザーリサーチやマーケットデータへのアクセシビリティをあげ、その結果がプロダクトの意思決定に反映させることを担保するような意味合いで語られていた。役割としては以下のようなもの。
1：ユーザーリサーチへのアクセシビリティをあげる
ユーザーリサーチの対象のプールとプロセスを整える。
そして、Productチームのリクエストに合わせて、迅速かつプロダクトチームの負荷が少ない形でユーザーリサーチを実施できるようにする。
2：リサーチのフィードバックを循環させる
実施したUXRのフィードバックがきちんとプロダクトの意思決定に活かされるように、フィードバックを循環させること。
User Research Repositoryのようなものを作り、それによりフィードバックを部署によらずアクセス可能なものとして、リサーチを最大限有効なものとする。
3：マーケットデータ（市場や競合）の情報収集
ユーザーリサーチだけでなく、市場や競合の情報収集も行い、それを全社に共有する。このあたりは各部署で勝手にやっているいたりもするが、重複も出たりするため、統合的にやることのメリットもあるとのこと。
悪い例として挙げられていたものもいくつか紹介。
例1：セールスが商談でのフィードバックをたくさん持てていたがプロダクト側に共有されていない
B2B saasとかだと意外とこの分裂は起きやすいのだろう…
セールスが受けたフィードバックをアクセスしやすい形で整えることもProd Opsで貢献できる部分であるとのこと。
例2：同じようなリサーチを重複したり、特定チームでのリサーチの内容が他のチームにいかされない
同じリサーチしてしまうことは集約的にリサーチを管理している部署があればある程度防げるかも。
ただ、行ったリサーチが他の部署では生かされないのは、全然あるな…
抽象化したりすると結構学びがあるが、これは結構難しい
例3：アクセスしやすいユーザーにばかりリサーチが集中する
B2Bだと関係値が深い取引先にのみリサーチが集中してしまい、リサーチにBlind Spotができてしまうという話。ただ、これはC向けサービスでもある。
以下のpodcastでも話されていたが、リサーチを通常の業務時間にやってしまうと、その時間に働いている人にはリーチできないみたいな話は当たり前ではあるが、意外とそこまで考慮してリサーチできて無い気がする。
ここでもProd OpsはResearcherと役割がかぶるわけではない。Researcherはリサーチの方法論/実践方法/内容の決定とその解釈などに責任をもつので、上記のProd Opsとはかぶらない。
Process & Practices
プロダクトの意思決定や運営、部署間連携などのプロセスを整えるような意味合いで語られていた。主に語られていたのは、Roadmapの作成/レビューなどProduct Planningのサイクルを整えること。サイクルの一例は以下のようなもの。
負荷が大きいため、こういったプランニングは頻度が落ちがちになったり、レビュー前の1,2週間前に急ごしらえで作ってしまうことが多いが、このプランニングは大きな価値を持ちうるもの。
そのためProd Opsとしては、このサイクルをテンプレートや必要なインプットの提供をするとともに、全体の進行管理をする。そして、このサイクルをより効率的に有意義なものとする。
たしかにこのプランニングは、直近1年のプロダクト方針を決めるものなのに、みんな本業の傍らでバタバタと期限に合わせてやってしまうことが多いと思う。そのため、ここをより意味のものにできる意義は大きいかも。
他にも細かくGo-to-MarketなどのProcessの話も触れられていたがここでは割愛。
改めてPMとProd Opsの違い
PMとProd Opsのわかりやすい比較表も載っていたので紹介。
感想
分業余地はたしかにあるかも
最初に思ったのは「こう見ると分業余地はけっこうあるな」ということ。正直、PMは総合格闘技みたいな風潮があり、何でも浅く(?) 広くこなせることが必須という風潮がある。ゆえに、ここまでしてもらえるというのは、贅沢のようにも思ってしまう。
しかし、PdMを本来の「より良い意思決定をすること」に注力できるようにすると、このような分業は妥当に思える。それに、本書でも触れられていたがSalesにはSales Opsがあるのは割りと自然に受け止められている。
ユーザーリサーチの重視度合い
若干本筋から外れるが、改めてUSのProduct界隈ってユーザーインタビューをかなり重要視していると感じた。
本書で紹介していたケーススタディとしてFidelity Investmentというアメリカの投資信託の会社でのProd Ops導入事例が載っていたのだが、導入後ではユーザーのリクルートが2日以内にできて、リサーチの結果もリクエストを受けてから3日で出せるようになったと書かれていて、驚いた。
バリバリのアメリカの投資信託会社でもこのスピード感で実施するように整えるくらいユーザーリサーチを重視しているのは素直に感心させられる。
最後に
非常に良い一文があったのでご紹介。
The systems and processes that create the product are as much the product as the product itself." Matsui interpreted that to mean, if a process to launch a new product is subpar or if there are leakages in collecting customer feedback, it becomes challenging to build and ship a compelling product that adds value to customers.
要するに、
「プロダクトを作るシステムやプロセスも、プロダクト自体と同じくらい、"プロダクト”である」
ということ。
プロダクトをローンチするプロセスが良くなかったり、顧客フィードバックをうまくできないと、価値ある形でプロダクトを出せなくなってしまう。
そう考えると、プロセス自体に投資する価値は高いだろう。（特に、プロセス自体に投資を多くしている組織も、日本にはまだ少ないだろうし。）
この記事が気に入ったらサポートをしてみませんか？