How is Product Engineering different from project-based delivery?

A leadership team may approve a project to launch a digital service and then ask the same people to move on at go-live. The service still needs support, improvements and decisions about whether it is worth further investment. Understanding the delivery boundary helps leaders avoid leaving those decisions ownerless.

A project and a product have different boundaries

A project is a temporary arrangement for delivering a defined change. It can provide a budget, governance and deadline. A product or service is the continuing capability that people use. Its needs can change as users, technology and the organisation change. Product Engineering concerns how the responsible people learn and make decisions across that continuing life. A project may create or transform a product, but completing the project says little by itself about whether the product is valuable or healthy.

A finite project can still be useful

Projects work well when a specific change requires a clear authorisation, coordinated suppliers or a bounded investment. They offer a useful way to manage scope, cost and dependencies. The risk appears when the project plan becomes the only definition of success and the delivery team has no route to revisit assumptions. Go-live then closes the budget or disbands the people who understand the service while users and operational colleagues are only beginning to encounter it. The alternative is to retain named product and technical ownership and a way to fund necessary operation and improvement.

Product Engineering keeps the decision loop open

Product remains primarily accountable for the What and Why: problem, value, outcomes and priority. Engineering remains accountable for the How and How Much: technical approach, risk, sizing and integrity. Together they decide what evidence to gather before and after a change. An enduring team can retain context, though a full-time dedicated team is not required for every product. The GDS Service Manual recommends planning and budgeting for improvement over the service lifetime. This is guidance for UK government services, and its underlying lifecycle lesson can inform other organisations without prescribing their structure.

Connect governance to the product’s lifetime

Ask what happens when the initial delivery ends. Name the owner of the product outcome, the owner of technical and operational integrity, the support route and the next review point. Make room for defects, security updates and user-led improvements. Keep a record of major assumptions and decisions so a changed team can act responsibly. Decide which work genuinely needs a project boundary and which belongs in the continuing product plan. Compare realised user and business outcomes with the cost and health of the service before committing further investment.

Example

Hypothetically, a council commissions a six-month project to launch an appointment service. The project board still tracks budget and launch readiness. Before closure, a product manager and engineering lead agree who will review completion problems, service incidents and accessibility feedback. The council funds a smaller continuing team and sets a decision point after real use. If the service misses its intended outcome, Product can change priority and Engineering can explain the feasible options and cost.

FAQs

• Must we abandon project governance?

  No. Projects can authorise and coordinate a bounded change. The organisation still needs named accountability and resources for the product once that change is delivered.

• Does Product Engineering require permanent funding for every team?

  No. Funding and team size can vary with demand and risk. The enduring requirement is a clear route for operation, learning and decisions about further investment.

• What counts as success after a project closes?

  Look at the intended user and business outcome alongside service quality, operational burden and the cost of improvement. Delivery against the original plan is only one part of that view.