見出し画像

エンジニアがプロダクトマネージャーになったら？

奥原拓也 / PdM / anynote

クラシルというレシピサービスを運営しているdely, Inc.でプロダクトマネージャー (PdM) をしている奥原拓也 (@okutaku0507) といいます。PdMの前は、サーバーサイド (Ruby on Rails) のエンジニアをしていました。

プロダクトマネージャーという役割が昨今、注目を集めています。不確実性が高く、変化の早い世の中において、事業の核であるプロダクトを成長させるために、プロダクトマネジメントの重要性が高まってきました。ITベンチャー、スタートアップにおいてプロダクトマネージャーを設置する企業が増えてきた一方で、プロダクトマネージャー人口はまだ潤沢とは言えず、社内育成や採用が難航しているのではないでしょうか。

僕もエンジニアからプロダクトマネージャーになった経験から、何回かイベントで登壇させていただく機会をいただき、エンジニアからプロダクトマネージャーになったキャリアについて話をしました。しかしながら、エンジニアからプロダクトマネージャーをすることのメリットやデメリット、醍醐味などを言語化したことがなく、体系的に考えてみたいと思いました。そこで、各社に勤めているプロダクトマネージャーの方にインタビューを実施して、言語化にチャレンジすることにしました。幸い、複数名の方にお話をお聞きすることができ、嬉しいことにエンジニア出身ではない方もお声がけいただき、自分にはない視点をいただけました。

このnoteは、僕を含め複数人のプロダクトマネージャーにヒアリングした結果を僕のフィルターを通して、僕の解釈をいれて言語化しています。そのため、話を伺ったそのままに記載していないことを先にお詫びいたします。

また、僕はエンジニアからプロダクトマネージャーになることに対して、良いも悪いも、どのポジションも取っていません。なぜなら、プロダクトマネジメントは総合格闘技であり、結果的にプロダクトマネジメントトライアングルで表せるように様々な領域の知見、経験が必要になります。もちろん、エンジニアリングの知見や経験は非常に役立ちますが、それだけでは戦い抜けないほど複雑です。できれば、エンジニアリング以外の知見や経験もあることは望ましいですし、プロダクトのフェーズや組織によってプロダクトマネージャーの立ち振る舞いは変化します。むしろ、変化の激しい世の中だからこそ、どんな領域でも越境し、素早くキャッチアップして、失敗しながらも実践を通して、改善していけるスタンスの方が重要だと思っています。

以上の理由から、このnoteがプロダクトマネージャーをされている方、これからプロダクトマネージャーを目指そうとされている方、これから社会人になろうとしてキャリアについて考えている方のご参考になれば幸いです。もし、内容について何か不明点やご意見がありましたら、Twitter (@okutaku0507) までご連絡ください。

どんなキャリアからスタートすべきか？

今回、エンジニアやセールスという役割からジョブチェンジしてプロダクトマネージャーになられた方に話をお聞きしました。面白いことに、プロダクトマネジメントになろうと思って、キャリアを歩まれていた方はいませんでした。今の組織やプロダクトにおいて、必要に駆られてジョブチェンジしたというケースがほとんどでした。エンジニアやセールスという役割でプロダクトの成功に関わり、プロダクトマネジメントに近しい部門間を越境するなどをしている中で、プロダクトマネージャーの道に興味を持ったということでした。

そのため、将来プロダクトマネージャーを志しているならば、主には三つの選択肢があるかと思います。まず一つは、キャリアのスタートをプロダクトマネージャーから始めることです。新卒としてプロダクトマネージャーを採用している会社もあります。そのような会社でキャリアをスタートさせるのが良いかと思います。なぜなら、プロダクトマネジメントにおいては結局全ての観点が必要になる総合格闘技であるため、どの領域にスペシャリティを持っていなくても徐々に領域を広げいく方法も一つの道だと思います。

もう一つは、プロダクトマネジメント領域のどれかのロールからスタートすることです。すなわち、エンジニア、UI/UXデザイナ、セールスのどれかあるいはその周辺領域です。いずれのロールも要件定義であったり、プロダクトマネジメントの領域と関わることが多くなり、振る舞い方によっては自然と素養が身についてくると思われます。最後に、将来的に携わりたい領域特化でのキャリアをスタートさせることです。具体的なロールの言及は避けますが、スポーツ業界あるいは人材業界などのプロダクトを担当あるいは立ち上げたいという意向があるならば、最初からその領域のどのロールでも、仕事をしてノウハウやドメイン知識をつけることは非常に良いかと思います。

