RevenueCatのミッションは、開発者がより多くの収益を上げられるよう支援することです。CEOのJacobは、隔週で行われる全社ミーティングのたびに、そのために私たちが取り組むべきことは「勝てるチームをつくること」と「開発者がより多く稼げるようになるプロダクトを作り、届け、販売すること」だと繰り返し伝えています。後者、つまりプロダクトを世に送り出すことを担っているのが、Engineering・Product・Design（EPD）であり、そしてその「勝てるチーム」を支える三本柱の一つが、私たちのプロダクトマネジメント組織です。

現在、RevenueCatのプロダクトマネジメントチームは6名のプロダクトマネージャー（PM）で構成されており、複数のポジションを募集中です。さらに、2026年に向けて今後も採用を進めていく予定です。そこで本記事では、RevenueCatでPMとして働くとはどういうことなのか、ここで成功するPMに求められるもの、そして私たちが直面している課題について、少し詳しくご紹介したいと思います。

RevenueCatのプロダクトが特別である理由

プロダクトマネージャーとして関われるプロダクトには、（あなたの両親も知っているような）誰もが使うコンシューマー向けプロダクトから、特定の業界に詳しくないと理解が難しいニッチなプロダクトまで、さまざまなものがあります。RevenueCatは間違いなく後者に属しますが、それでもなお、非常に特別なプロダクトだと私たちは考えています。

難解な課題、しかし大きなインパクト

RevenueCatの大きな特徴のひとつは、非常に複雑で、やや専門的な課題を解いている点にあります。アプリ内課金のペイロードに含まれる各フィールドが何を意味しているのか、Apple・Google・Stripeそれぞれでどのようなエッジケースが存在するのか、そしてそれらをどう扱うのが最適なのか——これらを正しく理解し、実装するのは複雑で、決して華やかな仕事ではありません。

私たちはよく「痛みを食べて生きている（eat pain for a living）」と言います。つまり、開発者が直面するつらくて厄介なインフラの問題を、私たちが代わりに引き受けて解決している、という意味です。それだけでも、RevenueCatは取り組みがいのある複雑なプロダクトだと言えます。かし、それ以上にこの仕事を意味あるものにしているのは、その先にある理由です。私たちは、アプリ開発者が自分たちのアプリをマネタイズできるよう支援しています。なぜなら……

  • 私たちは、（平均すれば）より多くのソフトウェアが世界にとってプラスになると信じている
  • 人々がソフトウェアを作り、それで生計を立てられるようにすることこそが、人類がより多くのソフトウェアを生み出すための最良の方法だと信じている

こうした考えに共感できるなら、RevenueCatは非常にやりがいのあるプロダクトです。私たちが解決している課題は、何万人もの開発者がアプリをマネタイズする手助けにつながっているからです。

RevenueCatのメンバーの多くは、アプリ開発のバックグラウンドを持っていたり、今でも個人でアプリをApp StoreやGoogle Playに出していたりします。だからこそ、私たちは顧客が直面している課題や、業界にもたらしている価値を実感をもって理解できます。実際に同じ立場を経験してきたからこそ、それができるのです。ここが、私たちのユニークな点でもあります。

お客様に愛されているプロダクト

RevenueCatには、多くのファンがいます。もちろん、すべてのお客様がファンというわけではありません。中にはプロダクトに対して正当な不満を持っている方もいますし、日々の業務で使う単なるツールのひとつとして捉えている方もいます。それでも、「アプリを作る」という自分の好きなことを仕事として成り立たせる手助けをしてくれる存在として、RevenueCatを心から気に入ってくれているお客様が数多くいるのも事実です。

カンファレンスで、わざわざブースを訪れてアプリについて話しかけてくれるお客様に出会ったり、App Growth Annualに参加した人たちから声をかけてもらったりすると、自分たちが携わっているプロダクトが愛されていることを実感できます。また、お客様が初めてのRevenueCat請求書について誇らしげにSNSへ投稿してくれるのを、私たちはよく目にします。これは、無料プランの枠を超え、アプリから実際に収益を得られる段階に到達したことを意味します。お客様がここまで喜んで「お金を払いたい」と思ってくれるプロダクトは、そう多くありません。

