月曜の朝。あなたは5人体制のスタジオで、12の製品が稼働中。3つはクラッシュアラートを吐き出し、いずれ目を通さなければならない。2つは週末にリリースされた競合アプリのアップデートにより、リテンションを失いつつある。1つは金曜日までにストア掲載を更新しないと、特集枠から外れてしまう。47件の顧客レビューが待っている。ゲーム4への支出はなぜか30%増加している。Burakはロードマップ会議について尋ねている。チームの誰かがゲーム7について尋ねている。あなたの週は8分後に始まる。
これが ポートフォリオ運用です。誰もそのプレイブックを書き記していません。
ほとんどの運用アドバイスは、間違った形態のために書かれている
運用の規範（書籍、スレッド、LinkedInの投稿）は、あなたが1つのことを運営していることを前提としています。成長責任者を雇う。ファネルダッシュボードを設定する。毎週の製品会議を実施する。北極星指標を選ぶ。
そのどれもが、ポートフォリオに触れると生き残りません。
5人体制で12の製品を運営するスタジオは、小規模な企業ではありません。スケールアップしたスタートアップでもありません。それは全く異なる運用形態です。少ない人員、多い製品数、製品ごとの浅いコンテキスト、豊富な製品横断的なコンテキスト。人員の計算上、各製品に成長責任者を雇うことはできません。製品数の計算上、各製品に毎週の製品会議を実施することはできません。どちらの形態のために構築されたプレイブックも、無理が生じ破綻します。
ほとんどのスタジオは、5つ目の製品あたりでこれに気づきます。最初の3つは管理可能だと感じました。4つ目は大変でした。5つ目で明確になりました。ここまで連れてきてくれたフレームワークでは、10個には到達できないと。
この形態にはまだ定まった名前がありません。一部の運用者は「ポートフォリオ」と呼びます。一部は「持株会社」と呼びます。ほとんどは単に「たくさんのものを運営している」と呼びます。何と呼ぼうと、その運用規律は独自のものであり（ポートフォリオ運用）、そのほとんどは、書く時間のない運用者の頭の中に存在するため、書き記されていません。
この投稿は、それを書き始める試みです。具体的には、単一製品のプレイブックが 複数製品スタジオで失敗する5つの点と、その代わりに何をすべきか。
5つの失敗モード
1. 手動スキャンが月曜の朝を食い潰す
最初の失敗は発見が最も容易で、修正が最も困難です。毎朝、チームの誰かがすべての製品をスキャンします。クラッシュダッシュボード。アプリストアのレビュー。支出レポート。エンゲージメントパネル。顧客サポートの受信箱。
製品が1つの場合、これは創業者の仕事で30分かかります。製品が5つの場合でも、創業者の仕事で3時間かかります。製品が12個になると、もはや行われなくなり、スタジオは顧客チケットで本当の火災に気づくことになります。
手動でのポートフォリオスキャンはスケールしません。オペレーターが下手だからではなく、作業が製品数に対して本質的に線形であり、オペレーターは一人だからです。ダッシュボードで時間を稼ぐことはできますが、12個の製品アラートのうちどれが本当に重要かを知る必要性から逃れることはできません。
必要な作業は シグナルのトリアージであり、オペレーターがダッシュボードを開く前に行われる必要があり、後ではありません。
2. 製品間で教訓が失われる
複数の製品を運営して3ヶ月も経つと、同じ苦痛な会話を2度することになります。チームの誰かがGame 4で問題を提起し、経験豊富なチームメイトが「App 2で去年の3月にこれを解決した」と言います。そして誰もが、その解決策が実際に何だったのか思い出せないことに気づきます。
単一製品の組織は、Wikiやランブックでこれを解決します。ポートフォリオスタジオはできません。なぜなら、関連する教訓が別の製品のコンテキストに埋もれているからです。Game 4のランブックにはそれがありません。App 2のランブックにはありますが、App 2のリードだけがそのランブックを読みます。製品横断的な記憶は、誰の頭の中にも確実に存在しません。
解決策は、より大きなWikiではありません。解決策は 組織的記憶 であり、製品ごとに構造化されつつも、製品間で読み取り可能であることです。Game 4の問題とApp 2の解決策は、誰かが再フォーマットすることなく、デフォルトで同じ形式で同じ場所にある必要があります。
3. 意思決定の機会が失われる
すべてのマルチプロダクトスタジオは同じバックログを抱えています。先週の火曜日に下されるべきだったが、下されなかった決定です。数週間前に調整されるべきだったGame 4の入札フロア。App 7のストアリスティングの更新。誰もフォークするのを覚えていなかったGame 11のリテンションテスト。
スタジオは判断力に欠けているわけではありません。機会に欠けているのです。コンテキストが準備されていれば10分で済むはずの電話が、準備に2時間かかるため、先延ばしにされます。何度も先延ばしにされると、それは行われなくなります。
必要なのは 意思決定のサイクルです。各製品について、特定の決定が予測可能なリズムで、コンテキストがすでに準備された状態で行われることを保証するものです。会議のスケジュールではなく、その瞬間が準備された状態で訪れるという契約です。
4. 部署横断的なコンテキストの断片化
小規模なスタジオでは、「部署横断的」とは異なるチームを意味しません。同じ3人が3つの役割を兼任していることを意味します。広告を運用している人がストアリスティングも運用し、ライブオペレーションも運用しています。彼らは連携が取れていないのではなく、自分自身と同期が取れていないのです。
問題は運用インターフェースです。広告費は一つのツールにあります。ストアリスティングは別のツールにあります。ライブオペレーションのドキュメントは三つ目のツールにあります。それぞれが同じ日の同じ製品について異なるストーリーを語ります。オペレーターだけが、それらが同じ製品であることを認識しています。
部門横断的なコンテキスト ポートフォリオスタジオでは、より良い会議が重要なのではありません。同じ人が3つの異なる役割から読み取れる、製品ごとの単一の記録が重要です。「今日のGame 4はどうなっている？」という質問に対しては、組み立てるべき3つの答えではなく、読むべき1つの答えがあるべきです。
5. グロースループが静かに衰退する
ポートフォリオ運用で最も費用のかかる失敗は、誰も気づかないものです。グロースループがリリースされ、2週間機能した後、停滞します。最初のコホートの後にフォークされるはずだったリテンションテストは、決してフォークされません。3月に調整された収益化曲線は、6月までにデフォルトに戻ります。誰も間違っていません。誰も何も間違ったことをしていません。ループが維持されていないだけです。
単一製品の運用では、創業者が覚えています。ポートフォリオ運用では、創業者は他に11の事を覚える必要があります。
A 自律的な成長ループ とは、システムがその状態を認識し続けるものです。ループが衰退しているとき、前提条件が変わったとき、分岐が必要なときにそれが表面化します。オペレーターは依然として決定を下します。システムは、決定を下すべき瞬間が過ぎ去らないようにします。
実際に機能するもの
5つの失敗モードに対する修正策は、5つの別々のツールではありません。それらは、異なる表面に適用された同じ根本的な変化です。12製品を超えて存続しているほとんどのマルチプロダクトスタジオは、通常は苦痛を伴いながら、このバージョンのいくつかを独自に発見しています。以下にその短縮版を示します。
1. 単位は会社ではなく、製品です。
ほとんどの運用ツールは、デフォルトで会社ワークスペースを使用します。つまり、1つのナレッジベース、1つのチャネル、1つのダッシュボードです。マルチプロダクトスタジオにとって、これは誤ったデフォルトです。記憶の標準的な単位は製品でなければなりません。ゲーム4は独自の決定記録、独自のシグナルログ、独自のコンテキストストアを持ちます。ポートフォリオは必要に応じてそれらを横断して読み取りますが、単位は製品です。
これが 製品ごとの記憶。当たり前のように聞こえますが、既製のツールでこれをデフォルトとするものはほとんどありません。
2. 決定はドキュメントではなく、第一級の存在です。
ほとんどのツールは、何が作られたかを記録します。必要なのは、なぜ作られたのか、どのようなシグナルがその決定を促したのか、何が検討され、却下されたのかも記録することです。A 決定記録 はドキュメントではありません。それは、オペレーターが忘れても残る構造化された成果物です。
テスト：3ヶ月後、新しいチームメイトがゲーム4の記録を読んで、当時のオペレーターの推論を再構築できるか？もしできるなら、その記録は役割を果たしています。もしできないなら、そのスタジオは同じ教訓を二度学ぶことになります。
3. キャパシティよりもケイデンス。
ポートフォリオ運用は、人材を雇うだけでは解決しません。必要な決定が、スタジオが維持できるリズムで確実に行われるようにすることで解決します。 決定ケイデンス が契約です。スタジオの仕事はそれを尊重することです。
4. 汎用アシスタントではなく、専門エージェント。
AIツールが登場したとき、あらゆることについて1人の汎用アシスタントに尋ねたいという誘惑がありました。しかし、実際のスタジオでは月曜日の朝を乗り切れませんでした。機能するのは 専門エージェントです。運用機能ごとに1人ずつ配置され、スコープされた記憶と単一の仕事を持ちます。クラッシュレポートを監視するエージェントはコピーライティングを試みません。ストアリスティングを監視するエージェントは収益化の変更を提案しません。
スコープは信頼メカニズムです。1つの機能の完全な記憶を持つ専門エージェントは、監査、調整、および逆転が可能です。すべてを扱う汎用エージェントにはそれができません。
5. ポートフォリオ全体にわたる1つの運用AI COO。
上記の5つの要素は、同じ場所に存在して初めて機能します。そうでなければ、12個のダッシュボードを12個のより良いダッシュボードに置き換えただけです。この作業の目的は 一つの運用思考です。つまり、すべての製品を読み取る同じ頭脳、すべてのラインで機能する同じエージェント、そしてオペレーターが唯一の統合レイヤーではなくなることです。
Qualiaに関する注記
これは、Qualiaを構築する上でのプレイブックです。この製品は、 AI COO として、2〜10人の小規模スタジオが3〜20のライブゲームやアプリを運営するポートフォリオオペレーター向けです。アーキテクチャは、製品ごとのメモリと専門エージェント、そして 共有ポートフォリオブレインで構成されています。デフォルトは human-in-the-loopです。私たちが評価する指標は オペレーターの退屈度です。Qualiaの画面を見て創業者が退屈するなら、その画面は間違っています。
私たちはまだ初期段階です。顧客は2社。セットアップは30分。もしあなたがマルチプロダクトスタジオを運営していて、上記のいずれかの失敗モードがあなたの週を蝕んでいるなら、ぜひお話ししましょう。 デモを予約.
これが未執筆である理由
ほとんどのプレイブックは、一つのものをスケールすることを前提としています。ポートフォリオオペレーターは、多様性に対してスケールしています。つまり、より多くの製品、同じ人員、製品ごとのSlackなし。作業は異なります。だからツールも異ならなければなりません。そしてプレイブックも。
もし私たちが見落としているこのバージョンのものを見つけたら、ぜひ教えてください。
執筆者 Doğan Turan、Qualia 共同創設者 ·