"プロダクトマネジメント"投稿一覧

中小企業の中でも零細に近い方でお答えしますが、ERPにかけられる予算があまりないというのであれば実情かと思います。
そんな企業さんにはNotionがめちゃくちゃおすすめです。もちろん中にNotionを理解している人がいて、社員とある程度コミュニケーションが取れる前提ですが、タスク管理や請求管理、備品管理、納品管理等ぶっちゃけなんでもできます。
自由度が高く設計も簡単なので本当に...

基本はあった方がいいと思うので、拾いに行く・学びに行くスタンスです。
プロダクトやサービスの知識を多く持っている人と信頼関係を作ったり、早く価値のある情報に触れれるようなポジションを取り行くこともPM・PDMには大事なスキルだと思っています。
「ドメイン知識を持たずにプロジェクトを進めることができる」も正ではありますが、より効果的に・効率的に進めるには不可欠だと思います。興味・... 続きを見る

基本的なドメイン知識に関連する考え方は、Tatsunori Tanakaさんの回答にほぼ全面的に賛同しております。

そのうえで、

ドメイン知識を求められるとしたらどのように対応していますか？

に関しては、ドメイン知識のある程度でも重要になる現場であれば、かなり初期の段階でドメイン知識を収集しにいくアクショ... 続きを見る

担当するプロダクト、PMに求められる役割によって異なるというのが前提ですが。
個人的な意見は以下です。

■基本的な考え
・ジョインする前からドメイン知識を持っておく必要性はない
・ただし、プロダクトマネージャーとしてはドメインを”理解する”姿勢と行動は必要
・特に課題探索、仮説検証をメイン業務にされる場合はドメイン知識が必要になりやすい... 続きを見る

ドメイン知識については、私も無形商材をGOALに導くための胆力の方が重要と考えております。
一方でメンバーと会話される中でどうしてもドメイン知識が必要になる場面もあるため、ジョイン後少しずつ必要なドメイン知識をキャッチアップするようにしています。

はじめまして。
「プロダクトマネジメントトライアングル」について初めて知りました。
PdMやPjMの方々の得意な領域は人それぞれだったりするので可視化する一つの手段として役に立ちそうです。
また、採用の際のこのトライアングルを意識するとミスマッチが防げそう。
私に関しては、開発者⇔ビズサイドに接点があるPMでマーケティング、パートナーシップ、ビジネスデベロッ...

（過去も今もたくさんありますしこれからもありそうです..）特に、設計した通りの使われ方をしていただけなかった事が多いです。

毎回気づくことは、
・正しい分析を行なって狙いを出さめること
・自分たちの狙いがいま設計しているもので起こせるのか？と強く問い続ける高い意識を保つ必要性
・第三者、願わくば想定されるユーザーからのFBを細かく得続けること（そ... 続きを見る

正解がない前提で回答します。

ズレが発生した時（特に遅れが発生した時）の動きとしては、スコープ範囲を絞る、変更する、がおそらく一番最初に出てくる選択肢です。「全てリリースできません」はビジネスインパクトが大きすぎたり、「全員残業です」というのはチームのマネジメント的に後々かなり苦しくなるのが見えているため、どちらも視野に入れつつも「まずはここまででリリースできないか検討しまし... 続きを見る

複数製品を一つのチームで管理していて優先順位付けをするのは至難の業な気がしていて（優先順位付けの観点が発散しやすそう）、情報収集を追えた後の意思決定は信念でやるしかないかもしれませんね。
・業績へのインパクト
・製品同士の連携有無
・将来達成したいビジョンからの逆算
・お客さんの状態
製品レベルでの開発投資をアロケーションする意思決定をするのであれ... 続きを見る

結局や経験や思想の話にはなってしまうのですが、プロジェクトに関わるそれぞれの職種の人の特性を理解することは最低限必要かと思います。
特に専門職と呼ばれる職種の人材の場合はそこの理解がないとプロジェクトを綺麗に推進していくことは困難です。

クライアントがいる場合や上層部などの口を挟む人間がいる場合はそういった人種の思考傾向を踏まえて、利害関係はどこに発生しているのか、... 続きを見る

実は納期になくていいもの、そのタイミングではなくて後からの方が良い影響があるから納期にはないほうがいいもの、結果は変わらないのに要する工数がちゃっかり肥大化してるもの、をプロジェクトの成功に情熱を燃やす人たちで探すのが良いと思います。それと並行して、進め方を改善するためのコミュニケーションへの投資を前もって決めて仕組みとしておいておくことかなと思います。

一人でゼロから何かを作り、リリースして、ユーザに使ってもらうまでやってみるのがお勧めです。
基本的にコードレベルのエンジニアリングの詳細は、エンジニアに任せればよいと思います。しかし、コンポーネントとして何を作る必要があるのか、情報を構造化できてないと何に困るのか、モデルは何を扱うべきなのか、などのシステムの構造や、自分は何をしたくなるのか、という扱いたい情報の概念は大きく変わるものでは... 続きを見る

1. 作成
半期を中心としつつ意思決定をするタイミングでは都度、プロダクト責任者と管掌役員がドラフトを作成し、チームとの協議の上で決定しています。事業状況に応じたイシューを優先順位を考慮して決定し、価値が積み上がることを意識して作成します。（半年後には、このように進化している）

2. 運用
開発は不確実性が高いので、定期的に優先度を判断して棚卸しながら、状...

※本投稿は、2023年6月27日に開催されたイベント「エンジニアのプロダクトロードマップとの向き合い方（https://offers.connpass.com/event/286019/... 続きを見る

※本投稿は、2023年6月27日に開催されたイベント「エンジニアのプロダクトロードマップとの向き合い方（https://offers.connpass.com/event/286019/... 続きを見る

※本投稿は、2023年6月27日に開催されたイベント「エンジニアのプロダクトロードマップとの向き合い方（https://offers.connpass.com/event/286019/... 続きを見る

全フェーズのスタートアップに関わってきましたが、PMFを測るような段階では、肌感で自ずとわかるような定性指標か、ユーザーの実態行動がわかる定量指標（エンゲージメント、アカウント増加率、コホートなど）か、どちらかが大きいです。

NPSも含め、アンケートだけで測った場合は、数の規模が大きくないとあまり信頼に足らないので、そこまで急激に伸びていれば、それ自体がPMF達成といえます。... 続きを見る

「ユーザーをどうしたいか」ではなく、「ユーザーに何を提供できるか」という事が本質だと思うので、これが明確になっていれば、「ユーザーをどうしたいか」という答えはすぐに見つかると思います。

意思決定をする必要が出てきた際、まずは「誰がその意思決定をするか」を明確にするところから会話する。
それはオーナーかその領域のスペシャリストか、もしくはチームではない部門長かしれないですが「誰がその意思決定をするか」と言うところからまずは決めること。

そのために、その意思決定の背景や必要性、結果について、チームで会話し目線を合わせる。
その後意思決定者が決... 続きを見る

売上に関連する指標を目的にチームでプロダクトづくりをすることは難しいと認識しており、売上の原因となる顧客状態を目的にするべきだと思います！

xx円, CVR xx%, etc... からはそれをかなえるユーザー体験を描きにくいなと