【事業開発・企画】優れたサービスをつくる方法

優れたサービス ビジネスハック
スポンサーリンク
ポール
ポール
こんにちは、ポールです!

Bizdevとして働くに当たり、プロダクトマネジメントやサービス開発に関する記事を日々読み漁ってます。目標は今年中にできれば200本、最低100本の記事を読破することです。

現状まだ20+程度しか読んでいませんが、だいたいの記事で同じようなことを言っているので
これが良いサービスを作るための本質的な方法なんじゃないか?と思うようになってきました。

まだまだ目標には遠く及びませんが、自分のこれまで復習も兼ねて、
一度、20記事を通して理解したことをざっくりまとめておこうと思います。

▼企画系はこちらもオススメ
売れる商品はどんな企画書から生まれたのか? – Don’t Think ACT!

Webディレクターにおすすめの本!ディレクションが学べる良書35冊(2018年) – Don’t Think ACT!

「売れる企画はマイクロヒット戦略で考えなさい!」が良かった – Don’t Think ACT!

【新規事業成功への必読本!】新規事業立ち上げに関するおすすめ本まとめ

スポンサーリンク

良いサービスを作るプロセス

以下が現状で自分が理解しているサービス開発する上で最善の方法です。

1.課題の仮説たてろ
2.その課題が正しいか検証しろ
3.OKならどう解決するか考えろ
4.その解決策で良いのか検証しろ
5.OKならMVP作れ
6.MVPを検証しろ

ちなみに、対象のサービスは以下の通りです。
・webサービス
・スマホ等のモバイルアプリケーション
※宇宙系のなど含め、超発展レベルの技術が必要なプロダクトや、そもそも事業に莫大な期間を有する新規事業には当てはまらない認識でいます

1.課題の仮説を立てろ

まずは、「そもそも解決するべき課題は何か?」を考えます。

・超分厚い企画書、仕様書を先に作るな。時間の無駄。
・いきなりプロトタイプとかMVPを作るな。時間の無駄。
・まずは「誰の何を解決する必要があるのか」を考えろ
・「その課題を解決する意義(価値)は何か」を考えろ
・この時点で、ソリューションの考えは持つな。捨てろ。

新規事業や新サービスとなると、
最初にガッツリ要件や仕様書を作ってしまいがちですけど、それではいけません。

2.その課題が正しいか検証しろ

次に、「その課題が本当に存在するのか?」を検証します。

・仮説で終わらせないで、ユーザーにインタビューしろ
・但し、ユーザーの発言を鵜呑みにするな。ユーザーを”観察”しろ。
・ユーザーには具体的に聞け。ユーザーは盛って話すことが多い。
→「1ヶ月に何回やると思いますか?」ではなく、「直近1ヶ月で何回やりました?」と聞け
・複数の課題、問題がでてくるはずだ。問題に優先順位をつけろ
・バイアスは怖い。もし課題の検証段階でソリューションの案を持ってるなら捨てろ
・およそ12名が「この課題を解決する製品が欲しい」ならそれは本当の課題の可能性が高い

3.OKならどう解決するのか考えろ

ようやく、「課題があることが証明した後に、どう解決するか」を考えます。

・解決策の検討は、エンジニアとかデザイナーも混ぜろ
・たいてい、エンジニアとかデザイナーのほうが良い解決策を思いつく
・解決策自体はいくつも手段がでてくるはずだ
・「本当にこの解決策が一番なのか?」を自問しろ

4.その解決策で良いのか検証しろ

解決策を考えたら、「その解決策で本当に課題解決ができるのか?」を検証します。

・そのソリューションで良いか必ずユーザーに聞け
・「あったら良いな」程度の解決策だったら弱い。出直す。
・およそ12名が「このソリューションが必要」というかどうか
・「有償でも良いからそのソリューションが欲しい」というユーザーを最低5人は集めろ
・どの機能に対して魅力を感じているのか聞け
→該当しない機能はとりあえず無駄だから捨てとけ
・そのソリューションにいくらお金を払うか聞け
→但し、例によってユーザーは盛るので、「既存の解決策にいくらお金を払ってますか?」とちゃんと聞け
・解決策を開発するプロセスに協力してくれるか聞け。最低5人は集めろ。
→今後のフェーズでも手伝ってもらえ。メールアドレスとか電話番号を聞け

5.OKならMVP作れ

これで、「めっちゃ解決して欲しい課題」と「めっちゃ確度高い解決策」の”案”ができました。
ようやく、ここからMVPを作り始めます。

・スピーディにつくれ
・できればMVP作ってる途中で仕様変更はするな。エンジニアのやる気が下がる。
→ここで変更するんじゃなくて、もっと前のフェーズでちゃんと固めとけ

※このフェーズに関する記事はまだインプットが追いついていませんので、内容が浅いです(汗)

6.MVPを検証しろ

MVPを作ったら、実際のユーザーに使ってもらって、課題を抽出します。

・メトリクス(数字の指標)は必ず測定しろ
・但し、メトリクスだけ測定しててもダメだ。インタビューしろ。数字からは「理由」がわからない
・「使い続けてくれているユーザー」と「やめてしまったユーザー」の両方にインタビューしろ
・もしかしたら一部のセグメントだけ使い続けてくれているかもしれない。細かく分析してみろ。
→狙うべき市場セグメントを特定できるかもしれない。

さいごに

もしかしたら今後読み進めていくうちに考えがアップデートされるかもしれませんが、
良いサービスを作る方法として、現状の理解は上記の通りです。

引き続きTwitter(@cowcow_u)でぶつぶつ呟いていくので、
興味がある方はフォローお願いします!

■本記事で紹介した書籍

コメント

タイトルとURLをコピーしました