インターネット上で最も希少なオペレーターになりたい場合は、次の 10 ステップに従ってください。

筆者の意見では、本当の意味での製品操作は、インターネット全体の中では比較的少ないはずです。では、どうすれば希少オペレーターになれるのでしょうか?著者はこれらの 10 のステップを示しています。

コンテンツ運用、ユーザー運用、チャンネル運用、イベント運用、ニューメディア運用に関する記事はネット上に多くありますが、プロダクト運用に関する議論はほとんどありません。これには2つの理由があるはずです。まず、プロダクトオペレーションに携わる人は多くありません。プロダクトマネージャーと非常に似た仕事であり、ほとんどの人は特定の方向へのオペレーションを行っているはずです。例えば、公開アカウントを運用する場合には、いかに質の高い記事を書くか、いかにフォロワーを増やすかを考えることになりますが、プロダクト運用となると、公開アカウントのオープンインターフェース機能をベースに、いかに機能やプロダクトとして展開していくかを考えることになります。

一方、コンテンツが豊富なプロダクト（ eコマース、コミュニティ、メディア）の運用業務に携わっている場合は、それに接する機会が多いです。ただし、プロダクト運用に配属されるかどうかは、実力とかなりの運次第です。ツール型のプロダクトであれば、運用という概念は基本的にありません。そのため、一般的には、本当の意味でのプロダクト運用は、インターネット全体で見ても比較的少ないはずです。

私たちは、新しい物事に直面すると、それを自分の慣れ親しんだ経験や思考の枠組みに組み込むために、既存の思考論理に従ってそれを定義する傾向があります。まず最初に、オペレーションに携わって 5 年未満の実務者として、現時点では製品オペレーションについて簡潔かつ正確な定義を与えることができないことを明確にしておかなければなりません。本当に製品運用を定義しなければならないとしたら、私の理解では、製品マネージャーが特定の機能をゼロから作成した後、コンテンツ、ユーザー、アクティビティ、チャネル運用、製品のアップグレードなど、その機能に関連するすべての作業に責任を負う必要があることを意味します。

上記の定義は、個人的な経験と思考に基づいた段階的な要約です。その後、Tieba の投稿読み取り (Tieba クライアントに付属するコンテンツベースの機能) に取り組んでいたときに、コンテンツベースの製品運用に偶然触れました。プロセス全体の価値ある部分を 10 のステップに分解し、ここで共有しました。Facebook が提唱しているように、完璧よりも完了が重要です。製品運用について、ぜひご意見をお聞かせください。

01. コンテンツの位置付け

機能をゼロから作成するプロセスでは、製品オペレーションは製品マネージャーと連携して、新しいバージョンのリリース時に新しい機能がスムーズに開始されるようにする必要があります。

製品運用のこの段階では、コンテンツレベルで製品自身のポジショニングを組み合わせて機能のユーザーポジショニングを決定し、ユーザーの好みに基づいて機能のコンテンツポジショニングを決定し、コンテンツポジショニングに基づいてコンテンツ更新メカニズムを確認し、自動更新か手動更新か、更新メカニズムとレビューおよびリリースメカニズムがあるかどうかを確認します。同時に、グレースケール期間中の機能のコンテンツ読み取りとインタラクション量の分析を通じて、コンテンツの位置付けと更新リズムをさらに最適化できます。

機能レベルでは、頻繁に使用する MIS バックエンドに重点が置かれます。広告システムの製品運用では、製品開発フェーズで広告配信後のバックエンドを担当します。コンテンツベースの機能では、コンテンツの編集と公開のバックエンドに重点が置かれます。

02. ターゲット分解

機能が起動した後、製品マネージャーがあなたに「責任を転嫁」した場合、おめでとうございます。あなたは製品運用段階に入りました。あなたはこの機能に関連するすべての作業を担当することになります。あなた自身の運用作業に加えて、機能の反復、機能の日常的な活動、機能の顧客サービスなどもあります...あなたの運用能力とグローバルな思考能力は大幅に向上します。

プロダクトの運用を始める前に、プロジェクトの背景や機能の目的、自身の運用思考を踏まえた上で計画を立てられる必要があります。目的を達成するために、データを直接的または間接的に改善するには何ができるのか、どのような道筋で物事を進めるのか、どの部門のサポートが必要なのか、そして、それがうまくできているかどうかを測る指標は何か、などについてしっかりと考えましょう。

03.データ分析

