学んだ製品の教訓：ShreyasDoshiとJohnCutlerとの会話

公開: 2021-07-13

比較的短期間で、ShreyasDoshiはTwitterで最も人気のある製品アドバイスのディスペンサーの1つになりました。 なんで？ 彼の執筆は明確で、謙虚で、自己認識的です。ホットテイクの消防ホースの中で特徴が欠けていることがよくあります。 彼が選んだフォーマットは？ スレッド。 そしてそれらの多く。 絡み合っているが組織化されている。 280文字の文字列に詰め込まれたキャリアの価値のある知恵。 ここで誰でも利用できます。

私は（良い種類の）狂気の背後にいる人について非常に興味がありました。 そこで面接を手配しました！ リーダーシップ、より良いリスナーになること、中間管理職の役割、キャリアと自己アイデンティティ、頑固さ、カレンダーシアター、ダッシュボードを製品として扱うことなどのトピックをカバーしています。

何が目立ったのですか？ Shreyasは豊富な製品管理の経験があります。 彼は、Stripe、Google、Twitter、Yahooなどの企業で最前線の製品マネージャーおよび製品マネージャーのマネージャーとして働いてきました。 彼は優れた作家であり、講演者です。 しかし、本当に輝いているのは彼の謙虚さと思いやりです。 彼は人々に彼のアドバイスを盲目的にコピーしないように警告し、そして彼がこれらのレッスンの多くを困難な方法で学んだことを公然と認めます。

インタビューは1時間30分です（下記のオーディオプレーヤーを参照）。 飛び回りたい方のために、以下のインタビューの概要をタイムスタンプ付きで作成しました。 各セクションで、Shreyasは親切にも関連スレッドへのリンクを提供してくれました。

Shreyasのフォローアップの質問がありますか？ @ Amplitude_HQ、@ shreyas、＃shreyasinterviewなどの質問をツイートしてください。 十分な関心がある場合は、フォローアップAMAのスケジュールを設定します。

@shreyasと@johncutlefishに質問があります#shreyasinterviewクリックしてツイート

また、製品戦略と製品管理におけるリーダーシップについて詳しく知りたい場合は、NorthStarハンドブックのコピーをダウンロードしてください。 それはあなたがあなたのビジネスとあなたのチームにすぐに影響を与えるのを助けるためのガイダンスとフレームワークでいっぱいです。

インタビュー目次

完全なトランスクリプトには、コンテキストに関連するツイートが含まれています。 みんなのためにこれらをキュレートしてくれたShreyasに感謝します！

  • はじめに[00:00:00]
  • 「私が書いたものすべてを信じないでください…」 [00:01:07]
  • 自分自身を理解する[00:04:03]
  • より良いリスナーになる[00:05:13]
  • ICからマネージャーへの移行[00:11:49]
  • 不確実性と組織文化について話し合う[00:14:10]
  • 中間管理職と「真理」 [00:16:52]
  • 製品のリーダーシップの役割[00:18:01]
  • 職業的アイデンティティ（およびリーダーシップの役割への移行） [00:21:56]
  • 人々がデフォルト以外の行動をとるのを助ける上でのマネージャーの役​​割[00:25:39]
  • 考え方、原則、戦術（そして戦術に固執する） [00:30:29]
  • 高性能チームの基本/基礎[00:35:11]
  • 基本を満たしたチームが貧弱な製品を生み出すのはなぜですか？ [00:37:31]
  • 志向性と頑固さ（あなたがなりたい会社と） [00:39:24]
  • 分析的および創造的な知性[00:44:14]
  • 衝撃レベル、実行レベル、および光学レベル[00:49:13]
  • 認知バイアスと共有語彙[00:54:37]
  • ダッシュボードを製品として扱う[01:01:51]
  • いっぱいのカレンダー、反応性、自己同一性、そしてポジティブ/ネガティブな習慣[01:08:20]
  • 現在の状況（およびギャップと現在の思考）の改善[01:14:24]
  • LNO：レバレッジ、ニュートラル、およびオーバーヘッドタスク[01:18:10]
  • 結論[01:21:23]

インタビュー記録

はじめに[00:00:00]

ジョン・カトラー：おはようございます、シュレヤス。

Shreyas Doshi：おはようございます、ジョン。

ジョン・カトラー：調子はどう？

Shreyas Doshi：かなり良いです。 ここにいてよかった。

ジョン・カトラー：それで私たちが話したのはこれが2回目です。 そして、私たちが最初に話したとき、あなたはそうだったのを覚えています、私はこのツイッターのことを続けなければなりませんか？ または、本はどうですか？ 何ヶ月だったのかわかりません。 つまり、パンデミックの時期は一般的に物事を押しつぶすようなもののように感じますが、それはしばらくしてからであり、物事はあなたのために絶対に爆発しました。

ですから、前回話してからの違いに注意したいと思います。 おめでとうございます。

Shreyas Doshi：ありがとう。 楽しかったです。 製品などについての考えを書き留めるだけです。 一度に280文字。

ジョン・カトラー：知らない人のために、シュレヤス・ドシ、私は最も簡単な紹介をするつもりです。 彼はプロダクトマネージャーです。 そのため、最近ではStripeで、TwitterとGoogle、Yahooでバックグラウンドを持っています。 多作の作家です。 そして、それだけだと思います。

無敵のベールを突き破り、それでよければ始めたいと思いました。 あなたの文章はとても簡潔だからです。 過去数か月で苦労していた間違いは何ですか。

「私が書いたものすべてを信じないでください…」[00:01:07]


Shreyas Doshi：うん。 ですから、私の執筆について私が言いたいことの1つは、まず第一に、私が書いたものすべてを信じないでください。 、だからそれは真実でなければなりません。 ジョン、それは私が製品や戦略、組織などについての私の考えについて本当に書き始めた過去1年間のことです。

ツイートや送信ボタンを押す前に、私が抱える最大の不安はああです。これが、文脈から外れた場合、または実装された場合に、今言ったことが有害になる可能性がある6つの方法です。間違ったコンテキスト。 それは私が書いたものについて常に心配していることであり、時には、あなたの特定の状況で実際よりも正確に、そしておそらく書く力の一部が真実に聞こえることがあります。

文章は完璧にはほど遠いです。 トレッドのどこかではっきりさせようとしても、多くのニュアンスを見逃している可能性が高いからです。 それが1つです。 2つ目は、数週間前にツイートしたと思いますが、アンチパターンについては、やらないことについてよく話します。 そして、私がそれらについて話す理由、そして時々人々が私に言う理由、ああ、これは非常に明確になりました。 私は、チーム内、会社内、自分自身、マネージャー内など、それが何であれ、このアンチパターンを見ました。 そして、どうやってそこにたどり着いたのですか？ それで、私はこの点をツイートしました。つまり、私が書いているこれらのアンチパターンの多くは、私がそのアンチパターンでした。 右？

私はそれを自分の中で見ました。

たまに、たぶん数時間だけで、ああ、ああ、私はそれを感じて、それを止めて、それを止めることに成功したような、このアンチパターンに入り込んでいます。 時々、私は何ヶ月もの間私が書いている特定のアンチパターンを持っています。 そして、私が長年持っていた他のものと私が自分自身の本当に素晴らしい仕事をしていないものがあります。

ですから、私が書いていることの多くには、その一部、またはすべてがさまざまな期間にわたって自分の中にあるという側面があります。 そして、唯一の違いはおそらくあなたが知っていることだと思います、自己の種類の観察ですよね？ 私が共有したいことの1つは、戦術について話すことができ、製品管理のフレームワーク、構造、およびテンプレートについて話すことができるということです。

自分自身を理解する[00:04:03]

しかし、ソフト面では、プロダクトマネージャーとして私たち全員が認識し、プロダクトマネージャーとしてより良くなるために非常に重要なことは、自分自身を理解することだと思います。 あなたが知っている、彼らが話しているハブは、ああ、ユーザーを理解し、顧客を理解し、市場を理解し、競合他社を理解します。

私はそのすべてに同意します。 しかし、自分自身も理解してください。 自分自身を理解することから始めます。 今、あなたは一度にあなた自身のすべてを理解するつもりはありません。 しかし、自分自身を理解することから始めると、ユーザーに関するこれらの他の理解のいくつかが容易になることがわかります。

私があまり得意ではないことがたくさんあります。 つい最近、私はツイッターで会話をしていましたが、誰かがシュレヤスに尋ねました。組織内でうまく管理するにはどうすればよいですか？

私は言った、見て、私は何年もの間管理するのが本当に苦手だったので、私はそれに対する答えを持っていません。 アンドリュー・ユーは私に管理についての本を送ってくれました。 だから私は言った、ねえ、アンドリュー、あなたはおそらく私がそうする代わりにこのツイートに答えるべきだ。 だから、それはあなたが知っていることのほんの一例です、私は完全にひび割れていません。

より良いリスナーになる[00:05:13]

John Cutler：私が本当に楽しんでいることの1つは、スレッドを通じて、脆弱であり、謙虚であることです。 私が本当に気に入ったツイートの1つを覚えています。そこでは、若い自分の方が聞き上手であり、自分も聞いていない時期に陥っていることに気づきました。

そして、それは私にとって非常に衝撃的でした。 私が思ったので、私は私の人生のこれらの段階を経験しました、そしてそれは静的な状況ではありません。 あなたはいつも学んでいます。 そのような状況で具体的に疑問に思っていたのですが、その自己実現はどのようなものでしたか？ あなたがそれを理解したとき、そしてどのようにしてそれを理解するようになったのですか？ そして、何をしましたか？ そして、あなたはそれをスレッドで詳しく説明し始めましたが、私はあなたがそれを説明し、それを直接聞くことに本当に興味があります。

Shreyas Doshi：それで、私は幼い頃、優れたリスナーでした。 子供の頃、私もかなり強い記憶を持っていました。 それはもはや事実ではありません。 今はいつも忘れています。 しかし、私はそのように始めました。 たとえば、学校の多くのことは非常に早い段階で、先生の言うことを聞いているだけだったので、私にとっては簡単でした。