こうしたフィードバックは、RevenueCatで働くことを非常にやりがいのあるものにしてくれますし、課題に直面しているお客様をさらに支援したいというモチベーションにもつながっています。

ビジネスと顧客のインセンティブが一致していること

先ほど触れた「最初の請求書」にも関連しますが、RevenueCatとそのビジネスモデルの大きな特長のひとつは、私たちのインセンティブが顧客のインセンティブと完全に一致している点にあります。RevenueCatは、顧客の収益に対する一定割合を料金としていただいています。つまり、お客様が成長すれば私たちも成長し、お客様が収益を上げれば私たちも収益を得るという関係です。

これほど純粋なビジネスモデルは、そう多くありません。私たちは心からお客様の成功を願っています。なぜなら、お客様が成功すれば、私たちも成功するからです。両者のインセンティブが完全に揃っていることで、プロダクトの選択がビジネスとして成り立つかどうかの判断も、非常にシンプルになります。

数年前、私たちは料金体系を簡素化し、無料プランであってもエンタープライズプランであっても、すべての顧客が全機能にアクセスできる形に変更しました。これは、RevenueCatの収益が顧客の収益に比例して伸びる仕組みであるため、規模の大きな顧客ほど自然と多く支払ってくれるからです。また私たちは、成長のためのツールは、すべての開発者が等しく利用できるべきだと考えています。もし安価なプランの小規模開発者にそれらのツールへのアクセスを制限してしまえば、それは顧客の成長機会を奪うだけでなく、結果として私たち自身の成長可能性をも制限してしまうことになります。

さまざまなプロダクトの接点と、それぞれの課題

最後に取り上げたいプロダクトの大きな特徴は、RevenueCatが持つ複数の「接点（サーフェス）」と、それぞれに固有の（技術的な）課題です。

  1. バックエンド：RevenueCatのバックエンドは、お客様にとってのミッションクリティカルなインフラです。お客様の収益ストリームを危険にさらさないために、何よりも信頼性を最優先する必要があります。また、非常に高いスケーラビリティも求められます。私たちのバックエンドは、毎日数十億件規模のAPIリクエストを処理しています。最も利用頻度の高いAPIエンドポイントは完全にキャッシュされていなければならず、そうでなければデータベースは一瞬で破綻してしまうでしょう。
  2. SDKとAPI：SDKやAPIは、開発者がそれらを前提にアプリやバックエンドを構築するため、数年先まで安定して使い続けられる設計である必要があります。特にSDKについては品質のハードルが非常に高く、もし不具合のあるSDKがアプリに組み込まれてしまうと、そのアプリが更新されない限り、長期間にわたって問題が世の中に残り続ける可能性があります。
  3. Webダッシュボード：Webダッシュボードでは、他の領域に比べてはるかに高い自由度でイノベーションや改善を行うことができます。そのため、試行錯誤を素早く回し、変更を非常に迅速にデプロイできる領域でもあります。
  4. コンシューマー向けUI：近年、私たちはコンシューマー向けのUIも積極的に提供しています。Paywall、Customer Center、Webチェックアウト、Webカスタマーポータルなどは、すべてお客様の「その先のユーザー」が利用するものです。そのため、信頼感を与えるための高い完成度と洗練度が求められます。

プロダクトマネジメントへの取り組み方

RevenueCatにおけるプロダクトマネジメントのアプローチは、私たちの価値観とタレントビジョンの両方によって形作られています。RevenueCatのプロダクトマネジメントがどのように機能しているのかを理解するには、まず「何を作るか」をどのように決めているのかから説明する必要があります。

何を作るかを決める

RevenueCatでは、毎年プロダクト戦略を策定します。このプロダクト戦略が、翌年に注力すべき主要なフォーカス領域を定めます。基本的に、年次のプロダクト戦略は前年度の戦略を土台とした進化であり、革命的な転換や急激なピボットになることはほとんどありません。戦略はリーダーシップレベルで決定されますが、その策定プロセスにおいてPMは重要なインプットを提供します。