機能の目標と実装パスを明確にした後、運用ではデータを通じて機能の最も現実的な状態を把握する必要があります。機能の初期段階では、毎日データをレポートし、毎週機能に関するデータ分析レポートを作成する必要があります。データ分析により、運用がより充実し、定量化可能な価値の出力を毎日確認できるようになります。データ分析作業には、リリース前のデータ展開、主要なパスの追跡、その後の操作におけるデータの継続的な注意と分析が含まれます。機能データの現状把握は手段であり、データを通じて機能最適化のニーズを提案することが本業務の核心です。例えば、あるコンテンツに対する「いいね！」の数が比較的少ないことがわかった場合、コンテンツの情報フローに「いいね！」ボタンを配置したり、「いいね！」の件数を増幅したりするなどの最適化案を提案することができます。

余談ですが、データ分析はどんな状況でも非常に重要です。純粋なコンテンツ閲覧機能を持つ製品を運営している場合、起業家としてはデータを使用してモデルを証明し、資金調達を行う必要があります。ビジネスインキュベーションプロジェクトの場合は、この機能のコアKPIに対する価値、つまり作成したコンテンツの必要性を証明する必要があります。

04. 競合製品の調査

機能データに基づいて主要な最適化の方向性を決定した後、通常は、機能の特定の最適化計画をさらにサポートして実装するために製品調査が行われます。私は、製品調査をユーザー調査と競合他社調査として理解しています。

ユーザー調査は主に、最適化の方向性に関する調査アンケートを設定し、ユーザーからのフィードバックを得ることに重点を置いており、定量的アンケートや定性的なインタビューを通じて実施できます。条件を満たした企業はユーザー調査を実施し、ユーザーエクスペリエンス部門と協力することができますが、調査の背景やユーザーサンプルの要件を運営側に通知する必要があります。

特定の機能に関する研究レポートの概要

競合他社の調査は、主に機能最適化の具体的な実施方法を研究し、さらに最適化したい機能のどのインタラクションがインターネット業界でより良く行われているか、どのように行われているか、そして参考にする価値のあるポイントは何かを調べることです。担当する機能が投稿の閲覧などのコンテンツ閲覧機能である場合は、Douban Yike、Zhihu Daily、Guokr Selection、NetEase News Client などのコンテンツ製品をもっと勉強することができます。競合製品分析を効率的に行う方法については、公式アカウント「Product Rookies」にキーワード「競合」を返信してご覧ください。

Douban Yikeコンテンツフォーマット

05. 機能的MRD

製品要件ドキュメントの作成は、運用部門が設計者や技術者と効率的にコミュニケーションをとるための一般的な手段です。通常、機能プロトタイプを描く作業はプロダクトマネージャーが行うべきですが、プロダクトオペレーションは機能の第一責任者であるため、プロトタイプを描く作業は自分で行う必要があります。

機能 MRD を作成する場合、製品マネージャーは Axure RP を使用してワイヤーフレームを描画することを好みます。もちろん、運用マネージャーもこのツールを使用できると最適です。そうでない場合は、グラフィック要素が多く、いくつかのインタラクションを設定できる PPT を使用することをお勧めします。また、機能MRDは企業ごとに書き方が異なります。私がよく使う書き方を参考までにシェアします。

機能的 MRD 作成テンプレート

06. グレースケールリリース

大規模なインターネット製品の場合、運営側では通常、機能の最適化とリリース時にグレースケールのリリース方式を採用しています。製品のリリースプロセスは一度にすべて達成されるのではなく、社内ユーザー→より忠実なシードユーザー→より広範囲のアクティブユーザー→すべてのユーザーというように、ユーザーの範囲を徐々に拡大していきます。このプロセスでは、運用担当者がベータ版のユーザー行動データに基づいて、製品関連の機能を迅速に改善します。

オペレーターがグレースケールリリースを行う際には、このバージョンの機能の目的に応じて、グレースケールユーザーのスクリーニング、データの展開、データ分析、テストレポートなどの一連のタスクを完了する必要があります。 もちろん、オペレーターがこれらのタスクを効率的に完了できるように、グレースケールリリースツールを提供する開発者プラットフォームが現在数多くあります。

開発プラットフォームが提供するグレースケールテストツール

07. 製品リリース

これは、製品オペレーターが最も見落としがちなリンクです。チャネルプロモーションを経験したことのないオペレーターは、最も基本的なオンサイトプロモーションしか行っていない可能性があり、新バージョンアップデートのプロモーションすら行っていない可能性があります。

製品運用の正しいリリース計画には、「アプリストアでの最初のリリース、 ASO 、 SEOの計画と実装、業界ニュースリリースのリリース」を含める必要があります。このリリースノードを組み合わせて、新バージョンの更新とアプリストアでのコメントの抽選を計画することもできます。これにより、古いユーザーグループの間で新バージョンのカバー率が向上し、アプリ製品のレビューが最適化されます。

