- 製品ロードマップの議論では、営業・マーケティング・R&D・事業責任者の誰もが顧客を語るが、肝心の**顧客が製品を雇った仕事（job）**を見落とすと、判断基準が曖昧になる
- Intuitはアンケートで出た150件の機能要望を追いかけるうちに feature chase に陥り、どの機能が本当に重要かを見分ける羅針盤を持っていなかった
- ミルクシェイクの事例では、味・価格・食感について尋ねても売上は伸びなかったが、購入状況を観察すると、朝の通勤者の長い通勤時間と空腹が中核となる job であることが見えてきた
- 同じミルクシェイクでも、朝はベーグル・プロテインバー・ジュースと、午後は子どもに与えるおやつの選択肢と競合し、評価基準と競合製品が変わる
- Job to be done を見つけるには、身近な問題、何もしないという選択、回避行動、人々が避けたがること、異常な使われ方を観察する必要がある
顧客の要望がロードマップの羅針盤にならない理由
- ロードマップ会議には、部門ごとに異なる顧客入力が持ち込まれる
- 営業は顧客と継続的に対話しているため、最も差し迫った要求を知っていると考える
- マーケティングは既存ブランドを活用して、新バージョン、新しい味、新色、特別オファーを作れると考える
- R&Dは新技術や応用から生まれる機能と利点に注目する
- 事業責任者は年末までにP&Lに寄与するリリースを望む
- それぞれのアプローチには一理あるが、自分の視点を裏づける情報だけを見る確証バイアスに陥ることがある
- さらに大きな問題は、どのモデルも顧客の jobを直接反映していない点にある
Intuitが陥った機能追跡
- Intuitは、顧客が望む新機能を尋ねるアンケートを広範囲に実施し、顧客は長い希望機能リストを提示した
- IntuitのCEOだったCookによれば、顧客は「150の機能」を要求し、開発チームはどの機能がより重要かを何週間も議論した
- チームメンバーは全員、それが顧客に合った選択だと信じていたが、実際には判断基準がなかった
- 顧客がその製品をどんな仕事のために「雇う」のかを知らなければ、正しい機能を見分けるのは難しく、Cookはこれを羅針盤なしで航海する状況にたとえた
ミルクシェイクの売上が伸びなかった理由
- ファストフードチェーンは、ミルクシェイクをもっと売るために、理想的な消費者プロファイルに合う顧客を呼んで質問した
- もっと安くすべきか
- もっと塊感があるべきか
- もっと噛みごたえがあるべきか
- もっとチョコレート味を強くすべきか
- 顧客は望む点を語ったが、それをもとに何をすべきかは明確ではなかった
- チェーンは顧客フィードバックに合わせてさまざまな施策を試したが、数か月後もミルクシェイクカテゴリーの売上に変化はなかった
観察で明らかになった朝のミルクシェイクの job
- 問いを「人々はどんな仕事を解決するためにこの店に来て、ミルクシェイクを雇うのか」に変えた
- チームは1日18時間にわたり店舗で顧客を観察した
- いつミルクシェイクを買うのか
- どんな服を着ているのか
- 1人で来たのか
- ほかの食べ物も一緒に買ったのか
- 店内で飲むのか、車でそのまま去るのか
- 午前9時前にミルクシェイクが多く売れ、購入者はたいてい1人で来て、ミルクシェイクだけを買って車で去っていった
- 朝の顧客に共通する job は、長く退屈な通勤時間をしのぎ、午前中盤の空腹を避けることだった
- 競合する代替手段はあったが、どれも完璧ではなかった
- バナナはあまりに早く食べ終わってしまい、午前中盤にまた空腹になる
- ドーナツは食べかすが落ち、指がべたついて服やハンドルが汚れる
- ベーグルは乾いていておいしくないことが多く、クリームチーズやジャムを塗りながら運転しなければならない問題がある
- ミルクシェイクは細いストローで濃い飲み物を長く飲む必要があるため時間をつぶせて、午前中ずっと満腹感が続き、カップホルダーにも収まる
同じ製品でも時間帯ごとに競合が異なる
- 人々は1日の中の異なる2つの状況で、異なる job のためにミルクシェイクを雇う
- 朝のミルクシェイクはベーグル、プロテインバー、新鮮なジュースボトルと競合する
- 午後のミルクシェイクは、子どものためにおもちゃ屋に立ち寄ることや、早く帰宅してバスケットボールをする選択と競合する
- 同じ製品でも job が異なれば、競合製品も評価基準も変わる
Job to be done を見つける5つの手がかり
-
1. 身近な job を見つける
- データ中心の世界にあっても、大きなイノベーションの一部は Job to be done に対する直感から始まる
- Khan Academy は、Sal Khan がいとこがストレスなく数学を学べるよう助けたかったことから始まり、同じ痛みを感じる人が多くいた
-
2. 何もしないという選択と競う
- 消費者が自分の job を満たす解決策を見つけられなければ、何もしないことを選ぶ場合がある
- 企業は既存競合のシェアを奪う方法だけを見るのではなく、見えない需要がどこにあるかも見なければならない
- Airbnbのグローバル・ホスピタリティ＆戦略責任者Chip Conleyによれば、Airbnbの「ゲスト」の40%は、Airbnbがなければ旅行しなかったか、家族と一緒に過ごしていただろうと答えた
-
3. 回避行動と埋め合わせ行動を見る
- OpenTableは、レストラン予約をめぐる古くからの回避行動から生まれた
- 友人たちと都合のつく時間を合わせたあと店に電話し、席がなければ、再び友人たちに連絡して別の店を探す過程を繰り返さなければならなかった
- OpenTableはこの予約 job を解決した
-
4. 人々がやりたがらないことを見つける
- Clayton Christensenはこれをnegative jobsと呼び、ネガティブな job は良いイノベーション機会になり得るとした
- Harvard Business Schoolの同窓生Rick Kriegerとパートナーたちは、息子の咽頭炎検査のために救急外来で何時間も待った後、QuickMedxを始め、これはCVS MinuteClinicsの前身となった
- CVS MinuteClinicは予約なしの患者をすぐに診察し、専門看護師が結膜炎、耳の感染症、咽頭炎のような日常的な疾患に薬を処方できる
- 必ずしも医師に行かなくてよいなら行きたくない人は多く、そのためMinuteClinicはCVS薬局店舗内に33州で1,000か所以上展開した
-
5. 異常な使われ方を見る
- 人々が何かの仕事を終えるために自ら回避行動や埋め合わせ行動を作り出しているなら、その job は重要であり、既存の解決策への不満も大きいというシグナルかもしれない
- こうした状況は潜在力の高いイノベーション機会につながり得る
より良い問い
- W. Edwards Demingは「正しい問いを立てられなければ、何も発見できない」と述べた
- より良い問いとは、顧客に何が欲しいかを尋ねることではなく、「その製品をどんな仕事のために雇ったのか」を尋ねることだ
1件のコメント
Hacker Newsのコメント
プロダクトマネジメントにおける古典的な失敗は、たいていユーザーが自分のニーズを分かっていると仮定するところから始まる。実際にはそれはまれで、本当のニーズを見極めるのがプロダクト側の仕事である。
人々が実際に使うまでは、いま作っているものがユーザーの望むものだという証拠はなく、ユーザーが要求したものがそのままニーズだと見なしてもいけない。
営業チームが「Xを作らなければ契約をクローズできない」と言っても、Xを作った後で何も変わらないことがある。原因は営業側の分析が間違っていたからだ。
特に新製品はユーザーが先に要求するものではないので、説明して見せる必要があり、「自動車が初めて登場したとき、顧客はより速い馬を求めていた」という例がこれに当たる。
誰かが何かを要求したら、その理由を掘り下げるべきだ。整備工場に行ってオルタネーターを交換してほしいと言ったとき、そのまま交換されると不満が残るかもしれないが、「なぜ交換する必要があるのか」と聞いてみたら問題はソレノイドで、それを直せば移動するという本当の目的が解決する。
だからシニア開発者の方がプロダクト担当者より優れたプロダクト感覚を示すことが多い。1〜2年開発して資格を取り、プロダクト職に移った人では、ベテランの深さに勝つのは難しい。
前提が何であれ、対話して掘り下げなければ次善の判断をすることになる。
ユーザー調査を通じて問題領域と機能空間を理解することには全面的に賛成だが、実際には自動車の発明家よりもSegwayを作る人の方をはるかに多く見てきた。
創業者の直感やひどいユーザー調査で作った後、顧客の要望を「より速い馬」だと軽く無視するケースが多い。自分の業務領域を自分が分かっていないという前提で追加されたカスタムワークフローに適応する時間もエネルギーも意思もない。
B2CとB2Bの違いはあるはずだが、こうした助言が適用されるときにその区別をほとんど見たことがない。ユーザーフィードバックを無視しようという意味ではないのは分かるが、そう解釈される場面をあまりにも頻繁に見てきたので、新しい比喩が必要だ。
もちろんそのまま受け取ってはいけないが、ユーザーに何を望んでいるか尋ねるよりも、行動を観察する方が多くの洞察を得られることが多い。ただし、何を学びたいのかが分かるように、観察環境をうまく設計する必要がある。
例えば「宇宙船の中を歩き回れて、微小隕石の衝突後に船体を修理するため船外活動ができるべきだ」といったものだ。
逆に企業や開発者がこの論理を過度に適用して、自分たちのゲームを楽しめないプレイヤーが間違っていると責めることもよくある。
営業がユーザーと最も多く接触しているため、プロダクトマネージャーは通常その言葉にそのまま従いやすい。
メールサポートを多くしていると、XY問題が機能要望に偽装されている例をよく見る。https://en.m.wikipedia.org/wiki/XY_problem
誰かが機能を要求し、たいてい追加するのも簡単だが、まず根本的な問題を理解しようとする。顧客は問題ではなく自分の解決策を話すことが多く、その解決策は悪いアプローチだったり、そもそも間違ったアプローチだったりすることもある。
機能をエレガントに追加し、文書化して他の人にも役立つようにするには、それが解決する本当の痛みを理解しなければならない。
「痛みを見つけて取り除け」は強力な販売手法でもある。時には顧客ではなく営業チーム内部の痛みのために機能が追加され、意思決定者が重要だと思い、デモ映えするという理由だけで、実際の顧客は使わない機能が入ることもある。
特にレガシーソフトウェアの置き換えでは、もう使われていないという確信が高く、作るコストが価値を上回るガラクタまで移行しろという圧力が常にある。
例えば、誰も実際には読んでいないレポート生成を手放せないビジネス担当者たちがいる。
記事は良いが、タイトルは本当に嫌いだ。顧客には多くのことを尋ねるべきだが、額面どおりに受け取るべきことはごくわずかだ。
顧客が要求した機能をそのまま実装するのは失敗への近道で、「Xができるようにしてほしい」を超えて質問を続け、掘り下げなければならない。
公平に言えば、記事も実質的にはその話をしているのだが、陳腐なタイトルにはうんざりしている。
ChristensenとDemingの推薦には同意し、Sidney Dekkerも加えたい。特に"Field Guide to Human Error"が良く、他の本も良さそうだ。
解決策が実在し、顧客に売れるかを検証する最良の方法の一つは、「今これを買いますか？」と尋ねることだ。「はい、請求書を送って注文を進めましょう」なら、何かが検証されたことになる。
逆に「うーん、たぶん。購買委員会と話してみます」のような反応なら、まだ迷走中だ。
製品がまだ準備できておらず実際の販売まで行けないとしても、Steve Blankが言うように「今100万ドル払いますか？」「ではいくら払いますか？」「無料で提供したらすぐ導入しますか？」といった質問につなげられる。こうした答えは、それが顧客の目に実際どの位置にあるのかを教えてくれる。
https://www.amazon.com/Four-Steps-Epiphany-Steve-Blank/dp/09...
経験上、顧客は自分が何を望んでいるのか分かっていません。だからこそ、創業者がその問題をもっとよく解ける何かを作りたいと思う理由があります。
「検証する前に作るな」という助言は本当に嫌いです。私には文字どおり一度も効いたことがなく、誘導質問をしながら同時に自分の足を撃つようなものです。
なぜこれをやるのかについての確信が必要です。まったく知らない業界に飛び込む人になると、失敗確率は99%です。自分が何をしているのか分かっているなら、成功確率は60%以上であるべきです。
一目で問題が解決されると人々が理解できる製品は売りやすいです。同じ問題を経験したことがあり、その問題を解決しようと乗り出したからです。
だから、多くの検証優先サイトは解決策の説明をわざと曖昧にしているのだと思います。
本人が原型的な顧客だったわけです。
「Henry Fordが人々に欲しいものを尋ねていたら、もっと速い馬が欲しいと言っただろう」という陳腐な引用は、理由もなく陳腐になったわけではありません。ほとんどの人は自分が何を望んでいるのか分からず、だから優れたプロダクト設計者は高い報酬を得ます。
区別すべきなのは、プロダクトビジョンとフィードバックの聞き方です。
人々の問題を解決する新製品を設計することに妙案はなく、経験・直感・技術理解・既存の代替手段の観察・技術的/経済的/社会的変化の予測などが混ざった技能です。
一方でフィードバックを聞くことは、設計したものが意図どおりに動くか、ユーザーを混乱させているものは何か、障害物は何かを確認することです。ここではユーザー観察、テスト、アンケートのような古典的な方法が役に立ちます。
簡単そうに見えますが、まったくそうではありません。現実が理念と衝突しても原則を曲げないデザイナーや、大多数のユーザーが遭遇し、サポートフォーラムやソーシャルメディアで怒っているバグを不可解にも直さない会社を数多く見てきました。
2つの技能は非常に異なり、どちらか一方をうまくやるのも難しいのに、両方をうまくやるのはさらに難しいです。記事はIntuitを事例にしていますが、政府にロビー活動をして毒を維持しながらその解毒剤を売る事業で、本当に優れた仕事をしている力学については読者に委ねます。
顧客は税務申告の苦痛を減らしたいと思っているのに、Intuitはその苦痛が強く残り続けるよう政府にロビー活動をしています。
私たちの製品の歴史は、このスペクトラム全体を通ってきました。
最初は、顧客である銀行が自分たちのビジネスをどう見ているのか、私たちの製品がどう改善できるのかにしか関心がありませんでした。何をしているのかも分からないままアイデアを素早く積み上げ、顧客の些細な気まぐれにまで合わせようと右往左往していました。私たちには彼らのビジネスを受ける資格がないと感じていました。
中頃には成果が出始め、10社を超える顧客をそれぞれが望むやり方で全員満足させようとして製品を作ると、結局何も残らないことに気づきました。
いま私たちの製品は、特定のソフトウェアや技術というより、ターンキーのコンサルティングパッケージに近いものです。顧客はいまや、自分たちのビジネスをどう運営すべきかについて私たちに指針を求めます。こういうバスを運転する立場になると、ソフトウェアスタックをずっと自信を持って標準化できます。最近では「退屈」という言葉が私たちの語彙に入ってきました。
私たちの顧客層の面白い点は、群れで動く傾向が強いことです。数社だけを特定の方向に動かせれば、残りはほとんど努力せずについてこさせることができます。リスク回避的な銀行家だけに当てはまる話ではないように思います。
記事で抜けているよくある落とし穴は、声の大きい少数の顧客に耳を傾けることです。
Hacker Newsや他の技術寄りのプラットフォームだけを読んでいたら、小さな画面で高性能なiPhoneにものすごい需要があると思っても不思議ではなかったでしょう。
実際にはiPhone miniの販売台数は期待外れでした。つまり、技術ハードウェアについてオンラインで長く書いている人たちは、iPhone顧客全体を代表していないということです。
割合が低かったからといって、出荷台数が少なかったという意味ではありません。
現実的に、どんな会社を作ったとしても、iPhone Miniよりはるかに少ない数しか売れない可能性が高いです。ならばApple基準では期待外れの販売台数だから、解雇され倒産すべきなのでしょうか。2,000万台未満しか売らない会社はすべて清算すべきなのでしょうか。小さなiPhoneの出荷台数より小さい顧客層を対象にする会社は存在すべきではなく、平均的な人のための平均的な製品に置き換えられるべきなのでしょうか。Mac Studioも、XDRディスプレイも、15インチで4,000ドルのMacBookもなくなるべきなのでしょうか。
iPhone miniに非常に満足している人を何人か知っていますが、今では彼らにはアップグレード先がありません。それでもこちらのほうが安くはあります。
人々が自分の問題を自分で解決できるなら、お金を払わなかったでしょう。
コンピュータで何かをするにはある程度の技術力は必要ですが、たいていはルールに従い、Excelを創造的に使えば解決できます。
価値は、人々が問題を解けるフレームワークを与え、彼らが考えつかなかった例外ケースまで考慮して代わりに考えたうえで、そのルール体系をプログラムにコンパイルするところから生まれます。
面白いことに、顧客に望まないものを尋ねるのは実際にはうまく機能します。
顧客に欲しいものを尋ねるのは、委員会式の設計に似ています。人々が望んでいるのは、1人のアーティストが作った、よく整理され自己一貫したビジョンからいくつかを取り除いた形なのです。