この戦略に沿って、チーム構成も見直します。RevenueCatでは比較的安定したクロスファンクショナルチームを採用しており、PMはエンジニアリングマネージャー（EM）のもとで働くエンジニアチーム、そしてデザイナーと協働します。

ロードマップは主に四半期ごとのプランニングプロセスで決定されます。このプロセスはこれまで何度も改善を重ねてきましたが、現在は以下のような流れで進めています。

各チームは、PM・EM・デザイナーを代表として、そのチームの優先事項案を提示します。それらはリーダーシップ（CEO、CTO、Head of Product）とともにレビュー・議論されます。この議論の中でロードマップに一定の調整が入ることはありますが、基本的には各チームが自らのロードマップと優先順位にオーナーシップを持ちます。このプロセスにおいて、PMは非常に重要な役割を果たします。多くの場合、PMは自分の担当プロダクト領域について最も俯瞰的な視点を持ち、プロダクト改善を通じてどのような価値を顧客に届けられるかを最も深く理解している存在だからです。

日々、そして週単位の業務においても、PMはEMやデザイナーと密に連携します。少なくとも週1回の定例ミーティングに加え、非同期コミュニケーションを通じてさらに頻繁にやり取りを行います。チーム内での機能の発見（ディスカバリー）と提供（デリバリー）はチーム全体の責任であり、緊密なコラボレーションによって実現されています。

プロダクトマネジメントにおける価値観の体現

前述のとおり、RevenueCatのプロダクトマネジメント組織を形づくるもう一つの要素が、会社としての価値観です。これらはNotionのドキュメントに書かれて放置されているような理念ではありません。日々の仕事の中で意識的に実践し、判断や行動の基準として自分たちを照らし合わせ続けている“生きた精神”です。

カスタマーオブセッション（顧客への徹底したこだわり）

RevenueCatでは、何よりもまず顧客に価値を届けることを最優先に考えています。この考え方は、私たちのプロダクトマネジメントの進め方にも明確に表れています。

  • PMは顧客と頻繁に対話することが期待されています：1対1の会話やユーザーリサーチのインタビューに限らず、サポートチケット、SNS上の投稿、セールスとの会話、顧客と共有しているSlackチャンネル、カンファレンスのブースでの立ち話まで、あらゆる接点が含まれます。
    • PMと顧客の間に壁はありません：より良いプロダクト判断につながるのであれば、誰の許可も必要ありません。必要だと思った会話は、すぐに設定します。
  • 顧客の実体験は、プロダクト判断において非常に強い説得力を持ちます。もちろん、顧客からの要望をすべてそのまま作るわけではありません。しかし、その背後にある本質的なニーズや未解決の課題を見極めることを重視しています。一般的に、わざわざ課題や不満を伝えてくれる顧客は、それだけプロダクトを大切にしている存在です。だからこそ、耳を傾ける価値があると考えています。
  • 問題の大きさに関わらず、顧客の声に向き合います。私たちにとって戦略もロードマップも重要ですが、顧客が遭遇したバグを素早く修正したり、使う上での制約を一つ取り除いたりすることで、「気にかけてもらえている」と感じてもらえることがあります。そうした小さな対応が、疑念を持っていたユーザーをファンに変え、やがてはプロダクトを広めてくれる存在（エバンジェリスト）へと変えていくことも少なくありません。

Always be shipping（常にShip続ける）

「Always be shipping」は、プロダクトマネジメントにおける私たちの姿勢に強く影響しています。具体的には、計画している内容のスコープを常にMVP（最小実用プロダクト）まで削ぎ落とすことを後押しします。その理由は主に次の2つです。

  1. 顧客に価値をより早く届けられること
  2. できるだけ早い段階で、顧客からのフィードバックや検証を得られること
Ship-or-dies（四半期ごとの必達リリース）

