Skip to content

Product Requirements Document (PRD #2) - “Let Me Check Before We Blow This Up”

1. What Was Going On

With PRD #1 approved, the immediate operational risk was addressed: scoring no longer had to live entirely inside Jim’s head.

That solved one problem.

It did not solve a quieter one.

Every scoring run still carried anxiety. Once initiated, results would eventually be published - but there was no structured opportunity for the business to pause, review, or sanity-check what had just been produced.

Leadership agreed this mattered. They also agreed it could not derail the core work already approved.

That tension is why this became PRD #2, not an extension of PRD #1.

2. The Conversation That Triggered This Step

After approving PRD #1, someone asked an entirely reasonable follow-up:

“Before we publish… can we look at the results first?”

This triggered immediate agreement - and immediate danger.

Suggestions started flying:

  • dashboards
  • reports
  • diff tools
  • side-by-side views

The room was gently brought back under control with a simpler question:

“What does the business need to be able to confirm before publishing?”

That question forced a second PRD.

3. The Artifact

Below is the Product Requirements Document for Outcome 2, exactly as produced.

Still no design. Still no tools. Just business needs.

# Product Requirements Document (PRD)

## 1. Outcome Reference
**Outcome Name:** Pre-publish review confidence  
**Initiative:** Season Scoring Risk Reduction  
**Problem Summary:** Scoring results are published without a structured business review step, increasing the risk of undetected errors.

---

## 2. Business Objective
Provide business users with the ability to review staged scoring results before publication, increasing confidence and reducing the risk of publishing incorrect outcomes.

---

## 3. Detailed Business Requirements
- The business must be able to view staged scoring results prior to publication
- Staged results must be clearly identifiable as not yet published
- The business must be able to compare staged results to current production results
- Review activities must not modify production data

---

## 4. Business Workflow (Refined)
1. A scoring run produces staged results
2. Authorized business users access staged results for review
3. Staged results are compared to existing production results
4. The business confirms whether results are acceptable for publication

---

## 5. Roles & Permissions
- **Role:** Scoring Reviewer  
  **Responsibilities:** Review staged results and assess readiness for publication

- **Role:** Operations Administrator  
  **Responsibilities:** Grant review access and manage review permissions

---

## 6. Constraints & Policies
- Staged results must not be visible to external stakeholders
- Review access must be limited to authorized roles
- Review actions must not trigger publication

---

## 7. Assumptions
- Review will occur prior to each publication event
- Reviewers have sufficient domain knowledge to assess results

---

## 8. Acceptance Criteria
- Business users can view staged results without affecting production data
- Differences between staged and production results are visible
- No staged results are published without explicit confirmation

---

## 9. Open Questions
- Who has final authority to approve results for publication?
- What level of difference requires escalation?

4. What Almost Went Wrong

Several people tried to merge this PRD back into PRD #1.

  • “Isn’t this just part of scoring?”
  • “Can’t reviewers just look after the fact?”
  • “Do we really need to formalize this?”

All of those shortcuts were rejected.

Review-before-publish is a distinct business capability, not a sub-feature.

5. The Decision

Decision Question Are the business requirements clear enough to support a safe review step before publication?

Decision Made Proceed.

Why This Was Good Enough

The PRD:

  • defined review as a business action
  • protected production data
  • avoided prescribing how comparison is implemented

That separation mattered.

6. What This Unlocked (And What It Didn’t)

Now Allowed

  • Design review workflows
  • Define domain concepts related to staged vs production results

Still Not Allowed

  • Designing UI layouts
  • Selecting comparison tools
  • Automating publication decisions

Those temptations are still premature.

7. Why This Step Matters

This PRD introduces intentional pause into an otherwise linear process.

Without it, speed becomes the default - and mistakes become inevitable.

By making review explicit, the business reclaimed control over when results become official.

8. Sarcastic Footnote

At least one person suggested that “we’d probably notice if it was wrong.”

This was not accepted as a control mechanism.