A Method for Boundary Resources Design to Increase Complementor Satisfaction

Innovation platforms are powerful engines for inter-organizational value co-creation. They use an “inverted” approach, making platform boundary resources (BRs) available to third parties for complementary innovation and generativity at the application level (Parker et al. 2017; Gawer 2020; Hein et al. 2020). This model also shapes the Industrial Internet of Things (IIoT), where IIoT platforms, as a subtype of digital industrial platforms offered by Siemens, Parametric Technology Corporation (PTC), or Microsoft rely on BRs (Pauli et al. 2021, 2025; Arnold et al. 2022). BRs constitute a participation architecture designed to enable and foster complementary innovation and generativity, while maintaining control from the platform provider’s perspective (Ghazawneh and Henfridsson 2013; Svahn et al. 2017). In practice, application programming interfaces (APIs), development tools, documentation, and community events represent exemplary BRs (Ghazawneh and Henfridsson 2013; Dal Bianco et al. 2014). The design of BRs determines the development effort and innovation output of complementors (Wulf and Blohm 2020; Soh and Grover 2022; Gong and Li 2023). For example, well-designed APIs and clear information about them reduce the effort to connect a platform to enterprise and cyber-physical systems. Purposeful social BRs, such as developer documentation and community events, make it easier to understand the platform’s added value (Dal Bianco et al. 2014), while poorly understood development tools can reduce the ability to digitize and analyze factory processes (Petrik and Herzwurm 2020).

As the examples above indicate, and as discussed in more detail in Sect. 2, poorly designed BRs reduce complementor satisfaction, which in turn reduces their engagement and willingness to innovate (Engert et al. 2022, 2023). Since complementors act outside the hierarchical control of the platform provider, there is no guarantee that they will adopt BRs. Moreover, over time, unresolved sources of dissatisfaction with BRs may even lead complementors to multihome or switch to other platforms, despite some vendor lock-in, since the IIoT platform market remains fragmented (Lueth 2019; Chen et al. 2022; Pauli et al. 2021; Mosch et al. 2023). At the same time, the challenge of designing satisfactory BRs is particularly salient in the IIoT context. Compared to platforms in business-to-consumer (B2C) domains, such as video games, platform providers design large numbers of highly specialized BRs (Petrik and Herzwurm 2019; Arnold et al. 2022) to enable architecturally complex and specialized industrial applications (Pauli et al. 2021; Arnold et al. 2022). This architectural complexity and the less standardized, more individualized nature of relationships between platform providers and complementors in the IIoT (Marheine et al. 2021) require systematic and continuous monitoring of complementor satisfaction, coupled with continuous (re)design of BRs.

Existing research highlights the importance of BRs as powerful instruments of platform governance, recognizing that their design influences complementor engagement (Hein et al. 2019; Svahn et al. 2017; Soh and Grover 2022). Research has begun to shed light on different BR archetypes and performance effects of BR design (Wulf and Blohm 2020), design decisions (Gong and Li 2023; Wulfert et al. 2022; Wulfert 2023), and deployment approaches (Hein et al. 2019; Svahn et al. 2017). However, our understanding of how to systematically measure and improve complementor satisfaction in line with BR (re)design, especially in complex business-to-business (B2B) settings such as the IIoT, remains limited. With a few exceptions (Wareham et al. 2014; Svahn et al. 2017; Wulfert 2023), existing work has predominantly focused on more high-level governance mechanisms (Ghazawneh and Henfridsson 2013; Bender 2020; Zapadka et al. 2022; Hurni et al. 2021; Engert et al. 2022; Soh and Grover 2022). Prior platform research does not investigate how platform providers can keep complementors engaged and committed to innovation on their platform. As a result, platform providers lack empirically grounded and actionable approaches to make informed decisions about the ongoing (re)design of BRs based on complementor feedback (Petrik and Herzwurm 2020a, 2020b).

