Free Image on Pixabay
今回は、プロダクト開発についてです。
この記事でわかること
この記事で書いているのは、開発の初期段階でのプロダクトマネジメントの方法です。
具体的には、実用最小限のプロダクトである MVP を開発してローンチし、MVP の仮説検証をどのように行うかです。
検証は定量と定性の両方からです。
以下は、記事の内容です。
- 実用最小限のプロダクト (MVP) とは
- MVP を市場に投入するタイミング
- どうやって検証するか (定量と定性からの評価方法)
実用最小限のプロダクト (MVP) とは
MVP とは、実用最小限の製品です (Minimum Viable Product) 。最小限というのは、仮説を検証するために必要な機能を持つことです。逆に言えば、検証から学びにつながらないものは MVP には実装しません。
プロダクト開発初期は、顧客はあえて絞り限定的です。想定する顧客が欲しいと思うもの、顧客の問題解決に焦点を当てて MVP をつくります。
MVP をつくりたいからつくるというプロダクトアウトの発想ではありません。MVP の意義は仮説を検証して学びを得るためです。
MVP を市場に投入するタイミング
起業の科学 - スタートアップサイエンス という本に、MVP を市場に出すタイミングの目安が書かれています。
MVP を使って、自分たちが提供しようとしている価値を検証するには、必要最小限の機能に絞り早く市場に出すことです。
MVP を市場に出すタイミングは、まだ出すのは恥ずかしいと思う時です。あと少しデザインを良くしたい、機能を追加したいと思う気持ちを抑え、このレベルではまだ恥ずかしいと思う状態に市場に投入します。
人に見せたり使ってもらうのを恥ずかしいということは、他の企業がまだアイデアを実現しておらず、注目されていない段階です。いち早く投入し、顧客やユーザーの反応やフィードバックをもらい改善をまわせば、後から参入するプレイヤーよりも先行者優位を築けます。
MVP から評価すること、評価方法
必要最小限に絞った MVP で検証することは、自分たちの開発するプロダクトが、顧客やユーザーが本当に必要とするかどうか、無くてはならないと思えるものなのかです。
MVP を使って、定量と定性の両面から検証します。
定量評価からの検証
定量からの評価についてご説明します。
定量評価をする理由は、以下の3つです。
定量評価をする理由
- 数字でプロダクトの現状を可視化できる
- 可視化により開発メンバー間での認識がそろう
- 同じ現状把握と目標のギャップの理解から、開発方針やアクションを考えることができる
良い評価指標の条件は、3つあります。
良い定量指標の条件
- 測定できる (当たり前のことですが、これは大事です)
- 大きな指標から因数分解され、構造化されている
- アクションにつながる
AARRR 評価指標
先ほど取り上げた 起業の科学 - スタートアップサイエンス という本には、定量の評価指標に AARRR (海賊指標) が紹介されています。
AARRR は、5つの指標の頭文字です。なお、海賊指標とも呼ばれるのは、AARRR が ｢アー｣ と読め、海賊の叫び声に似ているからとのことです。
- Acquisition (獲得): 顧客やユーザーが使う準備ができている状態。アプリダウンロード、サイト訪問
- Activation (活性化): 使用が開始される。アプリを立ち上げる、アカウント作成
- Retention (継続利用): 再利用や再訪問をし、リピーターになってくれる
- Referral (紹介): 口コミやシェアをして他の人に紹介してくれる
- Revenue (収入): 課金する、有料会員として契約する
5つのうち、特に注目して見たいのは3つです。Activation (活性化) 、Retention (継続利用) 、Revenue (収益) です。
3つの意味をつなげるとそのプロダクトは、ユーザーはプロダクトを使ってくれ、継続的に使い続け、お金を払ってでも使いたいと思えるものだからです。
定性評価からの検証
定量的な数字だけでは、顧客がプロダクトをどう使うかを理解するには十分とは言えません。
顧客やユーザーのインタビューにより、定性情報から顧客がプロダクトをどう評価するかを検証します。
MVP を使ってもらう顧客へのインタビューリストは、具体的には以下になります。
インタビューの質問リスト
- プロダクトに価値を感じたか。最も価値を感じたトップ 3 は何か。それはなぜか
- 使わなかった機能、価値を感じなかったことは何か。それはなぜか
- プロダクトを自分と同じような状況にある同僚や知人に推奨するか
仮説検証から学ぶポイント
定量データ、顧客やユーザーへのインタビューから学び、次の開発方針を定めます。
具体的な学びのポイントは、次の通りです。自分たちが想定する顧客への提供価値は、顧客にとっても本当に価値があるかどうかです。
仮説検証から学ぶポイント
- 自分たちの ｢価値仮説｣ は何が正しく、何が想定と違っていたか
- 顧客の価値評価の基準は、自分たちと同じだったか
- 次は何を改善すべきか。なくすものは何か。新たに追加するものは何か
まとめ
今回は、プロダクト開発について書きました。特に開発初期フェーズである MVP を使って、マーケットフィットをどう検証するかの方法です。
最後に今回の記事のまとめです。
- プロダクト開発初期は、想定する顧客が欲しいと思う顧客の問題解決に焦点を当てて MVP をつくる。
MVP を市場に出すタイミングは、まだ出すのは恥ずかしいと思う時。いち早く投入し顧客やユーザーの反応やフィードバックをもらい改善をまわせば、後から参入するプレイヤーよりも先行者優位を築ける
- MVP は定量と定性の両方から仮説検証をする。
良い定量指標の条件は、
- 測定できる
- 大きな指標から因数分解され、構造化されている
- アクションにつながる
- 顧客やユーザーのインタビューにより、定性情報から顧客がプロダクトをどう評価するかを検証する。
インタビューの質問リストは、
- プロダクトに価値を感じたか。最も価値を感じたトップ 3 は何か。それはなぜか
- 使わなかった機能、価値を感じなかったことは何か。それはなぜか
- プロダクトを自分と同じような状況にある同僚や知人に推奨するか
- 仮説検証から学ぶポイントは、
- 自分たちの ｢価値仮説｣ は何が正しく、何が想定と違っていたか
- 次は何を改善すべきか。なくすものは何か。新たに追加するものは何か
最後に
プロダクト開発の初期段階で、MVP という実用最小限の機能に絞ったプロダクトをリリースすることには、理由があります。
最小限の開発リソース配分で、自分たちが設定した価値仮説が正しいかどうかを見極めるためです。後からやり直しや失敗の取り返しがつかないところまで資金や時間を投入して開発するのではなく、小さく早く提供価値を検証します。
1回では全ての価値仮説を検証することはできません。優先順位をつけ、nice to have (あってもよい機能) ではなく、must (必須の機能) を MVP に実装し、顧客の反応やフィードバックを得ます。