「技術者に選定してもらえるプロダクト」を目指す過程での、一周目 PdM の 3 つのしくじりと教訓

はじめまして、 Flatt Security の @lmt_swallow と申します！ 本記事は pmconf 主催の プロダクトマネージャー Advent Calendar 2023 の 2 日目の記事です。 1 日目は 『プロダクトマネジメント人生を歩む』（うなぎごた | @go-go-pdm さん）でした。

私（米内）は、直近 1.5 年ほど、社内ではプロダクトマネージャーとしての業務を職責の一部としていました。 その期間で数回のピボットを繰り返しながら、最近ようやく GA にこぎつけたのが Shisho Cloud という 技術者向けのプロダクトです。

所謂 Business-to-developer（B2D） ビジネス の領域でのプロダクトマネジメントは、本邦では比較的事例が少ないように見受けられます。 そこで本稿では、技術者バックグラウンドのみを持った状態からプロダクトマネジメントを始めた素人 PdM の筆者が、数回のピボットの中でどのようなしくじりをし、どのような教訓を得て、その結果最近どのように 「技術者に選定してもらえるプロダクト」 に近づいてきているかを語っていきます。 具体的には、以下の 3 つのしくじりを起点として、教訓やプロダクトの変化を振り返っていきます:

  • しくじり 1: 「プロダクトと Dev(Sec)Ops との親和性」という観点が欠けていた
  • しくじり 2: 「技術的に面白いヤツ」にはなったが、「仕事を倒してくれるヤツ」ではなかった
  • しくじり 3: 「仕事を倒してくれるヤツ」にはなってきたが、「難しそう」という認知が強かった

技術色の強いプロダクトの PdM をしている方、あるいはエンジニアから PdM に転身しようとしている方にとって、何かしらのいい刺激になれば幸いです。

前提: どんな領域のプロダクトやってるの？

複数回のピボットを通して弊社（Flatt Security）は、ソフトウェアプロダクトを自社で作り、運用する組織 が有する、プロダクトのセキュリティ業務を効率化する プロダクトを作ってきました。 だいたいの事業領域を指し示すために、近いユニコーン企業を挙げると、Snyk や Wiz （$100M ARR に 18 ヶ月で達成したことで界隈を騒がせました）あたりが有名です。 Drata や Vanta がその次に近いです。

今の時点だと、AWS / Google Cloud を利用している組織が、「そこで動いている諸々のセキュリティって大丈夫そう？」をサクッと検証・管理するためのプロダクトを提供しています。

しくじり 1: 「プロダクトと Dev(Sec)Ops との親和性」という観点が欠けていた

今のコンセプトに至るまでのピボットの歴史の中で、ある時、「IaC コード中のセキュリティリスクを修正する pull request を自動的に出してくれる君」 というコンセプトのプロダクトを作りました。 ざっくりクラウドのリスクをシュッと低減してくれる Dependabot 的なものです。

これは、当時盛り上がっていた B2D x PLG 的流れの中で、当時のマーケットへの参入アングルの一つとしてトライしたものでした。 この取り組みに際して、ベータ版をいくつかの組織様にお試しいただき、フィードバックを得ていく中で、一つの気づきがありました。 それが 我々のプロダクトそのものの Dev(Sec)Ops との親和性 です。

いま、セキュリティプロダクトの主題の一つに「どのようなリスクをどう検知し、どう修正/リスクに繋げていくか」があります。 結果としてプロダクトは、どのような範囲にどのような検知ルールを適用するか、検知結果に対してどのような説明（や関連ガイドライン）を紐付けるか、… といったデータを持つことになります。 しかしこの点は、当時のプロダクトでは SaaS 内でポチポチ設定できるのが関の山で、当該設定は IaC 管理できるものではありませんでした。

また、弊社のサービスが提供する “ドメイン知識” は、弊社が有するソースコードの中にのみ存在していました。 結果として、ユーザが自らのセキュリティオペレーションを改善していくには、ユーザがゴリゴリとプロダクト外部でコードを書く必要がありました。

つまり、技術組織の Dev(Sec)Ops の実現を支えるためのプロダクトなのに、それ自体は Dev(Sec)Ops 的ではないものを作っていた、ということです。 自分がテックリードなら、わざわざそんな謎ベンダの謎 SaaS は選ばずに、最悪自分の手でメンテすることもできる OSS ソリューションを CI 等で動かそうと考えることでしょう。

このようなしくじりをふまえて、その後にプロダクトが迎えたピボットのタイミングからは、プロダクトの Dev(Sec)Ops との親和性 が意識されるようになりました。 例えばプロダクトの主たる設定値は、現在ユーザの GitHub リポジトリ上で管理できるようになっています。 また、GitHub Action での Continuous Deployment（CD）も実現できるようにしています。

