00:02
はい、おはようございます。ゼロトピックです。
10月5日、月曜日の朝に収録してます。
僕の住んでいる地域だけなのかわからないですけど、朝5時くらいに散歩してたら、虹がかかってて、すごい虹が綺麗だったんですよね。
しかも5時に虹を見るって、そうない体験なのと、ぽつぽつ雨が降ってたんだけど、晴れそうな雰囲気も出てて、いい集会になるといいなと思ってます。
個人的には今週めちゃくちゃ忙しくて、すごい重要なディールもあるし、採用面談もあるしっていうので、少し気合い入れて頑張ろうかなっていう、そんな1週間になりそうです。
もうちょっといらない話から始めると、最近フリーアジェンダっていう、僕とグロースキャンプっていう会社をやっているヒカルさんが2人で運営してるポッドキャストがあるんですけど、
2人でというか、そこにサポートで、現在メルカリに勤めているチルダっていう女性のサポートがいて、3人でフリーアジェンダっていうのを運営してるんだけど、
そのフリーアジェンダが99回収録したのが先週で、今週の木曜日にまた収録をやるんですけど、そこで100回記念になりそうなんですよね。
100回続くとか、そもそも何だろうな、必要じゃない、エッセンシャルじゃないプロジェクトなんだけど、そんだけ一緒に誰かと何かをやるってあんまり経験がないなと思ってて、
こんだけ続いてるのってすごいなと思ったともに、その続けるときのコツというか、何で続くのか、続くもの続かないものを僕もたくさん経験してきたんですけど、やっぱり続くものには続くものの理由があるなと思っていて、
そういうものはちょっとフリーアジェンダの方のね、結婚の会で軽く言語化してるんで、ぜひそれは聞いてみてほしいなと思いました。
100回目の記念で何話すんだろう、何話すのかちょっとまだフリーなアジェンダなので、パキッと誰も分かってない状態なんですけど、ちょっと100回記念をしたいなと思ってます。
このゼロトピック何話そうかなと思ったかというと、まずはGrowthという試作について、どういうものをやればいいかみたいなことについて話したいなと思っています。
これは別で僕がCampfireで社内に師匠がいないPMのための師匠コミュニティみたいなノリで解説したんですけど、それが意外にずっと盛り上がっていて、質問をもらったことがあったんですね。
それについて回答した内容をちょっと口頭で補足したいなと思って話しています。
03:03
その質問内容がGrowthの試作のマネジメント方法みたいな形だったんですけど、そこから発展して、じゃあ一体どういうものを実際にすればいいのかとか、そういう話になってきました。
まずその1個目のGrowthの試作のマネジメントみたいな方法については、明確にIssueから始まるべきだと思っているので、Issue Analysisをベースに試作は考えるべきかなと思っています。
Issue Analysisってどういうものかっていうと、それもフリーアジェンダっていう、そちらの第60何回とかで話してるんで、それを画像というか実際にどういうアウトプットを作るのかっていうのも画面共有で見せながら話してるんで、ぜひそれを見ていただければいいなと思うんですけど、
まず左側に一番大きいIssueがあって、それを割ったサブIssueがあって、それにN個の試作が連なるっていう、そういうツリー構造のIssue分析をしたものになります。
Issueって往々にしてクロスしたり、スパゲッティ状になるっていうのはすごいよくあるんですけど、あまりミニCとかスパゲッティをどうするかとか考えずに、とにかく大きいIssueが一番左に並んでるってことがすごい重要です。
そのIssueを解決するためのサブIssueもできるだけ具体的であることとか、あとIssueって何々できていないみたいな、そういう否定系の文章で書かれることが多いかなと思うし、
僕も初めてそういう風に課題なので何々できてないみたいな書き方をしてたんですけど、そうではなくて何々にするみたいな、どういう状態にするみたいな、そういうIssueの定義の仕方がすごいいいかなという風に思います。
理由は2つあって、1つは前向きに取り組めるってことと、あと何々するっていう言葉の裏には、それは施策を通じて何々するとか、
その後のアクションが必要なことがすごく強くメッセージされていて、それ自体がいいかなと思うんですよね。
何々しないっていう否定系、何々ではないみたいな状態をただ言い表すだけだと、ただ否定的な文章でちょっとうがった見方すると、「で?」ってなっちゃうんですよね。
だからIssueは僕は何々するとか何々状態になるみたいな、そういう未来に向けて書かれたものであるのがいいかなという風に思っています。
例えばね、1日100ユーザー獲得できていないって書かれるよりも、毎日100ユーザーを獲得するって書かれていると、
それをどうすればいいかっていうサブIssueに割りやすいじゃないですか、みたいな、そんなイメージです。
今の100ユーザーにするみたいなのが、ぶっちゃけいいIssueの定義文化っていうと結構微妙だなと思うんで、
なぜ微妙かというと、ユーザーを見ていないんですね。
サービスをサービス運営の立場としてパッと健康診断したときに、そういう言葉って出てくると思うんですけど、
サービスって誰が使うかというと顧客、ユーザーであって、その顧客の側を向いていないIssueは全部空虚だなと思うので、
06:08
やっぱり我々ってインフルエンス業をやってるわけじゃなくて、
プロダクトとかオペレーションとかマーケティングとかってあらゆるものは顧客のためにやってるので、
なので顧客の視点からIssueが語られるべきかなっていうのが、それは良いIssueだと思います。
もちろん僕もサービスを運営する側がサービスを見たときのIssueとして書くことはあるんですけど、
限定的というか全てがそれで構成されていては良くないかなっていうそんな話でした。
グロースの施策を叩き出したり、グロースの施策を行っていく上で何を重視するかっていうところで、
これはちょっと社内にもちゃんと名言化しておいておきたいなと思うんですけど、
僕はUXとちゃんとアラインしてることとか、あとはシステムデザインとかデザインシステムと、
これなんだ、言葉遊びみたいになってますけど、
要はサービスのデザインとあるいは将来のシステムのあり姿、
to beみたいなものとちゃんとアラインしてるかっていうのがすごい重要だなと思ってます。
例えば特定のKPIがあって、何々転換率みたいなのがあって、
これを2倍上げたいみたいな話になったときに、
2倍に上がることってそんなないですけど、
その何々転換率を上げるために、
ハック的な要素、UXもシステムとのアラインも全部無視した状態の施策って、
別に何本でも出せると思うんですよね。
例えばユーザーがその前のボタンを押したときに勝手に転換してしまうようにするとか、
これって果たして価値があるかというと僕はないと思っていて、
なぜならそのユーザーって嫌な思いをして利反する可能性もあったりするという、
そういうリスクをはらんでいて、
じゃあサービスって何のために提供するかというと顧客のためなのに、
その顧客の利反でまでやる施策って何の意味があるのっていう、
そういうマインドからあまり重視していないというのがあります。
なので当たり前ですけど、ユーザーの顧客の価値が上がること、
体験価値が上がること、体験価値が上がり、
かつシステムとしてもシステムっていろんなコンテキストとか積み上げの上に
そのプロダクトのシステムって動いてるはずで、
さらに将来どこに行きたいかっていうビジョンがあるはずなんですよね。
そのビジョンからそれないものをやるべき、
なぜならそれは後戻りする必要がないから。
なのでそういうものをやるべき。
かつそのUI上も、
例えばずっとプライマリーカラーがブルーのプロダクトだったのに、
急にグリーンが出てきて目立つから落ちちゃうみたいなものではなくて、
09:03
その後も当たり前のようにめくめくと使われるようなデザインシステムの中で
表現されるべきだと思うので、
基本的にはやっぱりプロダクトを作るっていうプロダクト開発の行為から
絶対に逸脱してはいけないなっていうふうに思っています。
ただその中でもできるグロースの施策って、
上げようと思えばキリがなく開けるので、
ユーザーの体験を極めて高めていくっていうことと
ほとんどグロースってのは僕は同じかなっていうふうに思っています。
あともう一つグロースでできることって、
1.1Xの積み上げなんですよね。
10%の影響があったらすごい良いぐらいで、
5%とか3%良くなったを積み上げていく。
その中にトレードオフがある場合もあるので、
そこのトレードオフの解消をするのかしないのかっていう意思決定をしていくことだと思うんですよね。
そうなっていくと、実はたくさんやったのにトレードオフだらけで、
結局何が上がって何が下がったのか分かりませんとか、
上がったものと下がったもののネットがゼロですみたいな、
そういうことって結構よくあると思っていて、
本当に良いグロースっていうのは、
そのトレードオフを生まないもの、
つまりユーザーにとってプラスしかないものなんですよね。
だからそういうものに限定して行うっていうのは、
僕は数字が良いんじゃないかなと思っています。
本当に何かの数字を2倍変えたいってやったら、
変えるべきってグロースとかっていう施策じゃないんですよね。
グランドデザインって僕が呼んでるんですけど、
プロダクトのデザインを変える必要があると。
プロダクトのデザインってのは設計なんで、
すべてアーキテクチャを変える必要があると思っています。
良い例で言うと、
我々Tablyっていうプロダクトをやっていたときに、
基本的にTablyってその生鮮食品のECの領域で勝負をしたいっていうのはずっと思ってたので、
Tablyっていう混打てが意思決定できて、
買い物ができて、購入ができる。
その購入ができるっていう部分でお金を稼ぎたいと思ってたんですよね。
なのでマネタイズポイントはトランザクションですと。
トランザクションに行くための機能をしっかり開発して世の中にリリースしました。
使ってくださった方の満足度がすごい高いし、継続率も高いです。
だけどここのファネルがすごいちっちゃいですっていう、
そういう事象が頭にありました。
これって本当に2倍とか5倍とか目指した水準に行くのっていうチャレンジを
しっかりやり切ったんですよね。半年ぐらいかけて。
いろんな施策を打ちましたもちろん。
ユーザーに対して1回目使ってもらえれば継続率が高いのは分かってたから、
1回目を使ってもらうためのハードルを下げようということで、
例えば300円こちらからプレゼントしてやってもらったり、
みたいな施策をたくさんシームレスにできるように
たくさん展開していくってことをやっていました。
ただ上げれたのはやっぱりせず2倍ぐらいだったんですよね。
リリース時の2倍ぐらいで、本当は10倍ぐらいに行きたかったんですけど、
12:00
そういう水準には行かなくて、やっぱり何でだろうって考えると
デザインが悪いんですよね。
それはコンダテっていうレシピっていうレイヤーから購入って、
使うシーンが全然違う。
なのでユーザーの普通の生活の中で早期されるタイミングが全然違うんですと。
僕らのアプリはコンダテアプリとしてすごい支持を得ていて、
ユーザーが何を買うかではなくて何を作るかとか、
何を作ろうかと計画するタイミングで開かれるプロダクトなんですよ。
そのタイミングで購入を一緒にしてしまうようなユーザーさんってのは間違いなくいて、
そういうユーザーさんって例えばセーキャを使われてたりするんですけど、
そういうユーザーさんには明確に刺さっていったと。
他方で、そうではないユーザーさんの方が圧倒的大多数だったっていう市場の状況があって、
そういうナチュラルな行動を変えていくっていうのは無理だと思ってるんですよ。
なので僕らがそれに対して一番大きく行ったグラウンドデザインの変化っていうのは、
コンダテのインターフェースを消す、やめる。
コンダテのインターフェースを消して、
ECのインターフェースでユーザーさんに商品を簡単に買える場所を提供するっていう意思決定だったんですね。
それがまさに今世の中に出ているStellaっていうプロダクトの姿で、
よく巷で僕が語っている内容としては、
タベリーで作ったサイトコントローラーとかクローラーとかみたいな
ネットスーパーを立ち上げるためのシステム自体が
B側にとって喉から手が出るほど欲しいものだったから、
それを提供することでスタートしてるみたいな話をしてるんですけど、
社内的にはもう一個重要な意思決定があって、
それはコンダテのインターフェースを捨てて、
ECのインターフェースに焼き直すっていう、そういうプロジェクトでもあったんです。
なので、この大きい意思決定の背景とか、
なぜそうするのかっていうのは、
かなり緻密にドキュメントを練り上げましたし、
あとはそれに行くぞってなった時も、
ほとんど僕が一人で意思決定まで大きいこと出しちゃったりすることが多いんですけど、
した上でもものすごい丁寧にコミュニケーションをしました。
まずは何か、それをやるって決めた日の夜に、
ちょっと悪いけどって言って、
石川さんに業務内だけど、
4つ屋のスターバックスに来てもらって、
僕と石川さんのちょうど中間地点が4つ屋だったんです。
彼らがこういう理由で、やめようと思ってる、
やめようと思ってるというか、
インターフェースをこっち側に寄せて、
かつ2B側からしっかりキャッシュフローを作れる、
事業モデルに変更しようと思って、
で、どう思う?みたいな。
っていうので、彼らの懸念するポイントとかを話し合って、
上げてもらって、それを一緒に協議して、
じゃあそれを回避する方法ってないのか?みたいなのを、
すごいしっかり話し込んで、
それをドキュメントに落として、
みんなで展開するという形でスタートしたところがあります。
その時の裏話で言うと、
石川さんもだし、僕も同じように懸念してたのは、
プロダクトを改変していくとか、
15:00
プロダクトを前に進めていくところの、
ハンドリングのオーナーシップを誰が持つのかっていうことで、
これ我々が持てないんだったら、
このプロダクトはやるべきではないっていう話をしてます。
それは何だろう、
大企業にそのハンドルがある状態って、
非常に遅いし、重いし、
あとはこれまで見れている限りだと、
良い意思決定ではない意思決定も多い。
なぜそれが起きているかというと、
技術的にそういうことが実現できないとか、
そもそもそういう技術者がいないってことによる、
非常に、要は質の低い意思決定がなされているっていう制約。
あとはもう一つは、
その意思決定の良し悪しを判断できる人がいないっていう制約。
こういう中から、
本当は色んな問題、複雑な問題を同時に解決できる方法があるのに、
それを選ばないっていう状態がずっと続いてきたのが、
僕らがお付き合いしているような会社さんの中には多かった。
それに引っ張られることで、
質の低いプロダクトを我々が気持ちよくプッシュできない状態っていうのは
絶対に避けたいっていうのだけは、
すごい大きく上がった懸念で、
それについては僕もずっと思っていて、
なので契約書のレイヤーでどうやって前さばきするかっていうのが、
自分にとってはめちゃくちゃ重要なプロダクトマネジメントだったと思っています。
それについても非常に今のところは、
背景も含めてしっかりクライアント側ともコミュニケーションした上で、
いい感じにできているので良かったかなと思います。
その結果、ECのインターフェースになったことでどうなったかというと、
やっぱり購入の継続率とかって倍ぐらいに上がるんですよね。
継続率が倍になるってちょっと異常じゃないですか。
購入するユーザーの数とかは1000倍とか、
そういう規模に上がっていっているので、
我々としては一番10Xな意思決定ができたかなというふうに思っています。
基本的にはグロースっていうのは、
その上手くいったものを上手く伸ばすっていうところにリソースが向けられるべきで、
上手くいってないものをグロースで何とかするっていうのは無理なんですよね。
そういう意味でも、
グロースをやる上で重要なこととか一緒じゃないし、
その前にやっぱりPMFというか、
しっかり良いプロダクトを世の中にプッシュするっていう、
そのためのデザイン、グラウンドデザインをちゃんと作って導くっていうのが、
創業者だったり経営者だったり、
もしくは一人のプロダクトマネジャーがそういうことをできるのかもしれないですけど、
あんまり例は見ないですけど、
そういう人間の役割なんじゃないかなと思っています。
ということで、今回のゼロトピアグロースについて話しました。
ぜひ感想をハッシュタグゼロトピアでつぶやいていただけると嬉しいなと思います。
それではまた。