本当に「Always be shipping」を実践し、スコープを最小化するための仕組みのひとつが、社内の明確な締切設定です。私たちが採用している主な仕組みが、四半期ごとの全社的な出荷目標である「ship-or-dies」です。

ある取り組みが ship-or-die に指定されると、四半期末までに必ず出荷するために、あらゆる手段を講じます。必要であればリソースを追加し、チームのスピードを上げます。その一方で、多くの場合、痛みを伴うスコープ削減も迫られます。「必須（must-have）」だった要素を「あれば嬉しい（nice-to-have）」に落とす判断をすることもあります（ソフトウェア開発を知っている方なら分かる通り、これは往々にして「結局やらない」ことを意味します）。

興味深いのは、機能をリリースして実際に顧客の手に渡ったあと、最初に寄せられる要望が、後回しにした部分ではないことが多いという点です。むしろ、まったく別の点に関するフィードバックが来ることがよくあります。これは、素早く出荷する価値を如実に示しています。私たち自身も、顧客自身も、機能が実際にプロダクト内で使われ始めるまで、どのように使われるかを正確に予測することはできません。それを知るための唯一確実な方法は、早く出して、その後に改善を重ねることです。

Bias for action（行動バイアス）

「Always be shipping」を支えるもう一つの重要な要素が、行動を優先する姿勢（bias for action）です。私たちは常に、不完全な情報の中で意思決定をしています。完璧な情報が揃うのを待っていたら、何も決められなくなってしまいます。だからこそ、RevenueCatのプロダクトマネージャーには、不確実性がある中でも意思決定を前に進める責任があります。ほとんどの判断は、後から修正することが可能です。終わりのない議論よりも、前進することを選ぶ。話すより、動く（Act, don’t talk）——それが私たちのスタンスです。

Own it（当事者意識を持つ）

RevenueCatでは、オーナーシップを非常に重視しています。プロダクトマネージャーにとってそれは、「誰かの問題」というものは存在しない、という意味です。私たちは一緒に勝ち、一緒に負けます。もし問題に気づいたら、それが自分の担当領域でなくても、何か行動を起こすことが求められます。

もちろん、プロダクトマネージャーがすべての問題を自分で解決しなければならない、ということではありません。ただしPMは、顧客の課題から解決策の設計、技術的なアプローチまでを横断的に理解している立場であることが多く、結果として問題にいち早く気づける存在でもあります。そして、そのこと自体が期待されています。

RevenueCatのプロダクトマネージャーは、高いエージェンシー（主体的に状況を変えられる力）を持っています。私たちは、困難な状況であっても変化を起こせると信じています。PMは、目の前の問題に対処するためにできる限りのことを行い、ときにはそれ以上のこともします（たとえば、より良く解決するために新しい知識を学ぶなど）。コードベースを掘り下げてバグの根本原因を探ったり、データをより深く理解するためにデータウェアハウスへクエリを投げたり、顧客の課題をデバッグするために急きょ通話に入ることもあります。

また、AI支援開発の進展により、プロダクトマネージャー自身がコードベースに直接貢献する場面も、今では珍しくありません。変更内容が比較的シンプルな場合、エンジニアにチケットを切って対応してもらうよりも、PMが Cursor や Claude Code を使って自ら修正し、レビューを経てそのまま出荷するほうが、はるかに速いことも多くあります。

まとめると：やることはたくさんあります。そして、これはまさに 全員総出 の仕事です。

Balance（バランス）

私たちのバランスという価値観は、おそらく最も誤解されやすいものです。これは「手を抜く」という意味ではありません（むしろその逆で、RevenueCatはいまもスタートアップであり、ここでの仕事は意図的にハードです）。私たちは、スピードを維持し続けてこそ勝てると考えています。

一方で、このバリューは「速く進むこと」と「燃え尽きること」のあいだには、非常に細い境界線があることも思い出させてくれます。意欲の高い人たちとチームを組み、面白く価値のある課題に取り組めているとき、ハードワークは大きなやりがいになります。プロダクトマネージャーは、チームのモチベーションや関心を保つうえで重要な役割を担うことが多く、解いている課題と顧客へのインパクトを結びつけて伝える責任があります。たとえば、顧客からのポジティブな声（いわゆる “good feels”）を共有したり、周囲に伝播するようなワクワク感を示したりすることです。

