企业（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，并不值得。
初创公司的产品开发必须精悍紧凑，迅速修正，不然上线的一天，就是梦想破碎的一天。