鎮痛剤 vs ビタミン論争から考える“ハマる”サービスの創り方

プロダクトの例え話で鎮痛剤(ペインキラー) vs ビタミンという比喩があります(例えばentrepreneur.comのこの記事とか)。今日はこのメタファーを使って継続率の高いサービス開発について考えてみます。

結論としては、鎮痛剤かビタミンどちらか一方が優れているということではなく、ビタミンから入って鎮痛剤にアップグレードするパターンに注目です。

あなたが今作っているプロダクトは鎮痛剤ですか、ビタミンですか?

考えながら読んでみてもらえると幸いです。

目次・PMFのどのレイヤーの話か・鎮痛剤(ペインキラー)とは・ビタミンとは・ビタミン→鎮痛剤へのアップグレード・TwitterとSlackの例・新たな需要を作り出す


PMFのどのレイヤーの話か

以前の記事で紹介したPMFピラミッドを使ってまずは全体像を把握しましょう。
今回のトピックはマーケット側の最上位の話です。

リーンプロダクト開発の流れでいうと②の部分です。

①顧客を定義して →②まだ満たされていない顧客ニーズを見つけて →③その課題を解決するバリュープロポジションを定義して →④ラピッドプロトタイピングで③を実現するMVPを発見し →⑤実装して →⑥リリース
という流れになります。

鎮痛剤(ペインキラー)とは

顧客が苦痛を感じている場合、その苦痛を和らげたいという明確なニーズがあります。ペインは文字通り「痛い」ので、解決策に対する強いモチベーションがあります。こういった実在する痛みを解決するソリューションを鎮痛剤(ペインキラー)と呼びます

苦痛に対する特効薬がまだ存在しない場合、そこには強力なマーケットがあります。

イシューから始めるというのはそういうことだと理解しています。

以下ポール・グレアムの『How to Get Startup Ideas』より。

「あなたが持つ問題」へ対して取り組むことが、なぜそれほど重要だろうか?とりわけ、その問題が実在するものであることを確認することは極めて重要だ。問題が実在するのであれば、それに組むべきなのは明らかである。スタートアップにとって最も重大な過ちは、どこにも存在しない問題を解こうとすることである。

効果がすぐには見えないビタミン

鎮痛剤に対してビタミンというのは切実な必然性はありません。needというよりはwantに近い存在です。

ビタミンC不足に起因する大航海時代の壊血病では数百万人が死に至ったと言われているようにビタミンが極度に不足すると死に至ることがあります。
とは言え、現代社会でビタミンを摂取する理由はもっと中長期の健康を考えてのことでしょう。

またビタミンは必要以上に摂取しても、単に体外に排出されてしまうケースもあるようです。

もちろん効果はありますが、鎮痛剤のような即効性はありません。

必ずしも即効性があるわけではない「nice to have」(あると便利)なソリューションをビタミンと呼びましょう。ビタミンは鎮痛剤よりも劣っているのでしょうか?

イノベーション≠鎮痛剤

インターネット業界にいるとUberやAirbnb、GAFAと言った企業の話題をよく聞きます。

多くの顧客に支持される彼らは、なぜ成功したのでしょうか?

よくよく考えると、彼らのプロダクトが出た当初は多くの人は「そんなもの要らない」と感じたのではないでしょうか。

彼らは既に顕在化している苦痛に対する解決策ではなく、まだ顕在化していないけれど近い将来ニーズの高まるサービスを出したのではないでしょうか。その意味だと世界を変えた彼らのサービスは鎮痛剤ではないのです

ビタミン→鎮痛剤へのアップグレード

もし今作っているプロダクトがビタミン(nice to haveだけどneed to haveではない)型ソリューションの場合、どうすれば成功の確率を高められるのでしょうか?

その1つの回答がビタミンとしてサービスを世に出した後に、プロダクトを鎮痛剤にアップグレードするパターンです。

以下僕がはまっている2つのサービスを例にとって説明してみます。

例1:ツイッター

ネットでつぶやいて何が楽しいんだろう?まぁようわからんがやってみるか →使い方わからないけど有名人フォローしたりファボったりしてみる  →たまにフォローされたり(botから?😅)、ファボられたり →楽しいかも。もう少しやってみるか →頑張る →疲れる →ツイットしてなくてもハイライト通知が来る →とりあえずアプリ開いてみる →ツイッター開くことが徐々に習慣になる →習慣化するとTLを眺められないことが小さなストレスになる →隙間時間にとりあえずTLをスクロールしてしまうようになる。

例2:Slack

なんかイケてるスタートアップが導入してるらしいよ、うちらもとりあえずやってみようよ →ライトでいいな絵文字とか。メンションも便利 →けどエンジニアや新しいもの好き以外はまだ使っていないなあ →徐々にPMやデザイナーにも広がる →カスタム絵文字とか充実してくる →エンジニアがインテグレーションを進めて各種外部サービスとの連携が充実してくる →社内でメール連絡受け取るのが苦痛になる →偉い人に掛け合って全社導入を決める →営業やコーポレートも使うようになる →正社員以外の常駐さんにも導入される(シングルチャンネルユーザetc) →社外の人からのメールもうざくなる →開発/デザイン系のパートナー企業との間にSlackの共有チャンネルを作ろうとする

