SaaSnoteにはTwitterの延長レベルのポエムしか書かないというマイルールがあります。した記事はブログをどうぞ。Twitterもやってます。SaaSにおいて、プロダクトに対する一顧客の要望に、逐一答えて翻弄されてはいけないと言われる。それは現実に起こりうることっぽい。それはなぜ起きるのだろうか。いうことをシャワーを浴びながら整理した。深夜で正直眠いので、がーっと書き下して推敲なしで出しちゃおう。振り回されチャーンのメカニズムこのように一顧客の要求に翻弄された挙句、チャーンになることを「振り回されチャーン」と呼ぶことにする。この振り回されチャーンはなんで起きるのだろう。それはこの9のステップから成るシナリオを辿っていくからだと思う。1導入の目的を明確にさせてない2顧客とKPIを握れてない3成果が目に見えて伝わらない4タンジブルな機能追加を求められる/チャーン理由にされる5チャーンの御旗を掲げて社内調整6なんとか対応する7でもなんか違うと言われる8結局、チャーン9残るのは焦点のぼやけたプロダクトそれぞれ簡単に説明する。1導入の目的を明確にさせてない受注時の導入目的を明確にして、自社製品を導入した背景や、顧客社内のカウンターパートやステークホルダーの期待、望んでるものを明確にしていない。2顧客とKPIを握れてない何を目的に導入したのかが曖昧だと、KPIに落とし込むことができない。目的を計測できるようにしたものこそが数値目標でありKPIだからだ。Managerが果たすべき役割だろう。3成果が目に見えて伝わらないKPIを顧客と握れてないもんだから、自社プロダクトを導入した時の成果が伝わらない。顧客も導入してそれがうまくいってるかどうかがわからない。目に見える形でわからないので、必然顧客の判断もどんどんフィーリング寄りになってくる。4タンジブルな機能追加を求められる/チャーン理由にされる目に見える成果が伝えられてないので、目に見えるもの、タンジブルなもの(触れるもの)が論点になってくる。すると、「あの機能が足りない」「ここが使いにくい」と言った、わかりやすく目に見えやすい、非常にフィーリングに偏った製品要求が出てくる。「それがないから解約(チャーン)する」という展開になる。5チャーンの御旗を掲げて社内調整チャーンされては大変なので、CSMは大慌てでチャーンという錦の御旗を掲げて、社内調整に東奔西走する。しまいには「これがないとチャーンする」って言ってるんです、と伝書鳩に成り下がって、社内を縦横無尽に羽ばたき、駆け巡る。6なんとか対応するそれを受けたプロダクトチームは、なんか違うぞ...という違和感を覚えつつも、チャーンという錦の御旗に忖度して、一顧客のフィーリングから出てきた機能の実装をなんとか仕上げる。いろんなワークアラウンド、設計やモデルの歪、そう言ったものを飲み込みながらもとりあえず作る。こんなときPdMはよくわかんないけど「チャーンはヤバいよね」ってことで、伝書鳩の御用聞きをして機能実装する判断を下してたりする。7でもなんか違うと言われるできたものを顧客に見せると、「なんか違う」と言われたりする。「でもこの機能はないよね、この機能がないと使いづらいんだよ」とかが後出しで出てくる。なんかうまく成果でてる感じないしなー、とか本音もチラリと見えてくる。「社内の方針変わって予算厳しくなっちゃってね」とか、持ち帰って自社内に報告しやすそうな適当なそれっぽい理由をお土産に持たされて顧客からチャーンを告げられる。9残るのは焦点のぼやけたプロダクトその後に残るのは信頼関係が失われて疲弊した組織と、全体感を失って増改築を繰り広げた結果、顧客の何を解決するのかという焦点がボヤけた、曖昧なプロダクトが残る。一顧客の要求に応える突貫工事をしたため、もれなくコードベースも複雑になっている。処方箋もしこんなシナリオがあるとしたら、処方箋はなんだろう。チームが契約するしないの最終ジャッジをできるくらいにカスタマーサクセスに権限を寄せて注力せよ、と青本でも言われてる。お互い不幸になることが見えてる契約はしない。Much)上げていくのかの温度感を顧客と揃える。これが多分めちゃ大事。この握りがあると、これがチームをアラインさせる北極星になり、異なる職種から成るチームが一つの方向を向く。3成果を目に見えるフォーマットにして見せて理解してもらうちゃんと見せるの大事。結果だけ出しても、そのことを適切に伝えない人間の評価が低いのと同じ。いいもの作ればOKだよねという、ものづくり教アンチマーケ派のプロダクトが流行らないのと同じ。いい結果を生んだらちゃんと伝える。顧客の担当者の上司や、会議でドヤできるような体裁に落とし込んで見える化してあげるとなお良さそう。4チャーンの錦の御旗に忖度せず、個別対応をきちんと退けるPdMがんばれ。