The Five Pillars of Collaborative Product Ownership

I have worked as an engineer, manager, tester and product owner. The product-owner role was among the hardest, and as a coach I often help people navigate it. Today I want to question the idea that product decisions must rest with one person.

Phrases like “one throat to choke” suggest a single person can be held responsible when things go wrong. I ask whether having someone to blame actually helps a team deliver a successful product.

The audience lists traits of a great product owner, including vision, communication, collaboration and knowledge. I ask whether we expect one person to possess all of these qualities and all of the relevant knowledge.

One definition makes the product owner part of a development team managing a backlog toward a shared outcome. That sounds collaborative, but I worry that other descriptions put all problem definition and solution design on the owner alone.

A backlog item is not yet a solution: it is a hypothesis that an idea might meet a user need. Only after testing and delivering can we learn whether the problem has actually been solved.

Prioritization depends on understanding customers and value. The product owner can talk to the team and use user research to evaluate needs rather than making every decision in isolation.

To determine whether something was successfully delivered, ask users for feedback or test with them. A manager approving a feature or an improved throughput chart does not establish that the feature solved a customer problem.

I also challenge the practice of hiding most of the backlog from the team. If the team shares responsibility for the product direction, transparency helps it understand the wider context.

I cite a study of custom internal business systems in which many features were little used or unknown to users. I acknowledge controversy and measurement difficulties around such studies; the point is to check actual use instead of assuming every delivered feature is valuable.

I contrast Frederick Taylor’s scientific management with approaches that treat frontline workers as sources of knowledge. Taylor’s emphasis on measuring work brought empirical attention to processes, but his separation of planning from execution also reflected a deeply disrespectful view of workers.

I turn to the Toyota production system and its influence on lean and agile thinking. The example is useful as a management philosophy, not a claim that manufacturing and software development are identical.

In a short Toyota employee video, a worker describes a system in which team members may stop the production line when something is wrong and contribute ideas for improvement. I emphasize listening to the people closest to the work.

I describe a suggestion system where staff can make small improvements and report them. The employee’s example of moving a frequently used tool shows how a local change can improve both comfort and effectiveness.

Respect should extend to software teams. I recall a company seeking more autonomous decisions while still prescribing how employees should dress, and ask whether its policies matched its stated trust in staff.

In a fictional production-line example, a worker notices damaged boxes and stops the line. The worker, manager and another colleague inspect the process together, agree on a fix and decide how to check whether it worked.

The group updates its standardized work to reflect the improved process. I distinguish a shared record that supports improvement from a fixed instruction imposed without the team’s participation.

Managers and frontline staff bring different perspectives: one may see the wider system, while the other knows the immediate work. Product owners, engineers and users can similarly solve problems together.

Bring the team a hypothesis, not a purportedly certain solution. Ask for the cheapest, quickest experiment that could invalidate it; deliberately seeking disconfirming evidence helps counter confirmation bias.

Whether an experiment invalidates the hypothesis or not, the team learns. Repeating this cycle builds shared product knowledge and a stronger basis for consensus.

My five principles are respect people, embrace uncertainty, use small experiments, learn continuously and avoid complacency. Give teams problems to solve and trust their ability to contribute.

Detailed plans can make uncertainty feel less uncomfortable without removing it. Small experiments help a team test the ground and learn before committing its full weight to a direction.

Finally, keep it safe to question even well-established assumptions. Collaborative ownership emerges when the team keeps learning together rather than delegating all judgment to one person.