POとPOじゃない人の勉強会 第6回

第6回は、カラーミーショップ のサブマネージャである ライティ が12章から14章をまとめました。

12章 製品をみつけだす

製品を定義するフェーズと作るフェーズを分けるのもわかるけど、走りながら考えるということも必要ではないだろうか。

ここで言っているのは、おそらく比較的大規模な組織でプロダクトクオリティなものを作ることを想定しているように見える。

「製品を見つけだす」というフェーズの終わりには2つの問いに答えられなければならない。

  • ユーザがいるか
  • 実現可能か

これはまさに、リーンスタートアップやデザインスプリントである。これらは、実際に手を動かしながらも、フェーズとして「製品を見つけだす」フェーズの活動だろう。

なので、要件定義をちゃんとしてから開発しろって話ではない。

マネージャはエンジニアリングチームを遊ばせておきたくないないから手を動かせという誘惑と戦わなければいけない。

13章 製品理念

インセプションデッキの話っぽい。

大体の衝突は、事業の目標の解釈、それらの優先順位について合意がとれていないことが原因。

目的や優先順位の話、視点を小さくしていくと、ミーティングの進め方にも繋りそう。

合意したあとに、ずれていくということも多い。どうすればいいのか。毎日復唱する？

XXプロジェクトでは、インセプションデッキをみなおしたりした。

意思決定のプロセスと理由付けをみんなに完全に見えるようにしておくことが大事。経営者やサービスの責任者など、現場から距離のある人は必ずしも理由付けを見える化できないこともありそう。どうしたらいいのだろう。

14章 製品委員会

意思決定に関わる全員をあつめるのが重要。

UX担当の人っていないね。

デザイナーがいろいろやっている、できる、ということは、一歩間違えると責任の所在が不明になる。

ロールによって見ているスコープが違うよね。

POやマーケティングは今ではない、これから進むところを見ていないといけないのでは。エンジニアリングやデザイナーとは見ている世界が違う。それを尊重し、お互い補完しないといけない。

流れを監視する > 継続的に全サービスを見るのは無理だよね。

見積りとか計画の話。

たとえば、3ヶ月後から開始しないといけない大きめの機能開発あるが、今から3ヶ月間は自由にできるというシチュエーション。
エンジニアの見積りでは3ヶ月となっていたものが実際にやってみると4ヶ月になる大変と困る。
こんなケースでPOはどうしたらいいか。

一つの解は、1ヶ月程度のスケジュールバッファをPOが設ける。つまりエンジニアの見積りで3ヶ月のものはやらない。

おまけ

今日は、 product_owners チャンネルで寄せられた参加者の声を載せておこうと思います。これで参加者が倍増するはず！

  • この後勉強会があることだけが心の安らぎかもしれない、、、(A事業部Tさん)
  • 心の拠り所になっている (B事業部Tさん)
  • 今日も学びが多かった！！ (A事業部Wさん)

プロダクトオーナーシップ勉強会 第5回

第5回は、写真共有サービス 30days Album のマネージャである としや が9章から11章をまとめました。

9章 プロダクトマネージャーを支えるブレインたち

「優秀な人を製品開発チームの一員にしてしまうこともある」とあるけど、そうしない、そうできないケースってどういう時があるんだろう。いい人だったら絶対欲しいのでは。他のチームのマネージャーだったり、そういうことかな？

この章では、大企業でマネージャに個室や独立したスペースが与えられていることを想定していそう。

他の社員やユーザへのアンケートやインタビューの結果を上手く使うのは本当に難しい。結局事業部の方針を優先しがちだったり、自分の欲しい答えを探してしまう。

10章 上から降ってくるものをうまくさばく

3番目以降は普通の仕事の話。

手のかからない社員 VS 報連相。ただふんわりと話を持っていくんじゃなくて、自分の考えをまとめてから行けということ。

根回しはありかなしか。会議の目的次第。決めるための会議なら根回しはすべき。

11章 製品の市場性評価

リーンキャンバスの形骸化。リーンキャンバスってなんだっけ？

リーンキャンバスの実際の使い方は RUNNING LEAN がすべて。

ざっくりと言うと、最初に両側を考えて、顧客と問題領域についてだけ書いたキャンバスをたくさん書く。そこから中を埋めながら枝刈りして、最終的な数枚のキャンバスの中から下にあるコストと回収について、一番価値のある案を採用してがっと作る。1枚のリーンキャンバスだけをがんばって考えるのはリーンキャンバスというツールを上手く使えていない。