そして、私はそれを本当に長い間保持することができました。 それは私の10代と20代前半で変わりました。 理由はわかりません。 それはあなたが若い頃に経験したことだったに違いありません。 あなたがちょうど、ある時点で、私はちょうど大学で完全に気を失うでしょう。

そして、私はそこに物理的に座っていたのかわかりませんでしたが、何が言われているのかわかりませんでした。 そしてそれは続いた。 ちょうどこのパターンになりました。 私がソフトウェアエンジニアとしてキャリアをスタートしたとき、会議で何が言われているのか、他の人が何を言っているのかについて、それほど無関心ではなくなりました。 しかし、その時点で5、6年間使用していなかったため、そのスキルを失いました。

ジョン・カトラー：あなたがそうだった瞬間はありましたか、待ってください、私はこれを失いましたか？ どのようにあなたはどうでしたか、それはどのようにあなたに夜明けをしましたか、それともゆっくりとした火傷のようでしたか。 それとも、あなたとニュースを共有したのはマネージャーか誰かでしたか？ どのように、どのようにそれを実現しましたか？

Shreyas Doshi：ジョン、私はこれを非常に遅く気づきました。 ですから、キャリアをスタートしてから約12年ほど、私は大丈夫なリスナーの状態にあったと言いたいです。 それが意味するのは、もちろん、私が聞いていたということです。 私は処理などをしていました。 しかし、私は自分の考えを形成する古典のこのモードにいました。 私の応答を形成し、私の応答を準備します。 または、実際に言われたことを聞いているのではなく、私が聞きたかったことを聞いています。

ですから、私はキャリアの中で少なくとも12年間その段階にありました。 ある時点で、私にとっての主な認識は、相手を理解するための鍵は、私が彼らを理解していることを彼らが知っていることを確認することであるということでした。 右？ それで私はその最初のステップから始めました。 そしてそれは非常に戦術的な種類であり、いかなる原則にも基づいていませんでした。 それは大丈夫のような戦術でした。

ジョン・カトラー：頭の中で考え抜かなければなりませんでした…

Shreyas Doshi：はい。 良いマネージャーになるためには、相手が自分の言っていることを理解していることを相手に理解してもらう必要があります。 それが私が始めた場所です。 そして、それから私はそれをしました、そしてそれは多分私を10人中4人から10人中6人にしたのかもしれません。それは問題ありません。 それは改善です。

しかし、次の大きな気づき、そして私が成し遂げることができた量子の変化は、あなたが言われていることだけを聞いて、あなたが完全に存在しているとき、反応が自分自身を作り上げることに気づいたときでした。 右？ だから私はあなたが話している間実際に考える必要はありません。 または、私があなたを理解していることを確認するために、あなたが言っていることをどのように要約するかを考える必要さえありません。

私はただ100パーセント存在したいだけです。 そして、私は好奇心を持ちたいです。 それが変化でした。 それは本物の好奇心であり、本物の好奇心を育み、存在し、自分の部分を見ることができ、発声されていた言葉に正確に戻ることができるスキルでした。

そして、それをしたとき、この本物の好奇心と存在感からアプローチしたとき、それは私がこれをしているときに、ああ、すごい、2つのことが起こっているのを見たときです。 1つは、私は[00:10:00]、彼らが言っていることにもっと興味を持っているとして、この他の人に出くわしたところです。 そして第二に、私の応答の質は非常に高いです。

以前は、多くの場合、応答は、大丈夫、私はあなたの言うことを聞いたという感覚を持っている傾向がありましたが、私の役割を考えると、私があなたの言うことを聞いたように、それはしばしばです、そしてここに私のアドバイスがあります。 またはここに私の答えがあります。 回答は、声明ではなく質問になりました。

これが、私が本当に彼らを理解していることを彼らが理解した方法です。 そして、私はそれらをさらに理解しようと真剣に試みていました。 彼らは私に何かを言った。 私は本当に出席していました。 私は本当に興味がありました。 そのため、私は彼らに、他の方法では尋ねなかったであろう質問をしました。 そして、その質問は私たちを状況をよりよく理解することができるように近づけました。 それを始めていくうちに、これは本当に効果的だと気づきました。 彼らが正しい質問であるならば、人々に質問することははるかに効果的です。 そして、彼らが他の人が状況について何を言おうとしているのかについての深い理解、またはあなたができる限り深く理解していることに基づいている場合。

ジョン・カトラー：あなたは時間の経過とともに何かを開発し、そのようにしてそれがはるかに良くなったように思えます。 同様に、1対1などでより良い質問をすることができます。

Shreyas Doshi：もちろんです。 そして、ご存知のように、私は私がPMを務めてきた4つの会社のそれぞれでPMのマネージャーを務めてきました。 この4社のうち3社は、最近の雇用主であるStripeを含め、個人の貢献者として参加しました。 私は個人の貢献者として参加し、その後、人の管理を始めました。

ICからマネージャーへの移行[00:11:49]


だから私はそのICからマネージャーへの移行を経験しました。 多くの人がそれを1回または2回経験します。 ええと、それから彼らはマネージャーのままです。 私はそれを何度も経験しました。 そして、私はそれが理にかなっているICにいることを気にしません。 だからそれは私にとってうまくいった。

毎回違いますが。 私がマネージャーとして成長したからです。 私が経営を始めたのは、プロダクトマネージャーになってから9ヶ月だったと思います。 ああ、私たちはあなたがしていることが好きだと言われました。 小さなチームを管理してみませんか？ 振り返ってみると、当時は気づいていませんでしたが、振り返ってみると、私はひどい、ひどい月経前症候群のマネージャーだと感じました。 これは、ご存知のように、これらのアンチパターンの多くに戻ります。 私はそうしてきました。 私は早い段階で覚えているので、私は答えを持っていると確信していました。

そしてそれは1つでした。 そして第二に、私の仕事は答えを提供することだと思いました。 チームメンバー内でその答えを受け入れるか受け入れるかという抵抗に遭遇した場合、私の仕事は非常に分析的な手段でチームメンバーを説得することだと感じました。なぜこれが正しい答えなのですか？

当時、私はマネージャーとしてひどいものでした。 そしてもちろん、今は非常に異なるアプローチを取っています。 その多くは、本物の好奇心を育むことと関係があります。一般的な人生の成熟度もそうだと思います。 しかし、私の考えを見ることができ、PMマネージャーが何をすべきかを理解することもできます。

彼らの仕事は何ですか、そして彼らの役割は何ですか？ 今はよく理解できましたが、以前は人の管理を始めてほしいと言われたばかりで、実際に何をすべきかわからなかったようです。

ジョン・カトラー：あなたが関わってきた企業について考えるとき、つまり、特定の企業文化について私が気づいたことの1つは、不確実性についての議論の扱いが非常に異なることだと思います。 不確実性を減らす絶対的な計画がない限り、不確実性について言及することは決してありません。

そして他の文化では、彼らはリーダーが言うことに対してはるかにオープンであるように見えます、ただ今はわかりません。 それで、そのためのあなたのゲーム計画は何ですか？ あなたがこれらの組織に出くわしたように、しかしあなたはリーダーの脆弱性の文化をどのように理解しましたか？

それは明らかに重要ですが、文化によって現れ方が異なるためです。

不確実性と組織文化について話し合う[00:14:10]

Shreyas Doshi：ジョン、そこでの文化についておっしゃっていたのが好きです。 どこに文化があります。 ええ、あなたは確かになっているはずです。 そして、あなたが確信が持てず、あなたがすべての正当化、分析的正当化を持っていない場合、あなたは無能であるとみなされます。

他にも、ある程度の不確実性が私たちの行動の一部と見なされている文化があります。そうです、これがどのように機能するかはわかりません。それで問題ありません。

それは、文化の2番目のカテゴリーがそれほど厳密ではないという意味ではありません。 私はそれがより厳密であると主張するでしょう。 それは、特定の入力に基づく厳密な数学的結果についての幻想に基づいていないためです。 [00:15:00]の製品を取り出して、それを外の世界に持ち込むときに伴うランダム性を理解します。 それは他のランダム性、市場のシステム自体などを理解します。

それは、これらのことを実際に理解しているようなものの中で機能します。 理想化されたものとは対照的に、そうそう、スプレッドシートのようなアプローチでこれを証明できるはずです。 ストライプは良い例です。 ご存知のように、私たちの創設者またはリーダーが、ええ、これについて確信する方法はありませんと言う製品レビューがあります。

お客様からのフィードバックを理解しましょう。 市場の状況を理解しましょう。 そして、それに基づいて、状況に応じて最善の決定を下します。 しかし、あなたが知っている、私たちはこれがうまくいくと確信する必要はありません

ジョン・カトラー：そうです。 それは信じられないほどのモデリングですよね？ リーダーの立場からのように。 そしてそれはそれが大いに役立つことを意味します。 リーダーがそう言うなら、確かに。

Shreyas Doshi：うん。 うん。 そして、ご存知のように、私がStripeで実際に練習しているのを見た、古典的な一方向ドア、双方向ドアもあります。 これは私たちが元にできる決定です。 右？

それでは作りましょう。 大丈夫だよ。 間違っている場合は、元に戻します。 それを元に戻すコストは実質的ではありません。 そして、元に戻すのが難しい、または元にできない他の決定があるかもしれません。 それらを正しくするために実際に時間を費やしてみましょう。 繰り返しになりますが、ここで私が言っていることはすべて、ジョン、そうだと思います。もちろん、ほとんどの場合、そうすべきです。

もちろん、あなたはそれをすべきです。 問題は、なぜこれが起こらないのかということです。 この意味で、ほとんどの組織が非常に、ある種、不完全なのはなぜですか？ そして、私はあなたと私が確実性劇場のこのトピックについて話し合ったと思います。 そして、それは特に中間管理職のために文化が生み出す心理的安全性と関係があると思います。

