What do Product and Engineering each own in Product Engineering?

Product Engineering asks Product and Engineering to become involved earlier and work more closely. Without explicit decision rights, that can create a new problem: Product assumes Engineering will fill gaps in product definition, Engineering assumes Product has already chosen the solution, and important decisions remain unresolved.

The shorthand “Product owns the What and Why; Engineering owns the How and How Much” provides a practical starting point. It sets primary accountability while leaving room for the joint work required to make good decisions.

Ownership becomes unclear when participation is mistaken for accountability

Both Product and Engineering should contribute across the product lifecycle. Engineers can identify customer implications and Product Managers can ask useful technical questions. Contribution, influence and accountability are different things.

Accountability identifies who must make sure a decision is made and remains answerable for it. The accountable person should seek relevant expertise rather than decide alone. A Product Manager who owns priority needs Engineering's view of cost and risk. An Engineering lead who owns technical integrity needs Product's view of value and urgency.

Teams get into difficulty when “shared ownership” means no named owner, or when an owner treats consultation as optional. Product Engineering needs both collaboration and decision clarity.

Product owns the What and Why

Product is primarily accountable for explaining:

• What problem is being solved
• Who experiences it
• Why it matters to customers and the organisation
• What outcome would indicate progress
• Why the work has its current priority
• What boundaries or constraints are important
• What clarity the team needs to proceed

Product also connects the Feature to product strategy and other investment choices. It gathers and interprets customer, operational, commercial and stakeholder evidence. It should be able to explain why this problem deserves attention compared with other possibilities.

“What” does not mean prescribing every screen, rule and interaction before Engineering participates. It means defining the problem and intended capability clearly enough to shape a response. Product may propose solutions, but should keep alternatives open until relevant technical implications are understood.

Product remains engaged during delivery. If new information requires a scope or outcome trade-off, Product decides from the value and priority perspective rather than leaving Engineering to infer business intent.

Engineering owns the How and How Much

Engineering is primarily accountable for explaining:

• How the capability should be designed and built
• Which architecture and existing services it should use
• What technical risks, dependencies and constraints apply
• How security, quality, accessibility, reliability and operability will be addressed
• How the work can be divided or sequenced safely
• How much effort is likely to be required
• What uncertainty remains in the estimate

The people who will do the work should inform its sizing. The Scrum Guide, for example, makes Developers responsible for sizing Product Backlog items while allowing the Product Owner to influence them through context and trade-offs.

“How Much” is not a promise produced without sufficient information. Engineering should state assumptions, confidence and material unknowns. Product should provide enough problem and outcome clarity for the estimate to support the decision being made. Early estimates can be ranges; greater commitment may require more discovery.

Engineering remains accountable for technical integrity even when Product has a strong preference or deadline. If an approach creates unacceptable risk, Engineering must make that visible and propose viable alternatives.

Understand, shape, estimate, deliver and learn together

Several activities work best as joint work:

• Understand: Product brings user and business evidence; Engineering explores system behaviour, feasibility and constraints.
• Shape: Product tests whether options address the outcome; Engineering explains trade-offs and finds simpler or safer approaches.
• Estimate: Engineering owns sizing; Product clarifies scope, value and which trade-offs are acceptable.
• Deliver: Engineering leads implementation; Product resolves product questions and protects the intended outcome.
• Learn: Product and Engineering review customer, product, delivery and operational evidence together.

A lightweight decision record can help when the trade-off is material. It should capture the problem, options, product rationale, engineering implications, decision owner and assumptions. This creates clarity without turning every decision into a governance exercise.

The same model can support AI-enabled delivery. AI may perform analysis, coding, testing or documentation, but it does not hold organisational accountability. Product still owns intent and value. Engineering still owns the technical standards and assurance appropriate to the work, even when the amount of direct engineering effort changes.

Example

A retailer wants customers to change delivery details after placing an order. Product owns the evidence that this is a valuable problem, the intended customer outcome and its priority.

Engineering identifies that address changes are safe before warehouse allocation but create fulfilment and fraud risks afterwards. Product and Engineering shape a Feature around the safe window. Engineering owns the integration design, control points, estimate and delivery. Product owns the customer messaging and value trade-offs. Both examine adoption, support demand, failed changes and operational incidents after release.

FAQs

• Who owns the Feature in Product Engineering?

  Product is normally accountable for the Feature's problem, value, desired outcome, priority and sufficient clarity. Engineering is accountable for its technical approach, implications, sizing and delivery. The Feature is shaped collaboratively, but its decisions should still have named owners.

• Who is responsible for sizing a Feature?

  Engineering is responsible for sizing because the estimate depends on the technical approach, dependencies, risks and people doing the work. Product supplies context, clarifies scope and helps explore trade-offs, but should not assign an estimate to Engineering.

• How much detail is needed before Engineering can estimate?

  Enough detail is needed to support the decision at hand. An early prioritisation decision may only require a range with explicit assumptions. A delivery commitment usually needs clearer boundaries, acceptance evidence and technical discovery. False precision should not replace unresolved uncertainty.