A. プロダクト作りにおいて意識しているのは、事業特性や組織構造、各部門のKPIと依存関係を正しく理解した上で、ステークホルダーの要求とそれを解決することで生み出されるアウトカムの関係性を明確にすることです。 その上で、開発によって得られるリターンは直接収益に結びつくのか、それとも資産価値を高めるのかを整理し、事業状況やロードマップに基づいて優先順位を判断するようにしています。 他には、開発に着手する前に市場不確実性を可能な限り減らすことを行います。例えばToCではプロダクトディスカバリーに注力し、ToBでは事業開発部門と連携して「売れるようにしてから作る」ことに時間を使うようにしています。
A. ユーザーインタビューをします。新しい機能を知っているかどうか、使ったことがあるか、使ってどう感じたか、を主に聞きます。機能を知っていない場合、マーケティングやGTMに改善の余地がある可能性があります。知っていたが使ったことがないのでれば、その新しい機能をそもそも必要としていないのか、リリースが分かりにくかったなどの可能性があります。使ったことがあって満足度が低い場合は、その理由を聞き、次回の機能改善に繋げます。
A. [1] ユーザーファースト。プロダクト企画のドキュメンテーションや、ステークホルダーとの議論などあらゆる場面で、まず始めに、ユーザー目線から始めるようにしています(ユーザーが抱えている課題は何か、ユーザーにとってのベネフィットは何か、など)。[2] 課題と期待効果の定量化。可能な限りデータを用いて課題を定量化するようにしています。また、プロダクト開発や改善によって、どの程度の効果が期待できるのか、も定量化するようにしています。[3] プロダクト効果の定量化。A/Bテストなどを用いて、可能な限り効果を定量化するようにしています。
A. 広く浅くではなく狭く深く。 徹底的にペルソナのニーズ・体験にブッ刺していくことだと思います。 そのたった一体のペルソナのニーズ、実行するタスク、タスク実行後の感情にまで寄り添って、ユーザーが「えっ!?これって私のために作られたものじゃん?」って思ったらそれは卓越したユーザー体験の提供になっているのではないかと思います
A. PdM1人でプロダクトを作ることは難しく、チームで共創していく中で 小さな認識のずれは最終的に大きなずれにつながります。共通認識を持てているか?がスピードにも品質にも影響を与えます。 同時に大事になるのがその認識を常にアップデートし続けることです。 一時情報を得て、チームで共有することによって最善の意思決定をし続けることが大事かと思います
A. 「新規事業立ち上げがやりたい」という、今思うと漠然とし過ぎている志望動機で拾っていただいたプロトコーポレーションに入社し、一切想像していなかった自社事業のプロダクト・マーケティングを担当する部門に配属され、ディレクター職としてスタートすることになりました。この配属が全ての始まりで、配属ガチャに超感謝してます。 Webサービスの機能開発の開発ディレクションからスタートし、その後、新規プロダクト立ち上げの開発領域のPjMやグロースフェーズのプロダクトマネジメント、新規プロダクト立ち上げなどを経験することができ、プロダクトマネージャーとしての土台を作ることができました。
A. 自分なりのアレンジをせず、定石通り一度やってみることです。サンプルが少ないながらにいくつかのアジャイル組織に関わらせて頂いた感想として、うまくいってない組織は何らかの身勝手なアレンジをしていました。例えば、スプリントはbi-weeklyなのにレトロスペクティブは3ヶ月に1回、など。“ファッションアジャイル組織“にならないように気をつけてください。
A. 「失敗の数」です。最近失敗していない、とふと感じた際怖くなります。失敗していない、というのは挑戦をしていない、ということです。挑戦もせず、コンフォートゾーンのぬるま湯から脱せていない、或いは誰からも指摘されない、怒られない、ネガティブなフィードバックがない、そんな状態にならないように、サウナなどで自省の時間を定期的に設けるようにしてます。
A. トリッキーな回答で恐縮ですが、PMという職種を抽象化して全ビジネスマンに浸透させたいと考えます。PM(プロダクト/プロジェクト/プログラム マネジメント)とは「対象の成功のために『なんとかする』」ということであり、僕の中ではJob-titleというよりはMind-setです。理想主義者に聞こえますが、関わるステークホルダー全体がこのMind-setを共有すれば自ずと成功の不確実性を下げることができるかもしれません。PMというMind-setの啓蒙、それに少しでも貢献できるキャリアにできれば幸いです。
A. めちゃくちゃシンプルに、縦軸にアイデア/選択肢を羅列し、横軸に判断軸を3つほど並べ、各々のマトリクスに◯✖︎△を入れてスコア化します。判断軸はプロジェクトやチームによって左右することはあるものの、基本的にはインパクトファーストを大事にしています。onsite議論であれば、ホワイトボードなどで書きながら可視化すると合意形成がしやすい印象です。
A. 一般的なプロセスとしては、N1インタビューをやったり、SQLを書いて分析したりします。重視していることは「事前準備を厳かにしないこと」です。ディスカバリープロセスの本質は「不確定要素を取り除くこと」にあるので、当該過程で何に白黒つけたいのか、を明確にしておくことは有効だと考えます。(=イシューの定義)
A. 質問にあるプロジェクトという単位に限らないのですが、「過度な透明性」です。 少し古いかもしれませんが、当時のスタートアップでは求職者をアトラクとする独自カルチャーの一環として「情報の透明性」を謳う会社が流行っていた記憶があります。経営ボードmtgの議事録から始まり、投資家とのmtg、会社のランウェイ、個人の給与、中にはメンバーレベルの会議の録画を全て公開する会社も見てきました。 一見素晴らしい試みに見えますが、この透明性がワークするには条件がある気がしています。それは所属する「メンバー全員の情報リテラシーが圧倒的に高いこと」です。情報を建設的に処理する能力がない組織に、溢れんばかりの情報を公開すると逆効果になることもあります。目的ありきで、ガバナンスがセットでの透明性を設計できるといいなと思います。