しかしながら、上記に挙げた限りではありません。いつどんなチャンスが回ってくるかわからない不確実な世界だからこそ、誰がどうなロールになったとしてもおかしくないですし、総合格闘技のプロダクトマネージャーなので、全く関係ないロールからなったとしても、スタンス次第でどうにでもなると考えています。変なこだわりや固定観念は捨て去ってしまって、自分自身のキャリアは自分で切り開くぞくらいに思っておくのがいいと思います。

エンジニアからプロダクトマネージャーになるメリット

このnoteの本題に入っていきます。エンジニアのバックグラウンドが、プロダクトマネジメントにどのように役立ってくるのでしょうか。結論から先に書けば「解くべき課題が明確である」という前提条件において「実現可能性が高い解決策を正しい順番で、素早く造ること」ができるのがエンジニアからプロダクトマネージャーになるメリットであると現時点では考えています。これは単にエンジニアのバックグラウンドだけがあればできることではないので、ジョブチェンジしてすぐにその価値を発揮できるとは思えません。また、その先にあるのは「素早くリリースすることで、最速で学びを得ることができ、リーンなプロダクト開発におけるイテレーションを高速で回すことができる」ために、最終的な本当に価値あることをユーザーに最速で届けることができ、プロダクトの成功に近づくと考えています。詳しく言語化していきます。

大前提

大前提として「解くべき課題が明確である」という条件を加えています。不確実性が高い世界において、解くべき課題が明確であることなんて中々ないことだと思います。しかしながら、全てのことを考慮して考察するとかなり複雑になってしまいますし、状況によって変わることの方がいいので、今回の考えにおいてはこの前提としています。

また、プロダクトは作って終わりではありません。素晴らしいプロダクトを創れば勝手に広まって使われるはずだ、というのは多くの場合、幻想です。西口 一希の書籍「たった一人の分析から事業は成長する 実践 顧客起点マーケティング」において、プロダクトはプロダクトアイデアとコミュニケーションアイデアで説明されています。プロダクト開発において、プロダクトの独自性や便益を追求することと、どうやってユーザーとコミニュケーションをしていくかを考えることはセットで考えるべきです。2021年の1月、Clubhouseというプロダクトは世の中を席巻しました。招待制という仕組み自体は普遍的でmixiで実践されていたものではありますが、コロナという時代背景やSNSやインフルエンサーという後押しもあり、テレビですぐに取り上げられるほどの人気だったのは、覚えている方も多いかと思います。このムーブメントは、日本のみならず各国で生じていたようなので、ある程度狙っていたのではないかと思います。これを狙って打てるプロダクトマネージャーは相当だと思いますが、この招待制の機能はよく実装されていて、エンゲージメントによって招待枠が付与されたり、個人情報的には微妙だなと思いましたがSMSを使って送信できるなど、誰でも持っていて手軽に利用できる仕組みを利用していたり、実装部分も非常に勉強になりました。このnoteでは、このようなどうやってユーザーとコミニュケーションすべきかというマーケティング的な概念も、非常に重要な成功要因だとは理解しつつも、割愛して話を進めています。予めご了承ください。

たった一人の分析から事業は成長する 実践 顧客起点マーケティングより

解決策の具体性と実現性が高い

解くべき課題が明確である時に、重要になるのが解決策のセンスです。エンジニアリングのバックグラウンドがあれば、企画をする段階において、解くべき課題は正しいのだけれど、解決策が実装困難なズレているものばかりになってしまうということが生じにくいと思っています。

つねに「生み出すインパクトの大きさ」を考えると同時に「一粒で、２度どころか３度美味しい解決策」を見つけ出そうとしているんです。

イケてるプロダクトマネージャーは何を大切にしているのか？

たいろーさん (@tairo) のブログの中で説明されている考えを引用させていただきます。インターネットのプロダクトを扱っているならば、ほとんどの解決策はインターネットが関係している、つまりプログラミングを記述することによる実装が絡んでくると思います。そこに知見があれば、まず実現性が低い提案を事前に除外してスムーズに話を展開することが可能です。超極端な話、早く移動したいという課題に対して、解決策に「どこでもドア」を創ればいいのではないか？！絶対みんな欲しいって言うでしょ！みたいな話が出てきません (あくまで極端な例です) 。今持っている技術やアセット、エンジニアリソースの中で実現可能なものを網羅して優先順位をつけることができます。

