「プロダクトマネジメント ―ビルドトラップを避け顧客に価値を届ける」を読んだ #26
azu
announced in
Announcements
Replies: 0 comments
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
-
O'Reilly Japan - プロダクトマネジメント
Issue: #25
ハードシングスへの突入と脱出|鈴木大貴 / HiCustomer|noteを読んでてて、そういえばビルドトラップの本読んでないことを思い出したので読んだ。
プロダクトマネージャー向けではあるけど、プロダクトを開発するときにプロダクトとして提供する以上誰にとっても共通の話が結構あって面白かった。
日本語はメインタイトルからは消えてるけど、原題はEscaping the Build Trapなので、ビルドトラップという言葉についての本(この著者が作った言葉)。
サンプルストーリーと共にビルドトラップにハマってしまわないようにプロダクトを作っていくにはどうするべきかみたいなお話。
例となっていた仮企業はUdemy見たいなオンライン講座を提供するProduct-Led Growth(PLG)なプロダクト。
視聴者は見たい講座がなくなって解約するためリテンションが低くて、その原因は講座の作成者が講座に時間がかかっていて、その原因は投稿用のUIだったり動画編集そのものが難しい見たいな実際にありそうな話だった。
論理的に正しいものを作っても実際にそれが使われないと意味がないし、ビルドトラップというのはただのアウトプットにフォーカスしてしまって、実際に使われることにフォーカスしてない現象だと解釈した。
作っても使われないと意味がない(出典が思い出せないけどWebKitで見た気がする、W3CとWHATWGの仕様の話だったかも?)という言葉は結構好きなので、読んでて面白かった。
これ書きながら思い出したのはRethinkDBはなぜ失敗してMongoDBが勝ったのかという話。
何からやるべきかの優先度の付けの話で、価値 x 緊急性のマトリクスからなる遅延コストの評価を使いましょうとか。
これは、バグとかセキュリティIssueのトリアージ基準とかと使うメトリクスが異なるだけでやり方は同じだなーとか思った。
本筋とはちょっと違うけど、この本で一番良かったところは、内部プロダクトもアウトカムを目標にするべきですか?というコラムみたいなところ。
内部ツールも外部ツールと同じように体験を良くすることで、色々よくなるよという話。
使い勝手の悪い社内ツールは、特定の箇所に負荷が高くなってしまって、その負荷を人間が受ける形(ヘルプとか手動操作)になってると離職率にそのまま直結するのでその通りだなーと思った。
開発ツールとか社内ツールをまともじゃない状態で開発してても楽しくないし、色々クオリティが落ちやすい。
たとえば、開発環境が悪かったりCI/CDが遅いとリリース回数も減るし、トライアンドエラーが減ると品質が落ちる。
なので、いつも最初に直しに行くこと多くて、直感と一致してる感覚があった。
最後にあった質問が面白かった。
関係ないけど、廃止したプロダクトの話でWHATWGでは結構色々消してたなーとか思い出した。
This discussion was created from the release 「プロダクトマネジメント ―ビルドトラップを避け顧客に価値を届ける」を読んだ.
Beta Was this translation helpful? Give feedback.
All reactions