Malte Scholzがairfocusを優先順位表からLucidのProduct Intelligenceへ変えた転換

冒頭から見えるairfocusの現在地は、単なるroadmap管理ツールではない。

公式サイトはfeedback、strategy、OKR、roadmap、deliveryを一つのconnected data modelで扱うProduct Intelligence Platformとして位置づけている。出典

課題の発見

airfocusの出発点は、product managerが意思決定のために使える専用ツールが足りないという違和感だった。

公式Aboutによれば、Malte Scholzは2017年にその問題に出会い、Valentin FirakとChristian Hoffmeisterを誘って開発を始めた。出典

Malte Scholzはairfocusの創業について、product managerとして「there was no dedicated tool built for the job」と感じたことが出発点だったと公式に説明している。出典

優先順位から文脈へ

初期のproduct managementでは、優先順位付けとroadmapが中心になりやすい。

airfocusはそこに顧客のfeedbackとinsightsを接続し、なぜその項目を選んだのかを追跡できる構造を積み上げた。

priorityの投票だけでなく、strategyやOKRまで同じ文脈に置く発想である。出典

Lucid買収という転機

2025年2月、Lucid Softwareがairfocusを買収した。

airfocusの公式発表は、LucidchartとLucidsparkを持つLucidの3つ目の主要プロダクトとして加わること、product teamsのworkとroadmapを一か所で扱う方向を示している。出典

買収は、airfocusが独立したroadmapping toolから、strategyからexecutionまでをつなぐLucidの製品群へ入った転換点と読める。

ただし買収額や売上は公表されておらず、成長規模を推測してはいけない。

AI-nativeな現在

現在のairfocusは、Insights agent、drift detection、MCP serverを前面に出す。

AIに一般的なpromptを渡すのではなく、チーム固有のfeedback、strategy、roadmapというproduct contextを参照させる設計だ。出典

結び

airfocusの道のりは、priorityを決める画面を増やした話ではない。

product managerの判断が埋もれる場所を一つのcontext layerへ集約し、Lucidとの統合によってstrategyからexecutionまでの接続を広げた話である。

価格やARRが公開されていないからこそ、評価すべき軸は派手な数字ではなく、意思決定の履歴をチームで再利用できる構造にある。

airfocusのPMFは、複数チーム・複数プロダクトを持ち、顧客要望・strategy・roadmapの分断に悩むproduct organizationにある。

公式サイトはfeedback、OKR、roadmap、deliveryを一つのconnected systemで扱い、意思決定を顧客と目標へ戻せる点を中核に置く。出典

単なるtask managementではなく、優先順位の根拠を残して経営・PM・開発の会話を揃える。

Lucid買収後はvisual collaborationとの接続も加わり、strategyからexecutionまでの文脈を広げられる。

最大のmoatは、priorityの単機能ではなく、feedback、strategy、OKR、roadmap、deliveryを同じデータモデルに蓄積する運用コンテキストである。

連携先が増えるほど移行コストと履歴価値が高まり、AI agentが参照できる固有のproduct contextになる。

ネットワーク効果は中程度以下。

利用者が増えると社内の意思決定共有は強くなるが、外部ユーザーが増えるほど価値が自動的に増えるmarketplace型ではない。

Intercomやcustomer portalを通じた顧客フィードバックの循環には、限定的な両面性がある。

主な対象は、複数のproduct teamを持つ企業のHead of Product、product ops、PM、経営層。

顧客の声を集めて優先順位を説明する必要があり、Jiraなどdelivery toolは残したままstrategy layerを整えたい組織に向く。

単一チームの簡易task管理だけを求める個人には過剰になりやすい。

第一に、priority・feedback・roadmapを分断せず一つのproduct contextとして設計したこと。

第二に、Jira、Azure DevOps、Intercom、Salesforceなど既存ツールとのintegrationを増やし、置き換えではなく接続から導入できること。出典

第三に、ProfessionalとEnterpriseを分け、multi-team portfolioやSSO、SCIM、onboardingを上位プランにまとめたこと。

公開情報だけではARR、顧客数、資金調達額を確認できず、成長規模の比較には限界がある。

ProfessionalもEnterpriseも公開価格ではなくRequest pricingのため、小規模チームには導入判断の不透明さが残る。出典

また、roadmap・feedback・OKR・deliveryを一体化するほど初期設計と運用の負荷は上がる。

既存のJiraやBIを使い続ける企業では、データモデルを合わせる導入プロジェクトが必要になる。

成長はcontent/SEO、case study、integration、product-ledな評価導線、enterprise salesの組み合わせと見られる。

公式サイトはroadmap、prioritization、product managementの検索意図に合わせたページを持ち、顧客事例では導入後のteam alignmentを示す。出典

Lucid買収後はLucidchartとLucidsparkとのcross-sellと、visual collaborationからproduct executionへ広げる余地が加わった。

一方で、enterprise向けのRequest pricingはセルフサーブの拡散速度とトレードオフになる。

主要チャネル: content, seo, customerStories, integrations, productLedSales

プロダクトの優先順位付けは、投票数の多い要望を並べるだけでは終わらない。

顧客の声、事業目標、実行状況が同じ文脈にあれば、なぜ今つくるのかを説明できる。

airfocusの示唆は、AI機能を先に売るのではなく、AIが参照するproduct contextを先に整えることにある。

日本企業では、顧客要望が営業・CS・開発・経営に分散し、roadmapの根拠が会議ごとに変わる問題が起きやすい。

airfocus型の導入では、日本語UIだけでなく、稟議・品質保証・部門間合意をproduct contextにどう記録するかが鍵になる。

まず一つのproduct lineでfeedbackとroadmapをつなぎ、効果を測ってから全社展開するのが現実的だ。