また、アイデアの具体性がグッと高くなり、どのデータを使って、ユーザーにどんな情報を入力してもらって、どういうデータを返すのか、最近発表されたこの技術を使えばいけます、というような具体性が高い提案を素早くすることが可能です。度々知見を持っているエンジニアに「これって実現できる？どのくらい工数かかりそう？」という質問をしなくても、自分で調査して、なんならプロトタイピングして実機で動かして検証してみるということも可能です。なぜ、具体性が高いと良いかというと、企画段階では全員がめちゃくちゃ良いという話で進めていたが、後々でエンジニアに確認したら、実現性が極端に低いが、実は工数がめっちゃかかるので現実的ではないということが発生して、大きく手戻りして一向に話が進まないということを防げるからです。企画の段階でガンガン話を進めることができます。

しかしながら、エンジニアリングのバックグラウンドがなくてもこれができているプロダクトマネージャーは沢山います。補填策の一つに経験が多くスピーディにコミニュケーションできるエンジニアが相棒になってくれているパターンです。これができれば、エンジニアのバックグラウンドがなくてもスムーズに物事を進めることができます。また、エンジニアリングの経験がなくても長い経験の中で、どんな実装をすればどのくらいか難しいかということや、データの流れを具体的に記述できるというようなスキルを身につけている方、どのミーティングではどこまで話を進めて、何を明らかにして、後でエンジニアに確認すればいいことは何かというのを整理できるという仕事を進めるのが上手いプロダクトマネージャーもこの問題はスムーズに解決できると思います。

一方で、エンジニアリングのバックグラウンドがあるが故に、自分達で手が届く実装可能な範囲で物事を思考してしまい、本当に解決したいことがおざなりになってしまうという落とし穴も存在するので、そのことについては後述します。

工数見積りが容易

自分にエンジニアとしての実務経験があれば、解決策に対して、工数を見積もることが容易になります。例え、サーバーサイドやクライアント (iOS/Androdi/webフロントエンド) に特化したエンジニアだっとしても、プログラミング言語、フレームワークという大枠はほぼ同じですし、調べればわかることも多いので、大外れすることが少ないと思われます。この妥当性が非常に大事で、企画の時にエンジニアリングのことを理解しておらず「この実装なら前もやってことあるので、大体2週間あれば余裕です」と話していたが、エンジニアに確認すると「この実装はテストとして実装していたので、捨てる前提でコードを書いていたので早く実装することができました。ちゃんと実装するなら、使うサードパーティも費用対効果を検証したり、レスポンススピードも加味しながら実装して保守性が高いコードを書いた方がいいので、1ヶ月以上はかかると思います」となって企画からやり直しということが事前に防げるようになると思われます。また、エンジニアとのコミュニケーションが上手くいっておらず、いついつまでに絶対欲しいという機能が蓋を開けてみたら大幅遅延して、クライアントさんとのコミニュケーションが大変というケースもあるかと思います。

なぜ、工数を把握することが重要かというと、不確実性が高い世の中においては、いつリリースできるかというスピードは非常に重要だからです。スタートアップや新規事業など、投資すべきかを判断する段階において1ヶ月という単位は長すぎるのではないでしょうか。世の中の変化は非常に早いので、スタートアップにおいてスピード負けしたら死活問題です。競合が素早く実装してきて、営業をかけていて、二番手として追いかけていくのは非常にしんどいと思われます。また、工数がかかるということはその分のリソースも使っているわけで、エンジニアもタダではないので、そのROIが合うかどうかも考えなければなりません。そのため、開発の優先度を考える上で、工数という観点は非常に重要は要因だと考えています。自分にエンジニアリングのバックグラウンドがあれば、ディスカッションの段階でスピーディに意思決定をすることができると思います。

しかしながら、自分にエンジニアリングのバックグラウンドがあるとしても、プロダクトマネージャーが全ての実装を自分で責任をもってやることは少ないと思われます。そのため、全てを自分で決めて開発を進めるのはチームに負担をかけてしまうことが多いです。実際に開発を行っていくエンジニアチームと密にコミニュケーションをして工数を把握し、合意形成をしていくことが重要です。常に無理なスケジュールを投げてきて、圧力をかけてくる人は、僕は一緒に仕事をしたくないと思ってしまいます (たとえ成果を出していても)。そのため、エンジニアリングの知識や経験がなかったとしても、エンジニアと密にコミニュケーションをすることができれば、工数把握という問題は解決されると思われますが、全ての解決策に対して「これを実装するなら工数どのくらいかかりそう？見積もって欲しい」とお願いし、工数が大きければ「どの部分が削減できそう？」などコミニュケーション量が増えてしまうことが懸念されます。エンジニアリングのバックグラウンドがあれば、自分でわかり判断できることは自分で調べたりすることで、エンジニアとのコミニュケーション量を最小にしながら物事を進められ、結果的にアジリティを高めることができると考えています。

