提問：看到 @cicada 在topic里提到 寫PRD也曾經被程序員表揚說“從技術角度來寫的PRD，看起來很舒服”，請教下各位PRD怎么寫才算是從技術角度來寫？
z：
1. 有可能的話，先綜述一遍你要的表現層，然后在 PRD 里把具體要實現的東西一條條寫出來。即是，開發只要照著你寫的單元一個個的制造「積木」，最后拼積木就行；
2. 定義在你產品中反復出現的一些名詞，并且在你的 PRD 里有且只用這個詞表示同一個含義。這就相當于是程序里的「變量」；
3. 能夠被復用的產品單元（模塊）就不要換著寫法寫好幾遍，開發可能會給你做出不同的東西來；
4. 在文檔里把涉及到交互的動作寫清楚路徑，不要讓開發自己去腦補「誒，首頁這里應該是跳轉到 XX 去吧？」
還有很多細節可以寫，但總的來說，我覺得給技術看的 PRD 不要是那種每次看都要理解一下要做啥的，而是直接告訴他，你要做什么的。越接近這個程度越好。（有些時候技術經理就是為了銜接這個環節的，如果產品和技術都各往前一步，就沒必要中間環節了）
cicada：
其實我也不知道技術為什么這樣夸我，并沒有刻意從技術角度去寫PRD，就是按照我自己覺得舒服的角度。不過現在的團隊里已經有兩位程序員這么夸過我了。
樓上@z 說的的確是我做的事情，先總后分，擅長拆分模塊，精準定義名詞，詳細描述路徑。可能這個就算是技術邏輯的一部分？比如說，從技術角度進行模塊化處理，并且清晰描述模塊之間的連接關系。
我不懂編程，也不想學。我覺得重點是具備和技術能順暢溝通的邏輯，以及在邏輯前面的準確的表達能力。如果邏輯和表達不夠好，即便是程序員轉型產品經理，也未必能和程序員順暢地溝通。而邏輯和表達恰好都是我的強項。
jchen174：
交互層，邏輯層，數據層，把握好這三者區別，大部分程序員都能看明白。
melodylai：
1.先說個不好的案例吧，曾經我的文檔都是寫在交互稿旁邊的，后面跑去問技術哥，你們覺得我的文檔哪里需要改進的么，后面技術哥說，媽蛋我們寫代碼都是一個頁面一個頁面來，你一個交互稿給我們，閱讀起來非常分散極不方便還容易漏東西～ 后面就習慣一個頁面一個頁面來組織文檔了，完了附一個交互稿在下面。
2.再來一個現在prd的經驗：盡量結構化，不要一坨東西堆在一起；有些用文字表達理解起來特別費勁的可以嘗試用表格／圖片表達，東西是死的，表達方式是活的。
cicada：
@melodylai 我的PRD發在Tower上，一系列關聯的頁面單寫一貼，帖子里先發視覺稿，再對著視覺稿寫技術需求，另一則小經驗是“多用小標題”。
melodylai：
@cicada 我這也差不多，不過協作平臺用的是騰訊爸爸家的TAPD。以前寫技術需求都習慣用純描述性語句，一大坨堆在一起，技術哥理解起來其實很費勁的，后面技術哥和我提到結構化的時候醍醐灌頂，從此PRD里面有了很多小標題和小小標題，小標題的寫法偏向于用提問句，然后把答案（也就是產品解決方案）以列表形式寫在下方。
cicada：
簡單來說，產品經理腦子里天然就是一張思維導圖，做什么事情都用思維導圖的樹狀結構來梳理，直到成為本能。有這個本能之后，不斷優化樹狀結構就是自然而然的事情了。
