Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Closed
azu opened this issue May 14, 2022 · 0 comments
Labels
Status: Released Released post

Comments

@azu
Copy link
Owner

azu commented May 14, 2022

O'Reilly Japan - プロダクトマネジメント

ハードシングスへの突入と脱出|鈴木大貴 / HiCustomer|noteを読んでてて、そういえばビルドトラップの本読んでないことを思い出したので読んだ。
プロダクトマネージャー向けではあるけど、プロダクトを開発するときにプロダクトとして提供する以上誰にとっても共通の話が結構あって面白かった。

日本語はメインタイトルからは消えてるけど、原題はEscaping the Build Trapなので、ビルドトラップという言葉についての本(この著者が作った言葉)。

ビルドトラップとは
組織がアウトカムではなくアウトプットで成功を計測しようとして、行き詰まっている状況
実際に生み出された価値ではなく、機能の開発とリリースに集中してしまっている状況

サンプルストーリーと共にビルドトラップにハマってしまわないようにプロダクトを作っていくにはどうするべきかみたいなお話。
例となっていた仮企業はUdemy見たいなオンライン講座を提供するProduct-Led Growth(PLG)なプロダクト。
視聴者は見たい講座がなくなって解約するためリテンションが低くて、その原因は講座の作成者が講座に時間がかかっていて、その原因は投稿用のUIだったり動画編集そのものが難しい見たいな実際にありそうな話だった。

論理的に正しいものを作っても実際にそれが使われないと意味がないし、ビルドトラップというのはただのアウトプットにフォーカスしてしまって、実際に使われることにフォーカスしてない現象だと解釈した。
作っても使われないと意味がない(出典が思い出せないけどWebKitで見た気がする、W3CとWHATWGの仕様の話だったかも?)という言葉は結構好きなので、読んでて面白かった。

これ書きながら思い出したのはRethinkDBはなぜ失敗してMongoDBが勝ったのかという話。

何からやるべきかの優先度の付けの話で、価値 x 緊急性のマトリクスからなる遅延コストの評価を使いましょうとか。
これは、バグとかセキュリティIssueのトリアージ基準とかと使うメトリクスが異なるだけでやり方は同じだなーとか思った。

本筋とはちょっと違うけど、この本で一番良かったところは、内部プロダクトもアウトカムを目標にするべきですか?というコラムみたいなところ。

内部プロダクトでの実験
「こういったテクニックを内部向けツールにも使う必要がありますか?」という質問をよく耳にします。答えは間違いなくイエスです。
...
社内ユーザーの満足度が高くなって、以前は仕事をうまくこなすのが難しいと思われていたこのポジションの従業員の離職率が下がったのです。ユーザーは多くの仕事をこなせるようになり、信じられないペースで採用を続ける必要もなくなった結果、事業コストが下がりました。
内部ツールは軽視されることが多いですが、それでも企業にとって重要です。ほかのプロダクトと同じように扱わなければいけません。方向性を理解し、問題を明らかにして、その問題を詳しく知り、何が適切なソリューションかを学習しなければいけません。価値を実証する実験が終われば、最初のバージョンの作成と最適化に集中できるのです。

内部ツールも外部ツールと同じように体験を良くすることで、色々よくなるよという話。
使い勝手の悪い社内ツールは、特定の箇所に負荷が高くなってしまって、その負荷を人間が受ける形(ヘルプとか手動操作)になってると離職率にそのまま直結するのでその通りだなーと思った。
開発ツールとか社内ツールをまともじゃない状態で開発してても楽しくないし、色々クオリティが落ちやすい。
たとえば、開発環境が悪かったりCI/CDが遅いとリリース回数も減るし、トライアンドエラーが減ると品質が落ちる。
なので、いつも最初に直しに行くこと多くて、直感と一致してる感覚があった。

企業がプロダクト主導かどうかを判断する6つの質問

最後にあった質問が面白かった。

  • 最後に作った機能のアイデアを思いついたのは誰?
    • オーナーシップの問題があるか分かる
  • 最後に廃止したプロダクトは?
    • 権限があるか
    • アウトカムじゃなくてアウトプットを見ている可能性が高い
  • 最後に顧客と話したのはいつ?
    • フィードバックを取り入れてない
  • 目標は何ですか?
    • アウトプット or アウトカムのどっちを目指しているかを判断できる
  • 現在何に取り組んでいますか?
    • 問題解決に何をするかという文脈理解
  • プロダクトマネージャーはどんな人ですか?

廃止したプロダクトの話でWHATWGでは結構色々消してたなーとか思い出した。

@azu azu added Status: Draft Not ready to post Status: Released Released post and removed Status: Draft Not ready to post labels May 14, 2022
@azu azu closed this as completed May 14, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Status: Released Released post
Projects
None yet
Development

No branches or pull requests

1 participant