In technology projects across government and emergency services, I've seen some deliver exceptional value quickly, while others drag on with a swathe of missed opportunities and a ROI hobbled by mismanaged input. The difference rarely comes down to technical complexity or budget constraints. One pattern has become crystal clear though - Product Owners can have an outsized impact on the value delivered, and the timeline it’s delivered on.
Putting some forethought and effort into choosing the right person - when you’re investing potentially millions of dollars - is both a logical investment of time, and a critical task on your project planning journey. Here's what actually matters when choosing your project's product owner - and it might surprise you.
#1. The Right Attitude (This trumps everything else)
What I used to think mattered: Deep understanding of the Product Owner role, personal experience as a user, knowledge of agile methodologies and frameworks.
What actually matters: Boundless enthusiasm and an unrelenting drive to get things done.
The best product owners I've worked with weren't necessarily the most process-oriented, and most had never done the job before. Some had never heard of Agile. They were the ones who treated the project outcomes like their personal mission and worked as though they were truly a part of the development team - no matter what the project structure was. They genuinely cared about solving user problems, and didn’t just work within the bounds of a Jira board - they were constantly looking for ways to find value and deliver outcomes.
What to look for: Someone who talks about the project's potential impact with genuine excitement, who asks thoughtful follow-up questions, and who brings up new ideas and connections outside of scheduled meetings.
What to avoid: Someone who treats this as just another responsibility added to their existing workload, and a list of tasks to be done.
#2: Dedicated Availability (of both the Product Owner and the relevant SMEs)
The reality: Your product owner needs to be genuinely available for the project - not squeezing it between existing priorities. But beyond their own time, they're also coordinating access to the entire ecosystem of inputs the project needs.
Your product owner becomes the crucial bridge between:
- Development teams and end users who understand the real problems
- Stakeholders with vision and the people who can make it happen
- Data gatekeepers and the data scientists who can unlock insights
- Decision makers and the users the project is supposed to serve
The coordination reality: For significant projects, this coordination function can easily become a significant portion of someone's role. If the product owner isn't truly available - or if the subject matter experts they need (military analysts, linguists, fire behaviour specialists, operational commanders) are constantly unavailable - you're looking at a string of hold-ups, blockers and ill-informed priorities for your development team.
What to look for: Someone who can dedicate real time to the project and maintain momentum across competing priorities. They should proactively manage stakeholder expectations, navigate calendar coordination without becoming the bottleneck, and get key decision-makers and subject matter experts engaged when it matters most.
What to avoid: If you HAVE to do fractional roles, I’d personally prefer to see a PO that’s split 50/50 between the project, and a user role, as opposed to a PO split 50/50 across 2 different projects. The exception, is if those 2 projects are closely intertwined (for example, 2 systems that form part of a critical workflow) - in which case, that kind of overlap could be exceptionally valuable.
#3: Organisational Influence and Credibility (The Hidden Superpower)
The reality: Your product will succeed or fail based on adoption by people across multiple departments and levels of seniority.
Your product owner needs to be someone who:
- Has credibility across different functions (not just in their home department)
- Can facilitate access when you need specific expertise, data, or approvals
- Understands how decisions really get made (beyond the formal org chart)
The most successful projects I've worked on had product owners who could flick a Slack message through and arrange access to busy subject matter experts, they could schedule a meeting and the right people actually showed up, or they knew exactly which approvals were truly necessary versus bureaucratic theatre.
The network effect: When your product owner has strong relationships, months of tedious question and answer, can compress into single conversations. When they don't, simple requests can become weeks-long approval processes.
The executive override challenge: Here's a common scenario - a high ranking official who's funding the project appears in the final sprint with a brilliant idea for a feature they think would be valuable. The problem? The users (those who the project was actually funded to serve) have already established this feature is flashy but not valuable. Your product owner needs the credibility and backbone to advocate for user priorities in these moments. They have the context, the real-world data, and they know the actual use cases. They need to be able to respectfully but firmly stand up for their users when it matters.They won’t by any means be doing this alone - but their input will be critical, in these critical conversations.
#4: Mission Motivation and Identity (Why They Care Is Why They'll Have Impact)
The people with the right attitude didn't choose their career path randomly. They've typically developed deep expertise in at least one critical area - GIS systems, counter terrorism, military affairs, operational planning, or emergency response protocols.
The reason you should care about where they’ve chosen to build their career, is that this domain expertise is actually a proxy for being motivated by the mission. They care deeply about the work because they've dedicated years to mastering it. They're going to work hard to make sure the job is done well because it's not just a project to them - it's an extension of their professional identity and passion. They go home and think about this mission, and how they can better contribute to outcomes aligned with it.
This domain expertise, and personal drive, often trumps formal product owner or product development training. They understand the real problems because they've lived them. They have instant credibility with end users because they've been in their shoes, and those same users probably already know how they functioned in their role - because they were good at it.
Here's the key insight: product development should be a meaningful step in their career journey, not their entire destination. The best product owners see this role as a way to amplify their existing expertise and drive organisational impact beyond their traditional domain.
Making the Investment Count
Most organisations approach product owner selection as "who's available and has some capacity." But in the government, defence and emergency services domains especially - if you're investing significant money, time, and resources in a major technology project, that casual approach undermines your entire investment.
If your organisation is investing hundreds of thousands or millions of dollars in a major technology initiative, the product owner role deserves careful selection and support.
The strategic approach: Identify your best candidates and make the product owner role attractive to them. Show how leading a successful technology initiative will:
- Expand their influence across the organisation
- Develop new skills in technology and change management
- Create tangible impact they can point to in their career progression
- Build valuable relationships across departments and levels
When you frame the product owner role as a career development opportunity rather than just another assignment, you attract stronger candidates and get better outcomes.
The organisational benefit: Investing in a great product owner doesn't just improve your current project - it develops internal capability for future technology initiatives and improves technical literacy across the organisation too.
The Bottom Line
Your technology choices matter. Your development approach matters. Your budget and timeline matter.
But none of that maximises value without the right person orchestrating the connection between what you're building and the people who need to use it.
When you're making significant technology investments, treat the product owner decision with the strategic importance it deserves. The ROI of getting this right compounds through every subsequent decision in your project.
What's been your experience with product ownership in technology projects? What factors have you found most predictive of success?
