Evidence
残す証拠
- request source、requester、customer/account context
- triage decision、priority理由、owner、SLA
- duplicate元と統合先の関係
- 受付から判断・完了までのlead time
ソウPM Tool Practice Playbook
PM向けProduct Ops Intake・Triageプレイブック
Slack・CS・営業・社内依頼など複数入口を、intake contract、triage、dedupe、SLA、ownerへ正規化するための実務runbook。
Decision question
最初に答える問い
依頼チャネルが増えても、重要度・owner・期限・重複を一貫したルールで処理し、PMの頭の中をqueueにしない運用ができるか
Preflight
導入・検証前のチェック
- 1. 受付チャネルを列挙し、各チャネルから残す必須fieldを固定する
- 2. Triage前のitemと正式backlog itemを別statusとして扱う
- 3. priority基準と緊急条件を文章で定義する
- 4. 重複判定時に元requester・customer evidenceを失わないmerge手順を決める
- 5. Urgent / High等の対象にだけSLAを設定し、全件deadline化を避ける
Runbook
運用手順
- Step 1. 新規requestはまずTriage queueへ集約し、直接roadmapへ入れない
- Step 2. 毎営業日または当番制でownerがduplicate / scope / priority / routeを判断する
- Step 3. 不十分なrequestは必要情報を追記してからaccept / decline / snoozeする
- Step 4. time-sensitive itemには明示的なSLAを付け、breachを週次reviewする
- Step 5. 月次でintake source別のvolume・accept率・duplicate率・lead timeを見直す
Failure signals
運用失敗を疑うシグナル
- Slack DMや会議口頭依頼が正式queueを迂回する
- Triage queueが単なる未処理backlogになりowner不在になる
- SLAが全件に付き、重要度の差が消える
- duplicate統合で顧客数や原文証拠が失われる
Sources
根拠にした一次情報
評価軸・運用ルールを設計するために参照した公式ドキュメントです。特定製品の推奨を意味しません。
Saved Workflow
保存した評価フローの現在地
進捗はこのブラウザのlocalStorageだけに保存します。候補製品名・評価点・PoC結果・Evidence本文は保存しません。