プロダクト開発における「冷静と情熱のあいだ」
ジュンセイとあおいは、10年後のドゥオーモで出会えるんでしょうか。（ここ、わからない方は無視してください）。
今日はGW中で少し時間ができたので、プロダクト開発について、これまでの反省から自分が感じていること、取り入れたことをツラツラと書いてみます。目的や想定読者がある記事ではなく、備忘というか、自分の現時点の考えのメモを残しておきたい、という感じです。
さて、本題。
プロダクト作りは難しい
私は前職でPdM的な経験を約3年積み、起業してからもプロダクトの最終的な意思決定は自分で行ってきました。プロダクトマネジメントを体系的に学んだ訳ではないですが、プロダクト開発においては沢山の失敗とSmall Winを経験してきました。
その中で、まず感じていることは、「プロダクト作りは難しい」ということです。ターゲットユーザを定め、その業務や実情を深く理解し、課題を発見して、それを解決するものをソフトウェアとして提供していく。言葉にすると単純ですが、これがめちゃくちゃ難しい。
弊社でも、開発した機能が全然使ってもらえなかったり、なかなかユーザに満足いく価値を届けられなかったり、と常に失敗を繰り返してきました。とにかく、難しい。
全てのプロダクトは「情熱」から始まる
新しく事業を始める場合であれば、そこに誰かの強い意志があるかと思います。こんな課題を解決したい、こんな世界を作りたい、XXはこうあるべきだ、といった、事業にかける強い意志です。このnoteではそれを「情熱」と呼んでみます。
弊社ではB2B企業向けの動画マーケティングSaaS「Vidbase」を展開していますが、その根底には、「B2Bにおける顧客と企業の関係性をより良くしていきたい」という私の思いがあます。これも一つの「情熱」です。
でも情熱だけだと上手くいかない
でも、情熱だけでは上手くいかないのがプロダクト作りの難しいところ。これまでの開発でも、「きっとこれがユーザの業務を圧倒的に効率化できる」、「きっとこれはユーザがめちゃくちゃ喜んでくれる」と思って開発・リリースした機能が全く使われなかったり、ポジティブな反応が得られなかった経験はきっと多くの方がお持ちだと思います。
プロダクト開発の言葉では、「ビルドトラップ」と言われるものかもしれませんが、そこにはやはりファウンダーや事業責任者の思いがあるからこそ起きることなんだなと感じています。弊社も典型的なビルドトラップに陥っていた時期があり、本当に沢山失敗し、反省しました。
情熱だけだと上手くいかない。
「冷静」を取り入れるためにやっていること
沢山の失敗から、ビルドトラップに陥らずにプロダクト開発を進めるために、弊社ではプロダクト開発の意思決定おにおいて以下のようなことをルール化しました。
- 徹底的に顧客と話す、インタビューする
- 顧客にとっての価値を言語化し続ける
- Time to Valueで割り引く
- 売れるまで作らない、売ってから作る
以下、それぞれ、もう少し詳細に書いてみます。
徹底的に顧客と話す、インタビューする
プロダクト開発の基本のキとして、どんな本にでも書いてあることです。でも、事業を立ち上げ、どんどん忙しくなる中で、顧客とじっくりお話をさせていただく機会は自然と減っていきます。とにかく、顧客の業務やその課題を理解するために、お客様と話す、インタビューをさせていただく。
自分たちがPCとホワイトボードの前で考えてわかることには限界がある、顧客に聞かないとわからない、という考えを前提に置いています。
※ インタビューにご協力いただいている方々、いつも本当にありがとうございます。
顧客にとっての価値を言語化し続ける
どれだけ便利だったり、魅力的な機能でも、tooBプロダクトにおいては、顧客にとってビジネス上の価値がないと、使ってもらえません。ビジネス価値は、究極的には「コストカット」か「売上アップ」のどちらかです。
そして、「コストカット」は理論上必ず実現できますが、「売上アップ」は一定確率論の要素が残るものです。
今から開発しようとしている機能は、顧客のコストカットに繋がるのか？繋がるとしたらどれくらいのインパクトがあるのか？もしくは売上アップに繋がるのか？それはどれくらいの蓋然性で実現できるのか？実現したらどれくらいインパクトがあるのか？
必ずしも全てを定量的に評価できる訳ではありませんが、この2点を常に言語化し、なるべく定量化するように心がけています。
Time to Valueで割り引く
ビジネス価値があっても、必ず顧客が喜んで使ってくれるとは限りません。この点は、「Time to Value」で割り引いて考える必要があると思っています。
「Time to Value（以下TtV）」は、顧客が商品やサービスを利用して「利用した価値があった」と気づくまでの時間、のことを指す概念です。日程調整ツールSpirの大山さんがとある勉強会で、プロダクトにおけるTtVをとにかく意識するべし、と話されていたことから、弊社でもすぐに取り入れた考え方です。（詳細はこちらのnoteに。）
例えどれだけ便利でビジネス価値のある機能でも、それを利用するための準備工程がとても長かったり、社内調整のコストが大きかったりすると、そのコストがビジネス価値を下回った場合には顧客に便益を届けることができません。具体的には以下のようなイメージです。
複数の部署での調整や準備が必要になる
顧客側でエンジニアリングリソースが必要になる
現在やっていない業務を新たに行う必要がある
みたいなケースがそれです。TtVが大きいと、よほど実現できるビジネス価値が大きくないとユーザはプロダクトを使う気になりません。弊社では、TtVが長すぎないか、既存業務からの乖離が大きすぎないか、を常に話すようになりました。
売れるまで作らない、とにかく売る
SaaS事業をやっている方なら、Autifyの近澤さんが発信されているBurning Needsに関するブログは読んだことがある方も多いかと思います。私もPodcastやブログを何度も読んで・聞いています。
このPodcastの中でも「プロダクトを作る前にとにかく売れ」という話が繰り返されています。この話、事業を開始する時のこととして語られていますが、実は既にリリース済みのプロダクト開発にも十分に当てはめることのできる内容だと最近感じています。
具体的には、開発に3週間以上かかるEpicは、まず営業・価値検証を先に進めていく。そして、確実に顧客に価値を届けられるとわかってから開発する、このフローに変えました。
※厳密には開発はStory Pointで見積もっていますが、分かりやすく3週間としてます。
冷静と情熱のあいだで
上記の4つのルールを定めてから、自社でも少しずつプロダクト開発の意思決定の質が上がってきた感覚があります。（※もちろん、今のプロダクトでお客様に圧倒的な価値をまだまだ産めておらず、これからなのですが。）
一方で難しいなと感じているのは、冷静さが上回りすぎると慎重になりすぎ、スピード感を失ってしまうリスクもあることです。
今後もより良いプロダクトを作れるよう、「冷静と情熱のあいだ」を行ったり来たりしながら、進めていきたいなと思っています。
以上