How should Product and Engineering estimate together?

Estimation often becomes a negotiation over a number. Product asks for certainty to support a roadmap or investment decision; Engineering is asked to commit before the approach and unknowns are understood. The resulting estimate can look precise while hiding different assumptions.

Product Engineering treats estimation as part of shaping. Product and Engineering build enough shared understanding to support the decision at hand, while preserving Engineering's accountability for the size.

Begin with the decision the estimate must support

An estimate has no useful level of precision in isolation. A portfolio comparison, an initial shaping decision and a delivery commitment need different information.

For early prioritisation, a relative size or range may be enough to show that one option costs materially more than another. Before a significant funding or date commitment, the team may need clearer boundaries, technical investigation and dependency evidence. During short-term planning, the people doing the work need enough detail to forecast responsibly.

Ask first: what decision will change because of this estimate, and what error would matter? This prevents the team spending days refining a low-priority idea or presenting an exploratory range as a promise.

Product provides intent, evidence and trade-offs

Product should explain the problem, affected users, desired outcome, priority, important constraints and what is negotiable. It should identify whether the estimate covers an experiment, an initial usable capability or a complete target state.

When Engineering raises questions, Product clarifies value rather than guessing implementation. If one requirement drives most of the complexity, Product can decide whether that requirement is essential, can be deferred or can be tested another way.

Good Product input does not require a finished specification. It requires enough clarity for Engineering to reason about possible approaches and for both parties to recognise when they are estimating different things.

Engineering owns the size and exposes uncertainty

Engineering identifies the technical approach that underpins the estimate. It considers architecture, integration, data, security, quality, testing, deployment, operational readiness, dependencies and the work needed to manage change safely.

The Scrum Guide assigns sizing to the Developers who will do the work, while the Product Owner can influence them through understanding and trade-offs. The principle applies beyond Scrum: a business deadline should not be presented as an engineering estimate, and Product should not assign a number on Engineering's behalf.

An estimate should state its basis. Useful information includes a range or relative size, assumptions, exclusions, dependencies, material risks, confidence and the point at which it should be revisited. Where one unknown dominates, Engineering can recommend a bounded investigation rather than add invisible contingency.

Different engineering perspectives can expose different assumptions. Collaborative methods such as relative sizing or planning poker can support discussion, but the conversation is more important than the technique. Agreement on a number without agreement on scope and risk is weak evidence.

Re-estimate when the decision or evidence changes

Estimates are made with available information. Shaping, delivery and external change can alter that information. Teams should update an estimate when scope, approach, dependency or risk changes materially, and explain the effect on the decision.

This is not a licence for uncontrolled movement. Product and Engineering can maintain a clear decision record: what was estimated, for which purpose, with which assumptions and at what confidence. Comparing actual learning with those assumptions helps the team improve its forecasting.

Avoid using estimation accuracy as the only measure of performance. Teams may otherwise inflate estimates, avoid uncertain but valuable work or spend excessive effort chasing precision. Measure whether estimates enable timely, well-informed choices and whether surprises are surfaced early.

AI can help analyse historical work or identify missing questions, but past tickets rarely provide a complete comparison and generated estimates can conceal unsupported assumptions. Human Engineering remains accountable for the estimate used in an organisational decision.

Example

A Product Owner is considering two ways to reduce manual account checks. They explain the volume, user impact, control requirements and the decision deadline. Engineering outlines a rules-based change and a broader workflow redesign.

The team estimates the first as a small range with high confidence. The second has an external-system dependency, so Engineering gives a wider range and proposes a short investigation. Product uses the value, cost and confidence to fund the smaller change now and gather the information needed for the larger decision.

FAQs

• Who is accountable for a Feature estimate?

  Engineering is accountable for sizing because the estimate depends on the technical approach, risks and work. Product is accountable for supplying sufficient context and using the estimate in the value and priority decision.

• How much detail is enough before estimating?

  Enough to support the decision being made. Early comparison may need a range and explicit assumptions. A delivery commitment needs clearer boundaries and stronger evidence. Unknowns that could change the decision should be investigated or made visible.

• Should an estimate be treated as a commitment?

  Only when the team explicitly makes a commitment at an appropriate confidence level. An early estimate is information, not a guarantee. Record its purpose and assumptions so stakeholders do not convert a rough range into a fixed promise.