サポートがない場合、どのように運営しますか?

すべてのオペレーションの学生はこの問題に遭遇します:

製品機能のサポートが必要な運用方法を思いつくのは大変ですが、さまざまな理由により、タイムリーな応答が得られず、非常に良いと思うアイデアが実行できなかったり、良い機会を逃したりします。

この場合、PM と RD を責めないでください。要件が削減されたのには理由があります。

1. 製品とオペレーションのリズムがずれている

製品には通常、独自のリズムと計画があります。たとえば、APP の機能要件は通常、今後 2 か月間にスケジュールされており、その中にはリリースする必要のあるコア機能があり、最も優先度が高いものになります。このプロセスでは、操作が製品機能と確実に同期され、新しいコア機能のコンテンツやユーザーを準備します。

しかし、製品と業務の調和のとれた連携は、通常、1 つのメインライン上でのみ存在します。また、運用は独自のリズムを持ち、他のいくつかのブランチから開始して、徐々にプロジェクトの進行を促進します。したがって、製品機能に対する需要は必ずあるでしょう。

これらのブランチ要件については、製品の観点からはコア機能よりも優先度が明らかに低くなります。したがって、ブランチ要件は、優先度の高い機能の開発が完了した後、または RD の人員が余剰になった後にのみ検討されます。これは正常かつ合理的であると思います。

2. 需要のメリットが小さいか不確実である

需要は常に相対的に過剰ですが、開発人材は常に相対的に不足しているため、何を満たす必要があるかは製品戦略と最終的な利益によって異なります。

リターンの低い要求は後回しにされるだけでなく、リターンが不確実な要求は大きなリスクを伴うことになります。需要をコントロールするという観点からすると、まずは信頼できる、よく考えられたことをやるというのはごく普通のことです。

運用担当者の考えは通常、「私はこれを計画しており、このような効果を達成するために製品にこのような機能サポートがあることを望みます」というものです。プロジェクトは運用部門によって開始されますが、前提条件は製品の機能であり、これがなければプロジェクトは達成できません。

これは、ほとんど制御できないまま、自分の運命を他人に委ねることに等しいのです。オペレーションが持つべき能力は、現状から最終目標までの複数のパスを提供することです。選択肢が 1 つしかない場合、リスクははるかに大きくなります。失敗の原因となる要因が 1 つしかない場合、プロジェクトは中止されます。

そのため、まずは製品の機能を避け、盲目的に要求せず、製品に依存しすぎないようにしましょう。まずは運用部門で試してみて、メリットが予測可能で十分に大きいことが確認できたら、製品開発を推進します。

運用手段を柔軟かつ合理的に使用して、製品機能を置き換える最も基本的な使用可能な形式を実現し、コアユーザーグループ間で試用して実現可能性の検証を得て、その後の製品機能の開発に備える。これが「運用優先」のコンセプトです。サポートがない場合、まずは運用の準備をする必要があります。

1. オペレーションファーストの利点

1. リスクは制御可能

製品開発を始めると、PMやRDの人員はコストとなり無駄遣いになってしまいます。オンライン化しても効果が出なければ、コストが無駄になってしまいます。したがって、影響をどの程度制御できるかがリスクとなります。

運用優先とは、開発人材に投資する必要はなく、運用手段を通じて試してみることを意味します。実装は完璧ではありませんが、効果はすでに明らかであり、意思決定の信頼できる根拠となります。そのため、製品機能からのサポートがあれば、より効果が高まると推測できます。

2. チャンスをつかむ

オペレーションにおいては、状況をうまく利用することが非常に重要です。うまく活用すれば、半分の労力で 2 倍の成果を達成できます。しかし、ベストタイミングを逃してしまうと、この勢いを活かすことができません。状況を利用して運用上の対策を実行したいが、機能開発の必要性により 2 日間延期された場合、最適な機会を逃したために実行できない可能性があります。チャンスをつかむには、迅速に対応し、最初に行動し、できるだけ早くオンラインにする方法を見つける必要があります。

3. 自信を高める

製品機能の設計・開発段階では、チーム内の各役割はオンライン化後の効果について不確実であり、アイデアが完全に一致することは不可能であるため、異なる意見が出るのは避けられません。そうすると、ブレインストーミングやPKしかできず、決定がスムーズにいかなければ、回り道をすることになります。

最初に運用を行い、いくつかの簡単な試行を行って結果をチームに提示すると、全員が問題を明確に理解し、合意に達しやすくなり、不要なコミュニケーションや試行錯誤のコストが削減されます。

2. オペレーションファーストのデメリット

1. 運営人件費の増加

機能を開発せずにプロジェクトを実行すると、実際には PM と RD の人件費が運用に転嫁されます。運用担当者は、プラットフォームを構築し、ユーザーとより詳細にコミュニケーションを取り、Excel を使用してオフラインでより多くのデータを計算し、製品機能を置き換える静的な特別なページまたは投稿を作成するために、臨時のチームを編成する必要があります。

2. ユーザーエクスペリエンスが悪い

操作を最優先にすると、開発コストを節約し、ホットスポットを見逃さないように迅速に起動できるようになりますが、プレゼンテーション形式が犠牲になり、ユーザーの読み取りや操作のエクスペリエンスが損なわれます。自然の法則に従って、利益と損失があります。これは、メリットとデメリットを比較検討した結果です。

3. 高いレベルの実行力が必要

オペレーションが第一であり、製品機能の役割を担うのはオペレーションであるため、このプロセスではオペレーション担当者に高い実行能力が求められます。これらは小さな詳細のように思えるかもしれませんが、コピーライティング、コミュニケーション方法、プロモーションチャネルなど、すべてを合わせるとプロジェクトの成功または失敗を決定する可能性があります。

