企業（Enterprise）和初創公司（Starup）最大的區別在於，企業通常已經找到了（算是）牢靠的現金流管道，短期內不必擔心生存問題；而初創公司還在不斷探索什麼樣的產品真的能賣到錢，以及如何讓使用者持續從口袋裡掏錢。對於初創公司，一旦賬上的錢不夠發出下個月的工資，團隊就立刻、馬上面臨爆炸，潰不成軍。
在真實的商業環境裡，很多工程師加入的是Enterprise，而不是Starup。他們習慣等產品把PRD文件和原型擺到案前，對商業模式的認知通常是：
商業模式不是我要考慮的事，反正我只需要把確定的模組實現，公司就會自動賺錢。如果碰到返工，那產品經理和老闆全是豬，自己沒想清楚，只知道讓我先做。
而在一家網際網路企業中，碰到一個既不懂商業邏輯，又不懂技術的產品經理的概率，還是很高的。
這樣的PM通常是老闆聘請的跟班，負責收集內部（通常來自上級）和外部產生的「需求」，將需求以文件形式「翻譯」給研發團隊。一個兩邊都不懂都人在中間當翻譯，結果只會炸成一地雞毛。老闆隔三差五跑進辦公室拍桌子要功能，留下PM和RD面面相覷，重新排期，把修改後的需求加塞插入。
中間一來一回，很可能一天就過去了。
企業還有機會試錯，初創公司這樣做就是自殺。
所以Starup的工程師（通常持有公司股份），就必須掌握開發任務的主動權，要釐清當前issue的優先順序，用MoSCoW原則來驅動，而不是沒有意義的P1,P2,etc. 而團隊中的PM，最好有技術背景，即便不能自己做研發，也要明白基本概念。如果工程師不止一次抱怨跟某位PM溝通是雞同鴨講，那麼這個PM會讓團隊整體的戰鬥力打個7折，甚至可能讓團隊完蛋（因為TA不曉得自己坐在這裡有什麼意義）。技術、商業（實操和嗅覺）、邏輯（包括資料的敏感性），PM至少佔一樣，否則不適合幹這份行當。
那麼，我認為初創公司最基本要做到的，是（樸素的）講好的你的使用者故事(User Story)
User story是Mike Cohn提出的一種描述需求的方式，通常包含：
- 幾句話講清楚使用者需求
- 驗收測試
典型的使用者故事描述格式是這樣的：
作為 <某類使用者>，我想要 <完成某個目標>，這樣的話 <某些理由>
- 例如：作為一個炒幣使用者，我想要夜間功能，這樣我晚上看行情做操作不刺眼。
拿這樣的需求擺在檯面上講，才能將PM和RD放在同一個原始場景內，效果遠好過丟過去十幾頁的PRD功能描述（沒有人知道你到底想幹嘛）。
RD也是使用者，幾句話能講清楚的需求，人家才能立刻秒懂，才能知道可能有哪些坑要填。
User story適合放在confluence（或語雀）上，團隊中的任何成員都有權利丟擲User story，快速對其進行討論。使用者故事作為團隊Knowledge base的一部分，必須做到快速冒泡，快速驗證。
User story最好能拆解到工程師能在一個Sprint（通常一到兩週）內完成，甚至一天的工作量搞定。否則粒度就應該拆的更細，由多個小的story拼接成某個具體場景。只有這樣才能：
- 大概齊能預判要花費的時間
- 工程風險可以在每天Standup（或者你用Geekbot代替）上被抓到
- issue看板上的任務才是「活的」，而不是「死在那裡」
通常，我會在所有的User story上追問：
這樣做對大部分客戶有價值嗎？他們想要這個功能想要到願意從口袋裡掏錢嗎？
這是因為初創公司就這點人、這麼點錢、這麼點時間視窗，任何不是Must Have(a.k.a 不是商業閉環裡必需的)的功能都佔用了你的研發資源。
功能被研發出來後，應該迅速在你的 Alpha使用者->粉絲使用者->普通使用者 裡驗證，如果它對拉高Retention Rate/使用者付費/交易頻次沒有直接（或間接的）好處，那麼它甚至一開始就不應該出現在backlog中。
對於初創公司的研發，重心應該在打造當前階段可交付的產品上。早期的過度設計（Over-Engineering），會將自己的工作暴露在全然不可預測的環境中，被設計模式（Design Pattern)綁架。
拿TDD當例子，資深研發都認同這樣的論點：TDD對於功能明確的、過程複雜的、核心的模組，可以有效減少系統風險，提高開發效率。
但對於「未知問題的解決」，TDD派不上什麼用場。多寫的那部分Unit Test，只會讓開發耗時成倍數上升。而TDD通常來說又都很具體，Unit Test只能保證區域性程式碼的牢靠，無法防範系統整體架構的風險。
從這點看，應該抓大放小，核心框架的測試有充分必要，而C端面向使用者UI層的Unit Test，並不值得。
初創公司的產品開發必須精悍緊湊，迅速修正，不然上線的一天，就是夢想破碎的一天。