■目次
オープニング（ビルドトラップのパターンと組織構造）―株式会社フライル
楽しいロードマップ・要望会議のすゝめ～顧客接点を最大化する工夫～ ―株式会社マネーフォワード
VoCは毎月500以上！集める工夫とプロダクト共有失敗談 ―株式会社ベーシック
Q&A
機能のリリース自体が目的化し、顧客課題を捉えていない機能を生み出してしまう「ビルドトラップ」は、プロダクトマネジメントにおいて陥りがちな罠の1つです。特にBtoBビジネスは、営業やCSの意見が強い傾向にあり、顧客の本当の課題が分からないまま要望を開発してしまうケースがあります。一方、営業・CSとの顧客接点を活かし、一次情報への接触機会を増やすことは、顧客ニーズの特定に大きく役立ち、ニーズ分析や仮説検証の出発点にすることもできます。
フライルでは2022年6月22日、「【プロダクトマネジメント実践論】PMと営業・CSが連携しビルドトラップを防ぐには？」をテーマにオンラインセミナーを開催。営業・CSとの顧客接点をプロダクトマネジメントに活かし、うまく連携することでビルドトラップを防ぎ、顧客への提供価値を高める取り組みについてディスカッションしました。
本記事で、イベントの模様をレポートします。
＜登壇者＞
辻 吏香氏
株式会社マネーフォワード
マネーフォワードビジネスカンパニー クラウド経費本部
副本部長 兼 プロダクト企画部 部長
新卒で大手企業向けソフトウェアハウスに入社し会計サービスの保守コンサルタントや導入プロダクトマネジメント、経費サービスのコンサルティングを経験。2019年9月株式会社マネーフォワードに入社。ビジネスカンパニー クラウド経費本部でカスタマーサクセスを担当したのち「マネーフォワード クラウド経費」のプロダクトマネージャーも兼務。「経費精算は、自走する。」未来を目指して邁進中。佐藤 和美氏
株式会社ベーシック
ferret One事業部カスタマーサクセス企画部
業務全体再設計グループマネージャー
2015年に株式会社ベーシックに新卒入社し、様々なサービスのディレクター、営業などを担当。2019年より「ferret One」のカスタマーサクセス部でサポートコンテンツ・チーム体制の強化から顧客対応まで幅広く経験し、現在はカスタマーサクセス企画部に所属しつつ、プロダクトマーケティングマネージャーとしてCSとプロダクト業務推進に注力。
※役職、職種はイベント開催時点（2022年6月）のものになります。＜モデレーター＞
財部 優一
株式会社フライル 代表取締役CEO
慶應義塾大学卒業後、Fintech系スタートアップZUUの創業期に参画。執行役員として、マザーズ上場までの急成長を経験。事業・組織の急拡大を経験する中で、セールス・CSなど顧客接点を担う部署と開発組織の連携に課題意識を持ち、2020年に株式会社フライルを共同創業。次世代プロダクトマネジメントプラットフォーム「Flyle」の立ち上げに従事。オープニング（ビルドトラップのパターンと組織構造）―株式会社フライル
財部：まず初めに、ビルドトラップの定義を明確にしておきます。ビルドトラップとは、「組織が「どの程度顧客の問題を解決したか」ではなく、「どの程度の数の機能をリリースしたか」をプロダクトマネジメントの成功基準にし、プロダクトが行き詰ってしまう状況」と定義されています。（出典：『プロダクトマネジメント ―ビルドトラップを避け顧客に価値を届ける』）
言い換えると、実際に生み出された価値ではなく、機能の開発とリリースに集中してしまっている状況です。機能やタスクといったアウトプット、顧客課題の解決といったアウトカムとなり、それが売上等のインパクトにつながっていくのですが、これがアウトプットに偏ってしまう状態のことをビルドトラップと言います。
ビルドトラップが起こるパターンとして大きく2つがあげられます。
1つ目が、組織内で営業・CSの意見が強いパターン。営業・CSの声が大きいと、短期的な売上のための機能開発になってしまうケース、プロダクトチームが課題の真因を捉えられないケースがあります。
2つ目は、機能開発がプロダクトチームに閉じてしまっているパターンです。この場合はプロダクトチームの顧客解像度が低いままなので、求められていないものを開発してしまう、営業・CSがうまく活用促進ができず、結局使われない開発になるといった状況にも陥りがちです。
いずれも、解くべき課題ではなく、アウトプットを出すことが目的化しやすい状態であると言えます。
ビルドトラップを防ぐためには、アウトプット主導ではなく、アウトカム主導の組織になっていく必要があります。ただ、具体的な組織のあり方は、各社最適がありますので、本日はぜひお2人のお話を参考にしていただければと思っております。
楽しいロードマップ・要望会議のすゝめ～顧客接点を最大化する工夫～ ―株式会社マネーフォワード
辻様：株式会社マネーフォワードの辻と申します。マネーフォワードは2012年に設立され、「お金を前へ。人生をもっと前へ。」というミッションを掲げ、データ基盤やアグリゲーションという連携技術を元にして、法人や個人、すべての人のお金の課題を解決するサービスを提供する企業です。
私は、様々な領域で展開している「マネーフォワード クラウド」というバックオフィス向けSaaSの中の、「マネーフォワード クラウド経費」という製品のPMをしております。
マネーフォワードクラウド経費は、「経費精算は、自走する。」というプロダクトビジョンを掲げ、「使った瞬間、経費精算されている未来を目指しています。
当初は「開発ロードマップ会議」にネガティブな気持ちを抱えていた
皆さんは、ビジネスサイドとのロードマップ/要望会議にどんな気持ちで臨んでいますか？とても大切なものだという思いは皆さんお持ちだと思いますが、身構えたり、少し気が重くなったり、申し訳ない気持ちになったりする方もいらっしゃるのではないかと思います。かつての私もそうでした。でも、今では毎月のロードマップ/要望会議が待ちきれないくらい楽しみになっています。こうなるまでの過程を今日はお話できればと思います。
半年前に開催していた開発ロードマップ会議の目的とアジェンダはこのようなものです。1ヶ月に1回、開発案件と優先順位を見直すことを目的に開催しており、アジェンダとしては2つありました。
1つ目が、開発中案件の進捗をPMからビジネスサイドに共有すること。2つ目が開発予定の案件に関して、優先度の入れ替えや開発時期についてビジネスサイドから相談を受けること。
ローンチしてから数年間はこの目的とアジェンダで問題なく進んできたのですが、製品が成熟し、組織も大きくなってきた中で、2つ目のアジェンダがメイントピックとなってきました。「ここまでにこの機能がないと受注できないかもしれない。何とかならないか」といった、既にある開発ロードマップを見直すような相談、しかも数ヶ月かかりの開発が見込まれる大規模案件に対しての相談が多くなっていたのです。
ただ、開発リソースが1ヶ月で劇的に変わることはほぼないため、ビジネスサイドが求める進捗を共有できず、毎月申し訳ない気持ちになることが増えていました。この状態はPMとしてつらかったですし、この会議の意味に疑問を感じるようになりました。
ユーザーリサーチとの比較からヒントを見出し発想を転換
ではここで少し話を変えて、ユーザーリサーチを行う際、皆さんはどんな気持ちで臨まれますか。PMの方やUXを設計されている方は結構好きなテーマで、ワクワクするのではないでしょうか。このユーザーリサーチと、開発ロードマップ会議。どちらも製品をより良く、お客様の満足度を上げるために行うものです。それなのに、PMとして向き合うときになぜ気持ちに差があるのかを考えてみました。
開発ロードマップ会議では、主にビジネスサイドに議題を出してもらい、PMはそれを受身で聞いて回答するような立ち位置になっていました。一方のユーザーリサーチは、基本的にPMやUI/UXデザイナーが仮説を立てて主体となって、お客様に検証していただくスタイルです。この2つの大きな違いとしては、受身なのか主体的なのかという部分にあると考えました。
■気付きを得たエピソード
気づきを得たのは、「経費承認時に明細を追加できるようにする」という1つの機能をリリースしたエピソードです。
実はこの機能、以前からたびたび要望としていただいていたものでした。ただ、優先度の高い案件がひしめく中で、何を置いても最優先に、といった意識は持っていませんでした。
そんな中で突如、CSからこの要望が一気に集まった時期があり、「あれ？」と思いました。そこでCSにヒアリングをしに行ったのですが、いまいち理由がわからなかったので、更に営業にもヒアリングしたところ、明確な理由を見つけることができました。
というのも、競合企業の製品強化により、営業が厳しいセールストークを強いられていたのです。その結果、CSがオンボーディングする中でも、強い機能要望があがってきていました。そこで、至急関係者を集めて議論し、、開発優先度を上げてスピードリリースをしました。
結果的に営業が厳しいセールストークをする必要もなくなりましたし、お客様から喜びの声もたくさん届きました。この経験は、変化を捉えていち早く対応したという意味で、成功体験になったなと感じています。
要望を集め続けるのは「変化を捉える」ため
そもそもなぜお客様からの要望を集め続けるべきなのでしょうか。様々な理由があげられるかと思いますが、その1つに「お客様の変化を捉えるため」というものがあると思います。
市場や競合、流行りものなど、世の中やお客様の変化を捉えようとした際、ニュースやウェビナーで情報収集することも大切です。ただ、一番身近で、確実に収集できる方法として、お客様から日々いただく要望の中に、「変化を見つける」というものがあると考えます。
何かしらの変化や新たな傾向が見られたときに、「なぜそうなっているのか」を徹底的にビジネスサイド、お客様までさかのぼって調べると、新しい発見や気づきが得られ、それらをプロダクトに反映することでいいループを作ることができるのではないか、と思っています。
この気づきから、開発ロードマップ会議も「変化を捉えるため」に行うべきだなと思い、目的とアジェンダを一新しました。
目的は、ビジネスサイドから先月のお客様の声とトピックを伝えていただき、製品開発に生かしていくこと、そして、開発ロードマップを遂行する上での課題がある場合に解決策を検討すること、という2つ。
そしてアジェンダは、1つ目は特に変更なしですが、2つ目を大きく変えました。ビジネスサイドの各部から今月のトピックという形で主に「変化」を話してもらうようにしました。たとえば先月は、電子帳簿保存法に関する問い合わせやご要望が増えてきているといった声が上がってきました。このように、常に傾向をキャッチアップすることはすごく大事だなと思っています。
また、このアジェンダ変更によって、各部門にも少し変化が起きています。営業やCSのメンバー同士で、今月お客様と話す中で変わったことがあったかを共有しあうようになりました。それによって今後、新しい気づきや視点が生み出されていくのではないかと期待しています。
開発ロードマップ会議を楽しいもの、有意義なものにするために。
PMが主体的に仮説を持って臨むこと、そして世の中やお客様の変化を捉えた上で、開発ロードマップを検証すること。開発ロードマップ会議をそんな場にすることが大事なのではないかと思います。
マネーフォワード様募集中ポジションはこちら
VoCは毎月500以上！集める工夫とプロダクト共有失敗談 ―株式会社ベーシック
佐藤様：株式会社ベーシックの佐藤と申します。
ベーシックは2004年設立の会社で、情熱を妨げる世の中のあらゆる問題解決をやり抜き、多種多様な企業が強みに集中できる世界を創造するために、「マーケティング×テクノロジー」を軸とした3つの事業に取り組んでいます。
私が所属しているのはferret OneというBtoBマーケティングのお困りごとをまるっと解決するサービスです。「今のマーケティング活動をもっと効率的に運用したい」「マーケティング活動を始めたいがどのように進めたら良いかわからない」などといった、BtoBマーケティングのお困りごとに対して「ferret One CMS」「ferret One MA」「ferret One コンサルティング」の３つのラインナップでアプローチし、戦略設計、サイト構築、マーケティング運用の効率化、ツール提供など、あらゆるプロセスから解決していきます。
本日はテーマをVoCに絞り、「顧客の声を毎月数百集める方法」「集めたVoCの整理方法」「プロダクトチームへ伝える方法」を中心にお話しします。
部署ごとに段階的なミーティングを設置してVoCを届ける
ferret Oneでは現在、顧客の声が毎月500件以上集まっています。顧客の声を共有するためのミーティングは毎月毎月10以上部署横断で毎週開かれています。結果として、2021年以降は顧客の声からの機能改善がより盛んになってきました。
ferret Oneでは、VoCを集める取り組みを、バリューチェーンに声を届けていくという意味で「Uber Eats」にかけて、「Uber Voice」と呼んでいます。カスタマーサクセス（CS）から、マーケティング・セールス（営業）・プロダクトの3つの部署それぞれが、今なすべきことをスピーディーに実現していくために、顧客の声を届けています。
■行われている会議体の詳細
運用方法としては、CSが顧客からの声をキャッチしたら、Slackの専用チャンネルにどんどん投稿してもらっています。Slackの投稿内容がGoogleスプレッドシートに自動連携されるようにしているので、各チームで毎週Googleスプレッドシートを見ながら、CS全体ミーティングに持っていく声を整理しています。
■スプレッドシート連携の運用例
Googleスプレッドシートへの入力だけでは足りない部分があれば、毎週各チームで補足として入力もしています。このような運用を続けるのはかなり難しいと思いますが、事業的に重要な取り組みと捉えているため、この業務自体をCSメンバーのミッションの1つとして組み込んでいます。
持ってきた声はその場で1つ1つすべて読み上げるのですが、その際には「共有です」「相談です」「改善要望です」「喜びの声です」なども必ずセットで伝え、他のグループの参加者がどういう視点で聞けばいいかを補足するようにしています。
その後は、ネクストアクションを決めます。CS全体のミーティングで出た声から各部署に聞いてほしい声を厳選した上で、責任者がプロダクト向けのミーティングや営業・マーケ向けのミーティングに持っていきます。
ただ、最近は、機能に加え顧客のマーケ事情をインプットするために、PMもCS全体ミーティングに参加している時もあるので、その時はよりスムーズに進んでいます。
VoCのカテゴリー分けのコツ
顧客の声を拾うときには、「ライトでいいからとにかくたくさんもらうこと」をCSチームにお願いしています。そのため、声の種類はとても幅広いです。
ferret OneはBtoBマーケティングにおけるお困りごとを解決するためのツールなので、「SEOで順位が上がりました」など成果に関する声はもちろん、「オンボーディングが良かった」「テクニカルサポートが早かった」など、ferret Oneに対する声や要望、その他にも共有すると士気が上がるような声も投稿しています。
先ほどもお伝えした通り、顧客の声をSlackに投稿するとGoogleスプレッドシートに同期されるようにしているため、今度はそのGoogleスプレッドシートを見ながら、カテゴリーごとに分類します。
分類方法の1つは、「ポジティブな声か、ネガティブな声か」です。
真面目に役立つ声を集めようとすればするほど、ネガティブな声を集めてしまいがちです。しかし、お客様の成果はマーケが見込み顧客を獲得して、それを営業が育て、実際にご契約いただいてCSが対応する、というようにたくさんの人がバトンをつないで得た成果です。そのため、部署全体で喜ぶためにも、ポジティブな声もガンガン共有したいと思っており、その意味であえて、ポジティブ/ネガティブのカテゴリーを分けています。
また、その顧客の声を誰になぜ共有したいのかがわからないと、改善が行われにくく、お客様のサクセスに対する解像度も上がらないため、誰あての声かを明確にした上で共有してもらうようにしています。
このような取り組みの結果、VoC件数は過去1年分さかのぼって見ても毎月約600件をキープすることができています。2021年からはVoCからの機能改善を積極的にできるようになり、多くのリリースを実現しました。
「見てください」だけではVoCはプロダクト側に届かない
ここまでうまくいっている事例をお伝えしてきましたが、もちろん最初からうまくいっていたわけではありません。ここからは失敗談についてもお話しできたらと思います。
当初、私が考えていたことは、「機能要望への声は、テキストを読めばわかりやすいものばかり。プロダクト部や開発部は無駄な会議は避けたいと考える人たちだから、スプレッドシートをそのまま共有してフィルタリングしながら好きに見てもらおう」というものでした。
ただプロダクト開発側からすると、単にスプレッドシートを共有され要件があいまいで、結局何をすればいいのかが全くわからない状態だったのです。そうなると、「ちょっと忙しいから後で見よう」となって、そのまま参考にされずに溜まってしまうだけになっていました。
この失敗を経て、プロダクト開発側に声を拾ってもらうために、2つの改善を行いました。
改善点① プロダクトチームに毎月定例ミーティングを設ける
1つ目が、プロダクトチームと月に1回ミーティングを行い、「どんな機能への声が多いのか」「具体的に何を改善してほしいのか」を伝えること。その結果、すぐ改善できるものを中心に、機能改善を進めることができるようになりました。この改善は、2021年にVoCからの機能改善リリースが数多く出せたことにつながっています。
ただ、先ほど辻さんのお話にもあったように、すぐにできない機能改善や新機能への起案など、重たい機能要望は既に決まっているロードマップに載せることが難しく、記憶の片隅にたまるだけになってしまうこともありました。
改善点② プロダクトメンバーも毎週CS全体ミーティングに同席
そこで2つ目の改善として、プロダクトメンバーに毎週のCS全体ミーティングに参加してもらうようにしました。そこで年間の開発ロードマップをもとに、「今、顧客がどのような課題でつまずいているのか」「ロードマップに取り入れる需要が漏れていないか」を見てもらっています。
機能要望をテキストで共有するだけだと、顧客の業務課題やプロダクトへの温度感などが伝わり切らず、判断が難しいことがあります。そのため、顧客から上がってくる要望全てを、PMがCSに直接ヒアリングするコミュニケーションをとるようにしています。その結果、新機能の起案に役立ち、年間ロードマップの最適化にもつながるようになりました。
現在の組織状況に合わせた集め方でVoCをプロダクトに活かす
先程の失敗談から、VoCを共有するときは「見てください」ではわからないこと、集めた声は整理しないと伝わらないことがわかり、体制や人数に応じて会議体はその都度修正していくことが重要であることを感じました。
また、そもそも共有するVoCがなかなか集まらない頃は、まず質より量でまずライトに集めること。各部署が喜ぶ声と、もっとサービスを磨きたくなる声を共有していくこと。それに加えて、最近よく取り組んでいるのが、同じ声を何度でも共有することです。お客様からもらう声は頻度が重要なので、何度聞いたことがあっても、同じ声を上げ続けています。
一方、ferret Oneでは、VoCをライトに集めることが習慣化したため、声を上げることに意識が行き過ぎて、週1の会議で時間が足りなくなってきたり、質の低い声が増えてきてしまう課題も見えてきています。
組織に合わせて今後も体制を柔軟に変更していければと思っています。
本日はご清聴ありがとうございました。
ベーシック様募集中ポジションはこちら
Q&A
顧客の声から真のニーズを拾うための工夫
財部：ここからはQ&Aセッションに移ります。関心を集めている質問として、「真の課題、ニーズを拾うために工夫したこと」があります。PMにとって永遠のテーマだと思いますがこちらはいかがでしょうか。
佐藤様：意識しているのは、「お客様からもらった要望を真に受けないようにすること」です。お客様はご自身のお困りごとから、お客様自身がイメージできる範囲で要望をあげてくれます。ただ、それは根本の解決にならないこともあると感じています。
なので、要望が上がってきたときに、CSに質問を返すようにしています。「お客様は本当は何がしたいんだっけ？」「今どういう状況のお客様の声だっけ？」ということを話した上で、補足を入れてプロダクトチームに共有するようにしています。質問で深掘りをすることで、営業やCSの方がはっとするような機会をつくることにもつながっています。
財部：その質問は先ほどのプレゼンの中にあったCS全体ミーティングの場でされることが多いのですか？
佐藤様：基本的には全体ミーティングの場です。ディスカッションが盛り上がりそうだと思ったら、別でミーティングを立ててプロダクトメンバーも一緒にその議題のことだけ話し合ったりもしています。
辻様：私の場合は、上がってきた要望に対して、その背景をめちゃくちゃ想像することを大事にしています。「お客様はこういう業務があり得るから、このような要望になったのではないか」という仮説をかなり作り込んで、要望を上げてくれた人に確認にいくようにしています。
そのように対応する背景として、プロダクトマネージャーがどういった思考でお客様の要望に向き合っているのか、営業やCSの方に理解してもらいたいという意図もあります。そうすると、はじめのうちは、そこまで深く突っ込んでヒアリングができていなかった方でも、次第に本質的な課題はなんだろう、を意識していただけるようになると考えています。
財部：そうすると徐々にCSや営業から上げられる声は変わってきますか。
辻様：新しいメンバーが増えているので、最初はふわっとしていることも多いですが、1回こういったやりとりを経ると変わってきます。また、このようなやり取りをSlackのオープンチャンネルで行うことにより、他のメンバーにもどのようなコミュニケーションが行われているかを知っていただくことにもつながり、より真剣に要望をヒアリングしようと思ってくれるようになっていると感じます。
また、それ以外では、Flyleでは、要望を上げるフォーマットの設定ができるので、背景を記入するような形でフォーマットをつくっています。背景というのは、「この機能がないことで、お客様がどのように苦しんでいるのか」というものです。それによって一歩踏み込んで考えてくれているのかなとも思っています。
ただし、もちろんそれで要望を上げることを躊躇するようになってしまうこともよくないので、按配は重要だと思います。
VoCからどのように優先順位をつけている？
財部：次の質問です。「お客様の声の優先順位はどのように決めていますか」。ベーシックさんでは月600件お客様の声があるということで、どのように優先順位を決めているのかが気になります。
佐藤様：プロダクトチームに持っていく声の優先順位は、今のロードマップに入っているものは100%、それ以外は量が多い機能要望を中心に伝えます。たとえば「1ヶ月で5件以上来ている」「先月と合わせて10件超えているから優先度をあげて今やる必要があります」のような温度感でお伝えしていますね。
ビジネスサイドに伝えるときは、あらかじめ聞きたい声の種類をヒアリングしていて。それに合わせていくつか持っていったり、成果が出ているポジティブな声は必ず持っていくようにしています。
また、機能開発の優先度決定のオーナーシップはPdMが持っているので、CSからはPdMが取り出しやすいように情報を届けるようにしています。
財部：辻さんはいかがですか？
辻様：まず、そもそも弊社では、顧客の声そのものではなく、それに紐づく機能案に対して優先度をつけているので、お客様の声に対して優先順位をつけているという感覚はありません。（ちなみに、それはFlyleを導入して変わったところでもあります）ソリューションに対して、誰にどんな価値が提供されるのか、開発の規模はどれくらいなのか、費用対効果として見合うかどうか、といったビジネスインパクトまでを並べて考慮した上で優先度づけするようになりました。
財部：お2人の視点に付け加えるとすると、「ターゲットを明確にする」というアプローチもあるかなと思います。お客様の声がたくさん集まっている要望や機能に寄りがちなところを、ちょっと立ち止まって、「今の注力セグメントは何か」を明らかにすることで、開発の優先度づけをされている会社さんは多い印象があります。
佐藤様：そうですね。弊社も、全てのお客様の声におこたえすることは難しいので、より注力すべき顧客セグメントの解像度を上げるべく、顧客の分類を見直したうえで、声のとり方を変えようという議論を進めています。
プロダクトビジョンはどのように策定すべきか
財部：次に、辻さんに聞いてみたい質問なのですが、「プロダクトビジョンはどのくらい社内に浸透しているのでしょうか？」
辻様：私が担当している「マネーフォワード クラウド経費」のプロダクトビジョンは先ほどもご紹介した通り「経費精算は、自走する。」です。これは半年ほどかけてつくったビジョンになっています。マーケや営業、CSはもちろん、本部長や開発の事業部長クラスまで多くの人を巻き込んで、この製品で5年後や10年後にどんな未来を描いているかをたくさん話し合い、時間をかけてこの言葉を生み出しました。今はそれを社内で浸透させていくところにあります。
やってみてよかったこととして、ビジョン策定の過程でワンチーム感ができ、製品について多くの人が理解・共有している状態が作れた実感があります。だからもしこれからプロダクトビジョンをつくろうと考えている方がいたら、時間はかかるし大変だとは思うのですが、ぜひつくってみることをおすすめします。
佐藤様：プロダクトビジョン策定の話し合いには、どういった部署の方が参加されたのですか？
辻様：最初はマーケ側が、マーケティングしていくためのキャッチコピーを作りたいといったニーズからスタートしました。ただ、話し合いを進めるうちに、キャッチコピーではなく、製品の「北極星」になるタグラインを作りたいという話になってきまして。そこから本部長、営業やCS、開発など、だんだん話し合いに参加する人が増えながら話が進んでいったような感じです。台風のように社内の色んな人を巻き込みました。
ニッチな要望にどう向き合うか
財部：「ビジネスインパクトが大きい顧客からのニッチな機能要望をどう判断していますか？」。これも難しい質問ですが、いかがですか？
辻様：どのくらいの規模のビジネスインパクトなのかにもよるので一概にいえませんが、基本的には開発工数をまず考えつつ検討することになるかと思います。
あとは、例えば「お客様の業務フローをこう変えることで対応できないか」と考えることもあると思います。
ニッチということは、何かがイレギュラーになっているということだと思います。エンプラ企業様にありがちなのですが、古い慣習が原因となって不都合が起きていることがあったりします。そこはCSメンバーにプリセールスで入ってもらったり、必要なら自分も出て行こうと考えながら対応しています。
佐藤様：付け加えると、それが北極星に向かう道の途中にあるかどうか、という視点は大事だと思います。弊社のツールはマーケティングに関するツールなので、認知獲得の部分から商談化のところまで、開発したい機能のスコープは幅広いです。ですので、「じゃあ今年、どこを伸ばしていきたいのか」。これに沿って優先度をつけていくことが大切だと思います。
==================
顧客の声や機能要望の整理をサポートする「Flyle」のサービスページはこちら