This study employs the echeloned design science research (DSR) methodology (Tuunanen et al. 2024) to create an artifact with a strong focus on practical relevance (Gregor and Hevner 2013). To address the aforementioned problem, we consider a systematic method as a purposeful artifact type, due to the ability of methods to assist decision makers in goal-directed activities (March and Smith 1995). In particular, the presented method aims to support IIoT platform providers in aligning the (re)design of BRs with complementor satisfaction. The method design is theoretically grounded in the quality-satisfaction relationship (Oliver 1980; De Ruyter et al. 1997; Spreng et al. 2009), which is why service quality techniques are used to obtain complementor feedback and measure complementor satisfaction. The design of the method also draws on rich empirical evidence from the MindSphere platform developed and operated by Siemens in the IIoT domain. The method was instantiated as a prototype, and its relevance and applicability were evaluated with practitioners from 12 platform providers in the IIoT domain. These companies are considered potential users of the method.

Using the theoretical lens of satisfaction and its relationship to quality, we provide a method for the continuous (re)design of BRs by platform providers, which helps them cope with the dynamic and heterogeneous nature of IIoT platform ecosystems. To formalize this design knowledge and make it accessible, each of the six phases of the method includes design principles, followed by operational guidelines and an exemplary instantiation of a web-based application prototype. Our theoretical contribution is a nascent design theory at the intersection of BR and platform governance research streams. We advance the existing knowledge base on complex BR portfolios (Dal Bianco et al. 2014) and their management throughout the platform lifecycle (Hein et al. 2019; Wulfert 2023). Beyond the scope of existing work, our method is unique in that it sets complementor satisfaction as a goal of platform governance and provides prescriptive knowledge on how to achieve this goal.

The paper is organized as follows. In Sect. 2, we introduce relevant theoretical constructs in an integrated research model on BR design and complementor satisfaction. Section 3 describes the research design, which follows the echeloned DSR. Section 4 presents the designed artifact, our method, which we demonstrate through a prototypical instantiation in Sect. 5. Section 6 reports the results of the qualitative evaluation of the method's relevance to IIoT platform providers, its applicability, and the limitations of its use. In Sects. 7 and 8, we discuss implications, limitations, and future research directions, and conclude with the results of the paper.

Our artifact is a systematic and continuous method that aims to help IIoT platform providers navigate the (re)design of BRs and align them with complementor satisfaction. In general, a method represents a set of steps to achieve goals or solve organizational problems, using constructs and models to clarify a solution space (March and Smith 1995). Methods accumulate knowledge as operational principles, representing nascent design theories and Level 2 DSR contributions (Gregor and Hevner 2013).

The method presented here is the result of a larger research project¹ involving iterations and intermediate artifacts (Baskerville et al. 2018). Among existing design genres (Peffers et al. 2018), our research best aligns with DSRM, which focuses on creating artifacts relevant to organizational problems. However, the progression of our research project deviates significantly from the linear nature of DSRM. At the beginning of the research project, empirical studies were conducted to generate sufficient knowledge about the understudied but complex IIoT domain, which is not comparable to B2C. The ongoing completion of the design knowledge led to intermediate artifacts to design the method with practical value for platform providers. Therefore, in order to communicate our non-linear research process adequately and increase transparency regarding the preliminary empirical studies and design decisions made, we use the organizing logic of the concept of “echelons” (Tuunanen et al. 2024). An echelon-oriented approach decomposes a larger problem into a hierarchy of logical subproblems. Solutions to subproblems serve as intermediate results that can be developed, validated, and communicated independently. In combination, the intermediate results contribute to the overall solution and provide legitimacy for non-linear and complex DSR projects (Tuunanen et al. 2024). In line with this, echeloned DSR allowed us to communicate the refinement of the design objective as we gained sufficient domain knowledge. Furthermore, the artifact presented in this paper is the result of four design and development echelons, which are empirically grounded in the precursor studies. This indicates an accumulation of knowledge that culminated in improved artifact designs and evolved into a systematic method. Thus, the echelons encapsulate both the precursor work and the novel design knowledge presented in this paper, streamlining the complexity of nonlinear research and increasing the transparency of knowledge accumulation in the designed method (see Fig. 2).

Full size image