中間管理職と「真理」[00:16:52]

私が中間管理職を見る方法は、あなたが本当の真実に到達できることを保証する組織の方法です。 地上には真実があり、そして、あなたが知っているように、人々はその真実に非常に直接取り組んでいます。 そして、彼らがその真実を見るとき、彼らはその真実を中間管理職に伝えます。 そして、中間管理職は、あなたが地上で見る真実の間で、この代理人として行動しています。 そして、真実の会社の幹部はマクロ規模で見ています。

ですから、中間管理職にとっては、双方が見ている真実を気軽に表現することが非常に重要だと思います。 彼らの仕事が危険にさらされたり、彼らの立場が危険にさらされたり、彼らのキャリアの成功が危険にさらされたりすることを心配する必要はありません。

そして、彼らがそれを行うことができれば、つまり、組織内の両方向でより良い種類の真実の流れを解き放つための鍵だと思います。

ジョン・カトラー：中間管理職は単なる1つの層ではありません。 多くの場合、それは複数のレイヤーです。 では、どのようにして、その2つまたは3つの層を横切って両方向に真実を流し続けるのでしょうか。

製品のリーダーシップの役割[00:18:01]

Shreyas Doshi：最初の観察は、私たちが実際に仕事とは何か、そして製品リーダーの役割とは何かについて話しているのではないということです。 右？

私の観察では、そのような製品リーダーのほとんどは、素晴らしい経験と素晴らしい履歴書を持っています。 あなたが彼らに尋ねるなら、あなたの役割は何ですか？ あなたの本当の役割は何ですか？ 彼らは苦労するでしょう。 そして、私は彼らを非難しません。なぜなら、あなたが知っているように、誰も彼らに彼らの役割が何であるかを教えなかったからです。 それで、彼らは物事を始めたばかりで、それがうまくいった場合、外部の検証を受けた場合、彼らはそれ以上のことをしました。 そして、検証されなかったものを抑制しました。

それで、どういうわけか、特定のスタイル、または特定のアプローチ、またはいくつかの暗黙の役割の定義に到達しました。 それは今では彼らの習慣に深く埋め込まれているので、彼らはそれを完全に説明することはできません。 私の役割はX、Y、Zです。

そして、それはとても重要だと思います。 役割を理解すれば、何をする必要があるのか​​が明確になりますよね？ あなたがする必要があるのは、他の人を通して製品の成功を可能にすることですよね？ そのように、事実上、どこかで中間管理職の製品リーダーとしてあなたがしなければならないことです。

そして、他の人を通してその製品の成功を可能にするために、私はそれについて話し、自己管理チームを作成しますよね？ したがって、自己管理チームを作成することは非常に重要です。 理想的には、製品リーダーとして、あなたはただ火を消すようなものではなく、そこにいる必要があり、すべてを精査する必要があるため、8つのレビューに出なければならないようなものではありません。

そして、これが多くの製品リーダー、私たちの日々の仕事の現実であることを私は知っています。それがしばしばそれが非常にストレスを感じる理由です。 そして、私はそのような多くの製品リーダーをかなり定期的に指導していますが、[00:20:00]このようにする必要がないことは彼らにとって驚くべきことです。 それはあなたがしている方法である必要はありません、あなたが知っている、文字通り週に40回の会議または50回の会議。

私が何度も聞いたこのジョークがあります。 ああ、あなたは製品リーダーなので、デスクにいることは決してないでしょう？ あなたがいつも会議に参加するように。 ハハ。 私たちはそれを現実として受け入れます。 私はその前提を絶対に拒否します。 実際、製品リーダーとして、あなたは自分の机でたくさんの時間を費やすべきです。 そして、それを行わない場合、それはあなたが自分の役割の2番目の側面、つまり自己管理チームを作成することを果たしていないことを意味します。 右？

ですから、その役割を理解することに戻ると思います。 そして、あなたが役割を理解すると、あなたの行動はあなたがどのように委任するかという点でかなり異なります、あなたが私に見せているこの流れへのこのアプローチは好きではありませんが、私は何か他のものが好きです、しかし、代わりに、ここを見てください、これが私がこれについてどう思うかです。

これが私がユーザーの目標についてどう考えるかです。 これが私たちが持っているコンバージョン目標について私がどう思うかです。 そして、ここに私たちが考慮すべきいくつかの原則があります。 正しい答えが何であるかを理解するために私たちが探すべきいくつかの指標がありますよね？ そのように、チームとの製品リーダーとして必要な会話です。それが、自己管理チームを作成する方法であるのに対し、ボブ、ボブは単一のページフローが好きですよね？ いいね、または単一ページのステップ。 そして、そのようなものはただのボブの癖です。 念のために言っておきますが、これはデザイナーに指示しているプロダクトマネージャーです。必ずそうしてくださいね。 のようですが、その理由が欠けています。 それは、ああ、ボブのレビューを通してそれをうまく取得したいのであれば、これを行う必要があるということです。 右。 これは、自己管理チームの反対のようなものを作成したため、意味がありません。

職業的アイデンティティ（およびリーダーシップの役割への移行）[00:21:56]

John Cutler：頭に浮かぶことの1つは、製品マネージャーは、IC PMから始めて、この漠然とした役割の性質を楽しんでいるように見えることが多いということです。 彼らはほとんど変身者として自己識別します。 やらなければならないことすべてに自分自身を押し込むようなものです。

そして、その人が監督になると上に上がるのが想像できました。 たぶん時々彼らはそれを手放すことができません。 多分それは彼らの役割を明確にすることができないことにつながる一つのことです。

Shreyas Doshi：ああ、ジョン、あなたが今言ったことはとても強く共鳴します。 それに応えて、2つのことを共有したいと思います。 1つ目は、この古典的な例があるということです。 そして繰り返しますが、これは何年も前の私でした。 これは12、13年前の私でした。 一見有能な製品マネージャー、製品管理のコアワークが本当に得意な人。

誰が言ったのか、わかりました、私たちはあなたに月経前症候群を管理してもらいたいのです。 さて、今、その状況で何が起こるかは本当に興味深いです。 そして、これが多くの有能なPMに起こった場合、私は思います。 そのため、少なくとも1番目または2番目の製品リーダーの能力がわずかに低下します…

ジョン・カトラー： PMは組織を上るにつれて、ますます能力が低下すると言っていますか？

Shreyas Doshi：そうですね、要件、バーが変わります。 右？ たとえば、私の場合、私はまだコア製品管理スキルセットを構築および開発していました。 完全には構築されていませんでしたが、他の多くの機能でも発生する管理を依頼されました。 しかし、課題は私も精神的にそこにいなかったということですよね？

私にはこれらのギャップがあることを知っていたように、そして私のどこかで、私はまだ私が本当に素晴らしい製品マネージャーであることを証明するためにその意欲を持っていました。 プロダクトマネージャーのマネージャーではありませんが、本当に素晴らしいプロダクトマネージャーです。 そして、それが私のチームに現れた方法は、あなたが知っているように、何かが起こり、私が行く、ああ、これは明らかに正しい答えではありません。 これが私たちがこれについて考えなければならない方法です。 たとえば、私の言語を見てください。 右？ これらのように私が使用した言葉です。

そして、私が実際にやっていたことは、今では理解できましたが、当時は理解できませんでした。 私が本当にやっていたのは、私がまだそれを手に入れていることを自分自身に証明しようとしているだけです。 そして、私がコアICの個人貢献者の仕事でどれほど素晴らしいかと同じように、他の人に証明して見せようとしています。 ああ、私はこれを製品マネージャーに見ています。特に最初の3、4年間は、製品マネージャーの管理に入るときはいつもそうです。 彼らはまだ、マネージャーの役​​割ではなく、製品管理の役割、コアICの役割を実行しようとしています。

そして、それは彼ら自身のためにあらゆる種類の挑戦を生み出します。 なぜなら、そのようなICアプローチを採用すると、あなたはマネージャーになり、[00:25:00]そうそう、私はその会議に行く必要があると言うからです。 招待していただけませんか。 製品戦略や製品の方向性について意見を述べるには、現場でそれが必要だからですよね？

対、あなたの人々を通してそれを理解するためのスキルを開発します。 そして、それはあなたのチームの人を苛立たせます。なぜ私の上司がこの会議に現れるのですか？ 意味がない。 そして、ああ、私の上司はマイクロマネージャーです。 または、ああ、上司がこの会議に出席しているので、私は今、自分自身が無防備で、正当で本物の質問をするのではなく、この会議に出演する必要があります。

人々がデフォルト以外の行動をとるのを助ける上でのマネージャーの役​​割[00:25:39]

私が話しているこのトピックに関連する1つのことをお話しします。それは、特に製品管理のコンテキストでマネージャーの役​​割を表示すること、マネージャーの役​​割、ディレクターの役割、VPの役割、CPOの役割を次のように表示することです。デフォルト以外の動作をいつ採用すべきかを人々が理解できるようにすることです。

具体的な例を見てみましょう。 ブログの投稿やTwitterのスレッドのどこかに、この種の製品マネージャーが必要なものがあります…

ジョン・カトラー：ちなみに、私たちはこれらに対して共同で責任を負っていたかもしれません。 だから私たちはできると思います、

Shreyas Doshi：もちろんです。 これは私が好きなものです、ああ、私は送信を打つことに神経質になっています…

ジョン・カトラー： …これについては悪夢があるので、私は…

Shreyas Doshi：確かに！ それでは、製品マネージャーが何をすべきかについての架空のブログ投稿を見てみましょう。 そして、それは製品マネージャーが彼または彼女のチームのためにそこにいるようなものです。 プロダクトマネージャーはチームのブロックを解除します。 プロダクトマネージャーは、チームが必要としているものをチームにチェックインし、効率的になるように必要なものを提供します。

