In the hit comedy ‘Dude, where’s my car?’ from 2000, two friends wake up with no memory of the night before and no idea where they parked their vehicle. They spend the whole film asking strangers, and every answer sends them somewhere weirder. I think of it whenever someone in one of my classes asks how to define their product, because what they usually mean is: where is my product? Ask ten people in your organization and you’ll get ten answers, none of them the one you needed.
Here’s the thing about those two friends. Their problem was never the car. Their problem was the activity. They kept asking where it was instead of doing anything about it. Product Owners end up doing the same when they wait for someone to hand them a product. That’s the passenger seat, and it’s a bad seat to sit in for a couple of years. When you don’t get handed a product, your job includes defining one. Helping your organization see its work from a product perspective isn’t a distraction from the job. It is the job.
Twenty years on, the title travelled further than the job
If you feel like a Product Owner in name only, that isn’t a personal failing. It’s a profound anti-pattern of the industry you work in.
After two decades of ‘Agile transformations’ and attempts to work with Scrum, the title ‘Product Owner’ spread faster than the accountability behind it. Dave West of Scrum.org describes the usual origin story: somebody was told to do Scrum, Scrum needs a Product Owner, and the role landed on whoever was nearest. A domain or subject matter expert. A project manager. A department head. The title changed. The budget, the reporting lines, and the organizational structure often didn’t.
Failures in positioning the Product Owner became common enough to earn names. ‘Feature factory’. ‘The build trap’. ‘Proxy Product Owner’. ‘Backlog administrator’. What they share is a missing accountability – a Product Owner, doing professional product management, positioned as someone with sufficient mandate to make decisions and set a course. In my classes, I meet people who can describe their backlog in forensic detail, but their product and its longer-term perspective? Not at all.
The 2020 Scrum Guide at least gives you something to hold your own situation up against: a product is a vehicle to deliver value, with a clear boundary, known stakeholders, and well-defined users or customers. Four things to check, and you can do it today. Find out how your product contributes to business impact. Draw the boundary by naming three adjacent things that are not your product, and one request you’d refuse because of it. Identify the most important stakeholders. Last but not least, empathize with your target group – who are you trying to reach and what are their needs?
Common anti-patterns related to ‘missing’ products
Let’s outline some anti-patterns that make it hard to define a product. Each of the following anti-patterns deserves more than a paragraph, so over the next three posts I’ll take them one at a time and get specific by discussing techniques that earn their keep.
1. Product Owners managing projects
Fixed scope, a deadline, temporary funding, and sometimes everybody even calls it a project. Nobody thinks product thinking applies. It does, and this isn’t the worst place to stand. A project has a customer, a problem that informs the project’s scope, and a release date.
2. Product clusters
One team, a backlog related to multiple applications that reads like a suggestion box from five departments, and no red thread running through any of it. Value questions do the heavy lifting here. What actually delivers value? What’s the business case? What could we stop doing entirely? What survives those questions usually clusters into something that behaves like a product.
3. Product Owners working at scale
Dependencies on other teams, siloed departments, and cargo-cult loyalty to a scaling framework. Here the boundary is genuinely hard to see, because the product doesn’t line up with the org chart, and the org chart is what people defend. What if I told you your job as a Product Owner is to work across those silos?
AI won’t find your product for you
Ask an LLM where your product is and it will tell you. That’s the problem. Feed it your backlog and you’ll get a confident, plausible boundary in seconds. What you won’t get is agreement. Those ten people give you ten answers because they want different things, and a definition only becomes real once they have argued it out and signed up to the result. A conversation with AI can draft a strawman, sharpen your questions, and spot the pattern in three hundred backlog items. It can’t tell you whether a customer will pay, and it can’t take the heat in the room when you tell a department their favourite system isn’t a product. Use it as a sparring partner. Ensure you remain the critical voice.
One more caveat. You often can’t redraw a boundary alone. Funding models, reporting lines and sponsorship sit above your pay grade. That’s also why defining the product is worth the effort: a boundary you can point at, with users and stakeholders attached to it, is the strongest argument you have for the mandate you’re missing. A definition without authority is just a document, but authority rarely arrives without one. So start where you can. Write down a boundary you’re willing to defend, and bring evidence rather than an opinion. That’s how a passenger talks their way into the driver’s seat.
So stop asking strangers where you parked. You don’t get a product – part of your job is to define one.
To be continued.