In terms of problem analysis, we analyzed the knowledge base on BRs in the IIoT domain with the help of additional empirical grounding through expert interviews conducted in our own preliminary research (Petrik and Herzwurm 2020c). We reasoned why complementor satisfaction is a meaningful goal for platform providers in the IIoT, and why the lack of systematic approaches to guide the (re)design of BRs in line with complementor satisfaction is a problem for them. This is because complementors in the IIoT rely on trusted partnerships with platform providers and on the resourcing nature of the BRs offered. In line with this, the initial design objective was to significantly improve complementor satisfaction in IIoT platform ecosystems through BRs. To achieve this objective, we designed a representative set of BR types in the context of IIoT (Petrik and Herzwurm 2019). This set, which culminated in the initial design echelon, fostered our analytical clarity about which BRs are offered by IIoT platform providers, and which predominantly resourcing goals these BRs support from the complementor perspective. In addition, the set of BR types provides the foundation for the subsequent echelons and is ultimately part of the resulting method. To gain a sufficient understanding of the contextualized goals of each BR and to track their evolutionary development, the identified BRs were drilled down to instances at the level of individual updates (demonstration echelon). The empirical data obtained in this and other phases of the research process (see below) are based on a comprehensive, multi-perspective case study of the Siemens MindSphere ecosystem (evaluation echelon).

Siemens is a multinational conglomerate best known for its industrial technology business. To protect its vertical pipeline business from commoditization and to respond to competition in the area of digital IoT-based services (e.g., predictive maintenance), Siemens decided to build up software capabilities to harness more value in the digital era. As a result, the platform that was launched initially enabled internal software development for enterprise IoT applications and was later opened to complementors, enabling the creation of a partner ecosystem. Over the years, Siemens developed an extensive portfolio of industrial devices and in 2015 decided to develop its own IIoT platform, MindSphere. MindSphere is an open operating system designed for diverse industrial applications, with no restrictions on specific manufacturing processes. After a closed beta phase, the platform was made available to complementors in 2018. MindSphere was chosen as a representative IIoT platform to study BR (re)design for two reasons. First, Siemens has openly communicated its intention to build an ecosystem and has made visible efforts towards offering BRs, providing rich data for analysis. In fact, the number of MindSphere complementors grew steadily during the DSR project. Siemens needed to continuously improve its ability to design BRs for complementors, moving away from previous pipeline business models. MindSphere serves as a unique case for observing the design of BRs from the ground up, as Siemens has maintained the BRs for 8 years. Second, analyst benchmarks rank MindSphere as a leading IIoT platform, successfully competing with hyperscaler platforms such as Azure IoT or AWS IoT (Gartner 2021). In line with this, MindSphere’s relevance in industrial applications continues despite technological changes such as the migration of the platform core to the industrial edge, outlasting several competitors. Edge computing involves moving computing, storage and networking capabilities from the cloud to locations where data is generated, such as the industrial shop floor (Cao et al. 2020). Siemens Industrial Edge is a platform to work with industrial data near industrial devices. Siemens has even mirrored its design, including most BRs, to launch an edge platform and expand its platform offering. In the process, the cloud-based platform MindSphere has evolved into the Insights Hub.

The empirical analysis of BRs provided by Siemens (Petrik and Herzwurm 2019) made us realize that the complexity of BRs in the IIoT exceeds that of B2C domains, due to their greater number and interdependencies. It helped us to derive the organizational problem inductively, revealing the lack and justifying the need for a BR (re)design method to increase complementor satisfaction as a target variable. Consequently, our refined design objective is to help IIoT platform providers navigate the (re)design of BRs and align them with complementor satisfaction. To achieve this objective, during the second design echelon, we created a measurement instrument for collecting complementor feedback to identify issues in perceived BR quality and their impact on complementor satisfaction. It is based on the satisfaction measurement techniques proposed by Töpfer and Mann (2008), satisfaction studies for enterprise software as defined by Hayes (2008), and our aforementioned set of BR types. During the subsequent demonstration echelon, we developed a questionnaire to systematically obtain feedback from complementors in the IIoT, here in the course of a satisfaction study with MindSphere complementors (Petrik and Herzwurm 2020a, 2020b), resulting in an additional evaluation echelon. The survey was conducted between May 31 and December 04, 2019. The sample consists of 21 surveyed companies, including four hardware complementors (e.g., component manufacturers and automation suppliers) and 17 software and analytics complementors. The satisfaction study reached approximately 7% of the total MindSphere ecosystem (see Appendix B in the online supplement for details on the complementors surveyed).

