tuneの日記

アジャイル開発、組織変革、マネージメント、ファシリテーションについて学んだことの記録

"プロダクトマネジメント ―ビルドトラップを避け顧客に価値を届ける"の感想

プロダクトマネジメント ―ビルドトラップを避け顧客に価値を届ける

プロダクトマネジメント ―ビルドトラップを避け顧客に価値を届ける

  • 作者:Melissa Perri
  • 発売日: 2020/10/26
  • メディア: 単行本(ソフトカバー)

社内で実施した読書会 & 議論で大分満足してしまい、記録を残し忘れていました。 今更ですが自分の感想メモです。

1章 : 価値交換システム

競合でその機能が成果を出していることを確認しているか?

競合がある機能をつけると「是非うちでも」という話が出てきがちで、2番手以降のプロダクトだと「星取表で負けてるから売れないんだ」という話に流れがちですが、「競合のその機能はユーザーに響いているんですか?」という返しはしたことなかったかも。でも「わからないけど星取表で全体的に負けているからダメなんだ」とか返されてぐぬぬとなりそう。こういうやりとり仕事でしていると、まずいいプロダクト作れていないので気をつけていきたい。

企業は従業員を顧客やユーザーと近づける必要がある。それによって学習できる。

これですね。

2章 : 価値交換システムの制約

リリースしたものがうまくいったかはどうわかりますか?

正常に動作した時の挙動や、受け入れ条件の話はよく出るけど、ユーザーの行動・振る舞いをプロダクトによって良い方向に変えたいことがゴールなので、どうやって知ることができるかはもっと気にしていきたい。

アウトカムってもうちょっといい用語ないかな?

この本を読んだ人同士だと「それってアウトプットじゃ無い? アウトカムは何だろう」と話せるけど、読んだことがない人に「アウトカムは何ですか?」と聞くとアウトプットが返ってきそう。もっといい日本語ある気がするんだけど思いつかない。読書会だと「Burning Needsどうだろう?」と思ったのですが、アウトカムよりさらに狭い界隈にしか刺さらなそう。

3章:プロジェクト / プロダクト / サービス

望ましいアウトカムを得られるまで組織を最適化する

アウトカムを目標に据えて、イテレーションでプロダクトを磨いていく。その過程で開発プロセスや開発組織も磨いていかないといけない。

プロジェクトではなくプロダクト

これは自分もことあるごとにいうようになったけど、プロジェクトやめていきたい。

4章:プロダクト主導組織

「ビジョナリー気取り問題」ってありません? エセジョブズ問題

自分の作りたいようにプロダクトを引っ張ることを目的としているPdM志望の人ってよくみませんかという話。 書籍では「ビジョナリー」と紹介されていたけど、TwitterSNSで見る感じ大抵の人はたまたまくじに当たった一発屋ジョブズでは無い感じ。 エセジョブズの人は夢を壮大に語るけど、何となくユーザーを向いてない気がするんですよね。

5章:私たちが知っていること、知らないこと

「未知の未知」が最近ようやくしっくりくるようになった

既知と未知の組み合わせの4象限の話。PdMは自身が手を動かすことによって未知を既知に変えていかなければならない。

6章:悪いプロダクトマネージャーの典型

PdMはミニCEOではない

会社(プロダクト)のビジョンを変えたり、人事をどうこうする権限がないので、CEOではないのだという話でした。 確かにその通り。

アジャイルではアイデアを検証するステップが抜け落ちている

これはここ1年ぐらいで痛感しています。 「小さく始めるんだ」といいながら、うまい検証のやり方を実験できてない感じ。

会社でPdM(プロダクトマネージャー)研修できそう。 ストーリーの書き方、ミーティングのやり方、要望の集め方、テストのやり方

PdMの育成プロセスがないよねという話から。 「いいPdMの排出企業」もこれといった会社が無い気がします。

自社でも育成に取り組んでいますが、「みてやって覚えろ」だけじゃなくて、定期的に勉強会・研修を整備しても良いのかもしれない。 複数社で協力してやると運営も楽になって良さそう。

7章:優れたプロダクトマネージャー

PdMはPO(プロダクトオーナー)を内包する

これもそうですねという話。 スクラムを使っていると、プロダクトオーナーが全てプロダクトの責任があるように思ってしまうが、責務を書き出してみるとPdMの方が多い。

10章:戦略とは何か?

優れた戦略とは詳細な計画のことではありません。 戦略は意思決定を助けるフレームワークである。

何をやるかのリストより、何をやらないかを決める根拠にできるものがよい戦略・フレームワークだなと思うようになりました。 中期計画も機能のリストじゃなく、重要なアウトカムのリストで作っておけば軸がぶれなくて良さそう。

11章:戦略のギャップ

上位の意図をどう実現するかは任せるべき。 なぜ必要なのかは上から下に伝える。どう実現するかは下から上に報告してもらう。

普段から心がけていることではありますが、判断に使うであろう情報はできる限りオープンにしておき、判断を委ねるのがスピードが出て良いですね。

12章:良い戦略フレームワークを作る

チームに制約を設けた方が動きやすくなるが、ミッションで狭めるのが良いかというと悩ましい

今の開発チームは会社のほぼ全領域に携われるようにしているけど、チームや組織ごとにある程度の制約を設けた方が自分たちで目標立てやすくなって良いのかなともやもや。 制約を入れた方が良いことには同意しつつ、どう入れるかはプロダクトの範囲ではない気がしています。

失敗に成功したい

気持ちとは裏腹に成功した失敗の実例が思い出せず。小さな実験しかやってないのだろうなと。 失敗しないと許容文化も生まれない気がするのでもっと実験していかないと。

13章:企業レベルでのビジョンと戦略的意図

ミッションは企業の存在理由を説明する。 ビジョンは目的に基づいてどこに向かっていくかを説明する

ビジョンとミッション、以前はしっくりこなかったのですが、ビジョンがしっかりしてる現職で働いていてこれは良いものだなと思うようになりました。 ビジョンの存在が強すぎてミッションが弱くなっているのでこれを時間作ってブラッシュアップしていくといいんだろうな。

15章 プロダクトのカタ

価値提案の中心でないものに対して、凝ったものを作らない

これ。 SaaSが増えてきたからか、自身の考え方が変わったのか、お金で解決できるものはお金で解決した方が良いなと考えるように変わりました。

16章 方向性の理解と成功指標の設定

AARRRはユーザー満足度について語っていない

これ。 定量指標を意識することは大事だけど、何を見ていて、何を見れてないのかは常々意識しないといけない。

17章 問題の探索

問題を根本的に理解しなければ、適切なソリューションを意図して作ることはできない

同じアウトカムに対してイテレーションで取り組んでいると、問題の理解度がだんだん深まってきて適切なソリューションにたどり着ける気がする。 プロダクトの弱いところを全体的に手直ししようとして表層的な問題に取り組み続けるよりも、自社の未来につながる問題に継続的に取り組んでいかないといけない。