プロダクトマネージャーのトレーニングについての考えを共有します

1. プロダクトマネージャーは常に失敗から学ぶ必要がある

2022年、張小龍はWeChatビデオライブ放送に出演しました。今回は生放送で交流するよう招待されました。司会の Pan Luan 氏と Geek の Park Zhang Peng 氏は次のように質問しました。「プロダクト マネージャーはトレーニングできると思いますか?」

張小龍：プロダクトマネージャーは訓練を受けることができないという結論に達しました

「プロダクトマネージャーになるということは、経験を積むプロセスです。能力を開発するには、常に失敗し、エラーを修正する過程で問題の解決策を見つけることが必要です。」

実際、私の周りのプロダクトマネージャーや友人を振り返ってみると、大企業であろうと中小企業であろうと、プロダクトマネージャーのほぼ 90% がワイルドな成長を遂げています。社内の他の同僚が共有するドキュメント、記事、ケーススタディを学び、それらを吸収して自社の製品の手法を設計し、業務ケースに適用することで、優れたプロダクトマネージャーになることができます。

トレーニングが不十分で目的のない独学では、リリースされた機能の背後にある困難を理解することはできません。

PMTalk のオフラインサロン活動中に、クラスメイトから「ケビン先生、お話いただいた事例はとても分かりやすいですね。とても勉強になりましたが、まだ自分ではできません。どうしたらいいでしょうか？」と質問されたことを今でも覚えています。

このようなシナリオは、実際には多くのプロダクトマネージャーが独学やトレーニング中に遭遇する可能性が高いものです。

プロダクトマネージャーの仕事は製品の研究開発の出発点となるため、上司のタスクやユーザーからのフィードバックに基づいて、製品をどのように設計するかを決定する必要があります。学習者には、教師や著者が個人的に体験した場面や周囲の環境に過去に戻る方法はありません。すでに作成され分類された PPT ケースからのみ学習でき、冷えた既成のプロトタイプと書面による要件ドキュメントのみがあります。

したがって、プロダクト マネージャーのトレーニングに申し込む場合は、作業プロセスにおける具体的な問題や困難を再現でき、実践的な操作を十分に「シミュレート」できるトレーニングを見つける必要があります。そうすれば、独学でプロダクト マネージャーになるための学習をするよりも、より効率的に知識を吸収できます。

2. 優秀なプロダクトマネージャーはプログラマーから生まれる

ロング兄弟：「プロダクトマネージャーと働きたいですか、それともエンジニアと働きたいですか？」

張小龍：「私はプロダクトマネージャーよりもエンジニアと一緒に働くことを好みます。」

同時に、張小龍氏は、優れたプロダクトマネージャーにはエンジニアリングの基礎がなければならないと述べました。実際、これは市場の多くの製品マネージャーに欠けているものです。インターネットは運用と成長にますます重点を置くようになっているため、多くのプロダクト マネージャーは、設計者や運用担当者から、システム自体ではなく、エクスペリエンス デザインとビジネス プロセスに重点を置く担当者へと変化しています。

システムの基盤となる技術フレームワーク、フロントエンドのコード アーキテクチャ、システムの高同時実行性、その他のソリューションについては何も知りません。当社には運用保守、開発、アルゴリズム、データなどの細分化された研究開発チームがありますが、開発出身のプロダクトマネージャーの場合、製品を設計する際に突飛なアイデアを抑えるのが難しいと感じることがよくあります。

中には単純すぎるものもあり、その結果、要件の欠落やプロジェクトの遅延が頻繁に発生します。

3. プロダクトマネージャーはAIに置き換えられない

プロダクトマネージャーの主な仕事は製品を設計することであり、製品設計は機械に置き換えることはできません。ここで張小龍は演繹と帰納という2つの概念について言及し、非常に具体的な説明をしました。

今日のコンピュータは帰納法でしかこれを行うことができませんが、人間は演繹法で行うことができます。

10万枚の猫の写真を集めてビッグデータを集計することによってのみ、10万匹目の猫が猫であるかどうかを識別できます。しかし、人間の場合は違います。赤ちゃんや子供は、数匹の猫を識別するだけで、次の猫が猫であることを知ることができます。

これが帰納法と演繹法の本質的な違いです。

4. 開発を理解しているプロダクトマネージャーは、テクノロジーを活用して製品を実現するのが得意です

例えば、張小龍氏はライブ放送で、Google の AlphaGo が人間とチェスで対戦したと言及しました。継続的なアルゴリズムのトレーニングを通じて、実際に 1 つの結果を知ることができます。それは、Google が確実に勝つということです。

AlphaGo が次に何をするかを実際に予測できます。彼は突然チェスの駒を倒したり、チェス盤上での動きを後悔したりはしないだろう。十分な回数トレーニングすれば、精度はどんどん高まります。

そのため、当社ではコンピューター AI を使用して効率を迅速に向上させ、よりコスト効率よく目標を達成しています。

5. プロダクトマネージャーは想像力だけに頼ることはできない

PMTalk プロダクト マネージャー コミュニティで働いていたとき、著者が記事を書くためのボタンのコピーライティングにいつも苦労していたことを今でも覚えています。それは非常に重要だったからです。コンテンツ コミュニティの出発点はコンテンツの出力であるため、私たちが望んだのは、優れたコピーライティングを使用して著者のクリックを誘うことでした。

そこで、コミュニティの名前にふさわしいように、このボタンを「トーク」と名付けました。実際、ユーザーはこのボタンをクリックするとエディターに入り、記事を書くことになりますが、オンラインになってからは、このボタンをクリックする人はほとんどいませんでした。

したがって、プロダクトマネージャーが有能かどうかを判断するには、対応する製品機能の設計とコピーライティングが実用的、合理的、客観的であるかどうかを確認する必要があります。

開発のバックグラウンドを持つプロダクトマネージャーは、合理的かつ論理的な考え方を持ちたいと考えています。まるでプロの旗手と一緒に囲碁を打っているようです。あなたの想像力では彼を勝ち取ることはできない。 WeChat には、想像力だけでなく、実装および操作できる客観的なロジックも必要であり、これはプログラマーの技術的知識と切り離せないものです。

『Weaving the Web』という本では、優れた製品設計とは、ユーザーが考えない、心配しない、待たないという 3 つのことを可能にするものであるべきだと述べられています。これが真実です。

しかし、多くの新しいプロダクトマネージャーは、プロダクトマネージャーであることに対する情熱と興奮をコントロールできないことがよくあります。彼らは製品の中に「ホットスポット」を作りたいと考え、自分たちの想像に基づいた名前を考え出しますが、実際にはユーザーにとって理解しにくい名前になっています。

本日のシェアは以上です。