なんならサービス価値のコアとなる リスクの検知ロジック に関しても、Rego/TypeScript コードとしてユーザ側で管理できるようにしました。 もちろん検知ロジックに対するテストコードも記述できます。 これにより「ちょっとこの検知ロジックだと false positive が多いな。改善したいな」といった際に、ユーザが自らのコードを改善していくことができます。

抽象化するならば、件のしくじりを経て、どう構成管理ができるか・どう継続的かつ安定的に変更できるか という論点をプロダクトマネジメントに組み込んだことになります。 結果として、これによって格段と「技術組織として選定しやすいプロダクト」として見ていただける機会が増えたように感じます。 一般 B2B ビジネスにおいては、これらのトピックの顧客意思決定における重要性はそう高くない印象ですが、B2D ビジネス のプロダクトマネジメントにおいては一考する価値がある要素ですね。

さらに抽象化するのであれば、プロダクトを用いて実装される業務のエクセレンスだけではなく、当該業務を設計・管理・改善するプロセス自体のエクセレンス もプロダクトバリューとして捉えるようにした、ということです。 近年の BizOps の発展を考えると、これは B2B ビジネスにおいても重要な要素となっていくのではないかと思います。

しくじり 2: 「技術的に面白いヤツ」にはなったが、「仕事を倒してくれるヤツ」ではなかった

さて、ここまでの話を踏まえて「CI/CD をしながら継続的にチューニングしていけるセキュリティプロダクト」に近づいてきたところで、次のしくじりが待っていました。 それはプロダクトのカスタマイズが高いこと・しやすいだけで、ユーザの仕事が片付くわけではない、という点への意識が希薄になっていた、という点です。 そうやって出来上がるプロダクトは、これでは技術者に選定してもらえるプロダクトどころか、おもちゃ・プレイグラウンド に近いシロモノになります。

この点に自覚的になってからは、初心に帰って、プロダクトがマーケットの問題を解決できているかに真摯に向き合うようになりました。 具体的には数ヶ月で 100 件前後のユーザーインタビューに自ら周り、そこで延べ 100~200 人ほどの技術者の方と話し、そこで聞いた話をもとに徹底的に「ユーザの業務を完結させること」にコミットできるプロダクトにするべく舵を切ってきました。

例えば「検出されたリスクを他チームに伝える」という業務の際に「他チームが分かってくれない」という課題を解くための プロダクト内への教育の Embedding や、 「自動検出されたリスクは必ずしもリスクと認められない場合があったり、許容できたりするので、その管理をする」という業務において「サービス外でスプシで対応管理しててしんどい」という課題を解くための 対応ステータス管理の実装 など、基本的な機能を愚直に埋めていきました。

一般に、プロダクトマネジメントという、マーケット/ユーザ・プロダクト・チーム・資本 をアラインさせる職責を果たすにあたっては、 「マーケット/ユーザのプロブレムソルバー」（→ マーケットの課題を解き、ユーザを幸せにする人）でありたいものです。 逆に、「プロダクトのプロブレムソルバー」（→ プロダクトの課題を解き、良くする人） としての性格が強まりすぎてはいけない、というのもこのしくじりから得た教訓かもしれません。

事業やプロダクトには必ず 0 → 0.1 の立ち上げのフェーズを経ており、その瞬間は必ず全員がマーケット/ユーザの課題に 100% の集中が注がれているはずです。 しかし、こと提供しているプロダクトが目の前に「プロダクトの改善」を考え始めると、必ずしもユーザードリブンでない改善 （「このボタンちょっと見栄え悪いな」）に目線がバラけていくことがあります。 そういう改善が、楽で手頃な仕事（”Low-Hanging Fruit”）だからです。そこまで向き合ってきたマーケット/ユーザ・プロダクト・チーム・資本のアラインを保つ仕事のタフさも、よりチームを楽な方向に向かわせる要因でしょう。 常にマーケット/ユーザの役に立つことを考え、その上でその考えとプロダクト・チーム・資本とをアラインさせることに集中していかねば、と改めて感じたきっかけが、このしくじりでした。

それと、100 件前後自分でユーザーインタビューをしたのはよかったです。これが何よりもプロダクトにいい影響を与えていると思います。

しくじり 3: 「仕事を倒してくれるヤツ」にはなってきたが、「難しそう」という認知が強かった

さて、少しずつユーザーの “Jobs to be done” にリーチできるようになってきて、かつ技術組織が選びやすいプロダクトになってきたところで、次のしくじりが待っていました。 それは サービスが進化すればするほど、様々なメッセージを伝えようとしすぎて、ユーザーがプロダクトの真の価値を感じる前に離脱してしまう という点でした。 こと上述の プロダクトと Dev(Sec)Ops との親和性 のような、対技術組織向けの点に関する機能が「なんか便利そう」という印象を与えるに留まってしまっており、「技術者に選定してもらえるプロダクト」に至るにはプッシュが足りていなかったのです。

