The Product Owner Mindset Every Developer Needs

Every team I’ve ever worked with has a product owner somewhere on the org chart. Somebody’s holding the backlog, deciding what ships next, catching heat when priorities shift. That part’s not up for debate.

What I will argue with you about: the best products I’ve shipped never came out of a team where one person did all the thinking and everybody else just executed. They came out of teams where the thinking was shared, where the person writing the code cared as much about the why as the person who wrote the ticket.

I’ll get into the actual job description in a second, because it’s a real job with real responsibilities. But almost every writeup of this role skips the part that actually matters.

Product ownership is a mindset, not a job title.

Quick Answer: The product owner is the person responsible for the product backlog on a software development team. They prioritize the backlog and choose what the team should work on next. Developers who think like product owners do more than build software; they understand why each feature matters and own the end result. Full Scale staffs developers who carry that mindset by default, not people who just execute tickets.

What does a product owner do?

A product owner is responsible for maximizing the value of the output of the development team. There, you have it: the definition. It's important because it's what you're probably looking for. The product owner is one of three roles on a Scrum team, with the other two being the developers and the Scrum master. The developers are responsible for building the product, and the Scrum master protects the process. But the product owner is the person who determines what should be built.

Their duties include:

• Managing and prioritizing the product backlog to ensure the team has the highest priority work available.
• Promoting the product vision and communicating it to the team and stakeholders.
• Liaising between customers, management, sales, etc., and the engineers.
• Serving as the proxy for customer needs to the team.

This sounds like a product manager, right? You'd be correct. There's some crossover in the role, and many smaller organizations combine them into one job. In a nutshell, a product manager generally owns the full product lifecycle, while the product owner works more closely with the dev team. I covered this more in product owner vs. product manager, so I won't get into it again here. Some teams hire a technical product owner for products that require some level of technical expertise to manage.

And there’s your role. But here’s the part that’s actually important.

Product ownership is bigger than the title

Another mistake I see companies make is putting a box called “Product Owner” on the org chart. They hire a product owner, hand them the backlog, and think product is covered. That’s not how it works.

One of the best developers I ever worked with proved this to me at Stackify, the company I founded in 2012 to build APM and logging tools that helped developers find and fix bugs in production. His job on paper was building out our monitoring support across the open-source languages we covered, Java, Node.js, PHP, Python, the usual suspects.

Nobody told him which languages mattered most or which frameworks to prioritize. He just figured it out, argued through the tradeoffs with whoever needed convincing, and owned whatever he shipped. His title said senior developer. His actual job, most days, looked like product manager plus team lead.

That’s product ownership. His business card had nothing to do with it.

In my book Product Driven, I say the greatest problem in most engineering organizations isn’t poor code or lack of technical ability, it is a lack of product thinking.

The toughest part of software development has never been the code. It’s figuring out what to build.

And product thinking can’t reside in just one person. As I wrote in the book, if your product depends on one person, you’ve got a problem. Product ownership must be present across the board.

What the mindset looks like in a developer

What’s the difference between a developer who has product ownership versus one who doesn’t? It really boils down to whether they wait to be instructed or understand what they’re trying to achieve.

Product-minded developers ask questions like: What is the purpose of this functionality for the user? How do we measure success? They’ll push on these ideas with some level of urgency, as they have a stake in where the product is going. Better to ask a tough question up front than to create a feature that nobody wants.

I’ve often talked about how I want chefs on my team who can taste a dish and tweak the recipe, not short order cooks who only do what the order says.

I experienced the limits of this firsthand myself. At VinSolutions, the company I co-founded before creating Stackify, and bootstrapped to $35 million in ARR before selling it for $147 million in 2011, I was in founder-mode for several years. I could talk to a customer in the morning and deliver a fix in the afternoon, no ticket, no product manager, no approval process. That’s the pinnacle of product ownership, and it worked great until it didn’t.

A product centered around its founder can’t grow. The fix wasn’t to hand product ownership to a single person and call it done. It was to get everyone on the team to think like a product owner.

This isn’t automatic either. To own their product, developers need to be able to talk to the customer, and understand the purpose behind their work. Without that context, they won’t own the problem because they’ll just confidently guess.

Why this matters more in the AI era

If product thinking was important before, it’s basically everything today. For most of the history of software development, writing the code has been the hard, slow, expensive part of the process. This is rapidly changing.

AI can now spit out a rough working version of the code as fast as you can explain what you need. I often half-jokingly tell my clients that we’re all paying developers to babysit AI: to evaluate its output, correct where necessary, and keep it from going off the rails. It’s an overstatement, but it makes my point.

Once the coding itself gets cheap, the real skill becomes knowing what’s worth coding in the first place. I’ve said this before: AI is the mechanical Turk now, it’ll write you the whole program if you ask nicely. Your job is managing it well, which turns out to be a completely different skill than writing the code yourself ever was.

The first pass at writing code is now done by AI. Humans need to determine what to write.

Supervising AI is product management work. That includes deciding what to build, understanding your users, and empathizing with the person on the other side of the screen. These tasks used to belong to a separate department. Now every engineer is expected to do them.

A developer who can only implement a finished spec is going to have a hard time, because that’s exactly what the machine is good at.

Do you actually need a dedicated product owner?

So if product thinking is something the entire team needs to be doing, then do you still need to hire a dedicated product owner?

The honest answer to this question is that it depends on what you’re building.

In many cases, especially for smaller teams, there’s no need for a dedicated product owner as long as developers have a sense of ownership. The product thinking is already present.

There are some products, however, which require deeper domain expertise or have strict regulatory compliance that would make it hard for engineers to understand what the customer wants without a dedicated product owner. Healthcare and finance are the easy examples, heavily regulated, full of domain knowledge that takes years to actually understand. On teams like that, a product owner who's fluent in the business and can sit across the table from a customer isn't a nice-to-have. They're the reason the engineering team builds the right thing instead of a technically correct thing nobody asked for.

This means the question isn’t whether to hire a product owner.

It’s whether your team understands the customer well enough to build the right thing.

If they don’t, hiring a product owner may help. If they don’t even after the hire, you have a problem much larger than your org chart.

This isn’t to say you should make decisions by committee, though. There must always be someone making the final decision on what to build next, even when there’s shared ownership. As the Scrum Guide says, “the Product Owner is one person, not a committee.” Shared product thinking and one decision maker can work together just fine. Everyone shares the thinking part, but that final prioritization call still lands on one desk.

The kind of developer worth hiring

Here’s how we staff engineering teams at Full Scale for our customers. We aren’t looking for someone who can only do the ticket. The natural tendency is to hire the cheapest developer you can find and give them a queue, what I call cheapshoring, and that’s a trap. The cheapest developer is the easiest one to replace, which is precisely the skill set that is being automated by AI.

So we staff developers who ask questions, challenge assumptions, and take ownership, and then we put them directly into your team via our staff augmentation model, as opposed to outsourcing your product to a black box. This is the model that Derrick Leggett built at AMC Theatres, with our engineers in the Philippines working as true members of his team rather than just a contracted entity.

The title was never the point

The product owner role isn’t going away. But the title was never the point. My favorite teams are the ones where every developer feels responsible for what they create, knows why they’re building it, and would rather solve the right problem than close the most tickets.

Giving someone the backlog isn’t giving them ownership of the why. That part still belongs to everyone.