Project or Product? Choosing the Right Path for Delivering Outcomes That Matter
- Marcus Ward
- Mar 29
- 4 min read

If you’ve spent any time in delivery—whether as a sponsor, PM, team lead, or exec—you’ll know that conversations about “project vs product” can quickly turn theoretical. There’s a lot of noise in the market about ditching projects or “going agile,” but for most of the leaders I work with, the real question is more grounded:
“How do we deliver this thing well—and not burn people out in the process?”
That question is at the heart of so many strategic conversations right now. We’ve got clients trying to modernise legacy systems, shift to customer-led delivery models, or reduce operational risk. And the complexity isn’t just technical—it’s human, structural, cultural.
What’s become clear over the years is this: it’s not about project vs. product—it’s about choosing the right delivery model for the outcome you’re trying to achieve.
Projects Aren’t Broken—They’re Just Misused
Let’s start here. I’ve spent over twenty years helping organizations improve how they deliver, and I’ve seen first-hand the value of well-run projects.
When scoped properly and run with discipline, projects offer:
• Clarity of purpose
• Defined milestones and accountability
• A clear end state that gives people closure and confidence
We see this work brilliantly in capital programs, regulatory projects, or major procurement efforts. For example, we supported Rio Tinto on a safety-critical roster uplift. The clarity and control provided by a structured project model were essential—not just for the delivery, but for the confidence it gave execs and regulators.
Where things go wrong is when every initiative is forced into a project model, regardless of complexity, customer needs, or long-term ownership. That’s when you see delivery drift, handover gaps, and fatigue.
Product Thinking Isn’t a Silver Bullet
On the flip side, the shift to “product” thinking has a lot of momentum—and for good reason. When done well, it creates space for:
• Continuous improvement
• Real customer focus
• Long-term accountability for outcomes
We worked with Transport for New South Wales that made the conscious decision to evolve one of their internal platforms from a project to a product model. The turning point? Realising that the real value wasn’t in launching the platform—it was in adoption, feedback, and iteration post-launch. That’s where outcomes like customer satisfaction and operational efficiency were actually won or lost.
But here’s the trap: product models require maturity. You need strong product ownership, stable funding, cross-functional teams, and executive support. If you rush into it without the foundations, you end up with the same issues you had in project land—just dressed up with different language. Sadly the fix is not a two day training course.
Why We Built a Triaging Tool
We saw so many clients wrestling with this question—project or product?—that we built a simple triaging tool to help leaders assess their initiatives.
It’s not magic. It’s a practical lens.
• What’s the level of change and uncertainty?
• How important is long-term ownership?
• How fixed (or flexible) are the outcomes?
• Is the organisation set up for iteration, or is it still structured around control?
It’s been a game-changer in portfolio conversations. It gives execs and delivery leads a shared language to make better calls—and avoid mismatched approaches that lead to rework or burnout. We've recently implementated this into an Oil and Gas Operator and the benefits have spoken for themselves
The Often-Ignored Variable: Capability
One thing we’ve learned is that the best delivery model in theory means nothing if your people don’t have the skills or tools to execute it well.
• You want great project delivery? Your teams need fundamentals—scope control, risk management, stakeholder clarity. That’s why we run our Project Management Fundamentals course. It’s not flashy, but it’s consistently one of the most practical and valued pieces of learning we offer.
• You want strong product ownership? Then your people need more than a job title and a training course. They need a clear definition of the role, real tools to prioritise and say no, and the support to hold the line on value.
That’s why we built our Product Owner Toolkit—not to sell “training,” but to help real people succeed in messy, complex environments. It includes self-assessments, playbooks, planning templates, and stakeholder maps—all developed from what we’ve seen actually work.
So, What’s the Right Model?
That’s the wrong question.
The right question is: What’s the outcome we’re trying to deliver—and what model gives us the best shot at delivering it well, without wasting time or people?
Sometimes that’s a project. Sometimes a product. Often, it’s a mix—or a staged transition from one to the other.
The common feedback we receive is that we live our values of flexibility so aren't constrained by a one size fits all approach . We’re here to help clients make smarter calls, build internal capability, and align strategy with execution in a way that sticks.
If You’re in This Space Right Now…
You’re not alone. These conversations are happening across the board—in government agencies, utilities, mining majors, and infrastructure portfolios. If you’re wrestling with how to structure a portfolio, define ownership, or move from intent to impact, we’d be happy to talk.
No hard sell. Just honest insight from people who’ve been in the weeds with you.
Want to run a few of your initiatives through the triaging tool?
Or chat about what product ownership needs to look like in your context?
Drop me a message. Let’s figure it out—together.
Recent Posts
See AllA few years ago, I walked into a meeting with a leadership team at a State Government Agency . Their PMO was struggling, and frustration...
Comments