ミートのための開発と、ワクワクする機能の開発のバランスの話。

基本的には数字と根拠に基づいて取捨選択すべき。1つのやりかたが狩野モデル分析。あたりまえ品質のもの(多くの場合はミート)を作るフェーズで、顧客満足度が上がらないと嘆くのは無意味。

MRDは誰が作るのか。事業の責任者が作る or プロダクトマネージャが作る？

収益モデルはだれがどこまで理解しているべきか。

プロダクトオーナーシップ勉強会 第4回

第4回は、デザイナー件プロダクトオーナーである @getsukikyu が6章から8章をまとめました。

この回からはなるべく議事録を書いて残そうとしていたので議事録があります！

6章 プロダクトマネージャーの条件

「そして、何よりも~」の文は何を言っているのか？
「啓蒙」という表現が相手の立場になっていないことを表わしているのでは？共感できる人を探そう、というメッセージっぽい。

知性は学校の勉強ができるという意味ではない。問題解決能力。

B級の人がC級の人を連れてくるのは、見る目がないというのと、保身という面もあるのでは。

倫理感。ワークライフバランスの話もある。エンジニアも似た側面があるね。

仕事と生活が一致している人を「僧侶タイプ」と呼んでいる人登場。

自分にとってベストなパフォーマンスがだせる働き方を知って、それを実践すればいいのでは。
それは生活や仕事のステージによっても変わるかもしれない。

全てを仕事にささげろってことではないといいな。

チームメンバーはプロダクトマネージャが困難にどう立ち向かっているかを見ている。

Q. 無理難題をどうチームメンバーに伝える？

A. 追加できるかの確認と、どれと入れ替えるかを相談する。

Q. 全部ってなったら？

A. 信頼関係次第では…信頼貯金をいつ切り崩すか。あとは伝え方もありそう。

上から言われたからお願いしますはプロダクトマネージャとして無責任だろう。自分が決めたこととしてお願いする。

プロジェクトマネージャがいれば、その人に移譲するのもありでは。

チームメンバーにいきなりぶちまけるとびっくりされることもある。チーム次第だけど、リーダー的な役割の人に事前に相談したほうがいいことも。

詰め込まなければならなくなったら、その結果をちゃんと共有するとよさそう。あの機能を入れたおかげで、売上がこれくらいあがったとか。

声高な要求に屈指ないことの重要さ。一方で会社の戦略は理解しよう。

7章 プロダクトマネージャーを管理する

プロダクトマネージャを育てるというフェーズのメンバーじゃないね。まずは自分達が成長しよう！

VP ≒ あんちぽさん では？ > ペパボでは事業部役員のひとたち。

組織や業態によってVPが果すべき役割は違いそう。

社内の競合する製品の戦略については、VPがいるともっとよい方向を見つけられるのではないかと思うことがある。

企業の戦略として、ブランドを統一する方向なのか多ブランド戦略なのかは意識しよう。

NPS(ネットプロモータースコア)を算出するのにどれくらいあつめたらいいのかな？

退会時だけでなく、継続のときにアンケートとってみたらどうだろう。ストックビジネスなんだし。

特注品の話。短期的な売上が目的になりがち。全体の中から優先順位を上げるのはいいかもしれないけど、本当にその人しか使わないような機能を入れるのは悩ましい。

8章 パットン将軍の教え

Q. あがってきたものがとんでもないものだったらどうする？

1分間マネージャーの話4つの分類。それぞれに目標設定が必要だし、コミュニケーションの取り方を変える必要がある。

作業途中を見られることの障壁。「そこまだやってないところなんで」

どうやったら無駄をなくすことができるか？

Whyとかイメージを共有しよう。ユーザストーリー、リーンキャンバス。クックパッドのやりかた http://techlife.cookpad.com/entry/2015/06/01/135804

プロダクトマネージャが正しい保証もないだろう。

京都行きたいっていって、大阪の切符買ってきたらまぁいいかな？方向性があってればいいってのはありそう？

他の人にこれはどうか聞いてみる。

本人にも聞いてみる。(本人も納得していないこともよくある)

完了条件を明確にしてあげる。だれにOKを貰えばいいのか、調整する相手はいるか？等。そうしたら、自然と自分でおわったつもりになることは減る、といいな。

おまけ

会議のありかたとか議事録について雑談

https://speakerdeck.com/kenchan/all-of-minutes-i-learned-in-esm