プロダクトマネージャーとして駆け出して失敗したこと3選

こんにちは！
僕はこれまで十数年ほどソフトウェアエンジニアとして仕事をしてきましたが、直近の3年間ほどプロダクトマネージャー(以下PdMと書きます)の役割を担当してきました。

ここ数年で各社PdMのポジションが置かれることが一般的になり、その中で僕のように元々エンジニアをしていた方が役割を変えてPdMを担うようになった場合もどんどん増えているのではないでしょうか。

PdMとして駆け出してここまで約3年間でいろいろな試行錯誤をしてきて、自分の思考の整理のためにPdMについての記事を書きたくなりましたので、モチベーションがあるうちに勢いで書きます📝

この記事に書いてあること

この記事では僕が過去に経験したいくつかの失敗を言語化してみます。

最近ではカンファレンスや様々な記事で各社のPdMの方々の取り組みや成功事例を知れる機会も増えてきました。
僕も何か成功体験について語れるとかっこいいのですが、僕自身はPdMとして「大成功した！」と胸を張って言えるような実績は残念ながらまだありません😢
ですが、過去を振り返ってあれは間違いなく失敗だったな〜と思うことがいくつかあり、これからPdMとして駆け出す方々には他人の失敗経験を知ることも少しは有用なのではないかと思うので、自分の失敗経験を共有してみようと思いこの記事を書くことにしました。

これからPdMとして駆け出す人も、経験を積んで「昔はそういうこともあったな〜」と思い出したい人も、気が向いたらぜひ読んでみてください💁‍♂️

プロダクトマネージャーとして失敗したこと3選

この記事での失敗のお品書きはこちらです💁‍♂️

• 1. 開発チームの稼働が空かないことを最優先にしてしまう😇
• 2. 手早く成果を実感できるタスクに流されてしまう😇
• 3. 失敗しないことに注力してしまう😇

1. 開発チームの稼働が空かないことを最優先にしてしまう😇

どんな状況だったか

プロダクトチームが動き始めたばかりの時やプロジェクトが一段楽した切れ目のタイミングでは、今すぐ着手できる開発アイテムがまだなかったり、過去に積まれていた開発アイテムはあるけども今やらなくていいよねというものばかりの状況になると思います。

僕がPdMをやり始めた時はプロダクトチームの動き始めに近い状況で、事業の目標や自分たちがどんな数値を伸ばすことを求められているかはある程度ハッキリしているものの、何をどうやって対処していくかの具体策は見えてないという状況でした。

どんな失敗をしたか

動き出したばかりのプロダクトチームではエンジニアからはとりあえず「何やったらいいですか？」ということを聞かれます。(それはもう頻繁に！)
そこで僕は、パッと思いついて比較的手がつけやすい既存機能の改善や、現状を把握するための調査系のアイテムなどを用意しました。
が、エンジニアのメンバーが優秀で手がとても速かったこともありどれも一瞬で完了してしまいました。

元々スクラムでの開発をしていたことからそれを引き継いで1週間スプリントでのスクラムによる開発としていたのですが、1週間分のつもりで積んでおいた開発アイテムが2-3日で全て完了になってしまうような状況でした。しかも今スプリントでさえやることが枯渇しているのに、それに加えて次スプリントにやることも見繕っておかなければいけません。

こうなるともう完全に自転車操業で「とりあえずエンジニアのみんながやることを少しでも多く用意しないと・・・！」という気持ちでいっぱいいっぱいで、開発アイテムが足りない状況で次のスプリントを迎えることがすごく怖くなっていました。

この時の僕は 「エンジニアの人たちがやることをひたすら用意するマシーン」 と化してしまっており、本来PdMが向き合うべきと思われる、ユーザーが抱えている課題、それをプロダクトでどう解決するか、どのようにターゲットを広げていくかなどの「プロダクトマネジメント」が全くできていない状態に陥っていました。

どのように対処したか

当時僕のマネジメントをしてくれていたCTOと2週間おきに1on1をしていたのですが、開発アイテムの用意に追われている状況を話すと 「1回開発止めませんか？」 と提案してくれました。

