【反論】製品がクソでも操作はしないといけない

昨日、私は知乎で質問に答えました。「運営側が最もよく言うのは『商品が糞の山であっても、宣伝しなければならない』ですが、この糞の山が常に悪臭を放っていたらどうしますか？」 』

答えは非常に簡潔ですが、もっと言う価値があると思います。しかし、答えを変えるのが面倒なので、ここに書きます。

「たとえ製品がダメでも、オペレーターとして機能させなければならない。」誰が言ったのかは分かりません。しかし、この発言がなされた後、非常に悪い傾向が生まれたようで、上司が方向性を決め、生み出された製品が良かろうが悪かろうが、業務部門はそれを見事に実行させなければならないようでした。

まず最初に、非常に古い事例についてお話ししましょう。

メジャーバージョンの開発に遅延が発生したゲームがありました。そこでプロジェクト チームは、この厄介な段階をスムーズに乗り切るために、過去のバージョンをレビューするイベントを立ち上げ、過去の傑出したメジャー バージョンをすべて取り出して、プレイヤーがそれらをもう一度プレイできるように組織するという 1 つのことを行いました。その結果、かなり良い結果が得られました。

このゲームがLegendなのかLegend Worldなのか思い出せません。

しかし、オペレーターとして、上司や監督者と多かれ少なかれ同様の会話をしたことがあると思います。

ボス：シャオ・ワン、最近のユーザー数/収入はどうですか？

シャオ・ワン：ボス、最近のデータはあまり良くありません。

上司：なぜですか？

王暁：開発の進捗状況/製品設計/…に問題があります。

上司：それで、どうするつもりですか？

王暁：予算を申請して活動を企画することも考えましたが、現状はさまざまな手段を使ってユーザーを集めることができても、維持することができない状況です。

ボス：それなら方法を見つけなければなりません。

Xiao Wang: しかし、現在のバージョンでは、当社の保持と活動をサポートするには不十分です。

ボス: 構いません。あなたには方法があるはずです。私はあなたを信じています。

シャオ・ワン：…

私たちは皆、シャオ・ワンの心の中に百万頭の馬が駆け回っているに違いないことを知っていますが、シャオ・ワンはまだこの骨を噛まなければならないかもしれません。

Legend/Legendary の例について言えば、それは実際には良い例です。結局のところ、歴史上、運用のリソースとして使用できる優れたバージョンや優れたアクティビティが存在するからです。

しかし、そうでない場合はどうなるでしょうか?

それはまるで、梁兄弟にツール製品の操作方法を尋ねるようなものです。

私はいつも彼に、まず機能を良くするように言っています。

製品と業務は切り離せないものです。前提は、全員が共同の力を形成し、お互いを引き離してはならないということです。

この質問に対する別の回答として、Zhihu では国際的なホテルチェーンの CMO の意見を引用しています。

製品が本当に悪い場合は、もちろん製品に問題があるはずです。しかし、平均以上であれば、必ずマーケティングを行ってください。

製品が本当に良くないのであれば、もちろんまずそれを良くしなければなりません。しかし、（業界の）平均を超える場合は、当然マーケティングを行わなければなりません。

インターネット運用と従来のマーケティングは、道筋は異なりますが、目標は同じです。

では、製品が平均レベルに達したかどうかはどうやって判断するのでしょうか?

簡単です。自分を競合他社と比較するのです。

競合他社と比較する場合、機能がどれだけ充実しているかを比較するのではなく、コア機能が 80 点以上に到達できるかどうかを比較します。

コア関数がこの条件を満たしている限り、エッジ関数を使用して違いを明らかにします。

どちらもグループ購入ですが、MeituanとDianpingには違いがありますか?

どちらも漫画アプリですが、BukaとManhua Houseには違いがありますか？

どちらもグルメレビューをしていますが、ChengmiとFanbenには違いがありますか？

答えは明らかです。

しかし、さらに明らかなのは、両者のギャップは製品の品​​質や運用能力の違いだけによって引き起こされるわけではないということです。