また、Balance には、他者への共感や思いやり、そして互いを一人の人間として尊重し合える、信頼に基づいたチーム環境を築くことも含まれています。プロダクトマネージャーは、自然とリーダー的な立場に立つことが多いため、こうした振る舞いを自ら体現し、周囲に広げていく上で重要な役割を果たします。

RevenueCatのタレント・ビジョン

RevenueCatのタレント・ビジョンは、高い能力を持つメンバーによる「勝てるチーム」をつくることです。そのため、すべてのチームメンバーに高い基準を設けており、採用やパフォーマンスマネジメントのプロセスを通じて、その基準を維持しています。

この考え方は、私たちのプロダクトマネジメントの進め方にもいくつかの影響を与えています。まず、RevenueCatのチームは、比較的シニアでプロダクト志向のエンジニアやエンジニアリングマネージャーで構成されています。そのため、RevenueCatのPMは、プロジェクト管理の細部に深く入り込んだり、非常に詳細なチケットを作成したりする必要はあまりありません。むしろ、必要な背景情報や課題空間の理解を的確に伝えることが求められます。そうすることで、エンジニアがPMの意思決定によってボトルネックになることなく、スムーズに開発を進められるようになります。

また、このタレント・ビジョンは、チームが比較的リーンであることも意味しています。私たちは、才能の基準が低い大規模チームよりも、高い能力を持つ少人数のチームの方が、はるかに速く動けると信じています。

プロダクトマネジメント組織が直面している主な課題

ここでは、RevenueCatのプロダクトマネージャーとして私たちが直面している主な課題を紹介します。

やるべきことが多すぎて、時間が足りない

これはスタートアップに共通する典型的な課題かもしれませんが、RevenueCatでもまさにそのとおりです。私たちは常に、取り組みたいアイデアや解決すべき顧客課題を、実際に対応できるキャパシティ以上に抱えています。そのため、会社としても、各チームとしても、そしてPM個人としても、適切に優先順位を付け、その判断を市場、顧客、社内ステークホルダーにきちんと伝える必要があります。この課題に対しては、戦略策定とプランニングのプロセスを通じて、常に最もインパクトの大きい機会に集中できるようにしています。

カスタマー・オブセッションと戦略的優先度のバランス

上記の優先順位付けとも密接に関係していますが、私たちはしばしば、「顧客第一主義」と「戦略的な優先事項」という2つの力に引っ張られます。戦略的な取り組みは成果が出るまでに時間がかかることが多い一方で、カスタマー・オブセッションという価値観は、比較的小さな顧客リクエストにも緊急性を感じさせます。どちらか一方に極端に寄りすぎるのは望ましくありません。長期的な戦略を優先するあまり顧客の声を後回しにすれば、反応が鈍いと見なされ、これまで築いてきた顧客からの信頼や愛着を失うリスクがあります。一方で、顧客要望への対応だけを最優先してしまうと、大きな勝負に出る機会や、市場の変化に乗るチャンス、プロダクトや会社の次の成長を切り開く機会を逃してしまいます。

成長は、調整コストの増加を意味する

RevenueCatはここ数年、非常に良い成長曲線を描いてきました。チームの成長は売上の伸びほど速くはありませんが（これも「勝てるチーム」というタレント・ビジョンの一部です）、それでも確実に拡大しており、今後も成長を続ける予定です。EPD（Engineering, Product & Design）チームが大きくなると、プロダクト改善のためのキャパシティは増えますが、その一方で調整や連携に必要なコストも増加します。エンジニアリングチームを2倍にしたからといって、出荷できる変更が単純に2倍になるわけではありません。一部のリソースは、必ず調整作業に使われるからです。また、チームが増えることで、プロダクトの各所で一貫性のない体験が生まれるリスクも高まり、それを防ぐためにもさらなる調整が必要になります。