それらは効果的です。 プロダクトマネージャーは、個々のエンジニアと定期的にチェックインして、必要なものを確実に入手できるようにします。 右。 したがって、この種の架空のブログ投稿を想像することができます。

そして、私がプロダクトマネージャー、または新製品マネージャーであると言って、「わかりました」と言ってください。これはすべて理にかなっています。 そして、私はこれを始めます。 そして、何が起こると思いますか？ 私がそれを始めたように、そしてそれは素晴らしい働きをします。 人々は、ああ、あなたが知っている、アリスが私たちのチームのPMとして参加したと言います。 そして、それはすごいことです。 それは昼と夜の違いでした。 私たちがPMなしで活動していたとは信じられません、そしてこれは驚くべきことです、より多くのPM、あなたは知っていますか？

プロダクトマネージャーなどとしての貢献に対して、アリスが認められていることを確認しましょう。 右。 わかった。 よく働く。 では、どうなるのでしょうか。 私がプロダクトマネージャーの場合、これをデフォルトの動作にします。 今年が仕事をする最初の年だからです。 さまざまな状況での製品管理については何も知りません。

これらのアクションの検証を取得していると思います。 だから私はこれらの行動と同じかそれ以上をしなければなりませんよね？ 今、私を別のチームに移送します。 または別の会社。 わかった。 さて、この会社、またはこのチームでは、このチームについて言えば、エンジニアは非常に独立しています。 They are already talking to customers directly, right?

They're talking to sales directly to understand requirements. They are talking to marketing. You know, the designers are doing end to end research and validation as well as again, kind of very customer centric. And it's generally a very high agency team, right?

Like again, the tech lead, or the lead designer, isn't afraid to go to the VP or the CEO and ask questions or ask for what they need and whatnot. 右？ You can bring in this product manager, who's performing these defaults, in this situation, what happens, right?

Same product manager, different teams. And the feedback is, oh, you know, we think Alice needs to create more room for ideas. We think Alice can sometimes create an unnecessary obstacle for us. We think that is a lot more process. We think there are many more check-ins than there need to be. We don't have to provide status on a daily basis for what we are doing, et cetera, et cetera. 右？ Same product managers, same actions, different contexts. 動作しません。 So with this now let's get back to the thing I've been mulling over recently, which is where is the failure here?

I don't think the failure is at the level of the PM. It's not Alice's failure. It's the manager's failure, right? It's the manager's responsibility to help a PM understand the context within which they are [00:30:00] operating and then nudge them towards non-default behaviors.

John Cutler: It's funny you had that conversation. I think there was a thread with Dee Hawk where he said, I talk about principles and these deep things, and you actually made the point where you said most people just want to get ahead.

You know, so talking about principles is a little tougher. I'm paraphrasing. I think I remember this in the back of my mind. But I thought what was interesting — that point — is it's also the toughest thing, right?

Mindset, principles, and tactics (and getting stuck on tactics) [00:30:29]

Shreyas Doshi: So, so a couple of thoughts there. One is it does depend on where one is at, right? There are three things that one needs to understand and use in order to get really good at something.

There's mindset, there's principles, and tactics, right?

People often will start with tactics. Which is here is a recipe for how to run this meeting, right? Here's the template for a product review. Here's a template for a product strategy doc, or what have you, right. Tactics are amazing. You need tactics to figure out the basics of a role and to be productive in that role and to learn by doing right. So tactics are really, really important.

What happens though, is for many people, they get stuck at tactics for the majority, if not the entirety, of their career. And that's where there is a problem. 右？ Which is once you have reached a certain degree of proficiency, you are not going to be able to, you know, seek the 37th tactic for doing this thing in order to actually be effective. 右。 And, and so what you need at that point, is a better understanding of the principles. Because with the principles, what you will do is you'll know which tactic to employ. But even more amazingly, once you start understanding these principles, you can create your own tactics, right?

And then mindset is the most important thing. All of us know we need to do certain things. I know I need to write that PRD, why am I not writing that PRD? And instead, spending my time on Slack, and replying to email, and convincing myself that I'm being productive by doing that.

And there is a very good reason why I'm not writing that PRD. I need to understand myself. I need to understand what is really going on. What I'm really fearful of when I'm avoiding writing that PRD that I really should be writing. So there's much more to mindset than that, but the point is to achieve the highest degree of competence in a certain field — and particularly, I think, I can only speak for product management really to achieve the highest degree of competence in product management — you do need to understand each of these three extremely well.

Depending on the context, some of this is just not possible. Look, a lot of what I talk about the implicit background there is it's, we're talking about you know, like Marty Cagan calls it empowered teams, right? Where people are given the right tools, and the freedom to arrive at the right answer. Without taking tremendous personal risk in order to do so. I have been fortunate to have largely worked at organizations where the teams have just been empowered by default. My perspective comes from that. I frankly don't know what it's like, and what success is like, in environments where teams are not empowered, where individuals are not empowered. A lot of what I might say in that context can probably be boiled down to, grow as much as you can in the environment, such that now you will have the optionality to move to an empowered environment where you can really exercise your skill and achieve, hopefully greater potential.

But even as I say that I'm in two minds, right? Like, I feel like, okay, it makes sense to try to grow as much as one can, based on the cards one is dealt. 右？ It seems to make sense to do that. My own personal experience. I was very early in my career. I was in these highly disempowered teams. That's sort of what I tried to do, but again, I'm a sample size of one. What works for me doesn't necessarily work [00:35:00] for everybody. So that part of me says, okay, yeah, maybe this should work. But the other part I'm not quite sure about is just like is it possible in every environment where teams are disempowered? 。

The basics/foundations for a high-performance team [00:35:11]

There are some basics that you need to have in order to have a chance of being a high-performance team or a successful team. Without those basics, yeah, with survivorship bias, you can find one team that managed to, against all odds, to succeed without those basics. But we can't really bank on that. 右。 Because we have one life, we have, you know, we are single threaded. We can't run a hundred simulations and then just pick the winning simulation. 右。 Or even like thread, like do three jobs on a given day. 右。 And see which one, see which one worked out better. And just like, uh….

John Cutler: A multivariate job experiment. それは本当に

Shreyas Doshi: So, so we can't do that. So, you know, any kind of like, oh, there's all these problems and they, yet we succeeded. So learn from us. 右。 Like there's very little to learn from that in my opinion. Because you're so single-threaded as a team, as a person, as a company it makes sense to just make bets that have a high expected value.

So let's assume that the basics are met. And what are some examples of basics that you have the right people in the right roles as an example, Right. It doesn't have to be the world's best people doing whatever, but at least there is some match to what the job is, and the people, who are supposed to do the job, as one thing.

You might even put a certain bar of empowerment. It doesn't necessarily have to be the highest empowered team ever. Because like that could have its own issues. But like a certain bar of empowerment. So anyway, you can make up some reasonable basics around, okay, any team or any situation needs to satisfy these basics, for it to have a shot at creating something that makes an impact, creating something that's remarkable.

わかった。 Now that these basics are covered, what's next? What do we need to do to increase the probability that we can meet our potential as a team? You know, as a thinker I have been thinking a little bit about a lot of my writing and what the general theme is. And one of the themes that I've been able to extract after the fact, is that really I'm trying to answer the following question in many different ways.

Why do teams with the basics met produce poor products? [00:37:31]

And the question is why do smart teams with sufficient resources– by resources I mean, money, all of that, right, not number of people necessarily– so why do smart teams with sufficient resources still produce mediocre or poor products? The current environment, again, sort of certainly you know, with startups and high growth tech companies, is that we all like to think we have smart teams. In this current funding environment, we do have somewhat sufficient resources in most cases, perhaps too many resources in some cases, and yet, many teams are not as successful as they ought to be.

And so why does that happen? 右？ I don't think I've answered that question just for myself. First trying to do this for myself, and then for everybody else. But I think the answer lies in a lot of different things that we just talked about. Around, oh, you know, one of the aspects of success is understanding the truth.

A lot of this goes back to things like decision-making, how do you collect inputs, how do you determine outputs? How do you get to those outputs? And then what are the right outcomes for us to achieve? Are we being sufficiently both logical and creative about how we get there?

I don't have an answer to sort of like the overall question of what distinguishes, you know, either poorly performing teams or high-performing teams and how are they different. I like to think about it as like, you know, this concept of assuming the basics are met, what needs to happen in order to maximize chances of success? And that's where I think context also plays a pretty large role.

Intentionality and stubbornness (with the company you want to be) [00:39:24]


John Cutler: What I've observed, at least in some of the companies that I admire the most is that someone is around who is just really stubborn about something, you know. They are stubborn about maybe engineering quality, or they're stubborn about connecting with customers. So anyway, that's, I'm offering that up as maybe an area that I'm looking into. That's what I've been thinking a lot about lately is stubbornness. We should connect our threads of research on this because I think it'd be interesting.

Shreyas Doshi: Yeah. I want to take that and do a live mashup of what you're talking about, uh, with this other idea that I [00:40:00] often bring up in conversations with startups, particularly as they're kind of starting to think about scaling that product development efforts. As they're thinking of adding product management. One of the questions I will often ask is what type of company do you want to create? Concretely. This is in the context of, you know, oh, I'm looking to scale my engineering team, looking to scale my product management. And I ask people to be quite intentional about what type of company you want to…

John Cutler: Because it's easy to give non-answers to that. I've heard a lot of non answers to that question.

Shreyas Doshi: Yes. And as it pertains to product work, right? Like what is going to be your focus? So that's one way to look at it. Do you want to be a customer focused company? Do you want to be an infrastructure focused company? Do you want to be a growth focused company? Do you want to be a product focus company?

Do you want to be a sales focused company…

John Cutler: I want it all…

Shreyas Doshi: And exactly, right!

Like, so that's what people say quite a bit. But then they start getting it, which is like, oh Yeah, Okay. I like, I need to be like, as a founder, my company is my product. And so I need to be quite opinionated or stubborn– so, this is where I'm connecting to your stubbornness– about what I want to create.

