プロダクトの初期フェーズを最高速度で走る方法

こんにちは。estieでプロダクトマネージャー（PdM）をしている三橋です。コンパウンドスタートアップであるestieには、PMFの有無に関わらず多くのプロダクトが存在します。現在私が担当しているのは、PMFどころか2024年4月から検討開始したばかりの新プロダクトなのですが、4ヶ月が経過してプロダクトのステージも進んできたので、自身の振り返りの意味も込めて、「チームの立ち上げ期（下図A）」「初期プロダクトの開発期（下図B）」で実際にやってよかったことをご紹介していこうと思います。

下記ブログの続編のような内容となっておりますので、ぜひ一緒にご覧ください。

www.estie.jp

このブログを書くに至った背景

先日同じチームのエンジニアが「過去3ヶ月間、良いスピード感だったと思っていて、これを今からの3ヶ月に一般化して持っていきたい。」と呟いていました。

実は、現在私が所属しているチームは4月に新設されたばかりです。想定顧客層は当初からある程度決まっていたものの、どんなプロダクトを作るか、どんな価値を提供するのか？はゼロベースの状態からスタートしました。それから約4ヶ月経過した今、改めて振り返ってみて、エンジニアが「良いスピード感だった」と思った理由を言語化してみようと思います。

なお、本ブログの内容は、あくまでもプロダクトの初期ステージで実践したことの話です。多くの内容はすでにPMFしているプロダクトにはフィットしないと考えているため、ご注意ください。

なぜ、良いスピード感だと思ったのか？

なぜ同じチームのエンジニアが「過去3ヶ月間良いスピードだった」と呟いたのか。振り返ると、そう思う理由は、「課題仮説の立案からプロダクトのプロトタイプ構築までのスピードの速さ」であったと思っています。

チームが発足した4月時点で決まっていたのは想定顧客層のみ。そこから課題仮説の立案検証という工程を経て、4ヶ月が経過した現在、10個のスモールアプリをプロトタイプとして開発済です。

前提として、estieには言語化文化が強く根付いており、過去の商談議事録などを後から入社した人でも自由に閲覧できるという環境のアドバンテージがあり、それによって課題仮説を立案しやすかったということは確実に言えるのですが、それでもわずか4ヶ月間で10個ものスモールアプリのプロトタイプを生み出したことは、チームとしても大きな成果だと思っています。

では、どのようにして次々と新しいスモールアプリを最高速度（自称）で開発していったのか。本ブログでは課題仮説立案以降のプロダクトの開発工程にスポットを当てて、チームで実施したことを振り返ってご紹介したいと思います。

実際に何をしたのか？

現在私が所属しているチームは5人体制です。

事業開発1人
プロダクトマネージャー1人（私）
デザイナー1人
エンジニア2人

estieのメンバーは全員主体性がずば抜けて高いため、私のチームに限らず領域をオーバーラップして縦横無尽に動き回ることが多いのですが、私が所属しているチームもそれを体現しており、個々人の役割を厳密に定義していません。ただし、何にそれぞれのリソースを捧げるか？というイメージだけは共通認識にしていて、下図のようなイメージで動いています。

蛇足ですが、私は個々人の力が強いなら下手な管理やマイクロマネジメントをせず、大きな目標だけを与えてWhatやHowは委ねることが目標達成の一番の近道だと思っているのですが、今のチームはまさにそういう動きができるチームなので本当に大好きです。

さて、ここからは、プロダクト初期フェーズでスピード感を上げるために実際にやったことをご紹介していきます。

プロトタイプはそのプロダクトが価値があるのか？を検証するだけのMVPに特化した

これは結果的にそうなったという側面も実際はあるのですが、課題仮説の段階でプロダクトビジョン実現のためには大量のスモールアプリが必要であることがわかっていたので、どうすれば一つ一つのスモールアプリを最速で開発していけるのか？という議論の過程でこの考えにいきつきました。

例えば、編集・検索など実際の運用では必ず必要になる機能は全く作っていません。「顧客がそのデモを見た時に価値を感じられるか？」そのために必要なら作る。そうでないなら作らない。という極めてシンプルな判断基準です。プロダクトの品質を上げる期間は、プロダクトが受け入れられそうかわかった後に別途設ければ良い。そのような考えを当初からチームの共通認識にしていました。

顧客にやりたいことをほとんどヒアリングしなかった

異論は大いに認めますが、なぜそうしたのか？という背景を先に説明すると、大きく5つの理由があります。

顧客が言ったものをそのまま作るのは面白くない
顧客ヒアリングを網羅的に行うのは時間がかかりすぎる
estieの言語化文化により、ターゲットとの過去の商談議事録を大量に読めた
過去の商談議事録から一定レベルで信じられるアイデアを得られた
顧客の課題の解像度を高めるためのドメイン有識者がチーム内にいた

弁明しておくと、決して私のチームは顧客の声を軽視しているわけではありません。むしろ逆で、この数ヶ月間、特定の顧客との商談は毎週実施して多くの議論を交わしています。

しかし、それらの商談で「業務で何が課題ですか？」「何が解決されたら嬉しいですか？」のような会話はほとんどしていません。「これが課題だと思うので、こういうプロダクトを作ってきました。どうですか？」というアプローチを毎週一貫してとっていました。

このようなアプローチができた背景には「顧客が述べた1のことを10に膨らませて構造化・言語化する力」がチームにあったからとも言えるのですが、これ以上スピードが出る進め方はないのではないか？くらいに思いました。

とはいえ、解像度が低い状態でこれを実施することは、市場で誰も求めていないプロダクトを作ることにもなりかねないので、非常に難しいアプローチではあると思います。今回の私のチームでは、たまたまその仮説が当たっただけなのかもしれません。

開発はスクラムではなく完全な個人任せ

スクラムよりも個々人で自由に開発した方が早いよね、という考えでした。とは言え運用的なタスクの漏れがないように途中からざっくりとしたチケット管理だけはしていました。ロードマップは1ヶ月先を目処にテキストで作っていましたが、毎週目まぐるしく変わっていました。

毎日話す時間を設けていた

Devのメンバーだけで1日1回の朝会、チーム全体で1日1回のチェックインをそれぞれ30分ずつ確保し、誰でも自由にトピックを持ち込める場としていました。具体的には、顧客との商談が終わった後のフィードバックや、プロトタイプの仕様やデザイン、開発の進捗、またはPRDについて議論する場になっていました。都度会議設定せずに毎日話す場があったことでタイムリーに話すことができ、スピード感は格段に上がったと思っています。