マルチプロダクト企業への転換

私たちが直面している最大の戦略的課題は、シングルプロダクトの会社からマルチプロダクトの会社へと移行することです。RevenueCatは長年にわたり、「アプリにアプリ内課金を実装するための最良の方法」であり続けてきました。その結果、現在では多くのサブスクリプションアプリが、立ち上げ時からRevenueCatを利用しています。しかし、新規サブスクリプションアプリの市場自体には限りがあります。

今後も成長を続けるためには、既存のターゲット市場に対してより多くの価値を提供することと、現在のRevenueCatプロダクトが必ずしも最適ではない顧客にもリーチできるようにすることの両方が必要です。そのためには、マルチプロダクト企業になることが不可欠です。まったく新しいプロダクトを追加するか、既存プロダクトを分解して個別に販売できる形にするか、その両方を検討しています。

これには、プロダクト意思決定のプロセスそのものを根本的に見直す必要があります。プラットフォームの一部だけを使う場合でも意味のある体験を設計し、適切な価格設定や課金モデルを整え、正しいプロダクトにたどり着き、セットアップできるオンボーディングフローを考えなければなりません。

この取り組みはまだ始まったばかりで、当面の間、私たちを忙しくさせ続けることになるでしょう。

RevenueCatにおける「良いPM」とは

ここまで読んでくれましたか？ では、RevenueCatでプロダクトマネージャーとして活躍できる人の特徴について見ていきましょう。もしかすると、あなた自身が当てはまるかもしれませんし、思い当たる誰かがいるかもしれません。

  • マネージャーではなく、ビルダー：RevenueCatのPMは、自分たちを「プロダクトを作る人」だと捉えています。バックログを管理したり、ステークホルダーの調整に追われたりするのが役割ではありません。チームと協働し、最善の解決策を提案し、チームがより速く前に進めるよう支援します。
  • ミッショナリー：私たちのミッションは「開発者がより多くの収益を得られるようにすること」です。PMはこのミッションを心から受け入れています。より多くのソフトウェアが世界にとって良いものであり、開発者が成功すれば、より多くのソフトウェアが生まれると信じているからこそ、私たちは顧客に徹底的に向き合います。
  • 徹底したオーナーシップ：RevenueCatのPMは、顧客の課題を解決し、プロダクトを成功させるために必要なことはすべてやります。誰かを責めたり、責任を転嫁したり、失敗を受け入れて終わりにすることはありません。孤軍奮闘するのではなく、真のチームメンバーとして責任を分かち合いながら、前に進む道を見つけます。
  • 不完全な情報でも決断できる：スピード感のあるスタートアップでは、完璧な情報がそろうことはほとんどありません。RevenueCatのPMは、意思決定に十分な最低限の情報を集め、素早く判断します。現時点のデータに基づいて行動し、チームを巻き込みながら前進します。そして、新しい情報が入れば、必要に応じて方向転換する柔軟さも持ち合わせています。
  • 深い技術的理解：RevenueCatは複数のペルソナに向き合うプロダクトですが、その本質は「開発者向けツール」です。そのためPMには、API、分散システム、SDKの制約、データモデルといった技術的な意思決定を理解し、説明し、評価できるレベルの深い技術知識が求められます。
  • 非同期コミュニケーションに強い：RevenueCatはグローバルなフルリモートチームです。そのためPMは、ドキュメント、Loom、FigJamなどを使った明確で分かりやすい非同期コミュニケーションに長けています。同時に、チームの認識を揃えるために、いつリアルタイムの会話に切り替えるべきかも理解しています。

採用中です！

RevenueCatでは、プロダクトマネジメントチームをほぼ継続的に拡大しています。意味のあるインパクトを持つ難しい課題を解くことが好きな「ビルダー」で、何万人もの開発者が自分の好きなこと（アプリ開発）で生計を立てられるよう支援したいと考えている方であれば、ぜひお話ししたいです。
現在募集中のポジションは、キャリアページからご確認ください！