Because what happens is you, you can't have it all. And if you're not intentional about it, you are focused on something it's just, you don't know what it is and then there's confusion, right. Like for yourself and for others. And so you take examples, right? It takes time to go through this conversation because, you know, it's, it's an odd

John Cutler: It starts out very high level too. It's like…

Shreyas Doshi: Right, it's, it's very high level…

ジョン・カトラー： …そして、あなたは立ち去ってコーヒーを飲む必要があります。そして、待ってください、私たちはさらにレベルを下げる必要があります。

Shreyas Doshi：わかりました。 右。 そして、そして、私が観察したのは、30分で20分で10分のように、通常、創設者にとって電球の瞬間があるということです。 なぜなら、創設者は通常、彼らがやりたいことに非常に近いからです。 つまり、これもまた、質問をすることが主な付加価値であるということの1つであり、必ずしも答えとは限りません。

しかし、例を挙げれば、Googleが例として明確になります。確かに、私がそこにいたときは、10、10年前のように、インフラストラクチャに重点を置いた会社でした。 それが彼らの暗黙の焦点でした。 エンジニアと話して、これはユーザーが必要としているものだと言ったとき、どうやってそれを構築するのでしょうか？ 答えは、ああ、それは非常に興味深いことです。 それは驚くべき問題です。 このバックエンドインフラストラクチャを構築する必要があります。 このバックエンドインフラストラクチャを構築するには、6か月かかります。 そして、この機能があります。 もちろん、製品担当者としては待つつもりですが、それは本当に長い時間のように思えます。これは大きな機能ではありません。

いや、いや、いや。 これが私たちのやり方ですよね？ 同様に、インフラストラクチャが必要です。 繰り返しになりますが、間違った選択や正しい選択はありません。 私もそれを指摘したいと思います。 右。 これは、Facebookを持っているようなものです。これは、少なくとも確かに、外部から、そして私が話をした人々からは、非常にメトリックに焦点を当てた会社のようです。

彼らは、メトリックを大きく動かすものに基づいて決定を下します。 そのため、GoogleとFacebookの動作は大きく異なります。 内部的には、その焦点のために、それらは非常に異なって動作します。

簡単に選択できるのは、お客様に焦点を合わせたいということです。 そして、私は人々に、もしあなたがそうなら、あなたが顧客中心の会社になりたいと言っているが、あなたがエンタープライズソフトウェアを販売しているなら、あなたが実際になるのは販売重視の会社。 繰り返しになりますが、販売に重点を置いた非常に成功した企業の例があります。

だから、それが必ずしも間違った選択だと言っているのではありません。 しかし、それについて意図的に考え、それを頑固なポイントに再び結び付けるだけで、それは物事を見る1つの方法ですよね？ これが私たちのやり方です。 本来よりもネガティブに聞こえるか、これでうまくいくと思いますよね？ これは、私たちが持っている文化で機能します。 これは、私たちが採用した人々やスキルなどで機能します。 そしてそれは、特にあなたがそれについて意図的である場合、非常に強力になる可能性があります。

分析的および創造的な知性[00:44:14]


ジョン・カトラー：私たちの会話の中で数回、あなたはその言葉の分析について言及しました。 そして、あなたはそれに代わるもの、おそらく創造的な知性について話しました。 それを少し掘り下げていただけませんか？

具体的には、測定について考える日常の仕事について考えています。 そして、私が観察したことの1つは、測定を使用して人を制御したり、物語を制御したり、完璧な答えを得たりすることと、測定を使用して学習することには大きな違いがあるということです。 彼らは非常に、非常に異なった感じがします。

あなたの心の中の分析的知性と創造的知性の違いは何ですか？

Shreyas Doshi：根本的に彼らはお互いに築き上げています。

しかし、それは業界のほとんどがそれをどのように見ているかではありません。 そして、非常に成功している[00:45:00]の企業を含むさまざまな企業の慣行は、一方を他方よりも優れていると見なす傾向があると思います。 そして、それは通常、そして繰り返しますが、私の文脈は、地理的にどこにいても、バレーベースの企業またはバレーのような企業から多くのものです。どういうわけか、分析上の理由は非常に重要で正しいと見なす傾向があります。

私たちは製品の創造性を軽視する傾向があり、本能や判断などのさまざまな側面を軽視する傾向があります

ジョン・カトラー：二重性がありますよね？ 私たちも人々の本能を大いに誇大宣伝しているように、特定の人々の本能は上がっていますが、私はあなたが何を意味するのか知っています。

Shreyas Doshi：うん。 ですから、これは興味深い種類の問題だと思います。繰り返しになりますが、適切なリソースを備えたスマートチームが、平凡な製品や貧弱な製品を生産しているのはなぜかというコアな質問に戻ります。 私たちが忘れているのは、多くのチームと多くの企業文化が、人々が創造的なアイデアを思い付くのを非常に難しくしているということです。 繰り返しになりますが、全体として非常に成功している企業です。

これの多くはどこから始まりますか？ それは会議から始まりますよね？ だから、あなたはどんなレベルでもあなたの典型的な製品会議に参加します。 あなたは出くわすでしょう、ほとんどのそのような会社では、あなたが5つの異なるチャートを示すならば、あなたははるかに有能であると出くわすでしょう。 いくつかのテーブルを表示します。 そして、いくつかの定性的な洞察。 そして、あなたは言うので、これが起こる必要があることです。 何も悪いことはないと思います。 右。

しかし、そのアプローチとその考え方で何が起こるかというと、それゆえ、結論や推奨事項は実際にはかなり制約されているということです。 彼らはこの箱に入っています。 あなたは彼らが実際にこの箱のようであるかどうかわかりません。 でもそうですよね？ さて、同じように創造的な知性を認めたとしたら、結論には奇妙なアイデアが含まれているでしょう。 それが定性的であろうと定量的であろうと、データから厳密に従わないもののように。 たぶん、それはそのような封筒の中にさえあるかもしれません、ああ、私たちはこれについて強い確信を持っていませんが、私たちはこれを試してみるべきです。 繰り返しになりますが、会議で製品レビュー会議に参加すると、製品マネージャーが創造的なアイデアを思いついたときに混乱したり、奇妙な見た目になったりします。

または、誰か、私はただ1つの役割として製品マネージャーを選んでいますが、エンジニアか誰でも。 第二に、彼らは後でlikeのマネージャーからフィードバックを受け取る可能性があります-そしてそれがそれほど多くないように組み立てられる方法は、創造的なアイデアを持ち込まないでください-誰もそれを言いたくないので-それはあなたがする必要があるようなものです提案をデータでバックアップします。

あなたは物事をより良くバックアップする必要があります、そしてそれは私がマネージャーとしてあなたに与えるフィードバックですよね？ この現象は、非常に成功している企業内でも非常に定期的に発生します。 そしてそれは、チームが実際に可能性を実現するこれらの製品を作成できるようにする妨げになります、ええと…。

ジョン・カトラー：最近、私の会社ではカバの意思決定が多すぎると誰かが言いました。 データを使わなければなりませんよね？ カバを追い払うためにデータを使わなければなりません。 そして、私は、まあ、あなたが腸のアイデアを持っているときに何が起こるのだろうと言いましたか？

そして彼らは、もちろん、もちろん、私たちは同じアプローチを使用するつもりだと言いました。 そのためのすべてのデータが必要です。 そして、私は、見て、あなたの問題はカバではないようなものでした。 最終的には創造的なアイデアが必要になるからです。

アイデアが1つしかない場合、それはひどいことです。 あなたが50のアイデアを持っているなら、それは麻痺しています。 たぶん３つありますか？ そして、私の友人のダン・ノースは、いや、あなたは7つ欲しいと言いました。 最初のアイデアはあなたのアイデアであるため、次の2つ、3つ、または4つのアイデアは基本的にあなたのアイデアをサポートします。 つまり、4つ目、5つ目、6つ目、7つ目は、快適ゾーンから抜け出すときなので、7つが必要です。

衝撃レベル、実行レベル、および光学レベル[00:49:13]

Shreyas Doshi：うん。 私が考える1つのフレームワークは、ほとんどの製品コンテキストにまたがる非常に基本的なフレームワークであり、確かに私が遭遇したすべての製品コンテキストは、私たちがよりよく認識する必要があると思います。これは、私が製品作業の基本的なフレームワークと呼んでいます。

だから私たちはこのすべての製品の仕事をしますよね？ これについてどう考えるべきですか？ この製品の仕組みについてどう思いますか？ 私が最近持っていた洞察は、製品作業には3つのレベルがあるということでした。 影響レベルがあります。 実行レベルがあります。 そして、光学レベルがあります。 そして、製品チーム、製品文化内の多くの課題[00:50:00]は、私たちが話し合っているレベルの不一致または誤解によるものです。 または私たちが運営しているレベル。

多くの場合、チームの1人が影響レベルで操作し、考えていることに気付くでしょう。 そして、別の人が実行レベルで考えています。 しかし、彼らはそれについて話していません。 彼らは状況の細部を訴訟しているのですよね？ ですから、典型的な例は、本当に一生懸命働くPMです。 つまり、実行レベルで動作するPMは、すべての可能性に対して非常に懸命に機能します。

彼らは素晴らしいカードを配られませんでした、しかし彼らはこの製品を実現させましたね？ 製品のように現実です。 彼らは満足している。 チームは幸せです。 エンジニアリング、製品管理、設計、データサイエンス、それらすべては、コア製品に取り組んでいる人々であり、彼らが何かを構築することに非常に興奮しています。

右。 そして、彼らはそれをあなたのエグゼクティブレビューに持っていきます。 またはローンチレビュー。 もちろん、ローンチレビューにはいくつかのデモが含まれています。 繰り返しになりますが、戦術は同期的または非同期的にどのように行われるかは関係ありません。 ポイントは、レビューされることです。 インパクトレベルで業務を行っているプロダクトエグゼクティブがいます。 そのため、製品の幹部は製品を見て、基本的なメッセージはこれでは不十分だということです。