いやもう、この一言を言ってくれたあの瞬間の後光がさす感じは一生忘れないです。
それくらい僕にとって救いの一言だったと思います。

その後プロダクトチームでの開発を完全に止めて、問題理解のためのユーザーインタビューや行動データの解析をする期間を2ヶ月取らせてもらいました。
この期間に「エンドユーザーDeep Dive」という名前をつけて、僕とユーザーサクセスの担当者と2人でひたすらデータを深掘って仮説を立て、開発しなくてもやれる改善案を検証するのをひたすらやっていました。

そうして得られた調査結果を元に、今後プロダクト開発で注力する課題と今後の計画をまとめてプロダクトチームを再始動しました。
その後は開発の計画が劇的に進めやすくなり、以前のように「何やろう・・・」と詰まってしまう時間はほぼなくなりました。

この失敗を通して問題設定がいかに重要かというのと、そのために多くの時間を費やす必要があるということを身をもって実感しました。

なぜこの失敗をしてしまったか

過去に開発プロジェクトのマネジメントをした経験がそこそこあり、開発の計画を立てて推進するスキルはある程度あるだろうと自負していたのですがこの時は全くダメでした。

なぜ最初から開発アイテムを用意できなかったのか？を考えると、現状の問題への理解が足りなかったからです。
PdMとしてどうやって問題設定をしていけばいいかが分かっておらず、そのスキルが不足していたことは間違いなく失敗原因の一つでした。
この"問題設定"はいわゆる要件定義の前提になるもので、それとは全くの別物だというのをこの経験を通して強く実感しました。プロジェクトマネジメントの経験が豊富にあるからといって問題設定ができるというわけではありません。

それに加えて、CTOからの提言で開発を止める頃には、問題の深掘りにもっと時間を使わないと無理だということには気づき始めていたんですが、それでも自分の口から「開発止めさせてください」とは言えなかったです。
それどころか、自分が今苦しい状況になっていることも当時は正直に話せていなくて「何とかやってます！」というようなことを言ってしまっていたと思います。
これは今思えば、 任されている仕事に対する敗北宣言をしたくない 感覚があったからなんですよね。

この気持ちを"キレイに"言葉にしたら「自分を信頼してアサインしてくれた人を裏切りたくない。期待に応えたい。」みたいなことを言ってしまいそうですが、結局は 周りの人たちから自分が無能だと思われることへの恐怖があり、自分のプライドを守りたかっただけ だった、と振り返って分かりました。

これを乗り越えるためには、無能だと思われることに対する勇気というか、その先に本質的な成果を出せるならそれは大したことではないと思えるようにする気持ちの切り替えが必要でした。

2. 手早く成果を実感できるタスクに流されてしまう😇

どんな状況だったか

PdMが成果を出して評価されるのは、何らかの施策を実施してその結果プロダクトの数値が伸びた時、ひいては事業の数値が伸びた時です。

しかし施策を実施した後にハッキリと結果が分かるのはすごく速くても1週間後だったり、1ヶ月以上の時間がかかる場合も多々あり、やった手応えを感じられるまでに時間がかかることが多かったです。
「自分がこれをやった！」と成果を実感できる時がなかなか来ない感じがしていました。

またエンジニアをしていた時と違って自分が手を動かして開発を進めるわけではないので、それに対する漠然とした不安みたいなものもありました。

どんな失敗をしたか

開発チームでの設計の詳細な部分の議論に入ったりプルリクの内容を見たりして「こうした方がいいんじゃないですかあ〜？？？」と小言を申したり、何なら自分でコードを書いてしまうこともありました。
その他にも、データ分析と称してひたすらSQLを書いてデータをこねこねしてそれによって得られた示唆っぽいものをドキュメントにしたりと、そういったわかりやすく手を動かせるタスクに多くの時間を使ってしまう時がありました。

こうすることで 「何かやっていて忙しい感」 を自分に対しても他のメンバーに対しても演出できますし、手を動かせば動かしただけの成果が実感できます。そんな誘惑に負けてしまっていたという感じです。

その結果PdMとしてやるべき調査や企画にあまり時間を使えていない状態になっていました。