エンジニアとのコミニュケーションがスムーズ

よくあるのがエンジニアとのセールス観点でのコミニュケーションがズレてしまうという構図です。常に変化するプロダクトの仕様を言語化して、仕様書を保守運用することは非常に困難です。スタートアップや新規事業ではなおさらです。もし作ったとしてもその時点の仕様は正しく記述できたとしても、すぐに形骸化してしまうことは多く、都度聞いた方がすぐに答えられるという場合も多いと思います。また、半年前は動いていたけれど、実際に動かしてみたら、前回の変更でバグになってしまっていたというケースも考えられます。一方で、セールス観点ではクライアントさんがいる場合に、プロダクトの遷移図や仕様を売り物にしているので、仕様変更があったりした時に、クライアントさんに伝えていたことと、実際が異なっていた場合、死活問題になることも往々にしてあります。また、このような問題はクライアント各社ごとに状況が異なり、複雑化することが多くあります。プロダクトマネジメントの観点では、各社ごとにアドホックな対応を繰り返していては、時間がいくらあっても足りなくなってしまいます。しかしながら、収益を上げることは会社を存続させ、自分達の賃金を確保し、持続的なプロダクトを開発することに直結するため、非常に重要です。エンジニアリングのバックグラウンドあると、変化する仕様をスムーズに認識することが可能であると思います。なぜなら、アプリケーションの構造を理解していると、仕様がどうなっているかということを推測することもできますし、コードを読めば一発でわかります。一方で、どの領域出身だったとしてもエンジニアと密にコミニュケーションをしたり、逐一確認することで把握することができるので問題になることは少ないかもしれません。

プロダクトのフェーズが進んでくると問題になってくるのが、技術的な負債と向き合うことです。初期フェーズのエンジニアの離脱、仕様のドキュメントがなかったり、度重なる仕様変更などがあったりする中で、生き残るために必死で負債を解消する時間などなく開発が進んでいってしまうということは良くあると思います。この技術的な負債は初期フェーズでは問題になることは少なく、負債の上に負債を重ねてもなんとか動くようなことが多いかと思います。しかしながら、データベースの構造であったり、データの置き場所、複雑化してテストが完璧ではない設計が重なりつつ、人が増えて、同じようなコードが乱立したり、仕様把握に時間がかかってしまい、想定工数よりも時間がかかってしまうというようなことに繋がります。この技術的負債について、言語化し、各ステークホルダーと合意形成することは非常に難しいのではないでしょうか。下手したら、数ヶ月新規開発を止めるというような判断か、動かしつつやるならば、「崖の上からから飛び降りながら、飛行機をつくる」ようなものなので、高い技術力と工数が余計にかかってしまうかもしれません。エンジニアリングにバックグラウンドがあり、技術的負債と向き合ったことがあれば、重要性が認識できているはずなので、そうならないように負債が小さく改修できる段階でちょっとずつ取り返していくことや、言語化して重要性を説明することも可能かと思います。

また、エンジニアリングにバックグラウンドがあると、各エンジニアの工数が空くタイミングを把握することができ、小さい改善施策の工数も把握できているので、そのような改善タスクを間に差し込むということもできると思います。例えば、クライアントサイドではAPIのリリース待ちになったり、SDKが準備できるだったり、サーバーサイドでは先にAPIの設計が終わって、クライアントの実装と修正指示待ちであったり、数日とは言わずとしても数時間は空いているなどもあると思います。全体スケジュールを遅延させることなく、改善策も進めることができると思います。

データ構造を理解し、SQLと親しみがある