For each question, the survey referred to the 15 BR types designed by MindSphere at the time of the survey. Methodologically, the survey combined two techniques for measuring satisfaction from Service Quality Management. The Critical Incident Technique (CIT) allowed for the understanding of memorable situations (Flanagan 1954) associated with the use of the BRs that are critical to complementor satisfaction. Additional questions and Likert scales were used to measure the self-reported importance of and satisfaction with the BRs, according to the SERVIMPERF technique (Töpfer and Mann 2008). Importance provided an additional perspective to measure the effectiveness of the platform provider’s quality improvement efforts targeted at individual BRs. In combination with CIT, respondents were given the opportunity to justify their rating, so that critical incidents had a validating effect on the quantitative ratings. The complete survey can be found in Appendix C of the online supplement. After surveying 21 complementors, we obtained 328 so-called sentiment reports, which contained 379 critical incidents across 15 BR types. We use this empirical data to illustrate the application of the designed method using exemplary BRs in Sect. 4. In particular, concrete quotes and figures from the empirical dataset show how to analyze feedback obtained from complementors.

Since the conducted survey suggested the effectiveness of the applied satisfaction measurement techniques, we have taken the design of the measurement instrument and embedded it in a comprehensive, multi-phased method (extended design). This intermediate artifact (Tuunanen et al. 2024) already essentially corresponds to the final method based on the last design echelon (refined design), as described in Sect. 4. In the last design echelon, we improved the consistency of the method and further detailed some activities based on the evaluation described in Sect. 6. Finally, we derived design principles (DPs) for each of the six phases of the method. The DPs follow the conceptual scheme of Gregor et al. (2020) to formalize the operating principles and make them actionable.

We instantiated the method as a web-based application prototype to demonstrate its technical feasibility and outline how it can be integrated into a platform provider’s natural context of software-supported platform governance (demonstration). We developed two instances of the demonstration echelon type. The first prototype was developed based on the extended design echelon. Along with the improvements made to the method (refined design), we also revised the prototype. Section 5 presents the revised prototype and explains, where appropriate, how it differs from the previous instance.

The last evaluation echelon aimed at a qualitative evaluation of the method and the prototype. To achieve a practice-based evaluation of the usefulness of the designed method (Tuunanen et al. 2024), we conducted focus groups with platform providers and complementors to capture experts’ views on the artifact. Focus groups were chosen because qualitative and contextual feedback from naturalistic users was appropriate to capture the richness of experts’ insights in a moderated dialogue, while due to the novelty of the method, its actual implementation in platform companies would have required an extensive project with new hires (Tremblay et al. 2010). This corresponds to an ex-post naturalistic evaluation (Pries-Heje et al. 2008; Venable et al. 2012).

Following the goals of confirmatory focus groups in DSR (Tremblay et al. 2010) and applicability checks (Rosemann and Vessey 2008), the workshops aimed to evaluate the artifact against three criteria. The relevance to practice aims to evaluate the method’s effectiveness in a specific context and its potential to address the aforementioned problem of platform providers in the IIoT, which is a core principle of DSR (Mark et al. 2007). The applicability and boundaries aim to evaluate how the method can be applied in the real context of an IIoT platform provider, and under which conditions the effectiveness of the method is reduced. The evaluation continued until the feedback from practitioners began to converge, and no substantially new considerations arose for further redesign of the method. At that point, we assumed theoretical saturation, which led to a stopping condition. A total of 59 practitioners from 12 organizations participated in the evaluation (see Appendix D in the online supplement for details on the evaluation participants).

