立正把项目管理理解为一种为了达成结果而愿意不厌其烦跟进的工作，这类事在很多人眼里是低价值的，但恰恰决定了交付漂不漂亮⁠1。在微软、Facebook 这类公司，技术项目经理的职责就是汇总各方进展、安排会议、跟进进度、确保依赖按时解决、让不同组之间的合作顺畅，保证项目如期发布⁠2。所以判断一个项目管理做得好不好，看的不是任务有没有被勾掉，而是结果有没有发生、协作有没有被 unblock⁠3。如果只是把任务填进工具、每周打勾，那只是流程动作，和项目是否成立是两回事。

立正明确说，30天路线图的本质不是项目管理，而是假设验证；每一周的那句话是判定标准，能不能用证据而不是感觉回答它，答不上来这周就算失败，不管交付了多少文档⁠4。他举的反面场景是：有人花一整天打磨文档格式却没跟真实用户聊过，有人把原型动效做得很精致却没把核心功能丢给用户试，有人建了漂亮的看板、任务全完成，但产品是否成立依然没有答案⁠4。所以当目标本身还不确定时，先问这一周要验证什么，再决定要做什么，而不是先排交付物。

好的项目经理能帮项目更有效、更快速地推进，也能 unblock 程序员，前提是他有良好的理解能力，能找到项目的关键点⁠3。立正也提到，好的程序员往往有很强的 ownership，会从用户角度设计功能、甚至自己做数据分析，这说明项目管理要解决的是让对结果负责的人能顺畅推进，而不是制造额外的汇报负担⁠3。一个可以试的做法是：在推进项目时，先找出当前最卡住结果的那一个依赖或决策，把它作为本周跟进的重点，看它被解决后进度是否真的动了。