How should a product team decide who has authority to make product and engineering decisions?

A team agrees in principle to move quickly, but a feature waits because nobody knows who can accept a scope change, approve a technical exception or stop work. Ambiguous authority turns collaboration into repeated escalation.

Classify the decisions the team makes

List recurring decisions: problem and priority, feature scope, technical design, release readiness, security exceptions and changes affecting other services. For each, distinguish the person who supplies evidence, those who must be consulted, the accountable decision owner and any formal approver. A decision can be collaborative without being ownerless. Authority may also depend on spend, operational impact, legal obligations or architecture scope; these limits should be stated rather than inferred from a job title.

Start with existing accountabilities

Existing role frameworks are useful starting points. The Scrum Guide gives the Product Owner accountability for Product Backlog ordering and Developers responsibility for the Sprint plan and quality within Scrum. GOV.UK service-team guidance assigns its service owner broad service accountability and describes Product Manager responsibilities. These are different organisational models. Use the model actually adopted locally and make its delegation explicit; neither source supplies a universal matrix for every product organisation.

Write usable decision rights

Under the hub’s working model, Product owns the what and why, including outcome and priority; Engineering owns the how and how much, including architecture, sizing and delivery risk. A product decision that creates unacceptable technical exposure needs a safe option or escalation, not a unilateral instruction to weaken controls. A technical choice with material user or investment effects needs Product input. GOV.UK’s multidisciplinary-team standard argues for decision makers being close to the team so it can respond to learning. The exact approval route remains an organisational choice.

Test the model against real choices

Create a short decision-rights table for decisions that repeatedly stall. State scope, owner, required consultation, approval threshold and escalation path. Walk through recent cases: a requested deadline, an architectural exception and an incident-related change. If multiple people believe they have final authority, resolve that before the next urgent case. Record major decisions with rationale and review triggers. Revisit the table as the product, risk or team boundary changes; avoid sending routine reversible choices through a committee.

Example

Hypothetically, a retail team considers a faster checkout using a new payment provider. Product owns the customer outcome and priority. Engineering assesses integration and resilience; security and finance have defined approval thresholds. The team documents which small interface choices Engineering can make, which investment choice Product can make and which provider decision requires leadership approval. A later deadline change follows the same route.

FAQs

• Does collaboration mean every decision needs consensus?

  No. Consultation improves the choice, while a named owner makes it actionable.

• Can a Product Manager overrule an Engineering safety concern?

  A risky option needs technical resolution or escalation under the organisation’s controls; priority authority does not remove safety accountability.

• Should every choice go in a decision log?

  No. Keep records for consequential or hard-to-reverse choices and make routine decisions where the work happens.