How Thinkr critiques a PRD: a worked example

Setup

Most product tools say they have an AI critique. Few show you what one looks like.

This post walks through a PRD and the critique Thinkr produced across eleven passes. We will look at what it caught, what it missed, and why the structure matters more than the model. The spec below is constructed, not a customer's — but the gaps in it are the ones that show up in real drafts every week.

The PRD

Here is the spec, trimmed to the part under review. It is the kind of draft that looks finished and is not — the work is "done," so the holes are easy to miss on a re-read.

Feature: Saved Views (B2B Analytics Dashboard)

Problem
Users rebuild the same filters every time they open the dashboard.
It is annoying and slows them down.

Goal
Let users save a configured dashboard view and return to it later.

User stories
- As a user, I can save my current filters as a named view.
- As a user, I can switch between my saved views.
- As a user, I can delete a view I no longer need.

Requirements
- A "Save view" button in the dashboard toolbar.
- Saved views appear in a dropdown.
- Views persist across sessions.

Success
Users will save time and be happier with the dashboard.

It reads fine. That is the problem.

What the critique returned

Thinkr ran the spec through its passes and landed findings as comments — each classified by severity, each pointing at the line it concerns, each with a suggested rewrite. Here are the ones that fired, by pass.

Completion

Blocker — Success section is not measurable. "Users will save time and be happier" is a hope, not a metric. There is no baseline, no target, no instrument. Suggested rewrite: "Reduce median time-to-first-insight per session from X seconds to Y; target ≥40% of weekly-active users with at least one saved view within 30 days of launch."

Major — No non-functional requirements. Nothing on the view limit per user, payload size, or load latency when a view is applied. Suggested rewrite: add a Constraints subsection — max views per user, max filters per view, target apply-time under 300ms.

Clarity of thinking

Major — Problem and goal are mismatched in scope. The problem is "rebuilding filters." The goal quietly adds "return to it later," which implies persistence, naming, and ownership — a bigger surface than the problem justifies. Suggested rewrite: tie the goal directly to the problem, or expand the problem statement to cover cross-session return as a named need.

Engineering readiness

Blocker — No acceptance criteria. Three user stories, zero testable conditions. Engineering cannot tell when "save a view" is done. Suggested rewrite: for each story, add Given/When/Then — including what a view captures (filters only? sort? column layout? date range?).

Major — Ownership and sharing are undefined. Are views private to a user, or shared across a workspace? In a B2B tool this is the first question engineering and security will ask. Suggested rewrite: state the sharing model explicitly, even if the answer is "private only, v1."

User flow coverage

Major — No empty and error states. What does the dropdown show with zero saved views? What happens when "Save view" fails, or a name collides with an existing view? None of these flows exist. Suggested rewrite: add flows for empty state, save failure, and duplicate-name handling.

Edge case & QA drill

Minor — Deletion has no confirmation or undo path. Deleting the active view is destructive and the story is silent on it. Suggested rewrite: specify a confirm step, and what the dashboard falls back to after the active view is deleted.

Domain gap analysis

Major — Multi-tenant assumptions unstated. This is a B2B dashboard, so a "user" sits inside an organization. Do views move with the user across orgs? Are they visible to an admin? The spec writes as if it were single-player. Suggested rewrite: name the tenancy model and where saved views live relative to the org.

Synthesis & final verdict

Top risks: unmeasurable success criteria; missing acceptance criteria; undefined sharing/tenancy model. Top improvements: make Success instrumented; add Given/When/Then per story; decide private-vs-shared before build. Readiness score: 2 / 5. The intent is clear; the spec is not yet buildable as written.

What it missed

Worth being honest about the ceiling. The critique flagged that Success was unmeasurable — but it could not tell you whether Saved Views is the right bet against everything else on the roadmap. It could not tell you that, in this product, most users only ever keep one view, which might collapse the whole feature into a default. Those are product-judgment calls that depend on context the spec does not contain.

A critique sharpens the spec you brought. It does not decide your strategy for you. Read it as the senior reviewer who makes your draft buildable — not the one who tells you what to build.

What that means

Notice what produced these findings. Not a cleverer model writing prettier prose — a structure. Eleven passes, each looking for a specific class of gap: completion, clarity, engineering readiness, flow coverage, edge cases, domain fit. The model is the engine; the passes are the road.

That is why structure beats model here. A general-purpose chat will tell you the spec "looks good" because nothing told it to go hunting for the missing tenancy model. The pass for domain gaps is what found it. Same model, different scaffold, completely different review.

It is the same point the principles post makes in the abstract: name the missing thing, take a position, prioritize. The teardown is just what that looks like when it runs.

To run these passes by hand, the PRD review checklist is the standing version, and common PRD mistakes maps each failure mode to the pass that catches it.

---

This is one of three anchor posts shipping with Thinkr at launch. Read also What makes a PRD critique actually useful and From research to proposal: the loop, or see the critique surface itself.