$0.99で始める

20個のプロダクトマネージャー向けプロンプトで、 トレードオフを見える化する

AIはユーザーもデータもスコープも勝手に作り上げて、自信たっぷりのPRDを数秒で書いてしまいます。このプロンプトを使えば、あなたのブリーフ、メモ、数字だけを根拠に作業させ、計算過程を見せ、エンジニアリングが始まる前に未解決の質問を洗い出せます。

[かっこ]の部分は、ブリーフ、メモ、チケット、数字などに置き換えてください。

01. 散らかったブリーフからPRDを書き、未解決の質問を一覧にする

Slackのスレッドと通話メモと締め切りはあるのに、仕様書がないとき。

この散らかったブリーフを、プロダクト要求仕様書(PRD)にまとめて。

[ブリーフ、スレッド、通話メモなど手元にあるものを貼る]

セクションはこの順番で：課題とその当事者、課題を裏付ける根拠、測定可能な成果を含むゴール、スコープに入るもの、スコープに入らないもの、番号付きステップで書くユーザーフロー、MUSTかSHOULDを付けた要件、他チームへの依存関係。

ブリーフに書いてあることだけを使って。書かれていない箇所は、埋めずにその場所へ[OPEN: 質問内容]と書いて。

最後に、未解決の質問をすべて、答えられる人別(私、デザイン、エンジニアリング、法務、顧客)にまとめ、開発を止めてしまう3つを先頭に置いて。

02. 機能をユーザーストーリーと受け入れ基準に分割する

リファインメントは明日なのに、機能がまだ1枚の大きなチケットのとき。

この機能を、チームが1つずつ作って出荷できるユーザーストーリーに分割して。

機能：[機能の内容]
ユーザー：[誰が使い、何を達成しようとしているか]
制約：[プラットフォーム、期限、すでに作ったもの]

ストーリーごとに次を書いて：
1. [ユーザー]として、[行動]したい。それは[成果]のためだ。
2. Given / When / Then形式の受け入れ基準を1ストーリーにつき3〜6個。書いた本人以外でもテストできるものにして。
3. S、M、Lのいずれかでの規模の見積もりと、不確実さの最大の原因を1つ。

最初の1つが、小さくても実際のユーザーが使えるものを出荷できる順番に並べて。実は2つのストーリーになっているものや、別のストーリーが出荷されて初めて意味を持つものには印を付けて。

03. PRDが見落としたエッジケースを見つける

仕様は完成したように見え、来週からエンジニアリングが始まるとき。

このPRDを、リリース後にバグ報告を受けるエンジニアの立場で読んで。

[PRDまたは仕様書を貼る]

仕様がカバーしていないエッジケースを、次の分類で挙げて：空の状態と初回の状態、エラーとタイムアウト、権限とロール、上限(非常に長い、非常に多い、ゼロ、重複)、同時実行(2人が同時に編集、ダブルクリック、再試行)、この機能ができる前のデータ、アクセシビリティ。

各項目について、シナリオを1行で、現在の仕様から読み取れる挙動、私が答えるべき質問を書いて。最初の1か月に実際のユーザーが遭遇しそうな順に上位5つを並べて。要件を勝手に作らず、質問して。

残りの17個のプロンプトを無料で開く

Whiziのニュースレターに登録すると、このパックの続きを読めます。

  1. RICEでバックログをスコアリングし、計算過程を示す
  2. インタビューメモをジョブ、課題、引用にまとめる
  3. 望むことではなく、実際にしたことを聞くディスカバリーインタビューの手引きを作る
  4. サポートチケットを、直す価値のあるプロダクト課題にまとめる
  5. エンジニアがそのまま作れる1ページの仕様書を書く
  6. 成功指標と、それを正直に保つカウンター指標を選ぶ
  7. 実験を設計する前に、まずサンプルサイズの問いに答える
  8. 全チームに担当者がいるローンチチェックリストを作る
  9. ユーザーが実際に読むリリースノートを書く
  10. 変わったことから始まるステークホルダー向け報告を書く
  11. やらないことを明言するロードマップの物語を書く
  12. 機能リクエストを、理由と次の一歩を添えて断る
  13. ローンチが出荷される前にプレモーテムを行う
  14. 競合の製品ページを主張ごとに分解する
  15. 長いチケット一覧から、1つのスプリントゴールを書く
  16. 求められた解決策を、その裏にある課題に戻す
  17. 2つ目のモデルに、最初のモデルが書いたPRDをレビューさせる