In an earlier field note, I argued for the return of the Product Owner.
Product Ownership can easily become reduced to backlog administration: writing stories, prioritizing work, answering questions and accepting completed items. But that places the Product Owner almost entirely inside the engineering process.
Product Ownership should connect engineering work to customer needs, business intent, desired outcomes and relevant quality expectations. I now think the Product Owner must return twice. First, before engineering begins. Then, after engineering declares the work done.
But even that may describe the responsibility too narrowly. Product Ownership is not two separate handovers. It is the function that closes the complete loop between business intent, engineering delivery and product learning.
Before the backlog
We often picture the Product Owner at the start of the engineering sequence:
Product Owner → story → implementation → testing → Definition of Done
But Product Ownership should not begin with a story. Before work enters the backlog, someone must translate:
- strategic intent;
- customer and stakeholder needs;
- desired outcomes;
- risks and trade-offs;
- business and operational constraints;
- expectations of product quality;
into product decisions that engineering can understand and act upon.
The backlog is therefore not the beginning of product thinking. It is the point where the broader business and product perspective is translated into the engineering perspective.
A story should not merely describe something that somebody requested. It should represent a sufficiently coherent product decision. This is the first return of the Product Owner: moving upstream from backlog administration towards responsibility for product intent.
Engineering produces more than functionality
Once work enters the backlog, the perspective changes. Stories, acceptance criteria, designs, implementation, testing and the Definition of Done help engineering turn product intentions into working increments.
This sequence asks whether the intended behaviour is sufficiently clear, whether the solution has been implemented correctly and whether the agreed engineering work has been completed. It also produces evidence.
By the time an increment is done, we know more about what was feasible, how the product behaves, which assumptions were correct, which risks remain and how the change affects the wider system.
But Definition of Done is an engineering boundary. It is not the end of Product Ownership.
After Done, reality provides new evidence
Testing produces evidence under selected conditions. After release, the product enters a different evidence environment.
Now we learn through:
- incidents and defects in production;
- helpdesk calls and customer complaints;
- customer behaviour and usage patterns;
- workarounds and abandonment;
- operational effort and cost;
- performance under actual load;
- security and reliability events;
- business and customer outcomes.
These signals are not merely operational noise. They tell us something about the product’s quality in reality. A feature can pass every test and still confuse users. A system can satisfy its acceptance criteria and still generate excessive support demand. A correctly implemented capability can fail to create the intended value.
Implementation produces a product change. Ownership continues until the organisation understands what that change means.
The second return
The evidence produced by engineering, operations, support and real use must be translated back into the product and business perspective:
- Did the change improve the product as intended?
- Does it contribute to a coherent experience?
- Is it suitable for actual customers and operating conditions?
- Did the expected outcome occur?
- What unintended consequences appeared?
- What should change in the product, its priorities or our understanding of quality?
This is the second return of the Product Owner.
But it is not simply the acceptance of a completed story. It may continue long after release, as evidence accumulates and outcomes become visible.
A completed story is an engineering result. It becomes product learning only when it is interpreted in its wider context and influences what happens next.
Closing the loop
The complete model is not:
Business request → backlog → engineering → done
It is closer to:
Business intent → product interpretation → engineering → evidence → release → operation → outcomes → learning → revised intent
Upstream, Product Ownership translates business intent into coherent and assessable product expectations. Downstream, it connects engineering evidence, production experience and actual outcomes to product judgement and future decisions.
Without the upstream connection, engineering receives requests rather than coherent product intentions. Without the downstream connection, delivered functionality becomes output without structured learning. The backlog may keep moving, but the product loop remains open.
A quality-governance function
Product Ownership does not own every quality activity. Engineering, architecture, operations, support, security, leadership and other stakeholders all contribute evidence and expertise.
But Product Ownership has a distinctive responsibility for maintaining coherence between:
- why the product exists;
- what engineering is asked to build;
- what evidence the organisation receives;
- what the product achieves in reality;
- what should be decided next.
That makes Product Ownership part of quality governance.
Quality begins before engineering, is shaped and assessed during engineering, and continues to be revealed after release. Product Ownership keeps those phases connected.
It begins before the backlog and continues after implementation. Its purpose is not merely to keep engineering supplied with work.
It is to close the loop between intent, delivery, evidence, outcomes and learning.
Leave a Reply