N= 1 実在する顧客の課題を解決することからすべては始まる
RENI社では「N = 1の実在する顧客の課題を解決すること」を極めて大事にしています。
このnoteでは、よく質問をいただく以下のような点について説明します。
- 極めて大事にしているってどれくらい？
- 具体的にどのようにしてN = 1の顧客の解像度を高めるの？
- スケールはするの？
RENIの事業
RENIは
- アーティストのECプラットフォーム「OGS」
- アーティストマーチャンダイジング基幹業務をデジタルスクラッチする「MD Cloud」
が主事業です。今回は後者のMD Cloudを題材にお話しします。
ちなみに、アーティストマーチャンダイジング業務とは、アーティストグッズの企画、製造、販売、予実管理業務のことを指します。
RENIの事業についての詳細は以下のnoteをご覧ください。
MD Cloudのミッション
MD Cloudの顧客は、上記アーティストマーチャンダイジング業務を生業としているプレイヤーです。
RENIのパートナー企業でもあり、MD CloudにとってのN = 1である顧客(以降、A社)は、アーティストとライセンス契約を結びアーティストグッズを企画、製造、販売しています。商品ラインナップや製造数までA社が意思決定して在庫リスクも抱えるので、ブランド(自社)名を表に出さないだけで実態はアパレル企業です。
MD Cloudのミッションは「A社の新入社員がMD Cloudを使えば70点の成果を出せること」です。
このミッションを高速で実現するためには、N = 1であるA社の業務について並大抵ではなく深く理解したうえでのプロダクト開発が必要でした。そのための具体的なSTEPとして、以下のフレームに沿って我々の取組みを紹介します。
①課題の不確実性を低減する
②実装の不確実性を低減する
課題の不確実性を低減するために
このためには、顧客の業務を肌感で理解しバーニングニーズを自分の言葉で言語化できなければいけません。
我々はその手段として、Product Managerである僕自身がA社の従業員になる方法を採りました。僕は2019年5月〜2021年4月の2年間、A社の従業員としてA社のオフィスに出社し、A社のテクノロジー周りの統括責任者として勤務しました。
A社の経営陣や現場メンバーとも日常的にコミュニケーションをとりワークフローの整理や課題の抽出を行い、時には全国のコンサート現場にも同行し雨が降る中トラックへの積込みや荷下ろし作業、屋外での販売業務などを手伝ったり、倉庫での出荷作業を行なったりと自分自身の体で顧客の業務を理解しました。
顧客の業務を自分自身が実際に遂行できるまで理解した結果、顧客の課題の解像度は高まり課題の不確実性を低減させることができました。
言ってしまえば、顧客と同様の業務が遂行できるうえで、顧客以上に顧客の課題を言語化できている状態です。
また、顧客の業務がイメージできない場合でも、すぐに直接確認できる関係性を築いているので、PdMの勝手な想像で課題を設定することもなくなります。
実装の不確実性を低減するために
課題の不確実性を低減することは実装の不確実性を一定レベル低減することに繋がります。ただし、課題を正しく認識していてもソリューションが正しくない可能性もあります。そのリスクを低減するために
①プロダクトの理想像と実装する機能を切り分ける
②顧客のフィードバックを高速にプロダクト改善に反映できるようにする
③コア業務とノンコア業務で要求の抽象化レベルにグラデーションを設ける
ことが有効です。
①プロダクトの理想像と実装する機能を切り分ける
Founder、PO、PdMなどは、長期的な目線での事業の到達点とそのために必要なプロダクトのToBeを常に考えていると思います。それ自体は健全なことですが、実際に実装する機能は、作り手の想像ではなく目の前の顧客がそれを使わない状態での業務など考えれなくなるようなものであるべきです。
想像で実装しないように要求の解像度を高めるためには、「要求やStory作成時に必ず背景や目的を記載するフォーマットにする」と「要求の認識をすり合わせるMTGでエンジニアやデザイナーがPdMを徹底的に詰める」をすると有効です。
フォーマットに関しては以下の記事で具体例を紹介しているのでご覧ください。
また、エンジニアやデザイナーは少しでも背景や目的が曖昧に感じる要求があったら納得するまでとことんPdMを詰めましょう。僕もPdMジュニアだった頃は毎週のSprint MTGが憂鬱になるくらいステークホルダーに目的を詰められました。笑
常日頃思い描いているプロダクトの理想の機能を目の前の実装に反映させたい気持ちは痛いほどわかります。
ただ、自分が設定したソリューションに顧客が明確に価値を感じているというファクトがない限りは、自分を疑い続けるべきです。プロダクトはファクトを積み上げることで新しい課題が明らかなることの繰り返しなので、想像のソリューションを実装する余裕は1秒たりともありません。
もちろん、いくら実装前に顧客が価値があると言った機能でも、実際に利用すると課題が浮かび上がることもあります。それはそれでまた次の実装の反省材料にすれば良いので、前向きに捉えましょう。
②顧客のフィードバックを高速にプロダクト改善に反映できるようにする
具体的なHowとしては、
- 実装前にプロトタイプを顧客に見せてソリューションの解像度を高めて無駄な実装をしない
- とにかくリリース -> フィードバック -> 改善のサイクルを高速で回す
などです。
重要なことは「プロトタイプを実装前に顧客に見せること」ではありません。顧客のフィードバックを高速に反映できるのであれば、必ずしもプロトタイプを作る必要はないと思います。
チームのメンバー構成や各メンバーのスキルセットに応じて最適な方法論を検討できることが大事です。
我々の場合、後に述べるコア業務の場合はプロトタイプを顧客に見せてフィードバックをもらい、ノンコア業務の場合は自分たちの判断で実装するという傾向が強いです。
③コア業務とノンコア業務で要求の抽象化レベルにグラデーションを設ける
ここで明示的に述べておきたいのは、MD CloudはA社専用プロダクトという思想ではないということです。僕たちの目的は音楽業界のDXなので、MD Cloudの仕組みは業界のプレイヤーにあまねく利用してもらいたいと考えています。
「そこまでA社に寄り添ってプロダクトを作ると他社への汎用性は失われてしまうのでは？」と思った方もいると思います。
そうならないために必要な思想が③であり、具体的には以下です。
- コア業務：競争優位性の源泉である業務。コア業務については、具体的な仕様レベルまで徹底的に業務をキャッチアップしソフトウェアに落とし込む。
- ノンコア業務：業務のアウトプットが競争優位性には繋がらず、いかに効率化してコストを削減できるかが重要な業務。ノンコア業務は、現行のワークフローや課題はヒアリングしつつ、MD Cloudを利用した既存業務に縛られない新しいワークフローを設計、実装する。
つまり、従来の受託開発のように顧客の要望に合わせたプロダクト開発をしているわけではないということです。
ノンコア領域に関しては、連携する外部のSaaS(WMS、POSなど)の設計思想もリサーチし、現行の業務に捉われず広くドメインに適用可能な要求に抽象化しています。
一方で、コア業務を徹底的にキャッチアップしてソフトウェアに落とし込んでいる理由は、A社がドメインの圧倒的リーディングカンパニー(シェア20%弱)だからであり、A社のノウハウは他社にも有益なものだからです。
結論、N = 1の顧客の課題からスタートしたとしても、その1の顧客に徹底的に入り込めば結果的に汎用的なプロダクトを作ることができるというわけです。(もちろん、顧客が増えれば増えるだけ新たにPMFが必要になることは避けられませんが)
MD Cloudを活用した事業戦略についてはまた別の機会に譲りますが、N = 1の実在する顧客の課題を解決することの重要性は伝わったのではないかと思います。
さいごに、ソフトウェアエンジニア採用中です！
冒頭で述べたECプラットフォーム「OGS」事業も、N = 1を大事にしたMD Cloudと同様の事業展開で自己資金のみでARR60億円強の規模に成長しています。
MD CloudはN = 1での検証がほぼ完了してこれからOGSと同様のフェーズに進む事業であり、かつ、OGSとのシナジーでさらに面白いことができることが目に見えています。
一方で、それに伴い現在のエンジニア1名体制から脱しチームを組成します。
大きな裁量のもと、責任感をもってガッツリ開発を進めてくださるソフトウェアエンジニアを募集中です。
興味を持っていただけた方は、ぜひ以下から応募ください。カジュアル面談も受付中です！
また、僕のTwitterアカウントからコンタクトいただいてもかまいません。
最後まで読んでいただき、ありがとうございました！
この記事が気に入ったらサポートをしてみませんか？