Prior to the workshops, participants received a summary of the method, which had been pre-tested by four academics with expertise in digital platforms. During the focus groups, we presented the concept of BRs, our problem statement, and the method on slides and then guided the practitioners through the phases of the method in the prototype. All statements made by the practitioners were recorded. These recordings were transcribed and subjected to qualitative content analysis. The transcripts were first open-coded to capture the depth of the experts’ statements. Connections between related statements were then established (axial coding) and assigned to the three previously mentioned evaluation criteria (selective coding).

Our method aims to support IIoT platform providers in aligning the (re)design of BRs with complementor satisfaction. To this end, service quality techniques are used to obtain complementor feedback on the perceived quality of BRs, in order to assess the issues and their impact on complementor satisfaction. The method consists of six phases, each with specific activities. To provide prescriptive knowledge for other design endeavors, each phase is further formulated as a DP (Gregor et al. 2020). We begin by introducing each phase and the corresponding DP, grounding them in the relevant literature. We then illustrate the application of the DP with empirical examples from the precursory empirical studies. Consequently, real data help to understand how the method should be applied. Figure 3 provides an overview of the phases and the steps involved, while the following subsections describe them in more detail.

Full size image

We have instantiated the method from Sect. 4 as a prototype to demonstrate technical feasibility and to outline how the method can be integrated into a platform provider’s natural context of platform governance supported by enterprise software. We developed two instances. An initial prototype was developed based on the extended design echelon. However, as we refined the method (refined design), we also revised the prototype.² Instead of combining multiple charts and metrics into a single dashboard, the revised prototype distributes them across multiple dashboards for clarity. The landing page links to three functional areas: (1) an online questionnaire to collect feedback from complementors; (2) dashboards for platform providers; (3) a dynamic report for platform providers. Figures 6, 7, and 8 illustrate the three functional areas, linking the instantiation to the DPs from Sect. 4.

Full size image

Full size image

Full size image

The first functional area is an online questionnaire which complementors can openly access to report quality issues. Alternatively, platform managers can distribute the questionnaire to complementors on a regular basis. Both scenarios help to establish and maintain feedback loops with complementors (DP1). The implemented questionnaire allows complementors to select specific BRs from a representative set of 15 BR types (DP6) and provide feedback in the form of positive or negative critical incidents (DP2). In addition, quantitative ratings of BRs are provided using five-point ordinal scales for importance and satisfaction (DP2). Finally, the questionnaire provides the opportunity to request additional BRs (DP6). Since different types of complementors in the IIoT may value attributes of BRs differently, potentially leading to conflicts, as described in Sect. 4.5, the questionnaire also collects mandatory information about complementors (DP5). The form can be flexibly adapted to include new BR designs, synchronizing feedback loops with the expansion of the BR portfolio (DP1, DP6).

The online questionnaire is connected to a database management system (DBMS) that stores and processes the feedback data. The DBMS is the backend for functional areas 2) and 3), which are intended for internal use within the platform-providing organization. The prototype allows for customizable workflows to control information, visualize data, and automatically calculate metrics, which is similar to the functionality of modern computer-aided quality (CAQ) systems. In addition to the ability to view feedback through dashboards, notification workflows send dashboard snapshots to departments involved in the quality management of BRs.

The second functional area is a set of seven dashboards that visualize feedback data in near real-time. Dashboard 1 contains four visual elements: (1) a stacked bar chart with the number of positive and negative sentiment reports per BR; (2) a stacked bar chart with the number of positive and negative CIs per BR; (3) a short list of the most recently collected CIs, including company name, complementor type, affected BR, incident description, importance, satisfaction; (4) a doughnut chart showing which complementors have recently experienced and reported problems. This functionality aims to analyze the collected feedback in a systematic way (DP3).

