プロダクトマネージャーがプロダクト企画についてエンジニアと話すときに、あらかじめ書いておくとよいリスト（ラフな PRD テンプレのようなもの） - ykmc09 blog
以前「プロダクト企画にエンジニアを早めに巻き込む（嫌がられずに協力を得る方法）」という記事を書きました。 ykmc09.hateblo.jp 「TL;DR : ひとことでいうと」を抜粋すると以下のような感じです。 決定事項になる前に早めに巻き込もう 巻き込むときは、 その意図や相手に期待することを伝えよう 特性を理解して、ちょっとした工夫（最初の一声はチャットなどの非同期コミュニケーションを使う、etc）をしよう この記事では、「はやめに巻き込もう」ということを中心に書きましたが、最低限こういったことを考えて書いておくと、話がよりスムーズになるよ、というものを挙げてみようと思います。 プロダクトマネージャーが用意するリスト 目的の概要（なぜそれをやる？）※もっともだいじ。これが無いとかなりキツイ。 誰のための企画？（基本はエンドユーザーになる。） その人のどういう課題を解決したい？ その課
私はPRD(Product Requirement Document)が嫌いでした。概念としてのPRDは好きですが、ドキュメントとしてのPRDが苦手、という話を聞いてください。 😭 PRDの嫌いだったところ① プロダクトマネージャーの仕事はPRDを書くことです、という誤解 実際に会社によってはそれをプロダクトマネージャーの主な責務にしているところもあるでしょう。しかし、私はプロダクトマネージャーの仕事は「何のPRDを書くのか？」を決めることであり、PRDを書く作業はプロダクトチーム全体で実施するものだと思っています。プロダクトマネージャーが書いたPRDの通りにプロダクトチームが動く組織は好みません。 ② これ1枚でほんまに全部書くんか？ PRDは「検討すべき項目がすべて検討されているか？」を問うフォーマットとして秀逸です。しかし、例えばPRDに「競合分析」や「市場分析」を記載することもあ
複数課題が混ぜこぜで、HOWだけが書かれていたPRD 要件定義の工数を50パーセント減・手戻りゼロにした改善策 ARR100億SaaSの現実 ～新設PdM組織が、PRD品質向上のため泥臭く越境した2つのこと～ 植木氏の自己紹介、株式会社ラクスの紹介 植木遼太氏：では発表を始めます。「ARR100億SaaSの現実 ～新設PdM組織が、PRD品質向上のため泥臭く越境した2つのこと～」というテーマで発表します。よろしくお願いします。 まず簡単に自己紹介と会社の紹介だけさせてください。私は植木遼太と申します。現在、株式会社ラクスというところで、「楽楽精算」という経費精算SaaSのプロダクトマネージャーをしています。 経歴としては、新卒はインフラエンジニアからキャリアをスタートして、その後にプロジェクトマネージャー、プロダクトマネージャーと役割を変えていったかたちになります。 次に、簡単に会社紹介で
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
プロダクトマネージャーが書いたPRDの通りに機能をつくる？｜小城久美子 / ozyozyo
複数課題が混ぜこぜで、HOWだけが書かれていたPRD 要件定義の工数を50パーセント減・手戻りゼロにした改善策