また、プロダクトのコア機能であるリスク検知ロジックが柔軟にカスタマイズできる、ましてや自分が書いた Rego/TypeScript コードをプロダクト上で走らせられる、なんてことになってくると、色々できるヤツ 的な印象が強まってきます。 こうなってくるとプロダクトの価値はユーザにボヤケて見えてきます。なんか便利そう、だけど難しそう ― これがよくある認知です。

この点に自覚的になってからは、まずプロダクトが何たるかをもっとシンプルに伝えるように意識を切り替えました。すごい点、強み以前に、プロダクトバリューが必ず伝わるような努力です。 そもそも自分に関係のあるプロダクトだと思えるタイミングを早くしなくては、Time-to-Value は大きなままなので、重要な点です:

Time-to-Value を考える上で、次に重要なのは、その訴求通りにサービス価値が実感いただけるかです。 少なくとも今は、しくじり (2) に対するアクションのおかげもあり、「なるほどよさげなプロダクトだ」という印象までは得ていただけることが多いです。

そして次に、さらにサービス自体が技術組織にフィットすることを実感してもらうには、その 色々できそうな機能 で具体的に何ができるのかを知ってもらう必要がありました。 そこで、ユーザーインタビューで聞いたユースケースを元に、実際にプロダクト上でのユースケースを実現するチュートリアルを拡充する というアクションを進めています。 これは Time-to-Value の中でも、API プロダクト系でよく言われる Time-to-Hello-World（TTHW） を短縮するためのアクションです。

オフライン勉強会 を開催して、そこで既存のユーザを含む様々な方と一緒にその 色々できそうな機能 を実際に使ってみてもらうチャレンジもしています。

以上のように、Time-to-Value へのこだわりのために、マーケ・開発・カスタマーサクセスの各点からアプローチしています。 これにより こう使えるんすね！ というお声をいただける機会が非常に増えてきています。 前項でプロダクトマネジメントを マーケット/ユーザ・プロダクト・チーム・資本 をアラインさせる職責と表現しましたが、とくにアーリーフェーズほど上記のようなデリバリーもプロダクトの構成要素と捉え、積極的に手を動かしていくことが重要だと感じるこの頃です。

おわりに

ここまで、各しくじりに関して以下のような転換・教訓を経て/得てきた話をしました:

  • しくじり 1: 「プロダクトと Dev(Sec)Ops との親和性」という観点が欠けていた
    • → 管理運用のエクセレンスを重視するスタイルへ転換
    • 教訓: 技術プロダクトこそ、プロダクトが xOps プラクティスに馴染むかを意識しよう
  • しくじり 2: 「技術的に面白いヤツ」にはなったが、「仕事を倒してくれるヤツ」ではなかった
    • → 何かができる要素技術から、業務を意識したプロダクトへ、再度意識を改めて転換
    • 教訓: マーケット/ユーザ・プロダクト・チーム・資本 のストーリー作りに正面から向き合おう
  • しくじり 3: 「仕事を倒してくれるヤツ」にはなってきたが、「難しそう」という認知が強かった
    • → とにかく Time-to-Value を短縮できるようなスタイルに転換（中）
    • 教訓: すべてを一気に伝えようとせず、シンプルな入り口を保った上で、手を尽くそう

どれも思い返すと初歩的な、プロダクトマネジメントの基本的な話です。技術プロダクトだからこそのしくじりは、せいぜい 1 つ目くらいかもしれません。 プロダクトのアーリーフェーズは特に一人が担うべき職責も多く、非常に集中が分散しがちではありますが、よりこういった凡事を徹底していきたいものです。

📣 宣伝: 技術者の方も Biz 職の方でも！一緒にセキュリティマーケットで勝負しませんか！

逆に、最近はプロダクトのフェーズも変わってきて、初期トラクションも見えてきたこの 「国内発・グローバル向けセキュリティ B2D プロダクト」 事業のチームを、より強化していきたいタイミングです。 自分の肩書は CTO なのですが、現在はこの記事で言及している新規事業のみにフォーカスしていて、なんならほぼ全部の営業/CS にも出てています。最近正直なところパンクしてきており、嬉しい悲鳴を上げる毎日です。

こういう技術基盤を創りたいソフトウェアエンジニアも、ユーザのセキュリティ業務をガンガン自動化していきたいソリューションエンジニアやコンサルティングセールスも PdM も、その他ほぼすべてのポジションも大大大募集中です。 「すぐ転職とかを考えてるわけじゃないけど、セキュリティマーケット興味がある！」「もうちょっと細かい中の話聞かせて！」等あれば、Flatt Security 採用情報ページ からご連絡ください or @lmt_swallow に是非 DM ください！

Written on December 2, 2023