Flickering ownership
The team begins with a clear request: customers need to export a report.
Implementation starts. The export becomes a scheduled export, then a configurable one. A conversation with sales introduces a second file format. Design changes the flow after seeing the first working version. A senior stakeholder asks why the feature cannot send reports directly to an external system.
Each change reaches engineering through the same product owner. Each arrives with enough urgency to interrupt the work already under way. The team keeps building while the definition of the feature moves ahead of it.
This is the pattern the original field guide calls flaky product ownership: requirements repeatedly arrive incomplete or change after implementation begins, creating avoidable work, missed expectations, and uncertainty about what the team is meant to deliver.
The label points at a person. The useful signal usually points at a system.
A product owner sits where customer needs, commercial pressure, design choices, technical constraints, and executive expectations meet. When that intersection lacks enough time, authority, or shared context, its instability appears downstream as changing tickets. Engineering experiences the movement as product indecision. Product may experience the same period as a stream of facts and demands that could not safely be ignored.
The work flickers because ownership itself is struggling to hold a decision.
Scope creep describes what happens to a commitment. Unstable product ownership describes one recurring path by which the commitment changes. A team can manage each new request carefully and still face the same disruption sprint after sprint.
The visible pattern begins before the code.
A ticket enters planning with a confident title and thin acceptance criteria. Important states remain unanswered. The team asks who can use the feature, what should happen when it fails, which existing behavior it replaces, and how success will be measured. Answers arrive gradually, sometimes from different stakeholders and sometimes only after the implementation makes an ambiguity concrete.
The product owner may use phrases such as “we can work that out as we go” or “start with the obvious version.” Those can be sensible instructions for exploratory work. They become hazardous when the organization treats the date and estimate as though the outcome were already well understood.
Midway through the work, priority changes. A new customer request becomes part of the feature. An earlier decision reopens after someone influential sees it. A requirement thought to be optional becomes necessary for launch. Engineers revise the design, discard completed work, and explain why the original estimate no longer describes the project.
The next sprint repeats the sequence.
Repository history can show the effect. Pull requests grow in waves instead of converging. A nearly complete change returns to active development. Code written early in the branch is replaced before release. Files outside the expected area appear late. Review comments debate desired behavior because the product decision never became stable enough to precede review.
The work tracker carries a parallel history. Acceptance criteria change after the ticket enters progress. Comments contain requirements absent from the description. New subtasks appear near the expected completion date. A completed ticket reopens because the latest interpretation differs from the one engineering implemented.
None of these signals proves weak ownership.
Software is a way of learning. A working interface can reveal a poor assumption more effectively than a meeting can. Customers may respond differently from research participants. Regulation, security, or an external dependency can introduce a genuine late constraint. A team that refuses to respond will preserve the plan at the expense of the product.
Healthy discovery changes the work deliberately. The team knows which questions remain open, schedules feedback while choices are still inexpensive, and revisits scope, time, or confidence when an answer changes. The owner explains what was learned and makes the resulting trade visible.
Ownership flickers when decisions repeatedly arrive late without restoring a coherent agreement. The team receives the change but lacks the priority behind it. Old expectations stay in place beside new requirements. The date, outcome, and quality standard all appear fixed, leaving engineering to reconcile constraints that no longer fit together.
Frequency gives the strongest clue. One disrupted project may contain an unusual discovery. Several projects that expand through the same decision path deserve a closer look. Compare when questions first became available, when someone answered them, and when engineering learned the answer. Delay in that chain often matters more than the number of changes.
The simplest cause is lack of time.
A product owner may carry several teams, maintain a roadmap, run customer interviews, support sales, answer executives, prepare launch material, and attend most of the meetings created by all of those responsibilities. Refinement receives the fragments left between urgent conversations. Tickets look complete from a distance because their titles exist. The decisions inside them have yet to receive sustained attention.
Work in progress hides across the product role just as it does across engineering. Five initiatives can each appear modest while their combined decision load exceeds one person's capacity. Engineering sees one slow answer at a time. The product owner feels a day composed entirely of interruptions.
Reducing that load may improve requirements more than any template could.
An authority gap produces a similar pattern. The owner can describe a direction but cannot defend its boundary when a senior stakeholder asks for an addition. Every request passes through because saying no requires influence the role does not have. The person becomes a courier for changing priorities rather than the place where priorities are resolved.
Responsibility without authority makes ownership ceremonial.
Sometimes ownership is genuinely unclear. A product manager shapes the roadmap, a product owner maintains the backlog, design controls the interaction, sales represents the customer, and an executive makes final calls. Each person owns a legitimate part of the outcome. Nobody owns the trade when those parts conflict.
Engineering then receives a series of locally authoritative instructions. The team complies with design, then sales, then leadership. From inside each conversation the latest request seems decisive. Across the project, the target moves because the organization has several decision makers and no rule for resolving them.
Distance from the customer can also delay decisions. A product owner who receives needs through account managers or support summaries may first encounter the important detail after engineering demonstrates a partial solution. The apparent change of mind is new information reaching the role too late. Improving access to evidence will help more than asking for greater decisiveness.
Some environments reward optionality for too long. Leaders avoid choosing between customer groups, workflows, or business models because a broad promise feels commercially safer. Product passes that ambiguity to engineering, where code eventually demands a specific answer. The owner may be blamed at the exact point where an organizational hesitation becomes impossible to conceal.
Engineering contributes to the pattern as well.
A team can accept a vague request without surfacing its assumptions, then treat later clarification as product churn. Engineers may begin before the owner is ready because keeping people busy feels preferable to waiting. They may ask implementation questions while leaving the underlying outcome unexamined. A technically elegant interpretation can travel surprisingly far before anyone checks whether it solves the intended problem.
The result is shared: product thinks the team understood, engineering thinks product decided, and the first demonstration reveals that both filled the gaps differently.
Managers should begin with one project history rather than a judgment about the owner.
Reconstruct the initial agreement, the important questions, the changes, and their timing. For each change, ask when the underlying information became available, where it waited, who could make the decision, and which constraint moved in response. Include product discussions, research, sales commitments, design work, and technical discoveries alongside tickets and commits.
The aim is to locate the decision latency.
A ticket may have waited three days for a product answer because its owner was overloaded. A product owner may have waited two weeks for an executive decision. Research may have existed before planning but never reached the team. Engineering may have held a question until the pull request was ready. Treating every delay as “requirements changed” would hide the path that could actually be improved.
Bring the evidence to the product owner with curiosity. “These three projects added significant behavior after implementation started; I want to understand where the decisions became difficult” opens a joint investigation. A list of rewritten commits presented as proof of carelessness turns operational data into a prosecution.
The person closest to the instability often knows its causes. They may immediately name the stakeholder whose requests arrive outside planning, the customer segment whose needs remain uncertain, or the number of simultaneous initiatives preventing adequate preparation. They may also describe how engineering starts work before product signals readiness.
The conversation should produce a smaller number of clearer commitments.
Set a readiness threshold proportional to the cost of reversal. Before a consequential project begins, the team should understand the target user, desired outcome, essential behavior, important exclusions, unresolved questions, and decision owner. The threshold can remain light for reversible changes. A migration, contract, or cross-team platform deserves more certainty.
Readiness means the known decisions are good enough to begin and the remaining uncertainty is visible. It does not require pretending discovery is complete.
Name open questions directly in the work. Assign each one an owner and a latest useful decision date. A question about an interaction should close before that interaction becomes expensive to replace. A question about customer value may require a prototype before implementation. Scheduling the answer makes uncertainty part of the plan instead of a surprise that arrives inside it.
Create a single route for consequential changes. Stakeholders should remain free to share information and ideas with engineers, but additions to an active commitment need to return to the accountable owner. That person decides whether the new value replaces existing scope, changes the date, or waits. Informal access stays open while the delivery agreement remains coherent.
The owner needs backing for that route to work. Leaders should make clear that deferring a request is a valid product decision, even when the requester has more seniority. If every escalation overrides the owner, the organization should recognize that the executive making those calls owns the resulting priority changes.
Capacity may need attention before process. Reduce the number of simultaneous initiatives. Give product time for discovery and preparation that is as real as engineering time for implementation. Move operational duties, add product support, or align one owner with fewer teams. A more elaborate ticket template cannot manufacture the concentration required to make difficult decisions.
Shorten the learning loop where uncertainty is genuine. Use a sketch, prototype, technical spike, or early demonstration to answer the riskiest question before committing to the full build. Invite engineers into discovery when technical constraints shape the available choices. Bring product into technical planning when implementation detail exposes meaningful differences in customer experience.
Early collaboration should resolve ambiguity before it becomes rework. It should not turn every hour of implementation into an open product workshop.
Agree on how the team will respond when learning changes the outcome. A simple change note can state what was learned, what now changes, and which existing expectation moves. This protects the owner's ability to improve the product while preventing the original date and scope from surviving as invisible obligations.
Review the pattern across several projects. Look for fewer requirements added after implementation begins, faster answers to open questions, and clearer trade-offs when new evidence arrives. Notice whether pull requests converge more steadily and whether review focuses on quality of implementation rather than late definition of behavior.
Also listen for changes in language. A healthy owner can say, “We do not know this yet, and here is how we will learn,” “This request matters more than the item it replaces,” and “That idea belongs in a later release.” Those statements combine uncertainty with authority. They give the team a stable way to move even while the product continues to evolve.
Engineering managers and product leaders should examine the relationship together. Recurring churn at their boundary belongs to both sides. Product needs enough technical access to understand cost and reversibility. Engineering needs enough customer context to distinguish a meaningful discovery from an arbitrary change. Both need an escalation path when value, time, and feasibility conflict.
Avoid solving the pattern by freezing requirements or excluding product from the work. Stability produced through silence will make the plan look cleaner while reducing the quality of the result. The goal is a decision process that can absorb evidence without transferring all of its uncertainty into engineering.
Product ownership becomes dependable when decisions have somewhere to settle.
That requires attention, context, authority, and a visible way to revise commitments. When one of those is missing, the backlog may still look orderly while the work underneath it repeatedly changes direction.
The moving ticket is the trace. Follow it upstream.