Information from end-of-use activities to product development
When a machine comes back for repair or remanufacture, the people who take it apart learn a great deal about how it wears and where it is hard to work on. Across the industry, very little of that reaches the engineers designing the next one. We spent six months studying the organisational conditions that decide whether it does.
The finding
-
01
A product-service system keeps the machine and the recovery work inside the firm. That makes end-of-use activity more visible internally.
-
02
Visibility and information flow rest on different organisational conditions. A business model can deliver the first without automatically producing the second.
-
03
Three things have to hold. A route from recovery to design, weight for that information once it arrives, and a form design can read it in. Each can fail on its own.
-
04
The contribution is a framework: eight organisational conditions that let you diagnose which of the three is missing, and where.
The gap this describes is not a data problem. The observations exist, and people who handle returned machines know a great deal about how they wear. It is an organisational question, and owning the asset does not settle it on its own.
The study was a qualitative embedded case study of one original equipment manufacturer in the material handling industry, covering the firm as a whole and three internal operating settings. Findings below are reported at that level, as they are in the thesis abstract.
Eight conditions, two thresholds
We pulled eight conditions out of the information flow literature and used them as the test. They split at two points where the flow can fail. Conditions A to D decide whether information crosses the boundary between recovery operations and design at all. Conditions E to H decide whether it can be used once it has crossed.
How a condition is assessed
Each condition is assessed on three levels. The point of the scale is to separate a requirement that is genuinely absent from one that exists but does not reach product development, because those need different responses.
| Level | Definition |
|---|---|
| Fulfilled | The requirement is clearly met and operates systematically. |
| Partial | Only partly met. It works for some actors but is not systematic. |
| Not met | Absent, too fragmented to function, or contradicted by the evidence. |
Two different kinds of shortfall
Applying the scale surfaced something the scale itself does not capture. A condition can come up short for two quite different reasons, and reading them as the same thing leads to the wrong fix.
On positioning, incentives and designated receivers, the requirement tends to be structurally absent. There is no route defined, no measure that connects recovery outcomes to design, and no role that owns the information on the design side. Nothing is being done badly here. The structure simply was not built to carry this, which is the normal state of affairs in manufacturers that grew up selling first-life products.
On awareness, end-of-use knowledge inside product development, and translation, the resource exists but is not routed. The knowledge sits with experienced technicians and operators. Translation happens, but it is pointed at commercial reporting rather than at design. This is the more tractable of the two, because the raw material is already there.
That distinction is the practical part of the framework. The first kind needs organisational design. The second needs a route and a translation step.
Three barriers
Grouping the eight conditions by where they sit in the flow gives three barriers. Each one can stop the flow on its own, which is why addressing a single one changes little.
| Barrier | Obstructs | Conditions | If you fix only this one |
|---|---|---|---|
| Structural decoupling | The channel. Whether a route exists at all. | B C G | A channel with no decision weight and no usable form carries information product development can neither act on nor justify acting on. |
| Financial rationale mismatch | The weight. What the information counts for in a design decision. | A D | Decision weight without a channel has nothing to weigh. |
| Untranslated operational knowledge | The form. Whether product development can read what arrives. | F G H | A usable form without a channel or decision weight produces design-ready knowledge that never arrives or never counts. |
The second barrier is the one worth dwelling on, because it is the least obvious and it generalises well beyond one industry. In a product-service system, value from recovery work accrues over the life of the asset, while design investment is decided up front against a business case scoped to the first sale. A change that makes refurbishment easier therefore reads as a cost now against a benefit that lands later and elsewhere. Nothing about that is irrational. It is what happens when two sound accounting logics meet at an organisational boundary, and it is why circular work tends to stall at the business case rather than at the engineering.
Method and detail
Open these if you want the underlying work. All of it is set out in full in the thesis.
The eight conditions in full
| Condition | The question we asked | Consequence if unmet |
|---|---|---|
| A Management commitment | Does senior leadership provide an explicit mandate for end-of-use information flow and circular activity? | Recovery work stays outside strategic and budgetary priority, and gets deprioritised before channels, receivers or translation routines can support it. |
| B Organisational positioning | Are end-of-use activities structurally aligned with product development, or placed where no formal connection exists? | There is no formal organisational route into design. Physical proximity alone does not fix it, because the separation is structural rather than geographic. |
| C Established feedback channels | Do formal channels or routines exist through which this information can reach product development? | Information either does not arrive or is exchanged irregularly and person to person. Knowledge stays local to whoever generated it. |
| D Incentive alignment | Do people in recovery operations and people in product development share an incentive to exchange and use this information? | Rewards keep favouring new sales, cost reduction or local operational goals. The financial rationale a PSS creates stays available in principle without becoming practice. |
| E Internal awareness of EoU activities | Are these activities recognised as relevant beyond the function that performs them? | Awareness stays close to the activity. Product development does not know what information exists, why it matters for design, or that it could ask. |
| F EoU activity knowledge in PD | Does product development understand recovery work well enough to read its design implications? | Observations about wear, access, disassembly or component condition stay operational knowledge instead of becoming design requirements. |
| G Designated information receivers | Is a named function or role inside product development accountable for receiving and processing it? | Anything that does arrive has no owner, so it is unlikely to be followed up or connected to design work. |
| H Knowledge translation | Are observations converted into a form product development can interpret and use? | The question is not whether information exists but whether it becomes requirements, test criteria, design rules or specifications. Without that it stays unusable. |
How the study was done
A qualitative embedded case study of one manufacturer, covering the firm as a whole plus three internal operating settings. The work ran in three phases: research design, then mapping and development, then evaluation and analysis.
| Respondents | 23 in total, labelled R1 to R23 for anonymity. 18 were met live, through semi-structured interviews and stakeholder mapping sessions. 5 product development respondents, R14 to R18, answered in writing through Microsoft Forms. |
|---|---|
| Functions covered | Central functions spanning strategy, sustainability, design and sourcing, plus operational and management roles at the three internal settings. |
| Workshops | 6 stakeholder mapping sessions using a rings of involvement method: a focal issue at the centre, then core actors, strong indirect influence, and affected or consulted actors. |
| Tooling | The comparison we needed across remote industrial teams was not being captured anywhere, so we built a digital stakeholder mapping tool to collect it. Seven build stages, from a three-ring canvas through a dependency layer to an aggregation dashboard. |
| Literature | 2,177 records screened, 78 in the final sample. 51 from database search plus 27 through snowballing. |
| Analysis | Four steps: affinity synthesis, mind mapping, cross-case analysis, then pattern matching against the eight conditions. |
Why organisational structure is the mechanism
In manufacturers of this shape, recovery operations and product development typically sit in different organisational verticals that meet only near the top of the company. That is not unusual and it is not a flaw. It is what you get when a service and aftermarket business grows alongside an engineering organisation, each with its own reporting line and its own reasons to exist.
The consequence is what the study is about. Retained ownership puts the recovery work inside the company, so the information is in principle available. Whether it travels depends on whether anything connects those two verticals: a defined route, a recognised input on the design side, and someone accountable for it. Earlier research is clear that physical proximity does not substitute for that. Feedback can stay absent even where recovery happens under the same ownership and close to production, which is why the framework asks about structure rather than distance.
This is why the framework is stated at the level of conditions rather than recommendations for any one company. The same eight questions can be asked of any manufacturer running value retention at scale, and most of them are only now building the organisational plumbing for it.
What this does not show
This is one embedded case, drawn mostly from the manufacturer's side, with no comparison against a firm that has not adopted a PSS model. The framework describes how an organisation is arranged. It does not establish that any single condition causes the outcome, and it should not be read as a verdict on any company.
We did not observe every product development decision, and the study cannot claim that end-of-use information never reaches design. What it can show is an organisational pattern, and that pattern is common enough across the literature that we would expect to find versions of it in most manufacturers running value retention at scale.
The obvious next step is testing whether the three barriers can be addressed together, since addressing any one alone leaves the other two in place.
Read it
The full thesis runs to 85 pages, with the complete condition derivations and the literature they are drawn from. It is being published through Linköping University's DiVA repository, which is where to get the authoritative version. If you work on this and want to talk before then, email me.
| Title | Information from End-of-Use Activities to Product Development: Organisational Conditions at PSS-Oriented OEMs |
|---|---|
| Authors | Jai Krishnan Murali and Johan Karlström |
| Institution | Linköping University, Department of Management and Engineering |
| Programme | MSc Sustainability Engineering and Management, 30 credits, spring 2026 |
| Report number | LIU-IEI-TEK-A 26/05298 SE |
| Supervision | Erik Sundin at Linköping University. Maria Bolin Anvill at Toyota Material Handling Europe. |