【プロダクト2周目のデザイン】0→1でも1→10でもない「1→2」というフェーズ
みなさんこんにちは。GoodpatchのUXデザイナーのArimaです！
今回はこれまで様々なフェーズのサービスに関わってきた経験から見えてきた「1→2」というフェーズの存在と、そのフェーズでやるべき「プロダクト2周目のデザイン」という内容を記載します。ちょうど0→1の真っ最中の方や、1→10を走りながらも悩んでいる皆様のお役に立てば幸いです！
※この記事には「0→1」や「1→10」という言葉が沢山出てきますが、0→1とは何か1→10とは何か、は人によって定義がバラついていると思いますので、ふんわり捉えていただけると幸いです笑
この記事はGoodpatch Design Advent Calendar 2022の12日目です。
1→10のグロース期によくあるプロダクトの悩み
サービスを立ち上げるとき（いわゆる0→1のとき）は、とにかく価値を体現する最小限のプロダクトを素早く作って素早くリリースすることを目指します。このフェーズの話は色々な場所で既に語られており、多くの実践例も記事に上がっています。
一方、サービスローンチ後の不安定な時期は通過し、グロース期に入ったとき（いわゆる1→10のとき）に悩んでいる方は多いのではないでしょうか。実際に相談頂くお悩みの中には営業戦略などのプロダクト以外の観点も多いのですが、今回は1→10の悩みの中でもプロダクトの悩みにフォーカスして整理できればと思っています。
※いわゆるPMFは通過して、バックログを積みながらゴリゴリ開発をしていくようなサービス拡大フェーズにいる状態を想定します。
顕在課題の例
1→10のプロダクトの悩みは次のような内容のご相談を頂くことが多いです。
ユーザー数（導入企業数）は順調に伸びていっているが、プロダクトが使いづらいという声が多く届く。
基本的なプロセスを踏まえた上で改善を行っているが、急増築による個別最適化が進み、徐々に全体の体験が悪化している
このような課題はサービスが急速に伸びていっているサービスが該当することが多いです。市場・事業・サービスの成長に伴い、既存の改善よりもやや新規開発の方が優先されるような状況で表出します。個人的には、その優先度自体は悪いとは思いませんが、プロダクト開発として工夫できるポイントはいくつかありそうです。
潜在課題の例
次に、実際に相談いただくことは少ないものの、伴走支援する中で見えてくる課題は次のようなものがあります。
目の前の目標やKPIに効きそうな課題を倒すために、大量の改善チケットを用意して地道な改善を続けていく
0→1から特にギアチェンジすることなく、改善を繰り返している
これらも一概には悪いとは言えませんし、グロース時期であれば必要な工程ではあるのですが、それだけをやっているだけでは1→10の“10”に到達することは難しいでしょう。
素早く作って素早くリリースした後、そのまま1→10に至るのは難しい
多くの場合「0→1の次に1→10をやればよい、そうすれば“10”に至るはずだ」と考えてしまいますが、それは誤りだと僕は思っています。初期仮説のプロダクト状態のまま、1→10のフェーズに耐えられるプロダクトにはなれません。付け足したり改善するだけではなくて、0→1で紆余曲折あったプロダクト作りと同じように、実はどこかで大きな変革を仕掛ける必要があります。
多くのサービスがこの変革のタイミングに気づかず1→10を目指してしまいますが、この変革の必要性に気づかない理由はいくつか存在します。1つは、1→10の“10”の状態が明確ではないこと。2つ目はリリース前の初期仮説の見直しが行われないことです。
どのサービスもリリース前の初期仮説は構築されていますが、その初期仮説のアップデートは意外と後回しにされがちです。その結果、0→1時点で構築された初期仮説にリリース後の意思決定が純粋に加算されていき、1→10の“10”の状態が見えぬ状態でプロダクトの改善が進み、結果として前述のような課題・状況が生まれると考えています。
1→2というフェーズで、意識的にギアを引き上げる
そうならないためにも、0→1の延長線上に1→10は無いということを理解し、リリース後にプロダクトのギアを引き上げる1→2というフェーズを設けることが必要だと考えています。大量の改善チケットを地道に倒していく前に、方針を定め直すことが必要です。
具体的には、0→1で作り上げた初期化説をアップデートすることが必要だと考えています。リリース時に作り上げた初期仮説はどんなに強固でもリリース後の情報量には敵いません。また、市場やユーザー情報といった外的な初期仮説だけではなく、この事業・サービスを通してどんなことを達成したいのかといった内的な初期仮説にもアップデートは必要になってきます。そういった意味でも、1→2というフェーズで意識的にギアを引き上げることが必要なのです。
1→2のギアチェンジに必要なこと
プロセスとして必要なことは大きく3つあると思っています。
①目的地の再言語化
ざっくりいえば、ビジョンの見直しです。
前述の通り、1→2のフェーズではリリース後の様々な情報を通して外的・内的な初期化説をアップデートする必要があります。ビジョンの見直しは内的な仮説のアップデートに当たりますが、多くの場合はピポットのような方向性ではなく、より視野が広くなり解像度も高くなったビジョンに昇華するケースが多いと思います。
昨今のMVPの考え方が広がり、素早く小さくリリースすることが増えてきた反面、リリース初期はビジョンが矮小化しがちです。その考えのまま1→10にいくと個別最適な打ち手が多くなりがちですが、ビジョンのアップデートを行うことでよりプロダクトの捉えるべき事象が広がったり、意味合いが変わるような変革が起こる場合があります。
こういった変革を起こすためにも、1→2の段階を設けてビジョンの見直しを行うことをお勧めします。
②地図の整理
ざっくり言えば、ロードマップ作りです。
①でビジョンが見直されるとロードマップも大きく変わる場合が多いです（変わらない場合もあります）。ここでいうロードマップとは機能のリリースタイミングということではなく、ビジョンの達成のためにはどんな段階を踏めばいいのか、そのためにはどの市場からどう抑えていくべきなのか、どんなユースケースからどんなふうに拡張していけば良いのか、といった少し抽象的なロードマップのイメージです。
③目的地の可視化
ざっくり言えば、プロトタイプです。
①と②の段階で目指す地点と道筋は言語化されたと思います。この時点で1→2のフェーズの7割くらいは達成されていると思うのですが、場合によっては目的地と道筋が見えているのはPOやPdM1人だけなんてこともあるかもしれません（実際、ビジョンとロードマップの再定義をすると定義前の違いが曖昧になりチームが混乱するケースはよくある）。そうならないためにも全てを可視化してしまうことをお勧めしています。
可視化、要はプロトタイプですが、アプリであればアプリのプロトタイプを作っても構いませんし、もっと抽象的な状態を示したいのであれば4コマ漫画などでも構いません。個人的にはこのnoteを読む方はプロダクト開発に携わる方が多いと思いますので、アプリのプロトタイプを作ってしまうことをお勧めします。ここで作るプロトタイプはロードマップのどの段階のものでも構いません。最終目的地を全部盛りにしてみたプロダクトでもいいし、次のステップに一旦進むためのものでもいいでしょう。
プロダクト2周目をデザインする
個人的にはこの1→2というフェーズで行うことを“プロダクト2周目のデザイン”と呼んでいます。0→1の過程を経てローンチするまでを1周目と捉え、その見直しのフェーズだからです。
このフェーズは非常に難しいのですが、一方でとても楽しいフェーズでもあります。
というのも、初期仮説をアップデートするということは初期仮説に抗うことに近いため過去の自分との戦いとも呼べるでしょう。場合によってはそれなりの立場の人が、過去の自分の間違いや視野の狭さを認めなくてはならないこともあり、客観的な視点が強く求められる取り組みでもあります。
一方で、プロセス的には誰もがプロダクト開発「2周目」の状態です。ビジョンを立て、ロードマップを作り、可視化するといった工程自体はそんなに新しい工程ではありません。このプロセスに関しては強くてニューゲームな気分で取り組むことができるので、案外すんなり進んだりもします。
敵も強いが自分も強い、プロダクト2周目のデザインをみなさま楽しんでください！
さいごに
前述した「グロース期における顕在課題・潜在課題」に心当たりがある方、もしくはプロダクト2周目のデザインで客観視をするために第3者の視点が欲しい方は、是非弊社にご相談ください！
また、1→2のフェーズやプロダクト2周目のデザインについて、さらに詳しい説明を後日ウェビナーなどで出来たらと考えています！（鋭意企画中……）日程が確定したら公式アカウントからご連絡するので是非ご参加ください！
この記事が気に入ったらサポートをしてみませんか？