08. コンテンツ基準

投稿を読むなどのコンテンツベースの機能など、ほとんどの機能は、最初はその機能の大まかな分類がされると思います。ただし、機能が製品に定着した後は、通常、地理的な場所、スマートな推奨、最も多くのインタラクション、最も多くのいいね、タグ ラベルなどに基づいて、オペレーションによって提供される最新または最もホットな、より特徴的なサービスの表示方法など、機能サービスの表示ロジックを再編成し始める必要があります。

ユーザーがコンテンツを作成するUGC機能を運用している場合、新しいアプリを使用するときによく表示されるガイダンスポップアップレイヤーである、製品レベルでコンテンツ共有ガイダンスの仕組みを構築する必要があります。 この作業の側面については、Zhihu または Baidu Encyclopedia を参照してユーザーをガイドし、ポイントの報酬と罰則のシナリオを構築できます。 Zhihu は、新規ユーザーがコミュニティを素早く理解し、操作方法を学び、大まかなコミュニティ コンテンツの標準を習得できるように、新規ユーザー向けのガイドとして「Zhihu ガイド」を提供しています。百科事典は、新規ユーザー向けのオリエンテーションをゲームのような小さなタスクに変え、ビデオやテキストを通じて新規ユーザーをガイドします。

百度百科事典の新しいユーザーガイド

09. イベント企画

私の意見では、アクティビティはデータを改善し、機能の最適化の方向性を短期的に検証する最良の方法です。たとえば、ポイントがユーザーの共有を効果的に刺激できるかどうかを検証したい場合は、特典を配布するアクティビティを計画するだけで、物質的なインセンティブが製品のコンテンツ共有量を効果的に増やせるかどうかを検証できます。

イベントの企画についてはあまり語りませんが、重要なのは、事前に準備して、イベント専用のツールを構築することです。これには、特別なコンテンツ テンプレート ツール (技術的なスケジュールがない場合は、Sohu Quick Site、ih5 などのツールが推奨されます) や、投票/PK/オーディオ/抽選/弾幕などのインタラクティブ ツールが含まれます。

10. プロジェクトレポート

機能は基本的にいくつかの異なる運用期間に分けられ、一般的には「検査期間 - 参入期間 - 成長期間 - 高度成長期間 - 成熟期間 - 衰退期間」に分けられます。各期間には異なる重点があり、機能の全体的な運用状況を上位機関に報告する必要があります。

プロジェクトの信頼性が高く、データポイントが多く、プラットフォームデータ分析が頻繁に行われ、「プロジェクトの背景、プロジェクトの目標、プロジェクトデータ、運用分析、経験の再利用、フォローアップ計画」というプロジェクト概要文書の作成ルーチンが使用されている場合、リーダーの突然のプロジェクト全体報告に遭遇しても、基本的に問題はありません。

ここでは、レポートのプロジェクト データの部分に焦点を当てます。レポートの焦点として、プロジェクト データはコア データと周辺データ (コンテンツ データ、ユーザー データ、さまざまな次元の比較データを含む) に分けられます。

コアデータを報告する前に、リーダーが機能の運用状況を迅速に把握できるように、プロジェクト状況の概要を添付する必要があります。この部分の喜びのアプローチでは、誰もがよく知っている特定の製品のベンチマーク方法を使用します。たとえば、小学校教育製品情報共有プロジェクトに取り組んでいる場合、レポートでは次のデータを使用して、「教育製品情報の共有とユーザー消費はどちらもかなり大きく、製品には20,000人以上の毎日のアクティブユーザーがおり、ユーザーは1日平均200の高品質の製品コンテンツを共有しています。プロジェクト全体の1人あたりの閲覧PVは10で、1人あたりの共有量は7 PVです。K12分野で購入する価値のあるものになる可能性が非常に高いです。」と開くことができます。

上記は、小賢が自身の運用経験に基づいてまとめた製品運用作業の10ステップです。機能が異なれば必要な作業も異なり、カバーされていないタスクもあります。たとえば、 O2O製品運用では、コンテンツベースの製品運用よりもマーチャント管理が1つ多くなります。

一般的に、製品運用は、単一方向の運用よりも包括的な運用マインドセットが必要です。同時に、多方向の運用を管理する必要があり、やるべきことも多くなります。道に迷いたくないのであれば、製品運用は機能のコア指標と運用目的を常に覚えておく必要があります（たとえば、投稿を読むという運用の目的は、新規ユーザーの維持率を高めることであり、コア指標は製品全体の新規ユーザーの維持データと投稿を読むという新規ユーザーの維持データです）。