誇張しすぎたプロダクト改善がちょうど良い

最近プロダクト改善に取り組む中で感じたことを書く。

開発しているのはリリースされて2年が経つアプリケーションサービスで、新規インストール数・LTVなどが停滞している現状。

さまざまな施策を通して改善を図っている。中で強く感じたことは、いろいろなことを考慮して妥当だと考えた施策を打っても何も変えることができないということ。

例えば、プライマリーボタンのテキストを変えてみましょうとか、ウォークスルーの順番を変えてみましょうとか。

いろいろやってみるけど特に大きく数字が動かないし、ユーザーの体験が良くなっているのかもわからない。

こんな仕事は眠たくなっちゃう

こういった施策は「数字が動いていないので戻しましょう」となるか、良いか悪いかわからないけど「なんとなく残す」という結果になることがほとんどのように思う。

では、どのようなプロダクト改善をするのが良いのか。

最近思ったのは、「誇張しすぎた」くらいの施策を打つのがちょうど良いということ。

デデデデデデデデデデー

そう、ハリウッドザコシショウの誇張しすぎたものまねくらいに。

ザコシの誇張しすぎたものまねがどんなものかを私なりに言語化すると、真似る対象の「そこさえ抑えておけばその人に見える」というポイントを的確に捉えた上で、そのポイントを最大限誇張して他の要素は捨ててでも面白くするというもの。

プロダクト開発に置き換えると、検証したいポイントを的確に捉えた上で、そのポイントが確実に検証できるくらい誇張した施策を打ち、他の細かい話は捨ててでもサービスを成長させること、というものになる。

なぜ誇張しすぎる必要があるのかというと、デザイナーである私の視点からは2つの理由がある。

1つは、自分のやっていることはどうしても細かいことが気になって、どんどん変化の小さいものを作るようになってしまうということに抗うため。

「これは良い改善案なんじゃないか」と思ったものは、他の人から見れば「それで大きな数字の変化は起きるとは思えない」ものであることがほとんどだ。

細かいことが目についちゃう

自分がデザインしているものほど視野が狭くなり、細かいことばかりが気になって、変更点もどんどん細かく小さくなっていくけど本人は気づいていないというのはものづくりの宿命だと思う。

誇張しすぎるくらいの意識を持つことで、この視野の狭まりを自覚することができるかもしれないし、それに抗うことができる余地が生まれる。

2つは、細かいリスクや過去の施策の小さな成功に囚われて、大きな変化を生むことができなくなってしまうことを防ぐため。

誇張せず妥当な提案では変化が小さく、周辺にある細かい数値悪化のリスクや、過去に行った施策の小さな成功を優先してしまう。

今より悪くしたくないやん

小さなスタートアップのサービスを成長させるのに細かいリスクを気にしていてはほとんど身動きが取れないわけだが、見えているリスクが気になってしまうのだろうし、そのようなリスクは挙げたらキリがない。

数字を追っているビジネスサイドの人から細かいリスクの追求をされることがあったが、「こんな細かいこと気にしてたら何もできないだろ」と思いつつも自分の考えを通す道理が手元になかった。

詰んだ状況のように思っていたのだが、誇張しすぎた提案であれば細かいリスクはスキップされて、実現可能性の話に持っていきやすい。

もう少し具体的に、いつどのように誇張すべきなのか。

私は施策の動き出し、現状の課題に対してどんなもので解決するかを考えるときにザコシになるべきだと思う。

単純な話だが、開発が進むにつれて施策は実現できるものに近づいていく。

だんだん眠たくなっちゃう

つまり、徐々に誇張の度合いは弱くなっていくものなので、最初の段階で誇張しすぎたものを提案しておかないと、最終的には超現実的で結果も目に見えている施策になる。

こういった問題に対し、私は先輩から「最初はいろいろ考えずに理想のものを作ることから始めると良いよ」と言われていたが、私の場合この言葉では足りず「誇張しすぎたもの」から始めることにしたのだ。

実際、前述の通り変更による細かいリスクは挙げたらキリがないし、動き出しの段階で完全に考慮すべきことを網羅することは不可能だ。。

このことを前提に、現実的で変化の少ない、やりっぱなしのプロダクト改善をしないためにも自分にザコシをインストールする必要性はあると思う。

自分たちでええやんええやんと言える開発をしよう。