プロダクトオーナーが意識しておくべきことをまとめてみた。

創業してからずっと、なんやかんやとReluxのプロダクト面は見続けており、
全てとは言わないものの、今なお細かいUXすらチェックしていたりします。
 
本日は、Loco日報とかで書き溜めてきたものをひっくり返しながら、
「プロダクトオーナーのあり方」について思うことをまとめよう、と思い立ちました。
少しでも、プロダクト作りに近い方の参考にならば幸いです。
 
なんだかメモを掘り起こしては加筆してたら、大作になってしまいましたが、(;・∀・)
早速、ここから7つのアイディアを紹介してみます。
 
 
結構長いのと、粒度バラバラですごめんなさい。
 
 

#1 ユーザー調査はほとんど意味がない

プロダクトオーナーのMissionを一行で表すとしたら、
「プロダクトを通じ、半歩先にあるユーザーの潜在課題を解決してあげること」だと思っています。
今ではなく「半歩先」で、顕在課題ではなく「潜在課題」 という点がポイントです。
 
スティーブ・ジョブズの例は大げさですが、機能についても言える話しです。
「馬が移動の中心だった時代に調査をしても、「車」という案は出ずに速い馬を求めるだけである。」
 
現代でも同じで、ヤフオクユーザーに「便利な機能」を聞いたところで、
「メルカリをつくってほしい」という意見はまず100%出てこないのではないでしょうか。
 
 
これは「ユーザー調査を一切するな、意見は無視だ」なんて意味ではなく、
我々は常に、半歩先の潜在的課題を解決することが求められているという点が大切です。
ユーザー調査ではあくまで現在ある顕在化している課題しか見えませんので、
半歩先の潜在的課題は、マクロな調査などではまずもって見えません。
(#注 ここ最近はNPSの取得をし、満足度の状態を定点観測するようにはしています。)
 
ユーザー調査はほとんど意味がなく、膨大なデータとにらめっこしながら、
プロデューサーの知恵の絞り出しにこそ、時をかけ努力すべきでしょう。
困った時すぐに「ここはユーザー調査だ!」というのは、思考停止のサインかもしれません。
 
 

 
 

#2 Whyから考える

 


 
このままなのですが、Whatから考えてしまうケースが意外とあります。
データ整理してみよ、ここA/Bテストしようよと言ってみる、この機能どう? 
とりあえずブレストしてみようか。 などなど。 かなり陥りがちな罠であるように思います。
 
また競合調査や似たサービスが提供している機能についても、
そのまま自社に乗り換えるのは、極めて危険だったりします。
たとえば、「Airbnbでは100%レビュー書かせているから、うちもそうしよう」という発想です。
 
彼らはCtoCプロダクトであり信頼こそすべて。その信頼を積み上げるためには100%レビューが絶対に必要(Why)だからそうしているわけで、単純にそれを通常のECなどでも実装するとただ単純に次回購入CVRが下がるだけだったりします。
※逆に、クレームも爆発しやすいけど
 
時間を使うべきはWhyからであり、
そうすれば自ずとWhatが大量に出てくるのでそこを誤解しないほうがよいものです。
Whatという表層コピーだけでは、プロダクトは成長しません。
 
 
あまりにも有名なSimon Sinek氏の動画は、
インターネットサービスのプロダクト開発にも組み込めますので必見。

 
※彼はWhy→How→What と言っているけれども、Why→What→Howもいいかんじです。
 
 

#3 直前の仕様変更は当たり前と、全員が許容すべき風土をもつ

あるある問題かと思いますが、仕様変更は100%起こり得るので許容が大切というお話しです。
プロダクトチームでテスト中にUXエラー(notバグ)を見つけたりしたときに、「エンジニアもここまで頑張ってきてくれたからな・・・」と、遠慮し、UXが落ちるかもしれないのにそれをそのままアウトプットしてしまうことがあります。人間だもの。
 
優しいチーム想いの思考であり、時にそれはとても大切ではありますが、
リリースをしてしまうというのは、100%絶対にダメです。ダメぜったい。
どんなに大規模修正となっても、やり直すべきなのです。なんならリリースしない。
 
理由はシンプルです。
ユーザーは、我々サイドのプロセスには一切の興味がないからです。
直前に仕様変更しようがしまいがプロセスを知らないので、影響が一切ありません。
彼らは世に出たアウトプットしかみることがありませんので、そこですべてを評価されます。
 
どれほど優れた設計もすべてのUXを再現することはできませんので、チーム全体で「どんな精緻な仕様・計画であっても、仕様変更は起こり得る。」と思っておくことが重要でしょう。また、その思考を持つことによって最後の最後にどんでん返しが起こらないようにプロセスにおいても入念なケアをするものですし、全員がOwenershipをもって業務に取り組む風土が醸成されていきます。
 
誤ったUXをリリースすることのほうが、数十倍も損失が大きい。 ということを、
プロダクトチームもエンジニアも互いに理解し合うことが大切とも言えます。
 
1つのネガティブなレビューは、
その裏に100倍以上の人がそう感じているもので、静かに去ってしまいますので、
遠慮は不要、サンクコストは許容、失敗はウェルカム。いつでも巻き戻しましょう。
 
 

#4 引き算の意思決定が難しい

ボタンを1つふやすなら、ボタンを1つ引き算しなければなりません。
新機能を1つふやすなら、旧機能を1つ引き算しなければなりません。
こんな動き方を、基本的には意識したほうがよいでしょう。
 
サービス開発に重要なことはコア機能であり、エッジですが、
運営を続けていくうちにどんどん膨れ上がり、使いづらくなっていきます。
難しいのは足し算よりも引き算であり、引き算の最終意思決定はオーナーにしかできません。
 
「新しい機能を追加しよう」は、必要だからこそ意思決定は簡単ですが、
「この機能を削除しよう」は、必要だと思ってリリースしたものですし、愛着もあり、
また、誰かしらは必ず使っているので、ユーザーデメリットがどうしても発生します。
しかし、たとえ利用者がいようとも数ヶ月後、半年後のプロダクトビジョンから考えて妥当ならば、鋼の意思をもって引き算しなくてはなりません。
 
当社では毎年末に「大掃除プロジェクト」と称して一斉引き算をするようにしていますが、16年も大きなものだけでもこれら機能を削減しています。(全て12月にさりげなく削除済、プロダクト以外の制度も対象)
 
・多言語ページ(利用度が低い5ヶ国語以上を削除)
・決済通貨の変更機能
・法人向け福利厚生サービス
・アンバサダー機能
・トラベルカルテ機能
 
 
引き算の意思決定こそ、
プロダクトオーナーのセンスや判断力が問われるポイントです。
 
 

#5 「プロデューサー病」に要注意

プロデューサー病とは、自身が一般ユーザーの数百倍頻度でサービスを見ているがためにかかるバイアスです。皆さまは、自分のサービスにアクセスしない日はないですよね。しかし、ユーザーの方々は(Reluxだと)1年に数回しか基本的にはアクセスをしません。
 
何が起こるかというと、全く本質的ではないムダなところを気にかけてしまったり、
一般的には誰も気にかけないような、使われないところを改善してしまっていたり、
また、使い慣れたごく一部の人しか使わないような機能開発を一生懸命に優先度highで対応したり、
プロデューサー病にかかると、誤った意思決定を日常的に執行してしまうものです。 
 
ありきたりですが重要なことは、素直なユーザー目線であり、プロデューサー目線はいらないのです。
毎日触っている時点で素直なユーザー目線からは離れてしまっているので、
「バイアスがある」という前提で取り組み、そしてその前提を超えて解決策を提起しなくてはなりません。
 
 

#6 結果指標よりプロセス指標

結果指標(多くのKPI)だけではなく、プロセス指標という考え方をもったほうがよいと常々感じております。
 
「KPIは何?」といえば二言目には「ここのPV数をこうやって増やし、CVRを改善しよう」という、誰でもできる因数分解の話に陥ってしまうことがあるものです。これは単なる結果指標であり、その手前のプロセス指標もあわせてみるべきであると感じています。
(→プロセス指標の多くは、OKRに適切な数値であることが多い)
 
その理由は、結果指標だけでは影響する改善が多すぎて、単にそこを追いかけるには不適だからです。
「あれ、この日はなんでこんなに上がったんだ・・・(;・∀・)?」などと、なりがちです。
 
PVを減らして濃くすれば簡単にCVRはあげられるし、
PVを思い切りあげることも簡単だからなのですね。(⇔CVRは下がる)
これでは数値改善しても意味がなにもないけれど、意外と普通に行われていますし、
実に分かりやすい利益相反でしょう。
 
KPIのモニタリングは大事であるのでそれはそれでするとして、
それよりも日々の改善活動は「CVRを操作している隠れ指標(=プロセス指標)」をこだわるとよいです。
 
たとえば、ありそうな適切な数値は、
・1UUあたりの滞在時間
・サイト内平均滞在ページ数
・サーバーレスポンス速度の改善  といったものですね。
 
これらは直接的にCVRにHitしない(ようにみえる)けれども、
明らかに予約相関があるような数値がいくつも転がっています。
これらをKRとして定め、「上がることが確かなる正義」な数値を探すべきなのですね。
参考:OKRとは
 
その改善ループをWeeklyでぐるぐるまわし、
気がつくとCVRが改善していく、というのが美しいプロジェクト体制のあり方ではないでしょうか。
 
 

#7. リーンx失敗を認める文化

また文化の話しなのですが、当社では「Fail Harder」というバリューを掲げています。
参考:新コーポレートバリューへの移行
 
「激しく失敗しよう」という意味なんですが、2つの良い点があります。
1つは、個人がみんな挑戦し合う文化になることです。
もう1つは、他者が失敗を許容しあう文化になることです。
 
今なお、流行りものはどこの旅行代理店や宿泊予約サイトよりも速く着手し、
それだけ失敗量も多いですが、成長し、結果的に芽が出てくれたものが大量にあります。
失敗量と成長カーブはおよそ比例するので、リーンに挑戦し失敗を称え合う文化を、
プロダクトオーナーは持っておいたほうが良いのではないかと、私は強く感じます。
 
 
失敗を恐れた打ち手は、たいていインパクトが何もありません。
「What would you do if you weren’t afraid?」
Link http://ifuwerentafraid.tumblr.com/
 
 

まとめ

他にもたくさんありますが、なんとなく重要だなと思っていることをだらだらと書き綴ってみました。めちゃくちゃ長くなってきたので、これにて m(__)m
 
これからも、Reluxでは半歩先の潜在課題解決を意識し、新しい価値提供をして参る所存です。
そして、共感いただけるエンジニア、プロダクト・マーケチームメンバーはいつでも大募集中です。
また、他にもこんなこと考えてるよ、などあったら是非教えてください。
 
 
是非、ご連絡ください。ᕦ(ò_óˇ)ᕤ
 
 
追伸:明けましておめでとうございますブログでした。