エンジニアをしていれば、SQLを書くあるいは認識してどのようなデータを取得しているかなどのことを経験することがあると思います。そのため、SQLにそもそも親しみがあるのではないでしょうか。しかしながら、SQLを理解しているだけでは実際に分析業務を行うことは難しいかと思います。どのデータがどのデータベースにあるのか、テーブル構造はどうなっているのか、どのログがどのタイミングで発火しているのか、ログに入ってるデータは何でどういう構造をしているのかなどを把握している必要があります。エンジニアに聞けばわかることは多いので、そこまでアドバンテージがあるとも言えないですが、ソースコードを読めば把握できることも多いと思われます。データサイエンティストは専門職なので、そのレベルで分析したり、統計を取ったり、かなり複雑なSQLを書くのは難しいかもしれないですが、ググればわかる範囲であれば、エンジニアリングのバックグラウンドがあれば、理解しやすくある程度の分析はできるかと思います。特にサーバーサイドのエンジニアリングに精通し、データベースの構造も熟知してれば、効率的なSQLを書くことであったり、利点が多いかと思います。

自分でコードを書いて推進できる

これがエンジニア出身であることの醍醐味のような気がします。ある一定の条件を満たせば、自分でコードを書いてプロダクトを前に前に進めることができます。その条件は、自分が得意な分野であったり、エンジニアリソースが極端不足しているような状況などです。というのは、プロダクトマネジメントの本領はプロダクトの方向性、意思決定に宿ります。そのため、具体と抽象を行き来する中で、具体の虜に戻ってしまってはいけません。短期思考と長期思考を使い分け、具体でアウトプットがわかりやすい状態に戻ってはいけません。とわいえ、コードを書かないと前に進まないという矛盾が生じてしまうことは多々あります。例えば、スタートアップであったり、新規事業であったり、プロダクトのフェーズが若く、組織もないようなものというフェーズにおいては、たった一人でもコードが書ける人がいることは非常に心強いものです。

また、プロダクトのフェーズがわかくPMFする前で、とにかくプロダクトを前に進めるフェーズにおいては、自分自信でフリーランスの方を採用してコードを一緒に書いて、なんならPRも自分でするというような働き方ができるのは元エンジニアだからです。方法にこだわらず、前に前にプロダクトを進めて、その後のことはその後に、そこにいる皆で最適解を考えて進めればいいのです。プロダクトの失敗は、そこまで携わってきた人全てのリソースを無にしてしまいます。もちろん、全てのプロダクトが上手くいくなんてないのですが、0.01%でも成功する可能性に賭ける、それが僕はプロダクトマネジメントだと思っています。その中で、優秀なプロダクトマネージャーは長期での技術的負債と向き合い、今が良ければ全ていいという状態から、長期で走っていけるようなコード、組織を設計できる人です。まだ僕はその領域では全くないのですが、そこを目指していきたいと思います。

エンジニア出身だからこそ気をつけること

これまで、良い側面ばかり書いてきました。これだけ見ると、プロダクトマネージャーの前身として、エンジニアは非常に良い選択のように見えると思います。しかしながら、エンジニア出身でなくて優秀なプロダクトマネージャーは非常に多くいらっしゃいます。そこにこだわらなくていいのです。総合格闘技なわけですから。エンジニア出身だからハマる落とし穴、気をつけるべきことも併せて言語化したいと思います。

プロダクトファーストで考えてしまう

気がつくと、この落とし穴にハマってしまっていることが多々あります。具体の解決策を高い解像度で考えられてしまうからこそ、ユーザーが本当に解決したい課題というよりも、実装できること、新しい技術、どんな便利な機能を提供すべきかからスタートしてしまったり、手段が目的かしてしまい、リリースしたら、誰も欲しいと思ってないプロダクトになってしまうなんてことはよくあることです。また、十徳ナイフのようになんでもできますみたいなプロダクト設計してしまい、何を解決してるとも言えない中途半端なものを作ってしまうみたいなこともあります。

本当に大切なのは常にユーザー視点に立ち、本当に価値あるものを提供しようというスタンスです。もしプロダクトファーストで考えてしまい、誰も欲しいと言わないものをリリースしようとして後戻りできない状況なら、正直に謝って初心に立ち返りましょう。止めるという勇気ある意思決定もプロダクトマネージャーしかできないのです。

良いプロダクトを作れば、自然と使われるだろうという幻想もよくある落とし穴です。また、売れないけど便利なプロダクトも持続可能性を考えると長期視点に立てば、プロダクトを提供できなくなってしまう可能性があるので、誰のためにもなっていません。やはり、プロダクトマネジメントはプロダクトマネジメントトライアングルで表現される通りに、総合格闘技なのです。どの視点からもプロダクトを見て、常にバランスを取りながら開発をしていく。このどっちにも偏らない、様々な視点の行き来が重要なのです。