ジョン・カトラー：脅威メーターが発砲します。

Shreyas Doshi：コルチゾールレベルが上がります。

ジョン・カトラー： …増やす…

Shreyas Doshi：そして、PMはイライラしています。おそらく、PMマネージャーも混乱しています。 ここにたどり着くまでに私たちが取り組まなければならなかったすべての困難を想像できますか？ これを起動することを許可する必要があります。 私はそれがこれらすべての欠陥であることを知っていますが、いや、いや、いや、いや。 これを起動することを許可する必要があります。

したがって、ここでの問題は経営幹部です。彼らは影響レベルで業務を行っており、ブランドへの影響について考えています。これは、これまでの水準よりも低い品質で製品を発売することです。 。 人々はすぐに修正について話し始めるので、それは興味深い状況ですよね？

これは、ああ、ご存知のとおり、これを1つまたは2つ変更する可能性があります。繰り返しになりますが、これらすべてについて話すことが重要ですが、最初にその不一致を認識することが重要です。 また、PM、エンジニアリングリード、またはデザインリードにとっては難しいことになると思います。 心理的安全性の観点からのように、そこにいる人々がこれにフラグを立てることは難しいでしょう。

したがって、経営幹部がより良い運営を行う方法、そしてこれはすべてのレベルの人々に当てはまりますが、チームが自分たちのしたことを誇りに思っている理由を認識することです。 そして、それらはその実行レベルで動作しています。 そして、明示的に呼びかけます–ああ、これは十分ではない、またはこれは基準を満たしていないなどの代わりに–これは実行レベルでは素晴らしいです、これは影響レベルでは不十分です、どのように私たちはあなたを達成することができますか知っている、ここでより良い結果？

これについて最後に言うのは、ここでの例の一部として、多くの場所で、人々が製品の作業をしているときに光学レベルを最適化していることがわかります。 CEO、創設者、または強力な幹部が、人々がただ飲み込んでいるという本能、または創造的なアイデアを思いついた。 右？ ボブがこれを言ったので、これに取り組みましょう。

ジョン・カトラー： …そして彼らは非常に決定的でした。 もちろん、彼らが決定的だったようなものです。 彼らはCEOであり、あなたは皆彼らの話を聞いています。

Shreyas Doshi：もう1つは、サイドカンバセーションのようなものです。多くの場合、これはうまくいかないと思います。 しかし、たとえば、これはボブが望んでいることなので、これを実行します。 ちなみに、必ずしもトップダウンである必要はありません。 右？ それが時々反対方向でもあるように。 右？ あなたは何かを構築し、光学を管理するために実際よりも成功していると考えています。

だから私は光学が悪いと言っているのではありません。 実際には、ある程度の光学系を管理する必要があります。そうすれば、作業の影響と実行の品質を忠実に表現できます。 光学レベルは、他の2つのレベルに役立つはずです。 したがって、そこで十分な作業を行う必要があります。 しかし、主に光学系を最適化するチームはたくさんあります。

人々はインセンティブについて、そして人々が基本的にインセンティブに従う方法について話します。 等々。 インセンティブの言葉は使いません。 ここでのより根本的な問題は、あなたの文化と組織が、実行に向けて管理したり、影響に向けて管理したりするのではなく、人々に光学に向けて管理するように強いるということだと思います。

認知バイアスと共有語彙[00:54:37]

ジョン・カトラー：それで、認知バイアスの世界での私の旅の一部は、ある時点で私がそれに夢中になっていたからです。 私は、認知バイアスについて知っていても、それを打ち消すのに効果的な方法を研究し始めました。 そして、それに遭遇するたびに、埋没費用の誤謬と戦う私の能力にはあまり効果がありませんでした。 何がうまくいかないのを見たことがありますか、そしてこれらのことを打ち消そうとするという点で[00:55:00]何がうまくいくのを見ましたか？

Shreyas Doshi：つまり、チームのために作成する共有語彙についてだと思います。 そして、共有された語彙は、単なる認知バイアスよりもはるかに広いトピックであり、非常に重要だと思います。

チームを健康に、またはより健康にしたいと思うなら、おそらくあなたがしている仕事の周りであなたのチームが共有している語彙は何であるかを考えてみてください。 そして、私はスクラムやその他の業界の流行語を意味するだけではありませんよね？ つまり、いや、いや、いや。 標準的な製品管理の資料の一部として表示されていないが、チームと共有しようとしている語彙は何ですか。 なぜこれが認知バイアスの文脈で機能するのか、誰かがボブと言うのは非常に難しいのですか、あなたは埋没費用の誤謬、または利用可能性ヒューリスティック、またはあなたが持っているものの餌食になっています。 ほとんどの組織では、誰かができることは非常に困難です…

ジョン・カトラー： …あなたが言っている標準的な運賃会議の話ではありません、それはそうではありません、ありがとう、ええ、私はただ埋没費用の誤謬を指摘したいと思います...ズーム会議はかなり早くシャットダウンします。 その人が始めたら…

Shreyas Doshi：その通りです！ ええと、それは、ああ、この人は人とうまく働かないようなものです。 または何でも。 右。 人々が得るように…

ジョン・カトラー： …彼らはあまりにも多くの本を読んだ。 ええと、

Shreyas Doshi：彼らにはラベルが割り当てられます。 ですから、それを知らせることが重要だと思います。 これが、私が個々の認知バイアスについて話さない理由です。 私は通常、チームのレベルでの認知バイアスについて話します。 右。 そうすれば、チームとして、これが私たちに起こり得るような会話をするのがはるかに簡単になるからです。 私たちは死刑執行の誤謬の餌食になる可能性があります。 ここで、実行するのに適切なチームではない場合でも、実行が容易であることがわかっていることを実行することにしますが、それは私たちに開始の満足感を与えます。 そして、何かを作成することの満足感。

あなたがすべての人に知らせたら、そして次にリーダーとして-私が言おうとしていることの責任は完全にリーダーにある-と言うことです、見てください、私はこれの餌食になります。 そして、グループとして、私たちはこれの餌食になるかもしれません。 これについてお話しすることを期待したいだけです。 そして、これが起こっているのを見たら、これにフラグを立てます。

これにフラグを立てれば、それは弱点ではありません。 それは実際にはその反対です。 私たちは本当に何が起こっているのかを認識し、おそらくより良い決定を下すか、より良い結論に達することができるということ。 だから私は共有された語彙だと思いますそしてそれから私が今言ったことは共有された説明責任です

私は一般的に説明責任という言葉が嫌いですが、それはまったく別のトピックです。 しかし、私はこの文脈でそれが好きです。それは、私たちが犯しているかもしれない間違いについて、お互いに思い出させ、チームとして自分自身に思い出させることについてのチームとしての一種の共有された説明責任です。 または私たちが持っているかもしれない明確さの欠如。

一例として、私が最近行っていたこのプロジェクトがあります。これは、未知数が多い非常に野心的なプロジェクトでした。 私は前もってチームと共有しました。実際、その場合、私は2つのことを共有しました。 1つは認知バイアスに関連していました。つまり、ご存知のように、私たちはこれら、これら、これらの認知バイアス、またはチームの認知バイアスの餌食になる可能性があります。

それで、それらに注意しましょう。 2番目にフラグを立てたのも、詳細は重要ではありませんが、非常に複雑な状況であり、複数のチームが関与しており、それらのチームはあまり協力していませんでした。 彼らは初めて働くようなものでした。

そして、私は彼らと共有しました。ここで私たちの邪魔になる主なことの1つは、特にこれらのチームの境界を越えて、私たちが互いに直接的でオープンにならないことです。 それはおそらく、私たちが犯す分析的な種類の間違いよりも、このプロジェクトがうまくいかない原因になるでしょう。

私はそのグループでそれをさらに明確にしました。 私は、お互いにうまく働き、お互いに直接向き合い、お互いの視点を理解する能力、そして何よりも心配しています。 私たちが話している他の種類の分析的なことのいずれか、それは、ああ、この限られたスペースなどの中でこれらの3つのナビゲーションオプションにどのように適合するかなどです。 それは私たちの成功を決定するつもりはありません。 私たちの成功を決定するのは、私たちがこのことについてお互いに難しい会話をする気があるかどうかです。 そして、私たちはお互いに、そしてお互いの視点に耳を傾けることをいとわないでしょうか？ 私が好きなもう一つの戦術は、私も指摘したいのですが、これは非常にふわふわしているので、これはばかげた会話だと思っているかもしれませんね。

それは分析的なものではないように。 しかし、あなたがそれを考えているなら、私の[01:00:00]の要求は、実際にそれについて私に話してくださいということです。 私たちは皆、お互いにオープンである必要があります。 これが時間の有用な使用法ではないことに気付いた場合、それはあなたが実際に私にオープンである必要がある最初のことです。 など…

ジョン・カトラー：あなたは彼らにあなたが彼らに勧めるという彼らの懐疑論を予想しています…私はそれが好きです！

Shreyas Doshi：うん。

ジョン・カトラー：基本的に、ここですべての拠点をカバーしようとしています。

Shreyas Doshi：この状況で私がしなければならなかったもう一つのことは、私たちが一緒に仕事をする予定だったチームメンバーの何人かと一緒に仕事をしていなかったからです。これをもう一度強調するために、主要なチームメンバーの何人かと一緒に。 ほら、これがチームリーダーとしての私の関心事のようです。

そして、一般的に、物事がうまくいかないときに、彼らが一種のオープンで共有する能力とエージェンシーを感じるように、彼らを十分に知るようになること。 つまり、これはデフォルトに逆らう例です。 一般的に、私はこのような定期的な1対1のチェックインを避けていますよね？ 追加を続けるだけで、ある範囲では、カレンダーを引き継ぐことができます。