Dashboards 2 and 3 help to build the quality models for each BR, integrating different QDs derived and enriched by CIs (DP3). Dashboard 2 displays the coded QDs as lists. Heatmaps in the lists show the amount of feedback per QD. They help to determine the relative importance and, thus, the criticality of the QDs. Two lists are implemented. The first list contains those QDs that are rated as significant to complementor satisfaction (as described in Sect. 4.4). This list shows only “Criticals” and “Dissatisfiers”, sorted by the number of “Dissatisfiers” to help platform managers pin down and reflect on the areas for action. The second list shows only “Dissatisfiers” (regardless of current significance), enabling comparison of different influences on satisfaction and facilitating targeted action. Dashboard 3 displays tables containing all CIs and the QDs derived from them for two sample BRs. Various other tables can be implemented here to analyze the content of the CIs at the level of individual BRs, code them, and assign them to QDs. This helps platform managers to derive concrete improvement measures from the quality models (DP4).

Dashboard 4 visualizes four sample quality models as heat maps, using different box sizes to indicate the varying impact of each QD on satisfaction. Additional quantitative feedback from SERVIMPERF is converted into four distinct metrics in Dashboard 5 to increase the impact of quality improvement measures on overall complementor satisfaction (DP5). Two bar graphs show the collected scores for relative importance and average satisfaction scores for each BR, and a ranking is generated based on the delta analysis (see Sect. 4.5). Finally, a coordinate plane (relative importance and average satisfaction; low, high) helps to identify the BRs that are most important to complementors and that perform poorly.

Dashboard 6 summarizes both positive and negative CIs for specific QDs of individual BRs in a tabular format, allowing a comparison of feedback from different types of complementors (DP5). This helps to increase the impact of quality measures, e.g., by focusing on the most frustrated complementors, or by addressing the broader ecosystem rather than the interests of a few individual complementors. In this way, conflicts of interest between complementor types are minimized. In addition, Dashboard 7 summarizes requests for new BRs and provides complementor type information to better understand the context of the request (DP6).

The third functional area generates a dynamic report that provides a more detailed view of the most urgent areas for action for the entire BR portfolio. It is a tabular overview of the QDs with the most frequently reported quality issues. Compared to the dashboards of the second functional area, these are already prioritized and summarized using calculations from Sect. 4.4 so that only significant “Criticals” and “Dissatisfiers” are included. For prioritization between QDs with the same significance, the BR importance ranking is implemented. In addition, the dynamic report of functional area 3 includes two extra columns that indicate whether quality measures have already been defined for the most urgent quality issues and whether the responsible units already implement the measures. Traffic light colors indicate the status of the definition of quality measures and the processing of the measures.

We conducted focus groups with platform providers and complementors to evaluate the artifact. A total of 59 practitioners from 12 platform-providing organizations participated until the stopping condition was reached. The evaluation allowed us to draw conclusions about the method’s relevance to practice, as well as its applicability and boundaries in the real context of IIoT. Thus, the evaluation was mainly aimed at assessing the artifact’s usefulness. The following quotes are illustrative excerpts from the focus groups, with the numbers in brackets referring to the company identifiers in Appendix D of the online supplement.