自分が解決できることで考えてしまう

解決すべき課題が正しくても、自分あるいはチームがある程度できる範囲の中で物事を考えてしまうというのもよく落とし穴です。これは最適化に陥ってしまったり、非連続的な成長が必要なフェーズでも思い切って踏み込めないなどがあり得ます。つまり、実装的に楽に実装ができたり、少ない工数でできることを積み重ねてしまう状態です。そのような"楽な"意思決定を積み重ねていくと、本当に欲しかったものから遠ざかってしまうことがあります。

何か解決策を考える際に、アイデアの実現が難しいかどうかから入ってしまい、難しいと思われるアイデアを自然に思考から除外してしまうということはないでしょうか。半年とか一年かかるけど、本当の本当に必要な実装というのもあります。それは実装が難しいと否定から入ってしまうのではなく、それは良いアイデアだからどうやって実現するかを考え抜こうという姿勢も時として大切です。

ぶっとんだ発想をしろというわけではありません。ただ、自分たちの枠組みをはみ出して思考するクセをつけるのです。これを意識できているかどうかで、非連続に成長しているプロダクトになるか、競合ひしめく中で成長の踊り場でシュリンクしていくのかが決まると言っても過言ではないと思います。

自分ができてしまうがために、パツパツになってしまう

前述として、自分でコードが書けることでプロダクトを前に進めることができると書きましたが、それは諸刃の剣です。プロダクトマネージャーは部署間の情報の非対称を埋めて、利害関係を調節したり、プロダクトの未来を考えてロードマップに落とすなど、様々な業務があり、特に考える仕事は細切れの時間だと、どうしても質を高めることができません。中途半端に自分がコードを書けてしまう環境では、周りにも頼られてしまったり、不要な開発も自分で片付けてしまうという心理に陥ったりして、本当にすべきことにフォーカスできていない恐れがあります。意識的に自分が手を動かさないようにすること非常に良いことではありますが、時にやらねばならぬ時もきます。このバランスと、積極的に権限移譲をしていくのがいいと思っています、エンジニアリングに限らなくても。

時間がパツパツになってしまうと、忙しい人認定されてしまい、本来聞いておいた方が良いことも遠慮されて相談されなかったり、何をやっているのかわからない人になってしまうこともあります。常に自分の業務を棚卸しして、権限移譲を積極的に行い、自分がボトルネックにならずにチームが有機的に動けるように整えていくことは非常に重要です。

Appendix / 海外事例

2/PdMはコードが書けるのか？ 米国PdMの5%しかコードが書けないらしい。他の統計データで多くても、30%。 PdMは、プロダクト部門以外に、マーケ、Customer Success、Opsなど多くの非エンジニア部門と連携するし、これらの部門出身者も多い感じもする。非エンジニアのPdMの方々、安心してください

湊 雅之 | Masayuki Minato@ALL STAR SAAS FUNDさんのツイート

大学での専攻はエンジニアリングが多いが、コードが書けるというスキルを持っている人は少なそうです。エンジニアからPdMというキャリアチャンジではなく、そもそもプロダクトマネージャーとしてキャリアをスタートさせているから？、かもしれません。

最近、YouTubeで海外のプロダクトマネージャーの動画を拝見しているのですが、Non-Techからどうやってプロダクトマネージャーになったかみたいな動画が上がっていたりするのですが、結論、技術的なバックグラウンドを要求している会社も多いが、それが全てではないという感じかと思います。

最後に

長くなってしまいましたが、エンジニアがプロダクトマネージャーになった際のメリットや気をつけるべき点について言語化を行いました。繰り返しになりますが、技術的なバックグラウンドがなくても優秀なプロダクトマネージャーの方は多くいらっしゃいます。どんな経験もあるに越したことはないのですが、もっと重要なのはプロダクトを成功させるために、今自分に不足していることは何かを言語化して、最速でそれを身に付けるにはどう行動すべきかを考え、すぐに行動に移していけるマインドセットやスタンスが重要だと思っています。総合格闘技のリング上では、何系の出身というのは瑣末なことです。変にこだわりすぎなくていいと思っています。しかしながら、このnoteが多くの方の役に立てれば幸いです。

連絡先

もし、何かございましたら、こちらよりご連絡ください。自分のドメインを取ったのですが、持て余していたので、STUDIOで自分のサイトを作ってみました。STUDIOすごいです。とても簡単にサイトを公開までいけました。


この記事が気に入ったらサポートをしてみませんか？