システムの顧客開発_仮説の記述その4

エバンジェリスト・ユーザ候補客ができたとして、以下が確認できたら「顧客実証」へと進みます。

  • 顧客が解決したい課題を特定したか?
  • 製品はそれらの顧客ニーズを解決するか?
  • もしそうであれば、ビジネスモデルは実行可能で利益を生み出すか?
  • 製品を購入する前後の、顧客の課題の変化を描けるか?
  • ユーザ、購入者、そして流通チャネルの組織図を作成できるか?

確認方法は顧客市場の課題、顧客の購入意思の検証となります。

この検証は、プロジェクト全ての土台なので、厳密に明確に決める必要があるといいます。

また、この段階のスタートアップの失敗パターンとして、以下があるので慎重に検討を重ねるべきだということです。

  • 間違ったユーザ(メインストリーム顧客)からのフィードバックを受けた
  • 最初の製品仮説で多くの機能を盛り込みすぎた
  • 市場タイプと製品タイプの判断ミス

確実に購入を約束していくれる顧客と、「必要最低限の機能」の2つがスタートアップが支出する「無駄」を最小限にしていくということです。

 

ここで疑問が湧きました。

従来の計画のプロセスと、このエバンジェリストユーザ顧客ドリブンの計画プロセスは、後者が勝っているように思えます。しかし、、、

私も拙いながらいくつかの製品•サービス開発に参加したり、また参加していないまでも社内外の身近なプロジェクトをいくつか見てきました。

 

プライマリ顧客(と私は呼んでいます)がスタートアップに必要であると誰しも考え営業し、見つけます。そして、虚心坦懐に顧客の要望を訊くことは、営業のエッセンスですし、技術者にもそのマインドが必要と言われています。なので、リーンスタートアップの顧客開発で書かれている事は、ある意味では目新しくはないと感じる人も多いのではないでしょうか。

 

しかし、多くのプロジェクトが抱える問題は、そのプライマリ顧客に振り回され、優先度の低い機能追加や(特に製品出荷が近づくにつれ)、あるいは顧客固有の既存システムなどの事情にほだされ(往々にして負の遺産的な)、その対応で技術者は疲弊して最後の仕上げを思う存分できません。そして徐々に製品の本来の強み、キャラクター、整合性、シンプルさが失われ袋小路に入っていくとうパターンを見ています。さらに社内やプロジェクトの資金繰りなど事情がからみ、それに抗う事ができないのです。そしてそのプライマリ顧客の専用システムに成り下がってしまうのです。

 

そういった経験があるので、リーンスタートアップを知り、どうやってこういったジレンマから抜けられるのかのヒントが欲しいという思いでいます。

そのため、素朴な疑問をあげておきます。

  • 顧客開発ができた事で、それを土台として決定済とする事は、良いのでしょうか?
  • この土台も常に見直しても良いのでしょうか?
  • もし見直せないとしたら、そこで硬直してしまう危険が大きいのではないでしょうか?

少なくともリーンスタートアップでは、エバンジェリストユーザ顧客の機能追加要求に必ずしも答える必要が無いという事を明快に示しています。そこだけでも私に取っては意を得たり!という気持ちでいますが、ここで何かを恒久のものとして決定するのはためらわれます。

疑問を残しつつ、先へ進めばまた良いヒントがあるという気もしています。

Posted in

コメントを残す

メールアドレスが公開されることはありません。 * が付いている欄は必須項目です

*

次のHTML タグと属性が使えます: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong> <pre class="">