ジョン・カトラー：過去5年間、毎週それをやっていたら、たくさんの友達を作ることはなかっただろう。 その答えの素晴らしい部分は、人々が認知バイアスについて学ぶとき、それはクレイジーだと思います。 彼らがしていることは、彼らがいつものようであるということです、まあ、これは他のみんなの狂った行動を説明しています。 あは。 今、私は幹部が彼らのように振る舞う理由を知っています。 誰もが最初に認知バイアスについて考えるとき、誰もが根本的な帰属のバイアスを経験するようなものですよね？

Shreyas Doshi：個人として、またはチームとして、ほとんどの認知バイアスを信じたくないのであれば、信じたくないのなら、多分それは大丈夫だと思います。 確証バイアスと根本的帰属のバイアスの2つをしっかりと信じている限り。

ダッシュボードを製品として扱う[01:01:51]

ジョン・カトラー：はい！

少しだけギアを切り替えて、本当に長い間お聞きしたいと思っていました。 あなたはダッシュボードを製品として扱うことについてこのことをしました。 そのためのインスピレーションは何だったのか、その考えは？

Shreyas Doshi：それは、ダッシュボードの使用方法について私が何年にもわたって行ったいくつかの異なる観察のコレクションでした。 そして、一般的に、製品チームがダッシュボードについてどのように考えているか。

ジョン・カトラー： …私たちが話している非常に分析的な人々。

Shreyas Doshi：うん。 そして、それは、ああのようなものです。 あなたはダッシュボードを持っているはずです。 ダッシュボードがあります。 それで、私が途中で行ったそれらの観察のいくつかを共有させてください。

まず、重要な機能または製品について書かれた多くのPRDがあり、この機能または製品のダッシュボードがどのように表示されるかをカバーしていません。 そして、それは大丈夫です。 同様に、私が求めているのは、その詳細なモックアップとしてここにあるわけではありません。

箇条書きを見せてください。 このように、使用状況の指標を理解するために追跡する指標は次のとおりです。たとえば、この機能はどのように使用されていますか？ ユーザーはこれで何をしていますか？ そして、2つ目はインパクトです。 影響指標に多くの焦点が当てられている場合があり、使用状況指標に十分に焦点が当てられていない場合があります。

ジョン・カトラー：もちろんです。

Shreyas Doshi：でも、私はそれを次のように主張したいと思います…

ジョン・カトラー：それを成功の指標とは呼ばないでください。 それなら心理的安全性について話してください！ それはすべてその時点で行われます。 主要業績評価指標、ご存知のとおり、それは…

Shreyas Doshi：はい。

ジョン・カトラー： …この時点では気にしないでください。

Shreyas Doshi：繰り返しになりますが、語彙は非常に重要です。 それは素晴らしいポイントです。 プロダクトマネージャーまたはその役割を果たしている人が所有する必要があります。

John Cutler：それを実現するには、多くのドメイン知識が必要です。

Shreyas Doshi：そうですね。

ジョン・カトラー： …使用法には独特の性質があります。

Shreyas Doshi：そして、ほとんどのチームには、ヘルスメトリックである他のカテゴリのメトリックがあります。 通常、エンジニアリングチームは、適切なインストルメンテーションとそのための適切なダッシュボードを使用していることを確認します。

それは最初の観察のようなものです、私たちはそれを適切に特定していません。 右。 したがって、2番目のことは、チームがそれを指定し、ダッシュボードまたはいくつかのメトリックの電子メールが何であるかを気にしないと仮定しましょう。 何かが構築されるように、それは今あなたに重要なことへの洞察を与え始めます。 人々がそれをどのように使用しているか、採用とは何か、影響とは何か、それは素晴らしいことです。

私が行った2番目の観察は、誰もそのダッシュボードを見ていません。

ジョン・カトラー：これらのツールの1つを提供している誰かに基づいて、このダイナミックさを確認できます。これらのツールの多くは、森に落ちる木のようなものです。 ダッシュボードの墓地があります。 そのようにしましょう。

Shreyas Doshi：確かに。 これがあなたとあなたのチームである場合、たとえば、気分が悪くなることはありません。 これは、私がさまざまな時点で遭遇したものの90％です。 右。 うん。 このダッシュボードの作成には、このすべての努力を費やしました。 ほとんど誰もそれを見ていません。

だから、それは第二の種類の観察でした。 これに気づいたので、気付いたのは、ちょっと待ってください。 私たちはメトリクスダッシュボードを実行していません。[01:05:00]私たちが言うことは私たちの製品に対して正しいことです。 したがって、ここには特定の種類の自己参照があります。 つまり、私たちが製品を構築する場合、その使用状況を追跡したり、メトリックを追跡したりすることが正しいことであることは明らかです。

したがって、製品への洞察を与えるダッシュボードを表示している場合は、それを製品自体として表示してみませんか。 ダッシュボードの使用状況を追跡します。 たとえば、単純なカウンターのように。 過去1週間に作成に多くの時間を費やしたこのダッシュボードを閲覧した人の数。

右？ 例として、それと同じくらい単純なもの、ビューカウントだけです。 そして、それを見て、ちょっと待ってください。実際にメトリックを見ている人は誰もいません。 つまり、2つの可能性が生まれます。 1つは、洞察や意思決定の観点からは役に立たないということです。 または、私たちと同じように、解決する必要のある問題があります。 しかし、それを製品として考えた場合にのみ、それを始めることができますよね？

もちろん、ダッシュボードを製品として考え始めたら、ダッシュボードの要件を作成し、それを元のPRDの一部にします。 これは、私たちが追跡する必要があるものです。 これが、追跡する必要がある理由です。 これが私たちがそれを追跡する方法です。 そして、その使用法などを理解できるように、ダッシュボードに物事を明らかにインストルメントします。

そして最後の部分は、これらすべての大部分は意図や能力などではないということです。 これらのことが起こるのは人々が無能だからではないと思います。 難しいからだと思います。 実は摩擦と同じくらい簡単だと思いますよね？ これは、忙しい日に行うことについて考えなければならないもう1つのことです。 あなたはそれが正しいことであることを知っています。 たまに使用状況の指標を表示するのが好きです。 または、少なくとも次の決定を行うときにそれらを参照してください。

しかし、摩擦があります。 あなたが管理しなければならない認知的負荷があります。 そして今、再び、それを製品として考えると、摩擦をどのように排除するかという観点から考え始めることができますか？ それが私たち自身の製品で行っていることですよね？ ユーザーの摩擦とは何か、そしてそれをどのように排除するかについて考えるように。

そして、それは興味深い可能性につながります。 私が長年持っていた習慣の1つと同じように、現時点では、Chromeにピンタブがあります。 そして、固定されているメール、Slack、カレンダーがあります。 固定されている他の1つは、メインのメトリックダッシュボードです。 だからそれはそこにあります。 新しいタブを開いたり、URLを入力したりする必要はありません。そこにあるだけです。 私が気付いたもう一つのことは、人々が電子メールの測定基準を愛していることです。 なんで？ 摩擦を取り除くからですよね？ 表示されるだけです。 そして、少なくとも私たち自身との間で、電子メールを見る必要があるというこの種の契約があります。 したがって、最終的に発生するのは、人々が積極的に探さなければならない一種のメトリクスよりも、電子メールで送信されるメトリクスをはるかに注意深く見ることです。

重要なプロジェクトの場合は、要約メールも送信することがよくあります。 ティーザーの高レベルの統計情報と同じくらい簡単で、ダッシュボードへのリンクだけです。 あなたに電子メールで送られるそのリンクでさえ、あなたにとってはるかに簡単になり、摩擦を取り除くでしょう。 それについて考えてやらなければならないのとは対照的です。

いっぱいのカレンダー、反応性、自己同一性、そしてポジティブ/ネガティブな習慣[01:08:20]


ジョン・カトラー：これらの人々のカレンダーを見ると、常に反応モードにあるこれらのPMを見ることができます。 彼らがこのことについて考える瞬間さえないこと。 あなたが彼らに与える最初のアドバイスは何ですか？ 彼らはこれをどのように統治しますか？

Shreyas Doshi：私はPMキャリアの最初の5年間を極度のストレスにさらし、かなりの程度の防御を常に行っていました。 物事がバラバラにならないようにする必要があります。 それが私がしているすべてであり、それは私のすべてのエネルギーを消費しています。 そして、その大部分は、もちろん、私はその役割においてはるかに能力が低かったと思います。 そのため、以前は時間がかかりました。 ですから、学習曲線があり、その学習曲線にはコストがかかることを軽視したくありません。 そして、それは誰もが経験する必要のある旅です。 右。 それで。 うん。

必ずしも悪いことではないと思います。 あなたは習慣という言葉を使いますが、そこに問題があると思います。 これが起こるのは、これらの初期の年、製品マネージャーとしての私たちの形成期のために、私たちは特定の習慣を身につけます。 たとえば、私たちが実際に行っていることにかなり優れていると仮定すると、成功が見られます。 そして、あなたは確かに、大丈夫、ええ、私は正しいことをしているようだと思います。 だから私はそれらのことをもっとやるべきです。 チームのすべてのエンジニアと毎週1対1で連絡を取り、何が起こっているかを確認し、個人レベルなどで彼らとつながることは非常に役立ちます。 だから私はそれをもっともっとやるつもりです。 素晴らしい。 チームに10人のエンジニアがいる場合に機能し、より多くのスコープがあります。 今は20、次に30です。[01:10:00]何、あなたは何をしますか？

ジョン・カトラー：そうですか？ そしてその間、彼らはすべてのエンジニアとそのような素晴らしい関係を持っていると自負し、自己認識します。 の1対1のブラックホール…

Shreyas Doshi：うん。 ジョンIは、それが何か面白いことを引き起こしたと思います。つまり、おそらく2つのことだと思います。 それは習慣とアイデンティティです。 それが私。 これが私のやり方ですよね。 ああ、あなたが話していること、またはこの他の人が話していることですか？