10年以上前、タオバオがeBayに挑戦したときを振り返っても、タオバオの運営戦略は正しく、無料サービスを利用してeBayの弱点を攻撃していたものの、タオバオはユーザーの購入信頼の問題を製品側から解決するためにアリペイの支援も必要としていました。そうでなければ、タオバオは販売者を引き付けるために商人向けの無料サービスに頼ることになりますが、買い手はどうでしょうか？

JD.com のような B2C では配達時の支払いも許可されていますが、Taobao が C2C だったときは配達時の支払いはどのように行われていたのでしょうか?次に、UnionPay または銀行ゲートウェイを使用します。

銀行に並んで専門的なオンラインバンキング口座を開設してみると、Alipay がTaobao の運営戦略に製品レベルでどれほどのサポートを提供したかがわかるでしょう。

シャンダには、「製品に欠けているものは、運営が補う」という有名な格言があります。

これについては多くの人が誤解しています。私はこう思います。「あの頃のシャンダは本当にすごかった。たとえ製品が良くなかったとしても、運用においては仕事をうまくこなさなければならないと認めていたのではないだろうか？」

しかし、この文はそう意味するものではありません。この文自体の文脈と意味は次のとおりです。

私たちはゲーム会社としてゲームを運営しており、ゲーム自体は常に進化し続けています。したがって、一部のバージョンでは欠陥や設計上の逸脱が必ず発生します。ゲームの成功の核心は、そのプレイアビリティです。ゲーム自体に大きな欠陥がなくても、あるバージョンに欠陥がある場合は、ゲーム運営者が率先して、活動を組織したり世論を醸成したりするなど、さまざまな運営方法を使用して、ゲームを欠陥の段階から抜けさせ、ユーザーと収益の良好な継続性を維持し、次のバージョンにスムーズに引き継ぐ必要があります。

製品と業務の連携を重視しています！単に糞の山を引っ張り出して手術室に投げ込むのではなく、手術室に悪臭を消してもらい、それを香りに変えてもらい、さらには糞を金に変えてもらいましょう。

製品とオペレーションが両輪で、会社が自転車です。開発を加えると三輪車になり、マーケティングを加えると自動車になります。

片方の車輪が丸く、もう一方が四角い場合、車は動きにくくなります。両方の車輪が丸くても大きさが異なる場合、車は安定して動きません。

ここでの話題は、製品と業務を連携させて、幸せで美しい生活へと向かう方法に直接置き換えられます。

方法はいくつかありますが、実際に実践すると、「尻が頭を決める」という現象が必ず現れます。この現象の発生を減らすことによってのみ、ビジネスはより速く実行できます。ここにいくつかの方法があります。いくつかの方法は人材向けであり、いくつかの方法は製品と操作向けです。それぞれ必要なものを取ることができます。

プロジェクトチームの構造

これは人事部にも会社の上司にも言われます。

私はプロジェクトチーム構造とフラット構造を経験しました。私の個人的な経験では、プロジェクトチーム構造では、コミュニケーションの利便性と、製品、運用、開発の3つの組織間の協力の積極的なレベルが最大化されます。

プロジェクト チーム構造の下では、全員のコミュニケーションとビジネスに対する理解がより同期され、ビジネス目標が一貫しており、共通の KPI を共有しているため、協力しないことは不可能であり、お互いを非難する機会はありません。

フラットであることは悪いことではありませんが、プロダクトマネージャーの調整能力と組織全体のメンバーの自主性に非常に高い要求が課せられます。

フラットな構造では、製品、運用、開発など、それぞれが 1 つのプロジェクトだけではなく複数のプロジェクトに取り組んでいるため、スケジュールの争いや責任の引き継ぎが発生する可能性が高くなり、この時点で協力して作業することが難しくなることがあります。

違った考え方をする

製品を設計する前に、操作の実現可能性を考慮する必要があり、操作時には製品の複雑さを考慮する必要があります。

