What separates a PRD engineering can build from one that triggers a week of back-and-forth? For each thing the gate checks, here's what good looks like versus weak - then run the two sample PRDs through the gate and watch the scores.
Clears the gate
Specific, testable, every state and edge case named. This is the bar.
Preview
# Chapter Rescheduling v2
## Problem & Goal
Writers abandon the chapter-scheduling flow - 32% drop off at the date-picker step because they can't see conflicts with already-scheduled chapters. Goal: cut drop-off from 32% to under 15% within 6 weeks of launch.
## Existing Behavior
Today scheduling is single-date only. v6.2 added recurring drafts. Clients below v6.0 call the v1 scheduling endpoint and must keep the current single-date UI (no forced upgrade).
## Design
Figma: [Chapter Rescheduling v2](https://figma.com/design/EXAMPLE/reschedule) - frames included for default, loading, empty ("No chapters scheduled yet"), conflict-error, and success states.
## Impacted Flows & Surfaces
Affects the editor schedule panel, the publish queue, and scheduled-chapter push notifications. No change to payments or discovery.
## Edge Cases
- Slot taken between load and submit → show conflict error and re-fetch the slot list.
- Offline → queue the reschedule and retry on reconnect; show a pending badge.
- Chapter deleted mid-reschedule → cancel and toast "This chapter no longer exists."
## Empty / Loading / Error States
- Empty: "No chapters scheduled yet." Loading: skeleton rows. Error toast: "Couldn't reschedule - please try again."
## Localized Copy
All strings finalized and added to the l10n sheet (EN, HI, ID). Dates render in the user's locale.
## Impact on Writers
Existing scheduled chapters auto-migrate to the new model; writers get a one-time in-app notice; no action required from them.
## Success Metrics & Analytics
Metric: schedule completion rate ≥ 85%. Event: `chapter_scheduled` fired on success with { source, is_recurring, had_conflict }.
## Platform Scope
Android + iOS this release. Web is a fast-follow and is explicitly out of scope here.
## Dependencies & Constraints
Depends on scheduling-service v2 (owned by Platform, already live). Ships behind flag `chapter_reschedule_v2`.
## Acceptance Criteria
- Given a taken slot, when I submit, then I see a conflict error and the slot list refreshes.
- Given I'm offline, when I reschedule, then it queues and completes on reconnect.
## Out of Scope
Bulk rescheduling, calendar sync, and web parity - tracked separately.
Gets sent back
Vague, no states, no metrics, "design later." The kind that costs a sprint.
Preview
# Chapter Rescheduling We want to let writers reschedule their chapters more easily. Right now it's a bit clunky and users complain. ## Solution Add a better rescheduling experience in the editor. It should be intuitive and fast. ## Features - Reschedule a chapter - Show upcoming schedule Design will be shared later. We'll track engagement to measure success.
What good looks like, criterion by criterion
Problem & goal
A concrete problem statement and the measurable goal of the change. Explains WHY now, not just WHAT to build.
Good
Writers abandon the chapter-scheduling flow (32% drop-off at step 2) because they cannot see conflicts. Goal: cut drop-off to <15%.
Weak
Improve the scheduling experience.
Existing / old behavior
How the feature behaves today, including relevant behavior across recent app versions (roughly the last ~10). Without this, engineering cannot reason about regressions.
Good
Today scheduling is single-date only; v6.2+ added recurring drafts. Old clients (<v6.0) must keep seeing the single-date UI.
Weak
Currently users can schedule chapters.
Design / mockups
Linked, up-to-date design for every new or changed screen and state. Not "design TBD" or a stale screenshot.
Good
Figma link with frames for default, empty, loading, error, and success states of the new panel.
Weak
Design will be shared later.
Impacted flows & surfaces
Which existing flows, screens, or systems this change touches or could break. The blast radius.
Good
Affects the editor, the publish queue, and push notifications; no change to payments.
Weak
Just a small change to the editor.
Edge cases & failure modes
Non-happy-path behavior: concurrency, empty inputs, offline, permission failures, partial data.
Good
If a scheduled slot is taken between load and submit, show a conflict and re-fetch. Offline = queue and retry.
Weak
Handle errors gracefully.
Empty / loading / error states
Defined behavior AND user-facing copy for empty, loading, and error states of each affected surface.
Good
Empty: "No chapters scheduled yet." Error toast copy specified. Loading: skeleton rows.
Weak
Show a spinner while loading.
Localized values & copy
Final user-facing strings and any locale-specific values (currency, date formats, RTL) are specified, not placeholder.
Good
All strings finalized and added to the l10n sheet; dates shown in user locale.
Weak
Copy is placeholder for now.
Impact on writers / creators
Explicit impact on content creators (writers) - their workflow, existing content, migration, and communication.
Good
Existing scheduled chapters auto-migrate; writers get an in-app notice; no action required from them.
Weak
Writers will use the new flow.
Success metrics & analytics
Measurable success metric(s) AND the specific analytics event(s) that will be fired to measure them.
Good
Metric: schedule completion rate. Event: chapter_scheduled fired on success with {source, is_recurring}.
Weak
We will track engagement.
Out of scope
Explicitly what is NOT included, to prevent scope creep and manage expectations.
Good
Out of scope: bulk rescheduling, web parity, and calendar sync - tracked separately.
Weak
(no out-of-scope section)
Platform scope
Which platforms are in scope (iOS, Android, Web) and any intentional differences between them.
Good
Android + iOS this release; Web is a fast-follow, not in scope.
Weak
Ship it on mobile.
Dependencies & constraints
External/API/team dependencies, feature flags, and known technical constraints or deadlines.
Good
Depends on scheduling-service v2 (owned by Platform, ready). Behind flag chapter_reschedule_v2.
Weak
No dependencies.
Acceptance criteria
Testable, unambiguous acceptance criteria an engineer can verify against.
Good
Given a taken slot, when I submit, then I see a conflict error and the slot list refreshes.
Weak
It should work well.