From 'Built It' to 'Explain It': Writing a PRD

Start: wanting to be a PM, but nothing to show

My target is Product Manager. But open my portfolio and it's all "built a site", "did research", "soldered a robot" — execution layer things.

A PM interviewer doesn't only ask "can you do it". They want to see can you think: why build this? for whom? how to make it better?

So I taught myself a lesson: review my own projects the way a PM would. First victim: the Fanren Xianxia companion — a full PRD.

What a PRD is, and why worth writing

PRD (Product Requirements Document) is the PM's blueprint — translating "I want a product" into who the user is, what scenario, what pain, how to solve, how to measure.

Its value isn't the document's beauty; it forces four answers:

1. For whom? — personas
2. Why? — scenarios & pain
3. How? — feature solution
4. Is it good? — metrics

How I reviewed the companion

Personas (not "everyone", three types)

• The binge-reader: slow updates, long gaps, forgets everything → "one-tap recall"
• The fragmented reader: reads in fragments, confuses relationships → "who is this" lookup
• The deep reader: wants sects, techniques, geography → structured info base

Scenarios & pain

Before, I only had a vague "make a reading assistant". Writing the PRD forced specific pains: binge gap, character confusion, heavy world-building, weak immersion — each mapped to a feature module, one-to-one.

Solution

Five core modules, all derived from pains, not "this would be cool":

• character database → "character confusion"
• plot timeline → "binge gap"
• world/map → "heavy system"
• seamless BGM → "immersion"

Metrics

The key shift: I defined a north-star metric — "recall success rate" (can the reader find what they want first try). Before I only cared "did I build it"; now I care "is it useful, will they stay".

Roadmap

I added an iteration path: data → multi-work → AI Q&A → community UGC. This made me realize: building a product isn't a one-time delivery; it's an evolving line.

What I learned

> "Building it" is execution; "explaining it" is thinking. The latter is a PM's real core skill.

Before, when writing code, my first question was "how to implement". Now I ask "why implement, for whom". This review didn't change the code — but it completely changed how I look at a project.

The full PRD is on the project page. It's not my most technically complex project, but maybe the one that best shows my product thinking.