多くの場合、製品マネージャー、運用マネージャー、開発者は互いに不満を言います。「これはとても簡単なのに、なぜこれをやるのですか?」

自分がやったことがないからといって、他人のことは簡単だと思わないでください。

運用側から提示される小さな要件でも複数のシステムが関係している場合があり、運用側ではそれを十分に理解していない可能性があり、製品管理側でも開発側と同様に理解していない可能性があります。

製品の小さな変更が大きな影響を与える可能性があります。たとえば、Alipay 9.0 ではロック画面のパスワードが削除されました。製品マネージャーは、設計前にユーザーからの否定的なフィードバックを深く理解していない可能性があります。

開発についても同じことが言えますが、今日は開発について話すのではなく、その意味を理解することだけにします。

コミュニケーションを続ける

コミュニケーションを保つことは非常に重要です。多くの人がそう言いますが、多くの人は口先だけで済ませています。

製品マネージャーは、運用部門からのフィードバックに耳を傾け、時間をかけて専門的な観点から結論を導き出す意欲を持つ必要があります。

オペレーションは、運用データからユーザーの潜在的なニーズを鋭く把握し、需要のロジックに留意しながら、プロダクトマネージャーが理解しやすい形で需要ポイントを表現できなければなりません。

バージョン変更に関わる機能ごとに、プロダクト側は運用部門とコミュニケーションを取り、全員がデータを使って自ら語る必要があります。何が変わったのか、なぜ変わったのか、そして、運用部門はどのような対応をする必要があるのか​​、ガイダンス、アナウンス、宥和、活動など、これらのことを事前に伝え、計画を事前に準備しておく必要があります。

メジャー バージョンがリリースされる前に、製品チームと運用チームが一緒にテストに参加し、論理レベル、運用レベル、ユーザー認識レベルからメジャー バージョンへの調整を完全に理解し、すべての準備を行う必要があります。

問題をためらわないでください。

製品、運用、開発、市場のいずれであっても、さまざまな角度から見ると、ビジネス上のリスクがいくつかあることは容易にわかります。

このとき、自分が自分の役割をきちんと果たしていれば、他の人も自然に自分の役割を果たせるだろうと考えないでください。たとえ彼らがうまく果たせなかったとしても、それは私のせいではありません。

これは責任とプロ意識の問題です。

ビジネスに関して見られるリスクを関係者が認識し、評価できるように共有することは非常に重要です。

この点はコミュニケーションの範疇に入れるべきですが、別途言及する価値があると思います。

最後に、もう一度これを強調しておきます。

運用能力を利用して製品の欠陥を隠さないでください。解決策は、問題に直面し、適切な治療法を処方することです。

実際にそのような状況に遭遇し、それを実行しなければならない場合は、オペレーターに次の提案もあります。

1. 小規模な運用アクションを実行し、運用データをリアルタイムで記録および分析します。
2. ユーザーからのフィードバックをタイムリーに取得し、整理して記録します。
3. データ分析結果とユーザーフィードバック結果をまとめ、解決策を提示してリーダーシップに提出します。
4. 事前に緊急時の対応計画を準備してください。問題が発生した場合は、カスタマー サービスと運用部門ができるだけ早く解決する必要があります。

最後に、長文です。

プロモーション活動は、一度にすべて展開することは避けてください。一度に 1 つのチャネル、1 つのユーザー グループで試してみて、規模を自分で制御してください。制御性が鍵となります。

これは、製品が金であろうとゴミであろうと当てはまります。

APP Top Promotion（www.opp2.com）は、モバイルアプリケーションプロモーションの運用方法、経験とスキル、チャネルASO最適化ランキング、アプリマーケティングの乾物共有に焦点を当てた、中国トップのモバイルアプリケーションプロモーションプラットフォームです。公式WeChatパブリックアカウント：appganhuoのフォローを歓迎します。

この記事は（APP Top Promotion）によって編集および公開されています。この記事を転載する場合はTop Promotionの承認が必要であり、この記事へのリンクを添付してください。