We've talked about agile fundamentals, MVPs, and when to use waterfall vs agile. Now let's tackle something critical: product ownership.
Who decides what to build? Who says no? Who owns the trade-offs between time, scope, and quality?
This 15-minute video covers an enormous amount of ground. I've watched it multiple times and always take something new from it.
Agile Product Ownership in a Nutshell
https://www.youtube.com/watch?v=502ILHjX9EE
In late 2014, early 2015, I'd just finished the factory move project. I knew how the factory worked, understood the operational problems, and could operate the systems.
We had talented technical people and excellent operations people. But there was a gap - understanding what operational problems the systems could solve and what was technically possible.
I could hold productive conversations with both sides.
Operations: "This manual process is painful, we're making errors, it takes too long."
Me: "Here's what the system could do, what we'd need to build, what the trade-offs are."
Tech: "We could automate this, but we'd need to change how this data is captured."
Me: "Here's what that means for operators and whether it's worth the disruption."
I wasn't the most technical person or the most operationally experienced. But I could bridge the gap and make decisions about what was worth building.
Things actually got delivered because someone could say "yes, build this" or "no, that's not worth it" without endless discussion.
Over time I moved on and this gap was filled by talented people who took things much further.
I've worked with some really talented ecom managers who were excellent product owners.
They knew exactly what customers wanted most. They could prioritise ruthlessly based on where we'd get the most value for our development effort.
They built features for the account area of the ecom site and delivered them in sprints - value every couple of weeks. They paired this with monthly marketing campaigns that wrapped up the features and gave customers the feel of a constant flow of improvements.
This wasn't about building everything. It was about building the right things, in the right order, and making sure customers knew about them.
Clear product ownership made that possible.
I've also worked with people fulfilling the product owner role who really struggled because they had the wrong bias.
Too tech-biased: Focused on technical excellence. Every solution felt like we were trying to build Skynet. No technical debt, everything architected beautifully, but often missed usability for actual users. They'd optimize for elegance when users needed simple and functional.
Too operationally-biased: Often missed how features could work incrementally. Didn't want to iterate or deliver incremental value. They wanted it to work in full the first time. This led to long delays before delivering anything, and often building more than was actually needed.
Too PM-biased: Wasn't product-focused. Just "give me a spec and I'll deliver." No sense of value, no prioritisation, no ownership of outcomes. Just execute the roadmap regardless of whether it was the right thing to build.
Good product ownership requires balance. Understanding the technology enough to know what's possible. Understanding operations enough to know what matters. But being focused on value and outcomes, not just specifications or technical excellence.
Here's something the video doesn't emphasize enough: product ownership matters just as much for bought solutions and configuration as for custom development.
When you're implementing enterprise systems, configuring platforms, or setting up integrations, you still need someone who can answer:
These aren't technical questions. They're business questions that need someone empowered to make the call.
Without product ownership in configuration, you get:
It doesn't matter what you're building or implementing. It needs a product owner.
My focus now is developing product ownership in others. We're building streams of work around operations and customer-facing systems. Not big enough for a product owner per thing, so we're grouping by who they serve.
This is influenced by Extreme Ownership from Jocko Willink and Leif Babin - leaders take complete ownership and accountability. I want people to own their areas completely, but I'll step in if there's a void. Not permanently, just until we develop that ownership elsewhere.
The goal is people who can:
Good product ownership requires bridging multiple perspectives while staying focused on value. You need enough technical knowledge to understand what's possible, enough operational knowledge to understand what matters, but you can't be too biased toward either.
The factory move gave me operational knowledge. The automation projects taught me to bridge tech and operations. The ecom work showed me what great product ownership looks like. The struggling examples taught me what happens when the balance is wrong.
This is an area I've spent a lot of time working in, and I'm trying to share what I've learned as others develop their own approach to ownership.
Watch the video (15 minutes): https://www.youtube.com/watch?v=502ILHjX9EE
Reference: Extreme Ownership: How U.S. Navy SEALs Lead and Win by Jocko Willink and Leif Babin