恥ずかしいことに当初はそんな状況でも良くないとは思っておらず 「いうて自分エンジニアなんでいざとなれば自分で手を動かせますからねえ〜(ﾄﾞﾔｱ」 みたいな気持ちも正直どこかでありました・・・。
PdMが自分で手を動かせること自体は悪いことではなくて場合により有利なことではあると思います。でも当時の自分はそれが期待される責務ではなかったり、今それを最優先にやるべではない状況だったのが問題です。

ほんとに厄介ですねえ・・・。いや、ほんと、すみませんでした。

どのように対処したか

これについては明確にこれをやったら誘惑に打ち勝てた！というものはなくて、今でも自分で手を動かして成果を出したい欲求に駆られるときは多々あります。

でもそれを避けるために当時試していたのは、チームでの決め事をワーキングアグリーメント的なものとして明文化していたのですが、その中に 「PdMはコード見ない！絶対！」 というのを書いて、自分で宣言してチームメンバーのみんなに認識してもらうようにしていました。

またその意識を忘れないように、slackの自分のtimesチャンネルに毎朝↓の画像をポストするようにして、「絶対に開発に手を出さないぞ・・・！」と鉄の掟を定めてました。

※「開発以外全部」って書いてるように、本来やるべきことは開発そのものだけでなく山ほどありますよね。気が乗らないってだけで・・・。

これらにより自分の意識としてはもちろん他のメンバーもその認識してくれるので、僕が実装の詳細に関わらないように配慮してくれていたと思います。

またデータの分析が必要な場合には明確なタスクとして開発チームのバックログに入れて管理させてもらい、みんなの前に晒すことで余計な時間をかけすぎないようにしました。そして徐々にデータ分析の作業自体もエンジニアのメンバーに任せてできる限り僕は手を出さない状態にしていきました。

これらのタスクには強い依存性があるので、他のメンバーの力を借りてなるべく近寄らせないようにしてもらえたことが功を奏したと思います・・・。

なぜこの失敗をしてしまったか

冒頭に書いたように僕が経験したPdMとしての仕事の多くはすぐに達成感を得られない場合が多かったというところに要因があると思います。

そして同じ会社でエンジニアからPdMになった場合は、他のエンジニアとコミュニケーションがとりやすい分そちらに流れてしまいやすいですし、開発の詳細にも抵抗がなくむしろ話がよく分かる分居心地がよくなってしまいます。
その結果今やらなくていいことをやっていたり、それどころか他のメンバーの仕事を妨害する行動を取ってしまっていたんですね。

ですが、 本来のPdMとしての仕事はチームによって書かれたコードがリリースされてからがやっと本番 で、その機能をユーザーの方々に使ってもらい、その結果ユーザーの方々の行動が良い方向に変わって初めて成果を出したと言えます。
調査や企画なども含めるととても道のりが長いですし、思った結果にならないこともめちゃくちゃたくさんあります。

特に元々エンジニアやデザイナーのような職種をされていた方であれば、自分で手を動かして創意工夫により問題解決をすることに慣れていると思うので、自分が自ら手を動かさない・動かせない状況になるのは最初のうちはすごくモヤモヤやストレスを感じてしまうのではないと想像します。
それに負けずに頑張ろうな・・・！

3. 失敗しないことに注力してしまう😇

どんな状況だったか

問題の定義ができたとして、それを解決する何らかの策を実行するときにはよく「小さく検証する」ということが言われています。
これはリーンスタートアップと呼ばれる手法で、失敗した場合の損失を抑えることで失敗しても1発で退場になることを避けてまた次の打席に立てるようにするための作戦で、試行回数を増やして成功する可能性を高めることを目指すものです。

この手法は素晴らしいものなのですが、それを扱う自分が未熟すぎて「小さい検証の先に大成功を目指している」というのを忘れがちになってしまっていました。

どんな失敗をしたか

仮説検証ってなんかPdMっぽいし小さくスマートに検証するぞー！！！と意気込んでいたのですが、小さく検証するということを考えすぎて開発のスコープを小さくしすぎてしまい「これやっても何もわからなくね？？」という計画にしてしまったことがありました。

またそんな初歩的な失敗だけでなく、仮説検証に慣れてきてからも失敗を避けることをあまりにも意識しすぎてそれが目的になってしまっていました。
確かに1つ1つの施策では失敗による大きな損失を避けられているしそれぞれちゃんと学びは得られているけど、1つも大きな成功ができてないし、全ての施策にかかったコストをまとめると結果的にそこそこの規模の損失になっているのではないか？？ということに気づいてしまいました。

失敗による損失を抑えて次の行動に繋がる学びを得ることはいいものの、その先に大成功を目指しているという本来の目的がいつの間にか意識から抜けてしまっていたような気がします。

どのように対処したか

僕自身はまだPdMとして「大成功した！」と言えるような成果を出せたことがないのでどうすればこの失敗に陥ることを避けられるのかはまだよくわかっていません。

でも、元々目指している成功がまずあってその実現ための大きなリスクを少しずつ分割してキャンセルしていく、と進められるようにマネジメントできないと上手くいかない予感はしています。

なぜこの失敗をしてしまったか

非常に当たり前のことなのですが1つ1つの施策はあくまで成功すること、むしろ大成功させることを目論んで本来実施しているはずです。

しかし結果が不明瞭なことに大きなコストをかけるべく関係者の納得を得て予算を確保するのはとても大変です。なので「小さく検証する」を掲げて、失敗した場合の損失が抑えられるからやっていいよね、という論法を使うと物事を進めやすくなります。

ですが、小さく検証することによって成功したストーリーが世の中に沢山ある一方で、逆は必ずしも真ならずで、 全てのことが小さく検証できるかというとそうではなさそう に感じます。
なので多少大きめなリスクを負わないと、そこからは大きく先に進むことができないタイミングがどこかで来るはずです。

小さく検証することは少しづつ上手くなっていっても、気づけば多少のリスクを負って物事を進めることをずっと避けてきてしまった気がしました。

役職がない立場でも、役職があり権限があったとしても、大きなリスクを取るというのは正直とても難しいものです。
でも、本当に大成功をさせようとしたら、多少のリスクがあろうとも覚悟を持って賭けることから逃げることはできなそうです。
その覚悟があった上で小さく検証することを使いこなせたら上手くいくのかもしれないですね。知らんけど。

まとめ🍺

という感じで、今までPdMとして僕が失敗した！と思ったことの中から、駆け出しPdMの方々に役立てていただけそうなことを書いてみました。
改めて言葉にして整理してみると、今回書いた失敗にはスキル面よりも心構えとかマインド面の方が強く影響していたなーと感じます。

昨今ではPdMのスキルについて体系立てて解説されている本がたくさんありますし、pmconfのような第一線で活躍されているPdMの方々の話を聞けるカンファレンスなどもあるので、知識のインプットがとてもしやすくなりました。
一方で、どんな仕事でもそうですが、知識があるというのと実戦で使えるということの間にはすごく大きなギャップがあるので、スキルを高めていくためには自分で責任を負いながら実務を通して試行錯誤を繰り返すことは必要と思います。

これまでに他社のPdMの方とお話しさせてもらう機会がちょこちょこあったのですが、事業ドメインや組織により各社それぞれに違った状況があって、開発以外にも様々な問題に直面しているというのを感じました。「プロダクト」の対象範囲はとても広いので、PdMとして大きな成果を出すのはやっぱりすごく難しいことだよなと思います。

ただその分プロダクトマネジメントはいくらでも追求できる領域で、人の役に立って人に使ってもらえるものをつくって届けることを全方位で推進するためのポジションなので、僕のようにエンジニアを経験してPdMに挑戦される方がいたらぜひ希望を持って一緒に頑張ってほしいです。

ちなみに僕の直近のお仕事はまたソフトウェアエンジニアに戻るのでPdMとしての仕事をする機会はしばらくない予定です。でも今後またいつかPdMをやる日が来た時にこの記事を読んでかつての失敗を思い出そうと思います⭐

まだまだこの先の職業人生は長いのでこれからも山ほど失敗すると思いますが、折れずにやっていきましょう〜💪