The PRD Nobody Reads (And How to Write One People Actually Feel)

I've read hundreds of PRDs in my career.

Most of them are dead on arrival.

Not because they're wrong. Because they're empty. Technically correct documents that answer every question except the one that matters: why should anyone care?

The Problem with Most PRDs

Here's what a typical PRD looks like:

User Story: As a user, I want to save items to a list so that I can access them later.

Acceptance Criteria: User can click save button. Item appears in saved list. List persists across sessions.

Technically complete. Emotionally dead.

No one reads this and thinks "I need to build this right now." No engineer gets excited. No designer feels inspired. It's a task list disguised as a vision.

And we wonder why products feel soulless.

What I Learned the Hard Way

A few years ago, I was working on a product I really believed in. I wrote a detailed PRD. Twelve pages, every edge case covered, beautiful diagrams.

The team built exactly what I specified.

And nobody used it.

The problem? I described what we were building, but I never made anyone feel why it mattered. The team executed perfectly on a document that had no soul.

That failure changed how I write PRDs forever.

The PRD That Makes People Feel It

Now I follow a simple rule:

Before you write what you're building, make the problem impossible to ignore.

A great PRD does three things:

Makes the problem undeniable so everyone feels the urgency
Makes the solution inevitable so it feels obvious in hindsight
Makes the scope ruthless so you actually ship

Here's the structure I use now.

Step 1: Start with a Person, Not a Persona

Forget "users aged 25-34 in urban areas."

Picture ONE real human being.

What's their name? What's their job? What time do they wake up? What's the first thing they feel when they open their eyes?

Example:

Maria is a 28-year-old marketing manager in Milan. She wakes at 6:45am. Before her feet hit the floor, she already feels the weight of her inbox. Forty unread emails. Three meetings before lunch. She hasn't had a thought that was hers in weeks.

Now you're not building for "users." You're building for Maria. And suddenly, every decision gets easier.

Step 2: Find the Moment of Need

When does Maria reach for your product?

Not "throughout the day." The exact moment.

Is she in bed? On the metro? After a hard conversation? At 2am when she can't sleep?

The more specific the moment, the sharper your product becomes.

Generic moment = generic product.

Specific moment = product that feels like it was made for you.

Step 3: Name Your Belief

Every great product has a contrarian truth at its core.

Airbnb believed strangers would sleep in strangers' homes. Slack believed work chat could feel like group texting with friends. Duolingo believed people would learn languages through a game.

What do YOU believe that most people don't?

Write it in one sentence. If you can't, you're not ready to build yet.

Step 4: Define the Magic Moment

This is the single interaction that sells the whole product.

The "aha." The screenshot you'd put on a billboard.

Ask yourself:

What happens in that moment? How fast can someone get there? (Under 60 seconds is good. Over 5 minutes is danger.) What do they feel right after? Name the emotion.

If you can't describe the magic moment clearly, your product doesn't have one yet. Fix that first.

Step 5: Be Ruthless About Scope

Here's where most PRDs go wrong. They list everything the product could be.

A great PRD lists only what v1 must be.

Two lists:

IN: The minimum set of features to deliver the magic moment. Nothing more.

OUT (for now): Everything you're saying no to. Write it down. It's a commitment.

The "OUT" list is more important than the "IN" list. It shows you have discipline. It builds trust with your team.

Step 6: One Metric

Not five KPIs. Not a dashboard.

One number that would make you cry happy tears.

"7-day retention above 40%." Or "50% of users complete their first project." Or "NPS above 60."

If you can't pick one, you don't know what success looks like yet.

The Template

Here's what I use now. Fits on one page.

# [Product Name]

## The Problem
[A short story. One person. One frustration. 3-5 sentences max.]

## The Belief
[One sentence. The contrarian truth your product is built on.]

## The Vision
[≤10 words. What this becomes.]

## The Magic Moment
[Describe it. Screenshot it if you can. Make it tangible.]

## What We're Building (v1)

IN:
• [Feature] and [why it matters]
• [Feature] and [why it matters]
• [Feature] and [why it matters]

OUT (for now):
• [Thing we're not doing yet]
• [Thing we're not doing yet]

## Success Looks Like
[One metric. One sentence.]

## Open Questions
[What you still don't know. Honesty builds trust.]

The Gut Check

Before you share your PRD, ask three questions:

Could a stranger read this and want to build it? If not, add feeling.
Could an engineer read this and start tomorrow? If not, add clarity.
Could you delete 30% of it? If yes, do it.

The Truth

A PRD is not a document. It's a transfer of belief.

Your job is to make the reader (engineer, designer, stakeholder) feel what you feel. See what you see. Want what you want.

If they finish reading and shrug, you failed.

If they finish reading and say "when do we start?" you did your job.

Write less. Mean more.

And build something worth building.