Kyosuke Kubo

サイボウズでPdMしてます。開発寄りの部分が得意です / 元フロントエンドエンジニア …

Kyosuke Kubo

サイボウズでPdMしてます。開発寄りの部分が得意です / 元フロントエンドエンジニア / 早稲田商卒/ 日本コーチング連盟基礎応用修了/ TOEIC850 / 筋トレ SQ 150,DL 160,BP 100

最近の記事

プロダクトマネージャーとして障害対応で意識していること

障害は起きないに越したことはないですが、色々な要因で起きてしまうものでしょう。もちろん、規模として大きいものから小さいものまで、まさに色々あると思いますが、ユーザーファーストで一刻も早く対応する必要があります。 この記事では、障害対応で意識していることをプロダクトマネージャー目線で著者なりに説明します。 事実の確認障害が発生した時、まず事実の確認をしっかり行います。 いつ、どのような事象が起きていて、それはどのくらいの範囲で発生しているのかについて明確にします。 その

    • サポート終了をどのように行なっていくか

      プロダクトマネージャーとして、プロダクトをグロースさせるだけでなく、”プロダクトを終わらせる”こともしばしばあるでしょう。要因は色々ありますが、目的としてはこれまで以上により多くの価値をユーザーに届けるためです。 しかしながら、使っていただいているユーザーがいる以上、迷惑をかけない形で誠実な対応を取る必要があります。 この記事では、サポート終了をどのように行なっていくか、その概要をざっくり著者なりに説明していきます。 トレードオフで価値があるかまず、サポート終了やプロダ

      • SaaSの重要指標を理解する(LTV, CACなどなど)

        SaaSを提供している以上、自社プロダクトの状況を診断するためにはSaaS特有の重要指標を定点観測していく必要があります。プロダクトマネージャーは、これらの指標を理解して、どのようにプロダクトを成長させていくべきか考えるでしょう。 この記事では、改めてSaaSにおける重要指標を著者なりに説明していきます。 MRR、ARR MRRとは、毎月決まって得られる収益で、ARRは年間の決まって得られる収益です。 重要なのは、”決まって得られる”という部分で一時的な収益は含めませ

        • 事業全体を早くざっくり理解するには

          プロダクトマネージャーの役割の一つとして、事業の価値を最大化するために、何ができるかを日頃から考え、実行することが挙げられます。そのためには、自社の事業がどのような構造でどこに強みがあってどこに弱みがあるのか理解していないといけないでしょう。 この記事では、プロダクトマネージャーとして事業を早くざっくり理解する方法を著者なりに解説します。 フレームワークに則って考えてみる事業全体をいきなり捉えようとすると非常に難しいです。そこでフレームワークに則って、全体を考えるのが良い

        プロダクトマネージャーとして障害対応で意識していること

          プロダクトビジョンからプロダクトロードマップに落とし込む方法

          プロダクトマネージャーに求められる業務の一つとして、プロダクトロードマップの作成が挙げられるでしょう。しかし、闇雲にロードマップを作っては意味がありません。 この記事では、プロダクトビジョンからプロダクトロードマップに落とし込む方法について著者なりに解説します。 プロダクトビジョンに立脚した開発テーマを策定するプロダクトをグロースさせていく際には、プロダクトビジョンを策定すると思います。(策定の仕方については以前書いた記事をご確認ください。) せっかく策定したプロダクト

          プロダクトビジョンからプロダクトロードマップに落とし込む方法

          プロダクトビジョンを設定する上での意識すべきポイント

          プロダクトをグロースさせる際には、「プロダクトビジョン」を設定する必要があります。しかしながら、プロダクトの特性を踏まえて、向かうべき方向を一文に設定するのは難しいでしょう。 今回、この記事では、プロダクトビジョンを設定する上での意識すべきポイントを著者なりに解説します。 プロダクトビジョンとはプロダクトビジョンがどのようなものかまず触れていきたいと思います。 プロダクトビジョンとは、プロダクトが全社ミッションに対して、どの市場にどんな価値を提供することで貢献するのかに

          プロダクトビジョンを設定する上での意識すべきポイント

          プロダクトマネージャーとして多様なステークホルダーと協力していくためのコツ

          プロダクトマネージャーとして働いていると、さまざまなステークホルダーと議論する場面が多いでしょう。利害関係もあることから、思ったように伝わらず、プロジェクトを進める際に難儀することもあるかと思います。 この記事では、プロダクトマネージャーとして多様なステークホルダーと協力していくためのコツを著者なりに解説します。 コミュニケーションで意識するべき点プロダクトマネージャーが関わるステークホルダーは多岐に渡ります。例えば、他部署だと、セールス、CS、マーケ、サポート。開発だと

          プロダクトマネージャーとして多様なステークホルダーと協力していくためのコツ

          ミーティングで使える言い回し集

          ミーティングでうまく意見を伝えられない、伝えるのが難しいと感じている方もいるのではないでしょうか。 そういった時の対処法として、よく挙げられるのが結論ファーストとか要点を言うとか。 枠組みとしてのアプローチが多いような気がします。 しかし、枠組みから変えて話し方を改善していくのは、文章構造を俯瞰的に捉えて実践する必要があるので、難易度は高いでしょう。 そこで、場面に応じて使える言い回しを覚えると言う方法を私は推奨します。 言いたいことを構造的に捉えて改善するよりも、低

          ミーティングで使える言い回し集

          ユーザーから頂いた要望をどのように製品に活かしていくか

          製品を開発しているとありがたいことにユーザーから要望を頂きます。 これは直接の声であり、製品にとっては貴重な意見です。 しかし、100%活かすためには、多角的に洞察する必要があります。 今回はどのようにユーザーからの要望を見ていくかまとめてみようと思います。 前提前提として、「ユーザーにもっと価値を届けたい」というのが背景にあります。これは使うサービスにもよりますが、B2Bであれば顧客の業務上の課題を解決して効率化するというのが価値に値すると思います。 価値を提供する

          ユーザーから頂いた要望をどのように製品に活かしていくか

          異動した際のキャッチアップとスタートダッシュの取り方

          異動した時って馴染めず、キャッチアップに時間かかって大変ですよね。 異動に限らず転職など環境が変わることは今後もあると思うので、今回異動した時に意識したポイントなどをメモとして記載しておきます。 関係者全員と意図的に雑談するやっぱり会話しないとどんな人間なのか伝えることはできません。 仕事のMTGで会話するのも良いのですが、自分ってどんな人間でどんな経歴なのかカジュアルな場で話す方がお互い警戒心が消えやすいです。(雑談ってのが大事)なので、関係するメンバー全員と一度は話す

          異動した際のキャッチアップとスタートダッシュの取り方

          プロジェクトを回す上で意識している1対1の会議と関係者全体が集まる会議の使い分け

          プロジェクト回す上で利害関係がこじれてなかなか前に進まないということはしばしばあると思います。その際に、1対1の会議と全体が集まる会議をうまく使い分けることで、その問題を緩和できることを気づきました。 この記事では、そのような会議の使い分けのコツについてシェアします。 1対1の会議の使いかたプロジェクトに関連するステークホルダーがたくさんいてある問題を解決したい時に、「まずこの部署の方だけと会議しよう!」というのが「1対1の会議」とします。 この場合、メリットとして3点

          プロジェクトを回す上で意識している1対1の会議と関係者全体が集まる会議の使い分け

          PMとして仕様を考えるときのざっくりとした考え方

          新機能の仕様作成はPMが担当する場合もあるでしょう。しかし、仕様を作成する時の気をつける部分を新人メンバーに教えるのがなかなか難しいです。 そのため、今回仕様検討時に意識すべきことを言語化してみます。 ※具体的な内部仕様や設計はエンジニアの仕事なので、今回の記事ではスコープ外とします ファクトベースで、インサイトを洞察するプロダクトの仕様を考えるときに、解釈と事実を分けて考えることが基本となります。 解釈で物事を考えると、自分とユーザーの意見に乖離が生じてしまうでしょう。

          PMとして仕様を考えるときのざっくりとした考え方

          プロダクトマネジメントしていく上での問題解決プロセス

          プロダクトマネージャーをしていると、どの業務においても、問題解決能力が大事だと日々実感します。 今回は、問題解決に必要な考え方を自分なりに説明します。 問題解決するとは筆者は、問題解決とは以下のプロセスであると考えています。 理想(目的)を設定する。 現状を確認する。 理想と現状のギャップを確認する。 ギャップを埋めるための越えるべきハードル(問題)を定義する。 問題を解決するための手段を考える。 手段から実際のタスクを洗い出す。 実際に実行する手段を選ぶ。

          プロダクトマネジメントしていく上での問題解決プロセス

          仕事で意識しているコミュニケーション能力について

          自分はPMとして働いているのですが、コミュニケーション能力が大事だと痛感する機会が多いです。 また、そのコミュニケーション能力が一体なんなのか、他人に説明するのも難しいと感じます。 今回は、その抽象的なコミュニケーション能力について、自分なりの定義と意識しているポイントについて説明致します。 学生と仕事上でのコミュニケーション能力の違い学生の時からコミュニケーション能力は高い方がいいと言われてきたと思います。 おそらく友達同士の会話でも、「あいつはコミュ力が高いからさ〜」

          仕事で意識しているコミュニケーション能力について

          プロダクトマネージャーになって半年がたった

          プロダクトマネージャーになってから半年が経ちました。 自分にとってプロダクトマネージャーは本当に面白く、向いている仕事だなと実感しています。一人立ちから半年も経つと色々できることも増え、全体概要も把握できたかなと感じていますので、半年なりの学びを共有したいと思います。 この記事では、PMの概略とそれに必要なスキルなどについて触れています。まだまだ経験の浅い自分ですが、半年前に知りたかったことをメインに書かせていただきます。なお現場によって異なる部分も多いので、個人の体験、

          プロダクトマネージャーになって半年がたった

          社会人になってから数学を中学からやり直しました

          タイトルの通り数学を社会人になってから勉強し直したので、その勉強の過程や方法をシェアしてみたいと思います。 背景そもそもなぜ自分が「数学を勉強しよう」と思ったかというと、エンジニアとしての地肩をあげるため、周りのエンジニアとの差を少しでも縮めたいためです。 自分は私立の文系の大学を学部で卒業してwebエンジニアとして仕事を始めたのですが、周囲のエンジニアは理系院卒が基本でした。 数学を受験でしっかり勉強していないことは自分の不利な部分であり、そこから生じうるロジックの構

          社会人になってから数学を中学からやり直しました