上記の 3 点に加えて、もう 1 つ問題が発生する可能性があります。オペレーションファーストの基本は、上司とチームがオペレーションに十分な信頼を寄せ、オペレーションの試みに基づいて結果を分析する意欲を持っていることです。そうでなければ、上で述べたことはすべて無意味になります。

サポートがない場合、オペレーションファーストは概念と意識です。ただし、実装時には次の点に注意する必要があります。

1. クイックトライアル

アイデアの誕生から実現までのプロセスには多くのステップがありますが、最も重要なのは最初の一歩を踏み出すことです。まだ製品が製造されておらず、自分のアイデアを比較的完璧に提示できないという理由だけで行動を拒否すると、勝つ可能性はありません。

2. 柔軟な思考

オペレーションファーストのコンセプトは、実は型破りなアプローチです。従来の考え方や作業フローを変え、遠回りしながら最終目標を達成します。そのため、オペレーターの思考も柔軟で固定観念にとらわれないことが求められます。

また、出発地から終点までは幹線道路または田舎道を通ることができます。具体的な選択は、最終目的地と現在の状況によって異なります。陽関大道は通常の選択であり、歩くのも快適ですが、道路が閉鎖されて使用できない場合は、その利点は無価値になります。逆に田舎道はぬかるんではいるものの、通行止めにならず目的地に早く到着できるので最高です。

問題を解決する方法は常にたくさんあります。理想的な方法は、1 つの方法に固執するのではなく、すべての方法をリストアップして、最も実現可能な方法を選択することです。

3. 実行中は細部に注意を払う

運用手段は製品機能を置き換えるために使用されるため、運用のすべてのステップは製品と同様に、詳細とユーザーエクスペリエンスに注意を払い、コンバージョン率を向上させる必要があります。

製品であれば、各ページのデザインや各操作プロセスの体験などです。運用においては、実行フェーズのコピーライティング、ユーザーとのコミュニケーションスキル、活動ルールの指示などです。これらの非常に詳細な要素は最終的な効果に影響を与えるため、細心の注意を払う必要があります。

4. 試すコアユーザーを選択する

運用が優先する対象ユーザーは、製品内のアクティブなコア ユーザー グループである必要があります。理由：

① 結局、製品機能が実装されていなければ、悪い体験は多かれ少なかれユーザーに害を及ぼすことになります。このグループの人数は少ないため、ユーザーに害を及ぼす影響も抑えられます。

②コアユーザーはインターネット製品の使用に習熟しており、たとえ体験が良くなかったとしても完了率には影響しません。

③コアユーザーは最高のサンプルであり、彼らが検証できれば説得力も増し、より多くのユーザーにコピーすることができます。

理論の後で、いくつかの事例を使って説明してみましょう。

▍ケース1:

あなたが知乎の運営者だとしましょう。李開復、馬化騰、雷軍が全員来たと知ったら、かっこいいページを作って、そこにこれらの大物たちを載せたいという強い願望が湧きますか？下の写真と同様です。

そうすることで、Zhihu のハイライトを強調し、散在する有名人の影響を合理化し、口コミとブランド構築に良い効果をもたらすことができます。

これは単なる静的なページですが、機能開発は必要ありません。UI デザイナーのみが必要です。しかし、運営第一のコンセプトによれば、急いで特別なページを作るのではなく、まずはどのような方法で有名人を推薦するというニーズを満たすことができるか、そしてどれが最も合理的な解決策であるかを検討すべきです。

この問題の結論は下図の通りです。Zhihu は要約トピックを一度もやったことがないようです。知乎は質疑応答サイトとして、知乎ラウンドテーブル、ディスカバリー、トピックスなどの運営ニーズを満たすために、常に独自の質疑応答形式を採用してきました。有名人を推薦したいというニーズも、質疑応答を通じて満たされます。

Zhihu には、あらゆる分野のさまざまなトピックを扱ったこのような要約投稿が多数あります。実は、これは特別なトピックなのですが、質疑応答の形で提示されています。こうしたポストの運用にはそれほど時間がかからず、PM、RD、UIのリソースも消費しません。また、拡張性も高く、複数回の追加や削減も可能です。

さらに重要なのは、ユーザーのために製品のコア機能を強化し、さまざまな遊び方を生み出しながら、ユーザーを常に同じ大きなプール内に留め、外部に転送せず、ニーズを満たすことです。この観点からすると、このアプローチが最も合理的です。

▍ケース2:

コア ユーザー グループまたはコミュニティの運営を担当しており、ユーザーの義務と権限がレベルごとに異なることを期待して、完全なユーザー ライフ サイクル システムを設計したとします。

最も重要なことは、ユーザーがシステムをシンプルかつ明確に理解し、進歩の達成感を感じることができるようにすることです。現在、この効果を実現する最良の方法はゲームです。ゲームは豊富な視覚効果とインタラクティブ効果を提供できるため、アップグレード時にユーザーに大きな影響を与えます。たとえば、次の 2 つの画像の効果は次のとおりです。

しかし、製品形態、開発コスト、サービス重点の制限により、一般的な非ゲームインターネット製品では、このような強力な結果を達成することは困難です。

運用第一のコンセプトに従って、低コストのソリューションを選択できます。静的ページを使用してレベル権限を表示し、ページ デザインとコピーライティングを最適化して、わかりやすく魅力的にし、最も基本的な効果を確保します。次の 2 つの図に示すように:

結論は

「オペレーションファースト」は概念であり考え方です。これは、日常業務の大小さまざまなことに応用できます。オペレーションを学ぶ学生は、常に変化する状況に対応するために、考え方を変えて試してみるとよいでしょう。

モバイルアプリケーション製品プロモーションサービス： APPプロモーションサービス青瓜メディア広告