Companies are forced to meet ever-changing customer expectations to achieve high acceptance of their products on the market. A considerable number of approaches can improve product design quality, such as quality function deployment, concurrent engineering, design for X (DfX), early customer involvement 
, and the utilization of product usage information (PUI) 
. As emerging technologies such as IoT technologies become widespread, producers can collect large-scale PUI from different stakeholders, including retailers, customers, users, and the providers of product-related services such as maintenance, renting, and leasing. Its content, format, and quality are heterogeneous and cover, for example, service reports, review reports, and embedded systems’ measurements. This information provides producers a better understanding of user expectations, usage situations, product behavior, and performance. Consequently, this understanding might revise product developers’ assumptions and experiences about the current state of the world and might lead to changed expectations, goals, and hypotheses in product development. It helps substitute assumptions for evidence, increase simulation models’ accuracy, create comprehensive test cases, and evaluate solution alternatives. For instance, the analysis of performance information can substantiate failure and degradation mechanisms that a producer can use to prioritize critical issues, analyze root causes, and eventually improve current and future product generations 
2. Product Usage Information (PUI)
A product is something sold by an enterprise to its customers 
. Companies manage product-related information through Product Lifecycle Management (PLM). This lifecycle often extends from the product’s early design stage to the manufactured items’ disposal. Figure 1
illustrates the product lifecycle from an information management perspective. The presented product lifecycle has three subsequent phases. Each phase’s name corresponds to its sequence position, i.e., beginning of life (BOL), middle of life (MOL), and end of life (EOL).
Phases and information flow of the product lifecycle 
This research focuses on information extracted from the MOL phase of a product or, in other words, the usage phase of a product. Wellsandt, Hribernik, and Thoben 
used the term Product Usage Information (PUI) for this information. They defined it as ‘product-related information that is created after the product is sold to the end customer and before the product is no longer useful for a user’. The term PUI is similar to field data 
, in-service information 
, and field feedback 
, but it indicates where the information comes from in the product lifecycle without constraining it to a specific data source, format, or content. This distinction is subtle but necessary, in the researchers' view, to better connect it to the extensive conceptual world of PLM.
Companies can acquire PUI through various communication channels, such as call centers, help desks, measurement systems, software logging, and various website and service types on the Internet. The latter include, for instance, weblogs, social networking services, product review services, and online marketplaces. The broad range of conventional and newer channels facilitates the rapid collection of PUI. Table 1
provides an overview of relevant communication channels. This overview is not comprehensive, but it outlines the complexity of PUI in product development. The source types are according to the Big Data source classification schema proposed by the United Nations Economic Commission for Europe (UNECE) to structure the PUI sources and channels 
. UNECE uses this classification in their official statistics, and thus the researchers consider it an acknowledged and credible schema. The schema differentiates three data source classes: human-sourced information (HSI), process-mediated data (PMD), and machine-generated data (MGD).
Table 1. PUI channels usable in product development.
HSI is mainly loosely structured or ungoverned data created by customers or users and includes, amongst others, opinions, complaints, and expectations. This feedback refers to product instances, but there is often no unique identifier to associate an instance to its user. Missing identifiers are sometimes a problem because the employees cannot combine the HSI with other information about an instance (e.g., measurements). Therefore, HSI can provide insights about many product aspects but often without being precise. HSI quality and amount rely much on the customers or users producing it and the available channels. Producers typically have more control over MGD and PGD.
MGD is mostly well-structured and typically originates from sensors and log files of product-embedded control systems. Producers can control MGD quality if employees take the product development’s information needs into account during the product’s sensor system design.
PMD integrates HSI and MGD. Service records, for instance, have text input from service personnel and data from measurements. They contain maintenance, repair, and failure information, which are helpful for producers to identify a product’s weaknesses.
Within the lifetime of a product, the PUI of a product can range from over many years. It is mostly written information. Each PUI refers to a piece of usage information from, for instance, a sensor of a product instance. These PUI all give limited insight into product use and generally only reflect problems with the products, and they offer little insight into general patterns of product usage 
. To have meaningful and holistic insight into product usage, companies usually require integrating and analyzing PUI from many product instances. A high number of pieces of PUI makes manual reading and analysis often hardly feasible.
3. Benefits and Usage of PUI in Product Development
Academic literature describes a variety of use cases that outline how product development tasks can benefit from PUI. PUI with information about reference products’ real-world usage revises the producer’s understanding of the product, its users, and usage context 
. This revised understanding suggests changes in requirements and product designs. It supports producers in capturing new requirements for product improvement and developing the next generation of product design. In the task clarification phase, the support focuses on changing the requirements list by adding, removing, or editing entries, based on a deeper understanding of, for instance, product usage and customer expectations. For example, Joung et al. 
contributed to identifying latent customer needs during the pre-execution and post-execution steps of product use by customers with an analysis of customer complaints. In the product conceptual, embodiment, and detailed design phases, it helps to analyze problems, search for solutions, and select and evaluate solutions. For example, Abramovici and Lindner 
and Abramovici et al. 
analyzed various types of PUI, including both unstructured data (e.g., MRO reports) and structured data (e.g., sensor data about temperature, workload, speed) to gain a comprehensive view of possible influencing factors and causes. Based on the gained insight on influence factors (e.g., temperature, speed), product developers can determine changes on respective design parameters (e.g., material, limitation of rotation speed) to reduce the failure probability. Alkahtani et al. 
analyzed warranty data and manufacturing data to recommend optimized design parameters and tolerance for maximum reliability and minimum cost. van der Vegte et al. 
explored time-stamped usage data for an engineering simulation to reveal how use-related phenomena influence product performance, and to evaluate and prioritize design variations. Stietencron et al. 
introduced real-life PUI-supported simulations into the product design process to eradicate the need for repetitive and costly rounds of prototype development, production, and testing.
In terms of usage methodology, data-driven design or data-informed design, using data mining and machine learning on big data for decision-making support, have been increasingly discussed in the literature as product innovation enablers 
. It has, on one side, chances to overcome the limitations of human analysis and guide developers towards optimal design decisions, and on the other side, still many challenges. PUI is often analyzed and utilized to support data-driven design for product improvement. Regarding the usage and analysis methodology of PUI, the reviewed application cases often use data science methods and tools (e.g., machine learning, text and data mining, and statistic analysis) to derive useful knowledge or models for development tasks. In some cases, researchers use a set of integrated PUI directly for, for example, simulation analysis 
4. PUI Provision in Product Development
As mentioned in the previous section, various researches have been conducted on the usage of PUI in scenario-specific product development tasks. On the provision of PUI in product development tasks, these approaches are often under an implicit assumption that the required relevant PUI is already identified and prepared, for example, in the approach of using MRO reports for failure cause identification 
. Abramovici and Lindner 
present a framework, i.e., a PUI Feedback Design Assistant, for the acquisition, extraction, aggregation, and analysis of PUI for the generation and provision of knowledge to develop improved development product generations. Although the research describes the scope of considered PUI and the layers supporting the use of PUI in product development, it has little focus on providing the right PUI to meet the needs of different product development tasks. Voet et al. 
developed a framework for capturing and analyzing product usage data for continuous product improvement. The framework is to determine which usage data, i.e., sensor data, should be captured in the next product generation, and then develops systems to capture and analyze these data so that the next generation of products can be optimized towards the given goal setting. To summarize, the research of Voet et al. is more from the viewpoint of capturing the correct usage data rather than the viewpoint of finding and utilizing the right existing usage data for a given product development task.
To find the correct information for product development tasks, information-seeking approaches are often discussed. Although many approaches support information seeking in product development, identifying task-relevant information from a rapidly growing number of structured and unstructured data is still challenging. Generic search tools, such as desktop search, database search, and web search, can help engineers use specific keywords to find experts and relevant documents, such as material information, technical reports, and patents. Enterprise Search supports the search of documents within the organization that contains relevant information and people with the right expertise 
. PLM/PDM systems, e.g., Teamcenter, enable engineers to find different kinds of product information, for instance, CAD drawings, BOM data, parts information, and manufacturing instructions, across more domains and departments. These systems work primarily on seeking product information from the BOL phase, although some PLM systems and customer success and analytic tools provide functionalities to manage, search or even analyze PUI, for example, integrating sensor data for realizing digital twins. They have hardly focused on understanding the product development activities, in which PUI is utilized, and providing appropriate PUI to satisfy the respective information needs of tasks.
5. The Context and Context-Based PUI Provision in Product Development
It is worth noting that there are many different definitions for the term “context”. Bazire an Brézillon 
and Liu et al. 
have conducted literature reviews on context taxonomies. Edmonds 
says that context is “the abstraction of those elements of circumstances in which a model is learnt…”. According to Merriam Webster 
, context is “the interrelated conditions in which something exists or occurs”. To achieve the researchers' objective of preparing task-relevant PUI, the researchers focused on the representation of product development tasks as the interrelated conditions or circumstances in which task-relevant PUI is utilized, i.e., identified and integrated. Dey 
use the term context to represent any information to characterize the situation of an entity. According to the definition, “if a piece of information can be used to characterize the situation of a participant in an interaction, then that information is context”. In this research, the researchers mostly use information about product development to characterize the current situation of a product developer during PUI utilization. The context is about, for example, for which product design object (e.g., medical imaging devices) and design activity (e.g., find the distribution and major sources of interoperability problems) the developer is looking for PUI. The context can significantly influence the identification, interpretation, and integration of the PUI. For different product design objects and design activities, the information needs of PUI could be different, and the PUI could be interpreted and utilized in a different way.
To improve the provision of appropriate information, context-based approaches have been proposed. They help provide knowledge and relevant documents applicable to the engineer’s situation 
. Redon et al. 
presented a context-based search platform based on the identification of an engineering context and the subsequent pushing of applicable knowledge to that particular engineer. They introduced a context model to represent the engineer’s context of an engineer working in a specific company, and then used it to index available knowledge. Liu et al. 
have proposed a knowledge recommending approach for new product development based on workflow context matching. It can help engineers find similar outcomes, e.g., product drawing and work instructions, of former new product development tasks. With the consideration of context awareness, Mehrpoor 
argues that existing systems either are too general or do not apply domain-specific tools and knowledge to improve information retrieval against stored data and information in file systems with the engineering focus and cannot satisfy engineering needs. Building on this assumption, Mehrpoor proposed a system to recommend relevant documents for engineers in specific work contexts. Therefore, he constructed an ontology-based context model as a knowledge domain to derive engineers’ work contexts and then used the context model to support the identification of engineers’ information needs. These approaches have built and applied context models to better satisfy the information needs of engineers but have their specific areas of focus. They have mainly focused on the recommendation and provision of documents and knowledge items in BOL phases, rather than PUI in MOL phases. Considering the characteristics of PUI, for instance, engineers often require integration and synthesis PUI from a large number of product instances to obtain meaningful insight for problem solving; approaches with the suggestion and recommendations of single documents and knowledge items are not optimally suitable for the provision of PUI during problem solving in product development activities. Furthermore, although there are many different context elements and context models around product development, for example, 
, they have targeted specific areas. Few of them focus on the purpose of this research, i.e., appropriately identifying and integrating PUI for product development tasks.
6. A Systematic Procedure for Utilization of Product Usage Information in Product Development
As presented in the above sections, many research studies have investigated PUI, the benefits of PUI in product development, and the capture and analysis of PUI for data-driven product design. However, preparing task-relevant PUI that fits different product development tasks is often ignored. The literature describes several methods, systems, and tools to help provide appropriate information for product development tasks, such as enterprise search, PLM systems, and context-based approaches. Nevertheless, they mainly focus on documents and knowledge items from the BOL phases, rather than PUI from the MOL phases. In their research, data integration is often little relevant. They cannot optimally support the identification and integration of PUI, although this kind of integration is usually required during the analysis and use of PUI. Additionally, PUI is from different systems or stakeholders with different viewpoints, its relevance, meaning, and interpretation could depend on the current product development tasks. Developers could have different perspectives and interpret and integrate PUI differently in different product development tasks. This research addresses this research gap in preparing task-relevant PUI and rectifies the related shortcomings and challenges. It proposes a high-level product development task model as context model to characterize the work context of developers during the PUI utilization and highlight contextual factors directly relevant to the PUI provision in product development tasks. Based on the context model, this research guides developers to identify the relevant PUI and interpret and integrate PUI appropriately according to their understanding and needs in the product development tasks. It aims for a systematic procedure that helps identify and integrate task-relevant PUI for different product development tasks.
Methodology for context-based PUI provision.
Figure 2 gives an overview of the proposed procedure for context-based PUI identification and integration. The procedure provides stepwise guidelines to support developers in understanding their current product development tasks, clarifying their information needs on PUI, and afterward identifying, interpreting, and integrating appropriate PUI for data-informed decision-making in the product development process. It is an iterative approach that allows going back and forth between steps until achieving a resilient result.