Skip to main content
Project management gets a bad reputation in product circles. Gantt charts, status reports, RAIDs logs - it can feel like the opposite of agile, adaptive product thinking. But there’s a real distinction worth making: project management is the right tool for certain kinds of work, and using it poorly doesn’t mean the discipline is wrong 📋

​
What project management actually is

Project management is the discipline of delivering a defined scope of work within agreed constraints - time, budget, resources. It assumes you know roughly what needs to be built and focuses on coordinating the work to get there reliably. That’s different from product development, where discovery is part of the work and the scope is expected to change as you learn. Project management works best when the uncertainty is low and the coordination challenge is high.

​
When it’s the right approach

  • Compliance or regulatory work - the scope is fixed by external requirements, not user research
  • Infrastructure migrations - moving to a new data centre, upgrading a core platform, cutting over to a new payment provider
  • Cross-functional launches - coordinating marketing, legal, support, and engineering for a major release
  • External commitments - when you’ve contracted to deliver specific functionality to a client by a specific date
In these contexts, the classic project management toolkit - milestones, dependency mapping, risk registers, clear ownership - is genuinely useful 💡

​
The tension with product thinking

Mik Kersten makes this argument compellingly in Project To Product - the shift from funding projects to funding products is one of the most important organisational changes a company can make. Project funding optimises for delivery of a defined scope; product funding optimises for outcomes over time. The failure mode is applying project management thinking to discovery work. Treating user research as a task with a completion date, putting feature development on a Gantt chart before the problem is understood, measuring velocity as a proxy for progress. Agile and dual-track delivery exist partly as a response to this - recognising that product work involves ongoing learning, not just execution of a pre-defined plan.

​
The hybrid reality

Most product teams need both. Delivery has a project management dimension - sprints need planning, releases need coordination, dependencies need tracking. The skill is knowing which mode you’re in and not confusing the two 🙌 Lesson learned: the best delivery managers I’ve worked with don’t fight the product process - they protect it. They handle the coordination overhead so the team can focus on building the right thing.