A Sustainable Product Has More Than One Supply Chain

A product team can point to a renewable-energy hosting region and reasonably call it an improvement. It can choose refurbished laptops, reduce image sizes or extend software support. Each action matters. None describes the whole system.

Digital products have several supply chains layered on top of one another.

The physical chain includes minerals, components, manufacturing, transport, devices, networks and data centres. The energy chain links every stage to grids whose sources and constraints vary by place and time. The software chain includes open-source maintainers, commercial platforms, app stores and security updates. A skills chain determines who can operate and repair the service. A support chain catches the people and cases the designed journey fails to accommodate.

These chains interact. A new software feature may require newer devices, increasing material demand. An aggressive hardware-life target may leave people using unsupported operating systems. A highly specialised architecture may reduce computing costs while creating dependence on scarce expertise. Moving computation to a user’s device may lower server demand but consume battery, data and processing capacity that not every user possesses.

This is why a single sustainability score can mislead. It creates the impression that unlike consequences have been resolved into one objective number. Measurement is necessary, but interpretation remains a decision. A team needs to know which impact moved, where it moved and who now carries it.

A practical mapping exercise can begin with a routine user journey. Take publishing a photograph. The image is created on a device, transferred through a network, processed into several sizes, stored in multiple locations, delivered repeatedly and eventually archived or deleted. Editors add descriptions. Developers maintain the pipeline. Readers download files on different connections and screens. Each step uses resources and depends on people.

The map reveals several modest interventions. The product might generate only the image sizes actually used, set a retention policy for abandoned uploads, choose efficient formats with reliable fallbacks and avoid loading high-resolution files into small layouts. It could make alternative text part of the publishing flow, improving accessibility without a later remediation project. It could document the pipeline so another person can maintain it.

None of those changes makes publishing impact-free. Their value lies in reducing avoidable demand while strengthening the service. They also show why environmental, social and economic sustainability should not be separated too quickly. A lighter page uses less data and often performs better on older devices. Clear maintenance guidance reduces operational risk. Accessible workflows widen participation. Benefits can reinforce one another when the system is considered together.

Tradeoffs still remain. A modern image format may reduce transfer but require processing energy and added complexity. Keeping multiple versions supports diverse devices but increases storage. Longer data retention may preserve cultural value while consuming resources and increasing privacy risk. Sustainable practice is not the absence of conflict; it is the habit of making conflict visible and revisiting decisions as evidence changes.

Suppliers matter, but responsibility cannot be outsourced to supplier claims. Procurement questions should reach beyond whether a vendor has a climate target. How long is equipment supported? Can parts be replaced? Is customer data portable? What happens when a service closes? Which subcontractors perform the work? Answers may be incomplete, yet asking consistently changes what the market learns to expect.

Teams should also examine their dependency on unpaid or under-supported labour. A critical library maintained by a few volunteers is part of the product’s supply chain. Contributing fixes, funding maintenance or reducing unnecessary dependency can improve resilience and fairness. “Free” software still rests on someone’s time.

The map should have an owner and a review rhythm, or it will become another workshop artefact. Ownership need not mean one person knows every chain. It means someone convenes the relevant perspectives when a major supplier, architecture or device requirement changes. The purpose is to keep the relationships visible at the moments when a team can still influence them.

The goal is not to map every connection before acting. That would turn interdependence into paralysis. Start with the largest known demands, the most vulnerable dependencies and the choices the team can influence. Make one improvement, observe its wider effects and update the map.

A sustainable product is not assembled from individually virtuous parts. It is cultivated across relationships: between hardware and software, efficiency and access, suppliers and communities, present usefulness and future repair. The map will never be complete. It can still help us care for more of what makes the product possible.