
『Outcomes Over Output』 事業を加速させるユーザの行動様式の変化
『Outcomes Over Output: Why customer behavior is the key metric for business success』 を読んだので、個人的に大事そうな箇所を記録する。ところどころ個人の解釈をいれてます。
私自身、最近、アウトカムやユーザにとっての価値などを考える機会が多いのと、 プロダクトマネージャー向けの目標設定の書籍として紹介されていたので、この書籍を読むにいたった。
書籍では、アウトカムについて、具体的な事例をとりあげつつ、個人や組織がアウトカムへ思考を切り替えるための方法や様々な問いかけがあげられている。
まず、アウトカムとは何か?
書籍によると「Change in human(customer, user, employee) behavior that drives business results」 = 事業を加速させるユーザの行動様式の変化 としている。
ここでは、誰の行動様式なのかどうかは様々な文脈があると思うので、ユーザとしている。それぞれの事業や状況に応じて置き換えてほしい。
最初の事例として、2年間かけて作ったものが使われることなく、何の価値も提供できないままになったことをあげている。
なぜ、こんなことになってしまったのか?
かつてのものづくり的な思考のままで作ったことを要因としてあげている。かつての物理的なものであれば、完了の定義は明確であったが、その思考のままでソフトウェアに適用してしまったこと。
また、開発の進め方で、よくある機能リストをもとに開発を進めることもあげている。
その問題点は、その機能の開発が完了しデリバリーされたとき、確かにそれは機能するかもしれないが、何も”価値”を生み出していないことである。
では、”価値”を生み出し、ユーザの行動様式が変化しているかどうかは、どのようにして確認すればよいか?
この問に対して、「より小さく、測定可能かつ密接に関連しているチェックポイントを設定してあげることと」と記載されている。(よく目標設定の際に利用されるフレームワーク「SMART」っぽい)
このチェックポイントにも関連するが、書籍では”Experiments” = ”実験” という言葉もよく登場する。
本当に”価値”が生まれているかどうかを確認するには、”実験”をすること。不確実性を管理するには効果的な方法である。
MVPという言葉があるが、書籍では単に実験という意味として使っており、 ”仮説が正しいかどうかを学ぶためにできる最小限のこと” としている。
私が「アウトカム」の話をするときは、同時に「アウトプット」と「インパクト」の話をするようにしている。(こちらの記事を参照することが多い Measuring developer productivity? A response to McKinsey )
書籍では、事業の売上・収益増加は「インパクト」であり、様々な結果の総和であるとしている。これをより小さく、実行可能な部分に分解して話す必要がある。
マネージャーとして、
「アウトプット」にフォーカスしてしまうと、何を作るかは明確だがそれがどう利用されるのかについては曖昧になり、
逆に「インパクト」にフォーカスしてしまうと、どうすればそれが実現できるのかどうかの具体性に欠ける。
そこで、「アウトカム」にフォーカスすることで、ユーザにどんな行動をしてほしいのか、それを実現するために様々な実験と学習を繰り返していくことができる。
“価値”とは何か?
ユーザの行動様式を変えるためには、ユーザ自身に”価値”を感じてもらう必要がある。
“価値”という言葉は曖昧で、人々の足並みを揃えることは難しい。
なぜ、難しいのか?それは、Leaders (ここでは事業責任者とする)と Executors(ここでは開発者とする)で、それぞれの特異性で考える傾向があるから。
事業責任者は主に売上や収益といったインパクトに、開発者は主にアウトプットとアウトカムに責任を持つ。
これに対する解決策は、事業責任者が気にかけているであろうインパクトにどういった効果を示してほしいのか?というコミュニケーションを試みることである。
現場目線で、自分たちの仕事が、事業責任者が関心を寄せているインパクトにつながっていることを、開発チームに示すことができれば、会話はより地に足が着いたものとなり、組織全体で足並みが揃うようになる。
書籍では、プロダクトロードマップにも触れている。
通常のロードマップというと、開発チームがいつ提供するかを約束した機能リストにしかすぎない。
こういったロードマップの問題点は、ほとんどの場合、推測や嘘であること。
これに対する解決策の一つとして、アウトカムベースでのロードマップを紹介している。
似たものとしては、カスタマージャーニーをあげており、自組織のインパクトやアウトカムをマッピングし、目標達成のための構成要素に分解していく。
この分解はユーザの行動を視覚化することであり、これによって、ユーザのどんな行動を奨励したいのか、どんな行動を排除したいのか、どんな行動が欠けているのかを考え始めることができる。
具体的な答えやアイディアでロードマップを埋めることは避け、むしろ仮説を中心に構築していくことを推奨している。
さいごに、組織やチームでアウトカムに向き合うために、書籍には以下の3つの魔法の質問が記載されている。
ビジネスを加速してくれるユーザの行動様式は何か?
私たちはどうしたら、よりそのユーザの行動をしてもらえるのか?
私たちの仮説が正しいことをどうしたら、知ることができるのか?
話の対象が機能を作ることに向かっていっているとしたら、書籍で紹介されているこれらの質問を投げかけていきたいと思う。