プログラミングではなくプロダクトを作るということ | プロダクトマネージメント論
エンジニアだけではなくエンジニアではない人も誤解しがちなのですが、『プロダクトを作る』ということは、デザインを書くとか、プログラミングをするとか、システムを開発するとかそういうことではありません。プロダクトの本質はお客さまの課題を解決することで、「プロダクトを作る」とは、課題を理解して解決する手段を設計して提供することです。
プロダクト作りをするためには「プロダクト・マネージメント」というお仕事がとても重要になるのでこちらの記事で3つの視点で説明します。
次にプロダクト・マネージメントを含めたシステム開発の体制の全体像については記事を参考にしてください。
1. お客さまの何に貢献するか
-- お客さまの理解が大事
まずは、お客さまやビジネスや生活を理解することが大事です。ビジネスや生活を理解しろというのは難しい話ではなく、以下を理解していることが一番大事です。
1. お客さまは誰か
2. お客さまが抱えている問題は何
3. 問題を解決することで期待している効果は
4. お客さまが重要視していること、重要視していないこと
5. お客さま自身でできるこ・できないこと
お客さまを理解する際に、男性か女性とか、20代か30代か40代かとか、中小企業か大企業とか、そんな漠然としたお客さま像を設定していませんか? 空想でペルソナ(顧客像)を書き出して事業を企画していませんか?お客さまをイメージする際は「プロフィール」ベースではなく課題ベースでイメージしてください。
「体重が100kg超えているので80kg未満まで体重を減らしたい人」とか「LTVが50円~100円のゲームアプリのユーザをCPIが20円~60円で獲りたい企業」のようにイメージすることが大事です。
お金を払ってでも解決したい強い課題(個人の場合は悩みや欲求)を明確にすることが大事です。
-- 無料の利用者はお客さまじゃない
そして大事なことは、お金を払ってくれる方をお客さまとすることです。無料サービスが溢れかえっている今のインターネットでは「無料」にしても簡単にはユーザは集まりません。無料で大量の利用者を集めて、その一部がお金を払ってくれることを期待するのではなく、最初からキチンと対価を請求するサービスを設計しましょう。
有料サービスで事業を設計すれば、お客さまからいただける収益と釣り合う範囲で広告費を投資しやすくなります。そうすると、不透明なことが多いプロジェクトの初期に、小額の広告を回して購入してくれるかのテストをすることができます。つまり「ターゲットとなるお客さまは誰か?」や「真に解決を望んでいる課題は何か?」という仮説の検証が簡単にできます。また獲得チャネルのテストをすることができます。
-- たくさんの利用者がいても真のお客さまは一人
そしてお客さまとは課題解決に価値を感じてくれてお金を払ってくれる方と明確に定義することが大事です。マッチングやプラットフォームには、ユーザやクリエイターや売り手や買い手などたくさんの利用者がいますが、その中から誰が真のお客さまなのかのを見極めることが大事です。
利用者の全員がお客さまであるということは絶対にありえません。
例えば、YouTubeには、視聴者、投稿者、広告主という三種類の利用者がいます。しかしこのような複数の利用者がいるプラットフォームで、お客さまをつなげるとかマッチングするとかボヤッとした価値を事業の価値としてはいけません。それは20年前の考え方です。利用者の中から真のお客さまを明確にして、そのお客さまと課題の解決にフォーカスして事業を展開することが重要です。
YouTubeなら「視聴者」が真のお客さまで、視聴者のためにサービスを作っていくことが重要です。
2. 快適さや効率性ではなく効果を実現する
プロダクトがお客さまに提供する体験の評価には3種類の軸があります。
1. 効果 (Effectiveness) ユーザがきちんと目標を達成できたか
2. 効率 (Efficiency) ユーザが目標を効率よく達成できたか
3. 満足度 (Satisfaction) 迷いや不快感やストレスがなく目標が達成できたか
参考:国内規格JIS Z 8521:2020
ダメなプロダクトのアイディアは3の満足度を目標としているものです。例えば「メルカリよりもっと使いやすいオークションサイトを作りたい」のようなアイディアです。
「触り心地の良いUIで最高のUXを」を新規事業の売りにするのは敗色濃厚です。他社の既存サービスの極めて小さいニッチな一部分を掘り下げるプロダクトならアリですが、資本もないのにすでに成立している事業より高機能・高品質なサービスを作るのは難しいしユーザを奪い取ることも難しいです。
予算が少ない新規事業において、他社の既存事業より快適な体験を提供する満足度を改善する案や、サクサク楽に処理ができようにする効率軸の改善案は、すべてNGです。
新たなプロダクトが解決すべき問題の優先順位は効果>効率>満足度です。
1. 効果=欲しいものが手に入れられるか?
2. 効率=より少ないコストで手にいれられるか?
3. 満足度=より快適にストレスなく手にいれられるか?
-- 技術選定にも影響する
また利用する技術の選定の際も、プロダクトが解決する問題の対象が効果なのか?効率なのか?満足度なのか?に大きな影響をうけます。
③の満足度の改善「快適に問題を解決したい」な場合、SPAやネイティブ対応といったコストが高いが質の高い体験を提供する技術の採用が求められます。
逆に①の効果の改善「他の解決手段がないので解決できさえすればよい」を対象とする事業フェーズの場合は、ノーコードや人力による問題解決のほうが良いことが多いです。
3. 1番小さく始められるところは何か
プロダクトのアイディアは仮説でしかありません。プロダクトの初期において構想を広げたりアイディアを盛ることは厳禁です。とにかく検証すべき仮説をピンポイントに絞る、短期間で楽に検証できる小さくはじめられるアイディアを考えることが大事です。
そして、「作って」から売るのではなくて、「売って」から作る考え方を意識することが大事です。例えば広告クリエイティブとLPだけ作って広告回してニーズあることが分かってから作るなどの方法も検討してください。なぜならテストマーケでは、プロダクトのコンセプトの検証だけではなくて、ユーザを獲得できるマーケティングチャネルの発掘が必要だからです。
-- リリース is King
最初から作りこまず、早い段階に使ってもらう売ってみるという「リリース is King」という考え方が大事です。
仮説の検証は、議論や市場調査やユーザアンケートなどで行うべきではありません。リリースしてみることが真の検証です。リリースして、お客さまに使ってもらうこと買ってもらうことで仮説の検証すべきです。
ただし、プロダクトの完成度に応じてリリースの範囲を調整するのが大事です。プロトに毛が生えたレベルで、プレスリリース打ったりドカンと広告打ったりは厳禁です。売るやリリースとはいっても大々的に発表することではありません。まずは誰か一人に試用してもらえるだけでも良いのです。小さく作り小さくリリースしていくのが大事です。
リリースをレベル0「リリースしない」とレベル100「プロモやPRを最大限する本格リリース」の二極の0/100で捉えるのは間違いです。リリースにも1から99までの段階があります。いきなり0から100にしようとせずに、リリースレベル0からレベル1「小規模なテストマーケをする」へ、リリースレベル1から100へも仮説の検証度合いにあわせて段階を踏んでください。
-- 成功したいなら早く失敗しろ
出来る限り小さくはじめる理由は「早く失敗する」ためです。成功するためには、失敗しないようにするのではなく、たくさんの打席に立つことが大事です。そして、早く失敗して仮説を検証して、軌道修正することです。
英国のハイパーカジュアル企業の "Kwalee" 曰く
「成功したいなら早く失敗しろ!」
です。
Kwalee社の事業はスマホ向けのゲーム事業です。スマホ向けのゲーム市場は日本だけで1兆円市場に成長していますが、過去に成功したチームでも次のゲームを成功する確率が低い難易度の高い市場です。
そのような市場で、 Kwalee社は「ハイパーカジュアルゲーム」というジャンルを開拓しています。ハイパーカジュアルゲームの開発では、一発でホームラン狙うのではなく、3日~1週間でプロトタイプを作成してテストマーケティングをします。じっくり作りこむのではなく、たくさん打席に立つことを重視します。早く失敗していく開発プロセスを重視し、多数のゲームタイトルを当て続けて、毎年何十億回もダウンロードされています。
特に、新規事業でのプロダクト作りは、不確定要素が大きいので、小さく始めることが重要です。
壁打ちしてプロダクトを磨き上げましょう - 最後に
スパイシーソフト株式会社では「レンタルCTO」というサービスを提供しております。
技術に詳しくない経営者向けに、壁打ちをして一緒にプロダクトのコンセプトを磨いたり、アドバイスをして開発をスムーズにすすめる『スポットコンサルのサービス』を提供しておりますのでご興味がある方はご一読ください。