いいえ、いいえ、いいえ、いいえ、それは私にはうまくいきません。 右。 私が違うように。 これが私のアイデンティティであり、これが私の運営方法です。 ですから、習慣とアイデンティティがあります。 そして、私はいつも、それが完全に管理できない状況にある人々を見ています。 彼らは何をすべきかわからない。

彼らはこれがそうだと思っているだけです。 時々彼らのマネージャーは彼らに言うでしょう、ええ、これはPMの仕事がどのようであるかです。 私のカレンダーを見てください、それはさらに悪いです！ そして、この少しの比較もあります。これは、カレンダーが悪いようなものです。 そして、その人はもっとPMですよね？

習慣とアイデンティティの問題のため、これはとても難しいです。 これは、ここに別の道があることを人々が受け入れるのは難しいです。 あなたが聴衆について考えるならば、これがリリースされるときはいつでも、彼らはこれを聞いています。 確かに、ここで議論されていることは私の状況には当てはまらないと言う人々がいるでしょう。 そして、それは私の上司のせいで、私の会社には当てはまりません。この理由で、私のチームが違うので、私が違うものは何でも、私はより大きな野心を持っています。 ですから、私が言いたいのは、実際にはもっと良い方法があることを認めるまで、これを解決することはできないということです。

これが現状であると考えるのではなく、この問題を解決したいということを理解する必要があります。 But once you start entertaining that thought, that there are other ways that this problem can be solved or at least should be mitigated, now we can talk. 右？ So now we are at a smaller part of the audience that is really stressed, but it's perhaps more open to sort of exploring those ways.

And then what I would say this goes back to the role of a product manager and particularly the role of a product leader. Remember we talked about building self managing teams. 右。 Well, what happens when you actually build self managing teams? You have to do less management, right? Because they're self managing. That's sort of the goal. Now, it doesn't solve the problem because how do we get to the goal?

The way one needs to think about these situations is you know, yes, I can stay on top of everything. And you know, in some cases, like we talked about, the context requires you to stay on top of everything. But, you don't have to make that your default, and you don't have to do it in every single situation.

So one of the things I like to tell, especially new managers, is assume there are things you are not going to be on top of. Because then you will have to go to every single meeting. You'll have to accept every single input in order to, sort of, figure out what to do.

So assume that's not going to happen. And what you need to do is to figure out ways in which now you're going to get those inputs through people on your team. And you are going to organize your one-on-ones in a way that you're able to get those inputs. You're, uh, you're going to organize rituals on your team, whether it's product reviews, or other rituals on execution check-ins or what have you, in order to get the right signal .

This is all easy for me to say, but it is hard to do, and it requires practice. And it requires trying to identify your unique style of doing it, et cetera, et cetera. But the beautiful part, when you cannot like, do this, and do this with some degree of success, is now all of a sudden you are able to be much more useful, and much more effective, right?

You are able to get more clearly to the thing that matters, right? You are able to help your team members. You are kind of like coaching them through experience around expressing to you the stuff that matters. 右。 And then you are able to also give them the independence, and the leeway, to be able to operate on their own versus kind of handling them through all of this.

Improving the current situation (and gap vs. present thinking) [01:14:24]

So, concretely, the common sort of argument I hear is yeah, yeah, things are horrible right now, but it's because I don't have a full team. Like I have this four or five head count. Once I get these people, and get them to be productive, things will be better. And guess what happens? You get those four or five engineers on the team, or four or five PMs on the team if you're a PM manager. Situation is worse, not better. But at that time, it's like, oh, you know the problem is we are not organized properly. My team should not [01:15:00] belong to this organization. It should be in this other part of this organization. And that's what's creating the problem for me. You know, so it's like this, kind of, basically we are on the treadmill forever right?

I'm not discounting the validity of these reasons. What I am suggesting is that regardless of external factors, which we should try to improve, and we should feel high agency towards making the organization better, and improving whatever situation we are in. But we need to also be very cognizant of how I can best manage the current situation I'm in. Versus like, basically I noticed that especially the managers and product managers that tend to get extremely stressed, and let the work affect all parts of their personal lives and whatnot is… they're constantly looking for the next thing that is outside of them that's going to fix this issue. And then that results in burnout, that results in frustration when it doesn't happen. And they don't pay enough attention to, okay, given this current situation, what do I need to do differently?

John Cutler: My friend Jabe Bloom has this interesting thing, which is gap thinking versus present thinking. And he makes the point that standard business school, standard consulting is all about the gap. What's the current thing? Exactly where do we need to go? How are we going to get across that particular gap?

Like that's a very tried and true way to think about it. And then he presents this other idea that present thinking is not adverse to thinking ahead. It's like, what's going on right now? What do we visualize as the better version of right now? Where do I have agency to act right now? Instead of just the gap, you know, it's like there and you have to go across it. It's kind of like little mini gaps, right. But the one part, the one thing you said that really resonates there is, you know, in some ways, as humans by, gap thinking is always a way to also “other” the problem.

It's the tendency of people to combine gap thinking with fundamental attribution bias, which is like, not only is there a big gap that we need to get across and there's the perfect plan to get across it. But the road involves other things in the org that have to happen, et cetera, to make it to it.

So I don't know if that's, I've liked that distinction between gap thinking and present thinking. One thing that's hard is that a good chunk of modern business is centered around gap thinking. What's the gap, bring me solutions, not problems, you know, like how are we going to get across the gap all the time? それで…

Shreyas Doshi: Yeah, that resonates a lot. One other thing I want to share around this topic of PM stress and this constant feeling of inadequacy, and I'm not doing enough to move the product forward, and and my schedule is crazy, and I'm just not able to perform at the level I need to et cetera, et cetera. All of which, by the way, again, a common theme is this was me for the first five PM career. And I used to share all of this with my wife all the time and like, you know, huge kudos to her to just like, listen…

John Cutler: She taught you how to listen…

LNO: Leverage, Neutral, and Overhead Tasks [01:18:10]

Shreyas Doshi: Exactly. So I think one key thing that was a turning point for me was the understanding of —uh, and I don't even know where I read it, it was some blog posts that I read and what I'm about to share is a paraphrasing of that, I can't find the blog post anymore for whatever reason— but it's what I termed as the LNO framework for PM effectiveness. Which is the observation that there are three kinds of tasks that I tend to do as a PM.

There's a leverage task, there's a neutral task, and then there's an overhead task. The leverage task, you know, as the name suggests, gives greater than what you put in. The neutral task will give you the same. And the overhead tasks will give you less. What most PMs do, and certainly what I did during those highly stressful days of my career as a PM, was I approached every task, any given task in the same way. Which is, oh, I'm going to try to do an awesome job. I was like some, you know, inner perfectionist, et cetera, et cetera. So I would spend a ton of time without understanding whether this is a leverage task, a neutral task, or an overhead task, right?

And, and what's right for the company you work for– and certainly for your team and very likely for you– is for you to understand that upfront. And then, you know, adjust the amount of energy and the amount of time based on that understanding. And I think what that does is, it certainly did for me, is it means spending more time and exerting more energy on certain things.

Because now you understand that this is a leveraged task. So instead of spending two hours on writing that, you know, completing that PRD, maybe you ought to spend four hours today to do that. Now of course, that extra two hours have to come from somewhere else. So find out [01:20:00] what are your neutral tasks or overhead tasks.

And so one example of, you know, usually a neutral, sometimes an overhead task, is you will get some requests for certain reports from finance, like, what's our 24 month projection for how the product is going to– like how much headcount do you need or whatever. Now, you know, I look at those things and, you know, there's the perfect way of doing it. And I see all these sometimes PM leaders, especially going to these meetings, and talk about all the analytical stuff of what's going to happen in September of 2022. And, November of 2023. And people are having all these discussions. Again, it goes back to, oh, we think we, we have certainty around what's going to happen.

They end up spending a ton of time on all of these things. And, what I typically do is like, again, usually– you know, sometimes it's an exception– but usually when I get these requests, I get them done in five, 10 minutes. 右。

Like these, these are the assumptions. どうぞ。 And if you need something more detailed, then please let me know how this is going to materially change, you know, things from a budgeting perspective or something else.

So that's just an example of where you kind of get back that time. And what I found is that as I started doing more and more of this, and on a tactical level what I would do is I created the to-do list, I would actually prefix the task just as a reminder to myself with L, N, or O .Right?

So when I started doing the task, I was like, okay, this is a leveraged as to how I'm going to approach

Conclusion [01:21:23]

John Cutler: I love that. I love ending with something really actionable. And so that's something that I'm going to do with the rest of my day too. To do these things. But, Shreyas, I wanted to thank you. We could have gone on for hours cause there's just so much, uh, so many questions I have. And I'm amazed too, about your ability to weave in and out your frameworks too. So you've actually inspired me thinking about how to be more actionable in these types of conversations. Because you've left people with specific frameworks, but we also went really deep into everything about intentionality, and culture, and stuff. So I really, really appreciate it.

And I'm super grateful for the opportunity to chat with you. And yeah, we'll stop now. But we should do it again at some point. Maybe people will have questions. Maybe we could do a follow-up like rapid fire, uh, answers to those questions if that would work for you.

Shreyas Doshi: Yeah, I would love that this was a blast. あなたが正しい。 We could have gone on for hours and this is fun stuff. So thanks for that.

John Cutler: I want to leave people with that one thing that Shreyas opened with. We've both probably learned the hard way. So when you see us tweeting assume that we've made the mistake 55 times, and we've had to work through it, context always matters, that would probably be like a footnote on those things. And three, I loved your statement too. You know, if you're in an unhealthy environment, you know, don't just assume you can just jump in. I think taking care of yourself, that's my theme, you know, as the tail end of the pandemic, is that people need to take care of themselves too.

Product Analytics for Dummies