我有幸在工作的头几年就开始关注牛人的项目管理是怎么做的，读的第一本项目管理书籍是《成为技术领导者》，作者站在一个技术牛人的角度上更关注人与人之间的协作。更有幸的是，我很快就有机会参与到一个北美的跨国合作项目里去，那时候正式敏捷刚刚起步的头几年。坊间有大量的文章在拿敏捷和传统的瀑布式项目管理流程做对比，其中最重要的对比就是需求分析。因为关键需求的遗漏、误解，各个合作方从未讨论过的潜在假设造成的项目失败屡见不鲜。程序员最痛恨的加班，尤其是无效的加班，也往往由需求变化，或者更准确的说是需求遗漏和误解引起。
后来，也有人告诉我，无论是采用敏捷还是瀑布，都有人做的很失败，也有人做的很成功。当然，这其中对技术难度和项目进度的把控能力对项目成功是必不可少的，但我觉得对需求的把握也同等重要。
在上份工作的后期，我开始作为售前，参与产品的销售、推广、对销售人员的培训，我能把产品的技术架构和优势讲得清楚又通俗，但对方理解了之后，问的第一句话往往是，这个产品有什么用？我跟对方解释说，我们的产品能帮你更安全的在移动设备上办公，这听上去并不像是一个很有吸引力的话术，一听就像是技术人员才会说的话，如果是“电梯间谈话”，那这单生意肯定黄了。移动设备办公是个通用说法，而我们的产品是为企业提供通用的安全基础服务，“通用”太大了，不够具像化，如果要具像化，就要了解客户的行业，什么场景下才需要在办公室以外的地方工作，而且一旦发生了网络安全问题，会对客户的业务造成很大的损失。虽然我们的产品技术优势很明显，用户体验也很棒，在网络安全方面绝对可以帮用户降本增效，通用性也足够强，具备很多竞品不具备的能力，但是，一个致命的缺点是，我们不懂客户的业务，不了解客户什么时候需要我们的产品。
大量的技术人员都把着眼点和精力放在如何提升技术水平，提高易用性、技术指标等跟技术有关的方面上，技术实力固然是根本，但如果需求是错的，或者产品找不到对应的市场，技术再好，也无英雄用武之地。