新たなストレスと需要

以上2つのパターンではストレスが重要な役割を果たしました。

どちらの例でも最初のきっかけはささいなことで、明確なペインを解決したいというニーズはありません。ただし使い続けるうちに、
・新しいやり方に依存し始めてその新しいやり方で進められない状況にストレスを感じたり
古いやり方に戻ることに苦痛を感じたり
し始めます。

Nice to haveなソリューションを使い続けるうちに、旧来のやりかたをストレスと感じるようになり、結果としてneed to haveなソリューションに進化する。ビタミン型ソリューションが結果的に新しいイシューを作り出し、自社サービスへのニーズが増すというサイクルです。

かゆいところに手が届くサービス

Nir Eyalは著作『Hooked』の中で"scratching the itch"という表現を使っています。小さなかゆみは痛みほど切実ではない。けれど、明確にストレスを感じており、かゆみをひっかくことで確実に満足感を得られます。小さなイライラは実はフラストレーションになっているので、それを解決することで顧客は満足するようです。

日々の生活の中で感じる小さなイライラこそが大チャンスなのです。PMたる者常にアンテナを張っておかないといけないのです!

お客さまにアクションを起こしてもらうためには痛みよりも切実ではない痒みで十分ということです。

↓Hooked日本版。SNSにハマる仕組み等が説明されています。


最後に

今までどこにもなかったソリューションで一気に世界を変えられればかっこいいですが、そう簡単にはいきません(僕も何個新しいWebサービスを開発してきたことか、、)。

メルカリUK事業立ち上げを経て、今はメルペイで働いているのですが、株式会社メルカリのミッションは「新たな価値を生みだす世界的なマーケットプレイスを創る」です。まさしく今後現れる新たなニーズを創り出すことが我々のミッションです。

今までになかった新たな需要を喚起し、新しい価値を世の中に提供する。メルカリが日本のフリマ市場で成し遂げたことを再現するためにはどうしたらいいのか?すでに多くの優秀な仲間が加わっていますが、この挑戦に共感していただける新たな仲間も絶賛募集中(メルカリ採用ページメルペイ採用ページ)です。

細々とですが、ツイッターもやってます。質問や感想、お気軽にどうぞ!

#PM #ProductManagement #プロダクトマネジメント #リーン #リーンプロダクト #agile #PMF #プロダクト #アプリ #メルカリ #メルペイ #ビジネス #イノベーション #スタートアップ #ベンチャー #新規事業 #テクノロジー #イシュー #ペイン #鎮痛剤 #ビタミン

この記事が気に入ったら、サポートをしてみませんか?気軽にクリエイターを支援できます。

スキ、ありがとうございます!
80

#デザイン 記事まとめ

デザイン系の記事を収集してまとめるマガジン。ハッシュタグ #デザイン のついた記事などをチェックしています。広告プロモーションがメインのものは、基本的にはNGの方向で運用します。
4つのマガジンに含まれています

コメント5件

國分さん、ありがとうございます!そうですね、初期ユーザさんを誰としてどう喜んでいただくか。そこからどうやって他の展開につなげるか。その辺りの全体的なストーリー作成能力が問われてきている気がします。参考になりそうなトピックありましたら教えてください!
早速ありがとうございます。

参考にさせて頂きたいのは「問題が存在するかどうか」を仮説検証するプロセスについてです。特にファーストローンチまで。ローンチしてからはデータが取れるので学習しやすいのですが、データがとても少ない状態だと、川嶋さんが何を信じてプロダクトを作るかは知りたいです。自分の描いたストーリーが「もっともらしい」と確信できるまで、どういう情報収集をしているかはとても気になります。

ぼくはB2Bプロダクト創っていた経験が長いので、特定少数セグメントに刺さると自分が信じられる程度には仮説を練れるのですが、toCになると少し苦手意識がありまして。ひょっとしたら、ドメインやターゲットごとにストーリー作成できるか、できるほど一次情報を取れてるかに依るのかも知れませんが。
初期フェーズでのKGIを何にするかが重要な気がします。確かにtoBとは違いが少しあって、toCは初期コミュニティの熱量が大事になるので、そのあたりを測定することを事前に決めてサービス設計することは肝です。逆にtoBはどうしたら良いかも気になります。
なるほど!そしたらKGIを決めるまでの川嶋さんの試行錯誤や思考プロセスを読んでみたいです。

toBに関しては、ぼくが考えていることをnoteに書いてみます。少し時間掛かるかもしれませんが。1人誰かが記事を書けば他のtoB PMも食い付いてくれる気がするので。
コメントを投稿するには、 ログイン または 会員登録 をする必要があります。