あなたは、開発時に、
顧客からの声を共有する仕組みを
作っていますか？

社長一人の動物的嗅覚によって
開発を進めていくのなら、
共有の仕組みの必要性は、
そんなに高くはないかもしれません。

しかし、社長がいなくても、
ある程度のヒット確率を保持したまま、
開発の再現性を担保していく、
となると、組織で意思決定していく
必要があります。

つまり、複数の人が新製品開発に
関与するわけですね。
複数の人が関与すると、
初期の企画段階のイメージと、
終盤の販売段階のイメージとで、
大分違ってくることがありますね。

いろんな人の主観的な判断に引っ張られて、
みんなに受け入れられるように
全体的にまるくなっていきますね。
判断がブレブレです。

そこで、なるべく、判断がブレずに、
客観的な判断ができるように、
文字化することが必要になってきます。
書面にするということですね。

開発前の新製品の企画時に、
顧客ニーズを取り入れて仮説を作り、
企画書にします。
このとき、顧客ニーズを中心にまとめる
ことが重要ですね。
判断基準も作っておく必要があります。

企画会議で、GOサインとなったら、
次は開発段階です。

開発では、アイデアや考えを現実の世界で
物理的に現す訳で、非常に難しい。
技術には、不確実性があって、
ある技術課題があったとしても、
それを解決できるかどうか分からないし、
いつどうやってやるのかも分からない。
この辺のコントロールが難しいところ。

そのため、顧客ニーズを元にした
新製品のコンセプトが文字化されていないと、
いろんな現実の壁にブチ当たって、
顧客ニーズからどんどんズレた方向に
進んでしまう、なんてことになります。

せっかく、企画段階で顧客ニーズを
キャッチできたのに、開発の段階で、
開発しやすいスペックに置き換えられて、
いつの間にか、当初の顧客ニーズが、
反映されなくなってしまう。
こうなると、販売段階でどんなに
がんばっても売れません。

それでも、せっかく開発したのだから、
と意気込んで、顧客ニーズのないものを
売ろうとして疲弊していく。
こんなパターンって、結構多いです。

企画段階で、顧客の声に基づいて
顧客ニーズの仮説を作り、
企画書でコンセプトをしっかり文字化する。
開発段階でも、文字化されたコンセプトから
外れていないかを定期的にチェックしていく。
やむを得ず、スペックを変更するときでも、
コンセプトにマッチしているかを常にチェックする。

このように、顧客ニーズを元にして、
常に共有できるような仕組みを作ること。
開発の再現性を担保した組織的な
拡販開発を行っていく上では、
必須となります。

あなたは、開発時に、
顧客の声を共有する仕組みを
作っていますか？

━━━━━━━━━━━━━━━━━━━━━━━━━━━
●●今週の深海奥義●●

・開発時に、顧客の声を共有する
仕組みを構築せよ！

━━━━━━━━━━━━━━━━━━━━━━━━━━━

ネオフライトクリエイションズ
宮川　壮輔