Stailerはどういった機能を備えていくべきか
以下の記事はStailerがプラットフォームであることを定義し、どのようにプラットフォームが広がりを獲得していくべきかを考えました。
この記事でも触れたように、Stailerプラットフォームは、外部へ汎用I/Fを備えた機能を搭載し、アプリケーションとしてパートナーへ提供していきます。そしてそのアプリケーションの運用・開発を通じてエンドユーザーの体験を間接的に支援し、流通額を成長させていくことが「Stailerの事業構造」になります。
ネットスーパーはどのように成長するのか
「Stailerに備えるべき機能」を考えるにあたり、最も重要なのは「ネットスーパーGMVがどのように成長するのか」というネットスーパーの構造を理解し、「Stailerの構造」をネットスーパーの成長構造にアラインすることだと考えています。
どれだけ希少なアイデアや、技術的に優れたアイデア、他社が成功したアイデアであっても、この2つの構造から外れたものは事業に対して再現性のある形でインパクトを生み出すことは難しいです。人間も事業も、重要なのは骨格です。
ネットスーパーにとっての成長構造を「Flywheel」として描き出しました。青い四角はこのFlywheelを回すためのイシュー(重要なレバー)を示し、そのサイズはイシューのインパクトの大きさを示します。先に触れたように、Stailerのビジネスはネットスーパーの成長と完全な一致を目指しているため、FlywheelはStailerの成長構造であるとも言えます。
次の議論に入るために、テーブルの形式でFlywheelを整理してみます。それぞれのレバーが事業上どういった価値(インパクト)へヒットするのかを合わせて整理してみます。
は特にパーチェスファネルや、サプライチェーンの上流に当たります。上流のイシューが動いて初めてFlywheelが回ることから、事業上の優先度が高いともいえます。
(が3つ並列しているのは、サービスのフェーズに依存して優先度の上下が入れ替わりうると考えているためです。)
事業インパクトと顧客体験は独立しているものか
ここまでは「事業」としてのネットスーパーのFlywheelの流れを見てきました。では「顧客の体験」はこの優先度とは独立して扱われるべきでしょうか。
答えはNoだと考えます。基本的にはFlywheelに沿って顧客の体験も一体で構築され、の順に、顧客体験へ及ぼすインパクトもより支配的だと考えられます。先程と同様にテーブルの形式で整理してみます。
上記から「基本的には」すべての開発イシューやビジネスイシューはFlywheelと関連付けられると言えそうです。Flywheelを回転させ、顧客体験・事業(パートナーの成功)の両面でのグロースを実現できると考えられます。
逆に言うと、このグロースが大きくならない限り、Flywheelは回転せず、再投資は進みません。Stailerとしては、常により大きく・早くFlywheelを回すために、大きいイシューへチャレンジし続ける必要があります。
イシューの大きさの捉え方
Flywheelのそれぞれのイシューは「動かすために必要な要件」がそれぞれ異なります。
例えば「」や「」についてはStailerアプリケーションの発展のみでインパクトを出すことができるエリアが広く、相対的に「短期的に、実験的に取り組みが実行できる」イシューが多いと考えられます。ただし狙える成果は粗利を2xする類のものではなく、丁寧に1.1xを積み上げる性質に近いです。
対象的に「」「」「」などは一つ一つの施策の実行に必ずパートナーシップ、サプライチェーンの変化、オペレーションの変化を要します。これらは数週間で成果を出せるようなものではなく、また関係者も多くなるため実行の難易度が高く、期間も長期化します。しかしながら例えば需要が溢れる日に供給スロットを2xできた場合、注文数を2xするような非常に大きなインパクトが期待できます。
「短期で、独立実施でき、小さな成果が望めるイシュー」のみに流れず、「長期で、複雑な関係性の中で実施し、大きな成果が望めるイシュー」へ投資をし続けることが中長期でStailerの価値を高め続けるためには重要な規律であると考えます。壺の中にどんな石を、どの順で入れるか。これが肝要であると考えます。
Stailerに必要な機能をどう考えるか
このFlywheelを活用して「Stailerに本当に必要な機能とその優先度 = ロードマップ」を考えていきたいと思います。
具体的にはFlywheelに対してイシューをさらに分解して紐付けるイシューアナリシスを実行して必要とされるアプリケーションイシュー = 機能を洗い出します。この機能群に対して、たとえば事業部やパートナーとの会話、行動データの分析を通じてQCDやインパクト、パートナーからの要求度合いなどの情報をインプットし続けます。これらのインプットが統合されることで、アイテムを拡張したり、優先順位を検討していきます。
ただしこの時点でのインパクトはあくまで見積りにすぎず、実際の実行や探索、事業を通じて得られるフィードバックを元に継続的にアップデートすることが重要となります。そしてすべての情報が揃えば自ずと優先順位が決まるというたぐいのものでは有りません。ロードマップは現実にもっと複雑になるでしょう。そんなときに意思決定を推進する人には適切なガバナンスだけでなく、強いリーダーシップが求められます。
こうして作られるロードマップは、実際の機能を検討したり開発したり、運用したりする業務と連動し、コンパスとして機能することを期待します。
参考: イシューアナリシスの注意点
事業開発・プロダクト開発にまつわる個人の経験則として、目の前のイシューに没頭すればするほど、客観性や網羅性は失われやすい、というものがあります。
イシューアナリシスはこのリスクを担保し、「全体の中で今解くべきイシューはなにか」「各Flywheel Issueにどういった投資配分を行えばよいか」の探索を目的とすべきものだと考えています。逆に言うと、イシューに対しての個別の具体性を議論する(これはこれでとても大事)においては情報量が多すぎてあまり向かないフレームワークです。
なぜロードマップは必要なのか
ロードマップの具体に入る前に、なぜロードマップなる存在が必要かについても言及しておきたいと思います。
端的に言うとプロダクトを取り巻くすべてのステークホルダーとの共通言語をつくり、認知負荷・コミュニケーション負荷を下げるためだと考えています。
プロダクトには、これを開発する社内のメンバー、利用するお客様、その利用状況やインサイトを可視化するアナリスト、これから導入を検討する潜在顧客など様々なステークホルダーがいます。
このすべてのステークホルダーに対して、一貫したコミュニケーションをしていくためのインターフェースがロードマップになります。
ロードマップを定め、運用していくことで以下のような状態を目指したいと考えます。
- 顧客の体験価値、事業価値へのインパクトなど多様な観点が計画に反映される
- 社内外ステークホルダーの観点を統合し、議論の土台とできる
- 次に提供すべき機能価値が社内で議論でき、明確に意思決定できる
- パートナーとの間で、将来の機能への期待値を適切に調整することができる
Stailerのロードマップ
さて、それでは早速Flywheel Issueを更に分解し、ロードマップをドラフトしてみます。以下は社内で公開したロードマップの初稿をスクリーンショットしたものです。
ロードマップのマスターDBには例えば「リリースのタイミング想定」「機能を要求しているパートナーの名前」「開発を担当するチーム」などを付記し、運用を始めています。
※以下はNotion DBで作成しているのですがDBが大きすぎて転機がうまくできず、スクショベタ貼りのため、たいへん見づらくなっております。PCからの閲覧推奨です。
※このロードマップはそのまま「会社が対峙するイシューのリスト」であるとも言えます。
※ロードマップに並ぶのはアジャイルで言うところのユーザーストーリーに近い単位になります。もちろんこのままでは開発が可能な状態ではなく、Epicやチケットへの切り出し、仕様等各種ドキュメントの策定や、見積もり、レトロスペクティブなどを通じて実際の開発に運用されることを想定しています。
今後のロードマップの扱い
ロードマップは一度書いて終わりというものではなく、重要なのは以下だと考えています。
- 絶えず事業・顧客・技術上の観点が統合され、反映され続けること
- ロードマップをマスタとしてアップデートし、運用し続けること
- ロードマップを元に、事業開発活動やプロダクト開発活動上のアイテムや優先度がしっかりとアラインされること
これらを達成するためには、会社としてオフィシャルなロードマップ策定機関が必要だと考えており、それこそが会社にとって真のプロダクトマネジメント機能になるのでは、と考えています。
(ロードマップ策定機関についてはまだまだ柔らかい段階ではあるものの、以下のような機構の構築に取り組んでいこうと考えています)
10Xとしてのプロダクトマネジメントのあるべき姿を描き、その状態を実現していくために2020年以降離れていたプロダクトマネジメント部門の管掌を、2022/7より私が復帰して行うことにしました。手始めには上述したようなロードマップ策定機関を創り、全社的な運用ができるように整備を進めていきたいと思っています。
同時に「徹底的に属人性を排除したプロダクトマネジメント組織」と、「現地現物へDeep Diveして得た個の解像度と意志が最大限発揮されるプロダクトマネジメント」という一見矛盾する2つが統合されたプロダクトマネージャーの組織を作っていきたいと思っています。
Stailerは現状8パートナーへのサービスを運用していきますが、機能開発による価値の進化と、プラットフォーム開発によるスケーラビリティの担保を両軸としてさらなるプロダクト変革を推進していきたいと考えています。
これらを一緒にリードし、悩み、顧客へ届けて反応を見て、一喜一憂しながらも着実に前へ進んでいくプロダクトチームへご関心がある方を切に募集しています。いろんな多くの方とこの記事を通じて会話・議論できることを楽しみにしています。