小团队做小产品，如果只能追求bigger and bigger的指标，会对细节做很多关注；但如果小团队做“大”产品，则只能先和别人比拼功能的多少，而不能拿细节说事，否则阶段性目标很难达成。
在开发过程中，这两种团队的相应指导思想肯定是不同的。代码、技术、架构等方面，不同团队也体现对应的特征。
为此，我还专门找过一些书籍来看，比如印象比较深刻的《实例化需求：团队如何交付正确的软件》。该书是在世界各地调查了多个团队软件交付过程后的经验总结。书中介绍了这些团队如何在很短的周期内说明需求、开发软件，并交付正确的、无缺陷的产品；为团队在实施实例化需求说明时使用的模式、想法和工件创建了一致的语言；展示了案例中的团队用来实现实例化需求说明原则的关键性实践；并在案例分析部分展示了一些团队实施实例化需求说明的历程。适合于项目管理、开发、测试、交付有关的人员阅读。
里面就系统性的阐述了如何不走弯路，开发出“正确”的软件给客户使用。讲得还是不错的。
对于toB产品，我们也无法断定先实现后优化的“快速迭代”方式是否正确。因为用户量不够大，用户的反馈还不够，如果只听一家之言，又怕被带偏。但优化是必定的，我们往往只能先作出基本功能，然后在用户体验后，判断是否与其实际场景匹配，用起来是否顺畅，甚至搞清楚最根本的问题“是否有用”。
我们现在这个团队，说实话，也是属于后者：代码量大，功能多，技术方面不谈，体验方面更不忍直视。前面两年，表面上是产品主导的，但由于toB的特征比较强，产品没有相关经验，无法对体验作出准确的定义，做出来的东西确实没有细节，再加上技术沉淀也少，只能追求形式上的“快速迭代”。一旦慢下来，回头去检视原有功能体验，就不是那个味儿了。