Relevance. The experts confirmed the practical relevance of the method. They highlighted several aspects that indicate that the method brings benefits and solves relevant problems in the practice of complementor management. First, the experts confirmed that complementors prefer those platforms deemed potent enough to design BRs of satisfactory quality, stating that: “… they [complementors] go where it is technically easiest to implement. That means partners, and that is the most important thing, they also have alternatives … They sell what their developers want to work with and what they are most effective with. This is also their profit margin. With this approach, we have a quick focus on BR to quickly achieve added value.” (#3). Thus, the experts declared that BR design helps to engage complementors with unique capabilities required for creating IIoT complements (Sarker et al. 2012; Pauli et al. 2021). One group of experts recognized their own BRs and commended on the informed approach to expand the resource portfolio, stating: “We were also at the Hanover trade fair with our partners, for example. Considering this experience, I found your evaluation in the 15 resource areas quite insightful, because these are really things I felt connected to and recognized in our company.” (#8).

The experts also recognized the potential of the method to strengthen collaboration with complementors. According to them, the method helps to achieve not only alignment on the BR portfolio based on feedback loops with complementors, but also internal alignment between the “back office” and the “forefront” in the platform organization:

The experts emphasized that the method helps to get a holistic picture and to make informed decisions about quality measures at the BR level by narrowing down the areas for action in the BR (re)design despite the complexity of a BR portfolio. It seems that despite the technical possibilities of monitoring BRs in the experts’ companies, the data are not systematically used to navigate the quality issues of complex BR portfolios during their lifecycle, which would be desirable:

In fact, only one platform provider admitted relying on software support to monitor BRs and integrate community feedback into BR (re)design. However, this particular software consisted of multiple fragmented tools and only allowed monitoring of a developer forum and support tickets. Since our method is supported by an integrated prototype and provides means for active feedback collection, we conclude that the method and its instantiation are an improvement over the state of practice: “There is automated monitoring of all platform services (APIs, Cloud Foundry, Cloud Infrastructure, etc.). There is automated sentiment analysis for the forums, resource usage is tracked, reported tickets are evaluated etc. The functionality is covered by many tools, not a central tool you can buy.” (#1).

Applicability and Boundaries. The experts confirmed the applicability of the method in practice and pointed out important conditions for its effectiveness. In particular, partner managers appreciated the techniques for collecting and processing feedback to prioritize BR quality measures. They also emphasized that, in addition to our prototype implementation, the method could be implemented using standard tools available on the market and widely used in practice:

However, effective use of the method requires organizational changes. These include the creation of cross-functional (i.e., boundary spanning) roles and the implementation of stabilized processes that align the continuous (re)design of BRs with partner management and promote internal knowledge sharing. As a result, implementing the method in a platform organization was seen as relatively challenging due to the effort required for continuous data collection and analysis, as well as the investment in software and BRs. The experts explained:

The experts also shared that the applicability of our method depends on the platform provider’s approach to market penetration. Some platform providers have moved away from a complementor-oriented approach and have shifted their focus from BRs to full coverage of their own vertical applications for the sake of higher profits. In addition, complementors with an industrial (i.e., heavy asset) background value the available support, discount programs, and ease of industrial asset integration more than a satisfactory designed BR portfolio:

In line with Hein et al. (2019), we see a boundary for the effectiveness of the method when the platform provider’s market penetration approach focuses on the demand side and neglects complementors, for example when a platform provider mainly targets machine-operating end customers. Such platform users are typically not interested in BRs for complement development, but rather value seamless platform integration, which is consistent with the observation that industrial end-users tend to form direct strategic alliances with platform providers, bypassing complementors (Hein et al. 2019).

In addition, industrial customers of complementors (i.e., the demand side of the IIoT ecosystem) may have technical dependencies on enterprise software from a particular vendor. For example, if the enterprise software of an industrial end customer is dominated by a single software vendor, such as SAP or PTC, its native connectivity may compensate for the quality shortcomings of other BRs, indicating that IIoT platforms do not necessarily compete at the BR level in certain scenarios:

Creating and maintaining complementor engagement is not a trivial task for platform providers facing inter-platform competition. Using the empirical context of the IIoT domain, we design, demonstrate, and evaluate a method to align the (re)design of BRs with complementor satisfaction, ultimately leading to increased complementor engagement. To this end, service quality techniques are used to obtain complementor feedback on the perceived quality of BRs, assess the issues and their impact on complementor satisfaction, and prioritize quality measures that contribute most to complementor satisfaction. The method is theoretically grounded in the Expectation-Confirmation Theory (Oliver 1980; De Ruyter et al. 1997) and draws on rich empirical data from the Siemens MindSphere ecosystem. Using echeloned DSR, this study accumulates design knowledge from multiple studies and iterations. The method is instantiated as a prototypical web application to help platform providers collect and process feedback through an online questionnaire, dashboard visualizations, and automatically generated reports. The practical relevance and application boundaries of the method were evaluated in twelve focus groups with naturalistic users. This research aids platform providers by presenting a holistic and iterative approach that helps align BR (re)design with complementor satisfaction and shows with empirical data how to apply it. It also helps platform scholars by enriching design-oriented research on BRs with a new perspective on platform governance research.