SaaSプロダクトの立上げ期をロジカルに攻略する
MonoRevoのCTO 森松です。
SaaS スタートアップのCTOとして、本当に価値のあるプロダクトを創造するために、ものレボで実践している手法を公開します。
一般的な手順
プロダクトの立上げ期に必要な事とは何でしょうか。技術系人材が創業期にいない場合は委託をすることになりますが、開発屋さんならばまず要件定義のためのヒヤリングと答えるでしょう。
- 課題と目標
- 機能要件・非機能要件
- 予算・スケジュール
一般的にはこの流れで整理していきます。問題なさそうでしょうか?いいえ、大問題が絡んでいます。課題と目標をシステム素人である創業者が伝える事になりますが、それは本当に作りたいプロダクトでしょうか?過不足入り乱れるでしょう。ドメイン知識を身につけながら会話している技術屋は、マーケットもSaaSもよく分からない状態で、なんとなく「なるほど!」と納得して受け入れるでしょう。大きな投資額が動きつつプロダクトのスコープが明確にならず、最終的には製造コストで判断が決まるという、空中戦が展開される状態が予想されます。
空中戦の末に何が出来上がるか
とにかく最低限の機能(MVP)で作ってFBを獲得して、PMFを目指そう!とプロダクトオーナーは思うでしょう。本当に品質が良い物が出来たら、運良くそうなるかもしれませんが、たいていの場合は課題と目標が膨れ上がって取り込まれて膨れ上がった「何か」になっていきます。そして、膨れ上がったシステムはコントロールを失って、バグを大量に吐き出すでしょう。開発屋さんはアウトプットを出す事を重視しますからとにかく作ります。不用意に委託するとこの着地点に必ずたどり着きます。
更に「何か」のシステムに合わせて、ビジネスを調整することを余儀なくされるでしょう。ビジネスサイドは、SaaSの価格設定を現物から絞り出す思考に陥ります。創業者は思考の海に溺れて、「これがやりたかった事だったのか?」と自問自答に陥るでしょう。
とにかく作るから脱却する
大切なCTOのお仕事はここからです。マーケットインとかプロダクトアウトとかの陳腐な言葉じゃなくて、ビジネスとプロダクトのシンフォニーを実現させるための考え方や手法を導入しなければなりません。インとかアウトとか製造を両極端に捕らえてしまう状態は、コミュニケーションに失敗していると思われます。熱い想いを持っている創業者は、ドメイン領域を深く経験し、お客様の声をよく聞いて本質を捕らえているでしょう。そのノウハウをプロダクトに取り入れて、革新的な技術とのシンフォニーを実現する事が大事だと考えています。
システムの基本原則に立ち返る
システムを定義すると
「目的のために、相互に作用して動く要素の集合」
非線形の要素の集まりが相乗効果を生み、目標に到達します。必ずゴールが定義されるべき事を忘れてはいけません。そして、システムは成長する事も、もう一つの大原則です。相乗効果を最大化したとしても、ゴール無しでは成長なのかどうかもわかりません。
何よりも先に、この目的の定義を明確にしましょう。それこそが実は忘れがちな、システムの一番肝心なポイントです。
MonoRevoで起こった悪い例の一つですが、システムの意義を「見える化」とおいて、ビジネス設計していました。これこそ、誰に対するゴールなのかわかりません。迷ったときは始めに戻って立ち返って考えてみましょう。
SaaS プロダクトが目指すゴールの定義とは?
シンプルに考えましょう。「お客様のペインを解決する」です。しかし、SaaSはターゲットも解決したいペインも一つではありませんし、特にバーティカルSaaSではペインが絡み合います。しかし、システム目線では目的の定義を明確にして作る必要があります。
MonoRevoでは、プロダクトxビジネスのシンフォニーを実現するために、以下のようなマトリックスを作っています。分かりやすいように簡略化しています。
目的とターゲットのマトリクス
業種A (範囲外) | 業種B (メインターゲット) | 業種C (セカンドターゲット) | 業種D (範囲外) | |
ペインA (優先度高) | システムA | システムA | ||
ペインB (優先度中) | システムB | システムC | ||
ペインC (対応外) | ||||
ペインA + B | システムD | システムE |
この表のポイントは以下です。
- 前述した通り、システムとは必ず目的が定義されます。縦列に解決したいお客様のペインを定義、横列には狙うべきターゲットを定義します。この交差がシステムを構築するときの大枠となります。システムとは要素群の固まりであり、目的にたどり着く方法はゴールによって変わるからです。
- どう考えても同じシステムに必然的になる場合は、「システムA」のように同じシステムである事を明記します。
- 経営資源が限られているスタートアップは、この表でシステムの対応する範囲を限定することも一つの重要な要素です。
- システムA+Bではなく、システムDです。再度言及しますが、システムは要素の集合です。目的が融合された場合、その集合の組み立ては別物になります。ΣA要素+B要素 < 全体の振る舞い である事の理解が大切です。
全社を巻き込む
上記の表の良いところは、全社を巻き込めるところでもあります。SalesやCSにも非常にわかりやすい。顧客のターゲットを絞れて、顧客に提供するソリューションを明確化できます。どう見ても、システムDやシステムEはアップセルなので、値段設定も分かりやすくなります。
プロダクト側は表を決めた後なにするの・・・?
システムA、B、C、D、Eという作業単位が出来上がることになりました。それぞれに対して以下のような作業を展開します。大雑把ですが
- ユーザージャーニーを作る (Biz)
- ストーリーボードを作る (Biz)
- ユーザーストーリーを作る(Biz + Tech)
それぞれの工程は順番では無く、ときには一番始めに戻って修正する事もあります。なお、作っていく過程でコピペ要素も当然でてくるので、1個にかける時間 x 全体数 = 全時間 とはなりません。
最後に
以上、システム作りの最初の最初のステップでした。ユーザーストーリーを作るときに、好んで使っている手法があります。この記事が多少でもアクセス稼げたら、続きを書こうと思います(笑)
MonoRevoに興味が多少でも出た方、ご連絡ください。