Tese

PLATFORM-PRODUCT MANAGEMENT IN IT:

Improvement and evaluation for an basic framework

platform-product MANAGEMENT IN IT: EXPLORATORY RESEARCH TO IDENTIFY SPECIFIC NEEDS IN KEY AREAS

Design, development, and evaluation of a mobile learning application for computing education

Design, development and evaluation of an basic framework

Qual a pergunta de pesquisa? INTRODUÇÃO – 10% Quais as teorias existentes? TEORIA – 20% Qual o caminho para a resposta? METODOLOGIA – 10% Quais os resultados encontrados? RESULTADOS – 20% O que estes resultados significam? DISCUSSÃO – 20% Qual a contribuição do trabalho? CONCLUSÕES – 20%

Keywords

Design science research, artefact creation, artefact evaluation, research methodology

ABSTRACT

instructions-start Resumo – 250 a 500 palavras

O tema e sua relevância, O objetivo, O que foi feito, Como foi feito, Que resultados foram atingidos, Que contribuição trouxe instructions-end

Good inspiration, do not have source:

Digital Transformation is an extraordinary development. Organizations do a lot of work being digitalized. But digital transformation is not only about technology. The comprehensive aspects are involved to provide better service and value to the customers.

The study focused on the application of the design science research approach in the course of developing a mobile learning application, MobileEdu, for computing education in the Nigerian higher education context. MobileEdu facilitates the learning of computer science courses on mobile devices. The application supports ubiquitous, collaborative, and social aspects of learning among higher education students. Moreover, the application eases access to learning resources. The paper first describes analysis, design, and implementation activities related to the development of MobileEdu. Also, the paper deliberated on the characteristics and scope of the adherence of MobileEdu to the traits and ideas of design science research. To evaluate MobileEdu in a real-life learning setting, experiment was conducted with 142 third-year undergraduate students in a Nigerian university. Besides the learning achievement of the students using MobileEdu, the study examined the impact of MobileEdu on students’ attitudes toward studying in a system analysis and design course. Experimental data were collected from pre- and post quizzes, interviews, and a questionnaire administered to students. The results of the evaluation are encouraging and showed that the MobileEdu application has a potential to improve students’ learning achievements.

Introduction

O campo de estudos, A(s) lacuna(s), A contribuição pretendida , A pergunta de pesquisa, A estrutura do trabalho → Artifact Definition, here, used in Research Approach

Na introdução, não ficar justificando muito… as outras sessões vão servir para isto

The object of study, therefore, will be the process of improving the artifact, by encouraging people who are knowledgeable about the topic, in addition to reviewing the existing knowledge base and the researcher’s analysis work, where the expectation is to produce information of

qual é o problema de pesquisa ? Whal o business problema que o artefato tenta resolver?

Essencia: Supports management of platform-products

As KITTLAUS noted, the last two processes, requirements and release has more potential This usually leads to fierce fights between product teams and product managers.

​ Digital transformation is present in all sides of our lives, from having almost all the songs in the world readily available to listen to and being able to connect with old friends to passing in instant payments. Behind this transformation, there is a capability that stands out for thriving technology companies: connecting with the needs of their customers to conceive and manage products (EBERT; BRINKKEMPER, 2014). Being customer-centric has gained even more emphasis when the most successful business models move towards “own the consumer” (MONTGOMERIE; ROSCOE, 2013). This capability has become so crucial in the competitive landscape that it has led corporate IT organizations to adopt product management practices, with an estimate that penetration could reach 70% adoption in 2024 (GARTNER, 2022).

​ The natural path of adoption for product management in IT is managing software that supports the company’s business operations such as better serving its customers. A second form of adoption is the management of internal products, the platform-products, which represent the foundations, technology structures, base architectures, and interfaces on which the products are built (HAINES, 2008) which has the potential to increase the agility and overall efficiency of using information technology (HARLAND; UDDIN; LAUDIEN, 2020). A practical example of platform-product is the ability to interpret texts through artificial intelligence; it, alone, does not provide any direct support to a business, but it enables and accelerates the delivery of software solutions that supports business needs, for example, when used to build a chatbot to enable a self-service channel that can lower costs and better serve digital-savvy customers.

​ Product management is defined as business management at the product level (HAINES, 2008). It comprises all management means of planning and coordinating the relevant areas of a product inside and outside the company, with the aim of sustainably optimizing the success of the product (KITTLAUS; FRICKER, 2017).

​ The practice of product management, applied to platform-products within an IT organization, has enormous potential because it can create value stream-enabled delivery with enough focus and specialization to increase value creation. Furthermore, reuse is one of the ways that software engineering multiplies value generation, and we have never lived in such a favorable moment in terms of technologies and practices to capture the maximum of reuse. Platform products are one way to enable reuse. The common parallel often related to reuse is the idea of “building-blocks”, but I see platforms more like body organs, a structural unit to serve a common function in the body (a client-product), where it’s internals are not know by other body organs. The benefits of investing in platform-products are the result of investment and intentional structured work that requires good decisions (LEHNERD; MEYER, 2011): How can we identify opportunities for using a platform approach, and evaluate then thoughtfully, since, once used, troublesome to change? How can we anticipate client product needs to make or keep the platform relevant and thereby increase product success? How to quantify its value and benefits? Once a software product depends on a platform-product, part of its evolution is also linked to the ability of the platform-product to evolve, so its conception, while generating many benefits, can also generate difficulties (LEHNERD; MEYER, 2011):

​ Early-stage software product management defined four core processes: portfolio management, roadmapping, requirements management, and release planning (VAN DE WEERD et al., 2006). Nowadays, product management encompasses a much wider spectrum, and those early-stage processes are a subset, especially within “product planning” (KITTLAUS; FRICKER, 2017). The main focus of this research is on the requirements management has described as “the alignment between the needs of the stakeholders and the product concepts” (KITTLAUS; FRICKER, 2017) and release planning that “refers to the management of the detailed contents and schedule of a forthcoming product release” (KITTLAUS; FRICKER, 2017).

​ This project proposes to study the following gap: What adjustments in the product planning—specifically requirements management and release planning—should be made in the context of managing platform-products within a corporate IT organization? Software product management is applicable to the context (KITTLAUS; FRICKER, 2017), but it has not been covered very much by research (HYRYNSAL MI; SUOMINEN; SEPPANEN, 2021). The opportunity, by using a design-science paradigm, is to increase knowledge and understanding of a problem domain and concomitant producing solutions (HEVNER et al., 2004), which is one or our research goals, which is to advance the theory while providing practical contributions. Its application in the project takes place in two steps: first, evaluate the SPM framework introduced by VAN DE WEERD et al., 2006) via interviews with platform-product managers working in IT organizations. These data allow an analysis to report the main findings, contrasting the literature, and even possibly identifying solutions to propose a modified framework adhering to the context. The second phase consists of evaluating the modified framework to determine if there has been any progress (PRAT; COMYN-WATTIAU; AKOKA, 2014).

​ This work will contribute providing a specific reference to Software Product Management in corporate IT organizations, in a moment that has a potential demand for knowledge because there’s projected increase of adoption of product management practice along with the fact that platform has become a strategic option for generating a competitive advantage for organizations (**HARLAND; UDDIN; LAUDIEN 2020). This research also provides other researcher with perspectives on the specificities and challenges of SPM on the study context and provide directions for future research to potentially stimulate more research for the study context.

Theory on product management, platform-product and how these related to IT Organizations

TEORIA – 2000 palavras

Visão geral do capítulo, Aspectos históricos do tema, Contribuições seminais, O estado da arte no mundo, O estado da arte no Brasil, Grandes questões, Síntese ou modelo: diagrama e descrição, Hipóteses

research to be able to build his argument

Outline:

Why requirements and release?

Short priorization is more critical, because your comment resources

While reviewing the resources… I found ..,…

Intro

​ The revised theory for this proposed research is divided as follows: a) essential information about the practice of Product Management; b) presentation of a special type of product: platform-product c) Product Management Specialization applied to software, and its specialization needs for platform-product; d) Why Product Management has gained attention in areas of Information Systems/Information Technology; f) and, lastly, the research proposal

Product Management

​ Product Management had its origins in the world of consumer products when the industrial era began to seek improvement in order to develop a complete understanding of the business results cycle, from conception to discontinuity of what was industrialized (HAINES, 2008) . Product is one of the four P’s concept well diffused in marketing, which comprehends defining the right product, in the right place, at the right price, using the right promotion, and, therefore, this practice has been more associated with a marketing function (KOTLER; KELLER, 2015). In the context of information technology intense products, given the complexity and specific knowledge needs, it is more common to observe marketing areas being responsible for brand development and customer acquisition, while a specific product management area takes care of the value proposition, development and other activities that comprise product management (WALKINGSHAW; BANFIELD; ERIKSSON, 2017).

​ But what are products? In a simplistic definition, a product is something that is produced (MERRIAM WEBSTER, [sd]). More broadly anything that can be offered to a market for attention, acquisition, use or consumption (KOTLER; KELLER, 2015). This includes tangible products such as physical objects and places and intangibles such as services and ideas (KOTLER; KELLER, 2015). In the world of technology, there is a combination of both types, for example, a cell phone (tangible) that already comes with some built-in services such as location tracking functionality (intangible).

​ On the other hand, the word management refers to achieving organizational objectives effectively and efficiently through planning, organizing, leading and controlling organizational resources (Richard L. Daft, 2010). Combined, managing products is taking care of all aspects of a product, holistically, in order to maximize its business result (KITTLAUS; FRICKER, 2017). The scope of product management comprises in (HAINES, 2008):

• Choose and justify products to build.
• Plan the creation, implementation, and result (profit) of the product.
• Develop and launch it.
• Manage performance from its entry into the market.
• Withdraw that product from the market and replace it with a new one.
• Efficiently allocate investments across all an organization’s products.

​ Within an organization in general, a product is part of a conceptual hierarchy whose hierarchy levels are explained in an orderly manner, from highest to lowest, in the table below:

Concept	Description
Product Portfolio	Grouping of related product lines especially used in very large organizations.
Solution or Package	Products and Services that, when offered together, solve or address a larger problem.
Product line	Collection of Products with some kind of synergy or common attribute, such as a target market or a similar building method.
Product	Goods, merchandise, services and knowledge that can be sold.
Product Element, Module or Terms	Physical or conceptual parts of a product that enable or form part of the products.
Product Platform or Base Architecture	It represents the fundamentals that are behind the product and that enable its construction. The platform provides something in common, and its purpose is its use in multiple products.

Table 1 - Description of the product hierarchy elements

Source: (HAINES, 2008)

Platform-Product

Need to contextualize what is and what is for the context.

Can I do this?

Will include my own definition?

Why DevOps is not considered: because it not part of the product, it is a way to build, ship and operate the product.

​ More directly, platform-product are a collection of modules or parts that are common to several products whose commonality is intentionally developed to achieve desired effects in order to maximize value creation (HARLAND; UDDIN; LAUDIEN, 2020). An example of a platform in the automotive segment is represented in the figure below, where a certain product line called compact cars, has products such as Jazz and Civic that share the same platform having common parts, production processes, and so on, whose objective The end is cost optimization, acceleration of product launches by requiring less effort, and so on.

Figure VPP - View of Platforms within a Product Portfolio

Source: Prepared by the author with data from Honda (ANSARI, 2019)

​ Historically, in the field of information technology, the technological infrastructure used by a company as part of their information systems are called “platform” A example is the Windows Operational System which is referred as “Windows Platform” when you have a discussion around how to build something. This type of use for the platform definition is closer to “computing platform” comprising any hardware or software used to host an application or service (BIGELOW, [sd]) instead of being part of an product, and is not the right equivalent for the root definition of platform-product; let’s explore more in detail, this point.

This type of platform is not the one of interest, because it is not part Each product built for this computational platform relationship with the function of the product built on this platform, that is, something the platform represents something more generalist. For example, you buy software to run on Windows, not because it’s Windows-based.

​ The evolution of technology has led to a proliferation of innovative business models and vertical partnerships between sectors, increasing the range of platform possibilities (VIAL, 2019), which has enabled the creation of products that serve as a platform for other products representing more granular capabilities, such as an payment platform that consists of specialized delivery of the ability to make payments, providing all related technologies, connections and processes. It is important to emphasize that in this format, the contribution to the product is more specific; if the platform evolves its capacity, it will contribute more directly to the success of the product that uses it and consequently to the business made possible by the product, unlike the previous example, whose evolution in the Windows platform would not necessarily imply a direct evolution in the software for Windows, in contrast to the payment platform, which, when accepting a new card brand or a new payment method such as PIX, all products that use it start to benefit in a more practical way.

​ The heart of the matter does not concern the technological element of the platform, but rather, managing the technological element as a product, whose customer, as it is a platform, are the products that use or will use the platform. Organizations that include an intentionality with the use of platform-specific management as part of their strategy have the potential to capture the benefits attributed to it, such as reducing time to market, costs, simplification, among others (HARLAND; UDDIN, 2014). There are lines of research that study more specific aspects of platform strategy as a means of generating competitive advantage for organizations, such as the impact on resource management (Harland et al., 2020).

​ When a platform is external, it is consumed. When it is internal, it can be created within the organization or simply an operationalization of something existing, a typical buy-or-make decision. In some specific situations, an internal platform fulfills its role so well that it can become a revenue line when it is made available to be consumed by external organizations. A very emblematic example is Amazon , which created platforms to enable its products and which, due to its perennial platform-product vision, became a new business unit, AWS.

Product Management applied to software

​ This field of knowledge was opened in the early 2000s (EBERT, 2007, 2014; HYRYNSALMI; SUOMINEN; SEPPANEN, 2021; KITTLAUS; FRICKER, 2017; VAN DE WEERD et al., 2006), and is considered “a well-organized process of processing issues related to requirements, products and releases” (VAN DE WEERD et al., 2006), and whose origin is attributed to organizations such as Microsoft, which invested in this capability in the 90s, and has as part of its success attributed to this development (CUSUMANO; SELBY, 1998), thus becoming references of these practices, among many other organizations that stand out with regard to successful products in the world of technology; the economic success of a product is the ultimate goal of product management (KITTLAUS; FRICKER, 2017)

​ In order to clarify the specificity of the practice of product management for software, I highlight three main differences from fundamental product management in the context of software: the direct cost per unit sold, distribution and evolution (KITTLAUS; FRICKER, 2017). Once developed, a person/organization that obtains an additional copy of a software does not generate a cost to the owner of the software, and the form of distribution benefits from electronic means, offering low friction, making distribution something that tends to the unlimited. Product upgrades also don’t add significant costs for distribution, which offers a way to upgrade the product for those who have already purchased it and a lower risk linked to product design issues. For example, when a car is launched and it has a problem, a “recall” is made, which not only displeases customers, but also generates costs to operationalize the arrival of the correction to the owners. There are exceptions in which there is an incremental cost per new customer, as is the case with those that are offered in software as a service mode, but, in any case, they are far from the physical and operational complexities of tangible products.

​ Existing research on the subject includes frameworks (FRICKER, 2012; KITTLAUS; FRICKER, 2017; VAN DE WEERD et al., 2006), differences with other practices such as project management (EBERT, 2014), bibliographical research (HYRYNSALMI; SUOMINEN; SEPPANEN, 2021), study on the role of the product manager (MAGLYAS; NIKULA; SMOLANDER, 2013), adoption process, impact and benefits (EBERT, 2007; EBERT; BRINKKEMPER, 2014). There is a lot of room for further study, especially when compared to the abundance of existing body of knowledge for software development itself or analogous practices such as project management. A hypothesis raised by the bibliographic research on the subject for the non-existence of either the terms used, so that a term can often be used for different constructs, which does not contribute to access to information on the subject (HYRYNSALMI; SUOMINEN ; SEPPANEN, 2021).

​ And what are the advantages of institutionalizing the function of product management to the software development activity? Its consistent practice and supported by training increases the success rate of initiatives in terms of schedule predictability, quality and duration of projects (time to market) (EBERT, 2007). A subsequent complementary study brought visibility to the impacts of efficiency gains and execution costs, which revolve around 20% per year (EBERT, 2014).

Product Management applied to software applied to the context of platform-products

Product management is fully applicable to a platform-product (KITTLAUS; FRICKER, 2017). There are few specific studies on the subject (HYRYNSALMI; SUOMINEN; SEPPANEN, 2021), and those that exist reinforce that systematic management of the process is necessary to capture the benefits, synchronizing the needs of different business areas or product lines (HARLAND; UDDIN; LAUDIEN, 2020), which direct hypotheses that there are nuances for this type of product.

Why has this subject gained importance in technology areas?

​ Since the beginning of information technology, there has already been a need for frameworks to improve decision-making capacity in relation to technology investments and a constant search to improve the way of delivering and capturing value (GORRY; MORTON, 1971 ). In an analysis of case studies on digitalization (URBACH; RÖGLINGER, 2019), the authors argue that organizations that intend to prosper in the digital age must develop the potential of digital technologies, rethink their business models and transform themselves, and for this , it is necessary to review business processes, organizational structures and especially the management of information technology, in order to, in a more integrated way, be aligned with the new needs of customers and business models.

​ In particular, the digital transformation has not only stimulated the increase in investments in information technology, but also the dynamics to employ the investments, as it creates and influences consumers’ perceived value expectation and makes access to technologies that previously they were restricted to large corporations (VIAL, 2019). Managing structural change and organizational barriers in order to capture maximum value from the transformation is part of the process (VIAL, 2019).

​ Generating more value for the business requires a greater understanding of its meaning and definition. The practice based on identifying real customer problems and solving them from a business perspective, that is, value creation, applied to software is Software Product Management (KITTLAUS; FRICKER, 2017).

Research proposal

​ Among the points of opportunity to contribute to the topic of platform-product Management, the purpose of this work is to specifically study the macro activity of requirements management and release management. First, because the definition of requirements, in addition to being one of the first activities to be carried out in the life cycle, software product management is emerging and does not have specific platform-product studies within the proposed context (HYRYNSALMI; SUOMINEN; SEPPANEN, 2021). Second, because it is one of the critical success factors of a product management practice (EBERT, 2014), so that, when implemented, it conveys customer value. Thirdly, because this work guides decisions to invest or not in a platform-product initiative and is also used as an input for choosing the paths of how to carry out this initiative. And, finally, it is an area that has signs of differences in relation to a common product, since its success involves understanding two layers: the product that will use the platform, and an understanding of the context of this product, including external . This information was confirmed through contact with the most notable organization on this topic, The International Software Product Management Association (ISPMA ®).

​ A platform-product is a kind of delegation of responsibility, as a product chooses one or more platform-products to achieve benefits, mainly by focusing on what is essential for the product itself. Within an information technology area, there is still a need for a balance of different stakeholder needs : the product itself wants agility, and not be limited by platforms; executives want optimized costs and efficiency, and the organization wants successful products.

​ The research question, bearing in mind what has been presented, is: What adjustments in the product management framework, specifically requirements management, should be performed to manage platform products within an ICT? Thus, the project proposes to understand the differences and opportunities in relation to what is offered as a practice for the management of software products, and the formation of knowledge that supports this research came mainly from studies in technology companies, which business is the product itself.

​ What is the big problem in the context, prioritization … more reasonable investment … lack of visibility I invest this I have this.,

Design and Evaluation of an Framework Research Theory

We consider these as the minimum evaluation properties for the project and right sized for the research constraints, specially from

​ An artifact in technology is something invented, discovered or developed by man that has worked well enough to be considered valid for dealing with the problems, both external and internal, of the users or beneficiaries of the artifact (LEE; THOMAS; BASKERVILLE, 2013). The framework under study is a type of artifact.

plagio warning - vs Design Science topic

pode ser learning through the act of building ()n theory development in design science

​ Design science is an approach and paradigm for structured and collaborative development of new solutions, knowledge about them, and their use and environment (Schallmo et al., 2018). It is an iterative creative process, a solution-based approach, a human-centered way of thinking and working for addressing problems that are ill-defined or unknown.

​ Design Science is IS is the most preeminent research approach for artifact development, as artifact as the center of the definition of some seminal authors in the field (March & Smith (1995); Hevner et al. (2004); Peffers et al. (2006); Vaishnavi & Kuechler (2007)).

Not only an suitable approach because object under study, an artifact, but also an constructive approach that enables contribution in practical terms even with research constraints, as stated by Wieringa, 2009, as concerned on “designing useful things”.

The DS process includes six steps: problem identification and motivation, definition of the objectives for a solution, design and development, demonstration, evaluation, and communication (SIX), which are not expected to proceed in sequential, they can start at almost any step and move outward. (peffers2007).

​ Baskerville et al., 2018 provides an high level research process in DS, as you described in the bellow image, which was incremented with our the perspective or our research:

​

​ Methodology

​ Design Science Research (DSR) is a method that establishes and operationalizes research when the desired goal is an artifact (Dresh 2014). Hevner et al. (2004) provides seven research guidelines as it follows, that will be used as an way to validate the research approach.

​ Beyond general guidelines, an methodology can provides more detailed aspects like principles, practices and procedures necessary to carry out research projects. (Venable, 2017) offers guidance on choosing an DSR methodology, which provided an base structure for structuring the research methodology, and then further design and choose appropriate methods underneath.

​ A set of Design Science Research Positioning Statements were suggested by (Baskerville et al., 2018). One of these is “Design artifacts” whose objectives are presenting the guidance of “Demonstrate its novelty and its practical improvements, first, then move to reflecting on design theory contributions.”.

​ Design Evaluation

mudar testo sobre Naturalistic evaluation

​ One of the critical elements of an DSR project is defining evaluation: how to check progress in your design. Hevner et al. (2004) suggest five methods to evaluate an artifact and type of evaluations. (Pries-Heje et al. 2008) defines evaluation settings. One of these is naturalistic evaluation that is conducted to assess the performance of an artefact in a real environment, hence human complexities involved in real situations are part of such evaluations.

​ Venable et al., 2012 introduces an framework for defining evaluation is DSR projects, and makes the point that an project needs both an evaluation strategy and evaluation method, with questions to be followed in order to define the strategy. The strategy framework selection is matrix based with one dimension being evaluation setting (eg. naturalistic) and the second being the evaluation moment. ex ante and ex post. The authors also affirms that an hybrid strategy, eg. selecting more than one box, can be used to resolve conflicting goals. From the strategy method selection, methods are presented as options for evaluation, and orientation that specific detailed evaluation must be designed.

​ Sources of evaluation methods can be found in literature as primary research objective in the research, but also on those that designed artifacts, as DSR guides to reflecting on design theory contributions as an secondary goal (Baskerville et al., 2018).

​ Among the choices structured for selecting on DSR methodology proposed by Venable, 2017, the most aligned option was Peffers et al. (Peffers, Tuunanen, Rothenberger, & Chatterjee, 2008) that propose a six-step Design Science Research Methodology (which they abbreviate as “DSRM”). This methodology provides principles, practices and procedures necessary to carry out research projects, but high level guidance for an starting point that need to be expanded in choices and detail, and as referred by an seminal author as one option for recognition and legitimization of DS research (hevner2010).

Research approach

MÉTODOS – 1000 palavras

Visão geral do capítulo, Abordagem escolhida e justificativa, Descrição dos métodos, Roteiros e questionários em anexos Na seção de metodologia da dissertação vc deve informar e justificar a abordagem, descrever e justificar o objeto, e tb descrever detalhadamente como foi feita a análise e a coleta de dados, inclusive mencionando os entrevistados

O que não mostrar:

1. Não deve mostrar resultados
2. Devo colocar as dimensões que estou avaliando aqui?: Dimensions: not here:

O que eu quero fazer, porque escolhi Design, como vou validar os artefatos Constructor, → Aqui que vou determinar quant/quali

Here I will described what I choose as methodology.

Validation method?

O que eu tomei como base para decidir o evaluation method ? Artifact Type, …

How to do research in IS ? The most provincial research ?? Design Science. I found references to do what I wanted with it, and even not search for other options…

Jeitão que o pessoal coloca… Incluir os guidelines (ref - USING DESIGN SCIENCE RESEARCH AS PARADIGM FOR INFORMATION SYSTEM RESEARCH: AN APPLICATION):

The DSR is a widely applied research approach and is concerned with developing useful artifacts. From: Robson, C. and K. McCartan (2016). Real world research. 4th ed. John Wile Sons.

Possiveis melhorias:

• Validity and Relialibityt
• Porque alguem fez, eu uso e tudo bem? Talvez mencionar algo sobre a qualificação, ou alguma tentativa de triangulação?
• Falar sobre Bias do Researcher?
• A Referencia do CRM usou uma referencia de roteiro muito robusta, deveria ter usado?

Em algum dos ultimos artigos fala de Design Science e depois metodos mais genéricos de pesquisa

Anexo - Questionário semi estruturado fase A - Como outros estudo fizeram

Adopted Methodology

​ The methodology follows Design Science Research (DSR) approach with the objective of improve an existing design artifact. We have chosen DSR, first because it focuses the creating and evaluation of artifacts that address specific business problems (HEVNER et al., 2004) and secondly because it is concerned in “designing useful things” (WIERINGA, 2009), that are aligned with the research goals.

Not only an suitable approach because object under study, an artifact, but also an constructive approach that enables contribution in practical terms even with research constraints, as stated by WIERINGA, 2009, as concerned on “designing useful things”.

​ In this research, the starting point is an existing artifact, advancing the process start to the evaluation phase. This phase will generate data that will feed back the process, generating suggestions that, once implemented, should be evaluated, and from there we will generate conclusion about the artifact improvement and also the research process. The diagram below synthetizes the whole methodology elaborated for this research project:

​ The diagram below synthetizes the whole methodology elaborated for this research project:

Figure PTB - Project Research Methodology following DSRM steps (Peffers et al.)

​ We provide more details of each of the research steps, but first, we present a list of global choices based on the previous section with the appropriate reference and details that supported each choice:

Goal → Objetives → Purpose → Research Question →

Topic	Choice
Research Goal	Produce both knowledge and practical contributions for Software Product Management
Research Objectives	1/ Evaluate an existing artifact formatively to identify weaknesses and areas of improvement; 2/ Evaluate both the existing and the modified artifact resulted for improvements from goal 1, to determine the degree of the improvement of evaluated properties
Purpose	Contribute with an area of knowledge in which potentially should have more future demand and the topic have not been covered by research too much
Research Questions	1) What changes are required in an existing framework to be used in the context under study? 2) After modifications were made, how much progress was made?
Research Approach	Design Science Research
DSR Methodology	Design Science Research Methodology (Peffers et al.), choice based on (Venable, 2017), because of the objective alignment and scope

Evaluation Definitions for DSR (Hevner et al. 2004)

Topic	Choice
Method	Analytical method
Type of Evaluation	Static analysis, under- examine de structure of artifact for static qualities

Support references specific to framework artifacts

Topic	Reference
Evaluation Strategy	Naturalistic, Ex Ante followed by Ex Post (Venable et al., 2012), with other research with similar strategy as reference (Pelt et al., 2021)
Evaluated Properties	Prat et al., 2015)provides an hierarchy of evaluation criteria’s, and completeness, usefulness and Intention to Use were choose. The first is the core of our research question, how complete is the framework in given context, specially because it was created for an different context. The second, usefulness, because our research aims to contribute in practical terms, useful artifacts. Finally, intention to use a ultimate predictor of practical contribution.
Constraints	Obtaining respondents for our research will be a bottleneck, and also it will rely on low cost wide reach approaches to get then. Restricting the number of properties to the core is need to target an 20min duration data collection method to avoid dropout rates (BRANDTNER; HELFERT, 2018).
Evaluation Method	(Structure) Venable et al., 2012
Ex Ante	Expert Interviews (Pelt et al., 2021, ALBRECHT, 2021)
Ex Post	Quantitative evaluation of framework artifact survey (ALBRECHT, 2021)

​ Simultaneals, to find support for our methodology contributions, hence, it being our secondary goal, we found reference methodologies applied to other research projects that were used to define this project methodology..E

What design processes will be used to build the artefact? The design science research framework and the three design science cycles are used to build the artefact. The researcher also makes use of surveys/questionnaires to determine if all the requirements were met after a specific data model was chosen.

Interviews with subject matter professionals to evaluate existing artifact in context

WHY Interviews

Dimensions being evaluated: Perceived Completeness, Perceived Usefulness, Intention to Use

To evaluate the existing artifact, we used expert interviews

Among the forms of evaluation foreseen by this methodology, the proposal for the evaluation stage was to: xx. Its choice was due to … As a way of evaluating the DSR in IT artifacts, its application suggests a phase to explore the artifact and propose improvements in its design through..

​ We conducted an ex-ante evaluation of the existing artifact through subject matter professionals interviews to (1) understand how complete (2) and if is useful in real-world settings to represents their professional activity managing platform-products and (3) obtain suggestions for improvements and future work.

​ According to WIERINGA (2014), eliciting expert opinions using interviews is a useful research method in the conceptual stage of artifact evaluation. Interviews can be used as a primary data gathering method to collect information from experts about their own practices, beliefs, experiences or opinions (HARRELL & BRADLEY, 2009).

​ The interviews were conducted with an semi-structured approach, to have a guided conversation around the aspects we defined to explore the framework, but with flexibility to go off-script and bringing additional perspectives not necessary present in the framework itself. The interviews took place in virtual format through a videoconferencing tool, with recording and automatic transcription, so that the interviewer could keep focused on the conversation. It had a target length of 45min, with maximum 60min per interview.

​ The interview script is fully detailed in appendix A, and it comprehends of 3 sections : introduction, Context Awareness and Demonstration followed by Evaluation. The interview script had two dry-run sessions to ensure it was meeting it´s purpose, and improvements were made after then.

​ Professionals working in working in corporate IT organization where software in mainly to support of the company’s business operations, which we will refer as Subject Matter Professionals (SME) from now, who can reside anywhere in the world, who speaks English and who are currently working for a, at least in manager level which responsibilities including managing one or more platform-products for at least for 6 months. These criteria aimed to bring experienced professionals with a possibility of authentic critical vision.

Framework Improvement through qualitative data analysis

​ The qualitative data analysis followed the 6 steps suggested by CRESSWELL, 2014, as following: 1/ organize and prepare data for analysis, 2/ get a general sense and reflection by reading all data, 3/ detailed analysis in a coded way, 4/ build initial description from the coded material, 5/ Description and themes presented in the qualitative narrative, 6/ Data interpretation.

​ The interviews transcripts were codified into an hybrid coding strategy. Deductive coding was done using three different code types being attributed for all coding parts: framework section, evaluation dimension and element type. The inductive coding was used to organize insights not initially mapped, but relevant for the theme. We used an tool named “Delve” to make the coding and analysis.

​ The improvements in the artifact was made analyzing the data, interpreting what would be the modifications necessary to fulfill the comments, combined with the author previous literature review and experience in the theme and also with previous experience working with IT artifacts.

Improved Framework Evaluation though web based survey with subject matter professionals and potential beneficiaries of the artifact

Outline: Why survey? Benefits, Challenges, Target number of respondents?

To explain part of my choices I will use an an reference paper.

so he can navigate thought it using zoom in/zoom out and screen movement capabilities

​ We targeted to evaluate the modified artifact using an web based online survey, because it is a suitable method for evaluation studies (Siva et al., 2019), including evaluation of research designs, offering access to unique populations in very optimized research time usage at low cost (Wright, 2005).

​ Evaluating an framework via online survey poses an challenge of ensuring the respondent understood the artifact before responding to the survey which is the demonstration. An research project (BRANDTNER; HELFERT, 2018) studied an multimedia web based evaluation of artifact, in very similar settings, including, naturalistic, ex-post, evaluation of an artifact, which provided not only guidance for both designing the survey and the tool, but also design process knowledge about the method, described as key learning and recommendations, which were fully followed in survey tool design, but extended it with one specific aspect that was having the framework available to be reviewed all the time during the survey completion instead of presenting the questions without the ability to review the framework.

​ A customized survey interface (Figure SQF) was developed, and it included the following features: 1/ an introductory video with instructions of how to use the survey tool 2/ An introductory video for each framework to explain the framework 3/ in the screen with the survey question, the framework under evaluation was presented allowing the respondent to interact with the framework while being in the survey process.

Figure SQF - Screenshot of the questionnaire with the framework visible and interactable

​ Analyzing the challenges posed specifically for web based online survey (Siva et al., 2019), the ones considered to be the most do address where: a) difficulty to explain in detail the study objectives - addressed via the introductory video also having an channel were respondents could direct contact the researcher about the research objectives b) the inability to ensure the sample population is mainly from the targeted population: the survey required respondent to identify themselves using an LinkedIn account exactly to confirm if the respondent is part of target population based on his profile c) respondent creating bias by submitting the same responses multiple times was managed by restricting respondents to submit just one response, d) Poor response rate, a concern that was surpassed with the active engagement of the researcher in the social network in participating in professional groups (Siva et al., 2019) and interacting directly with potential respondents via networking.

​ The audience chosen comprehends in the the same subject matter professionals (SME) used for interviews in a earlier step, but also professionals that have interest in the research topic but with limited experience, which we believe could be the main beneficiaries of the designed framework. Software Product Management researchers also were invited. We assumed that this population are generally knowledgeable of computer and internet skills, since they are LinkedIn users, posing that no additional requirements would be needed to be considered in the web survey, due respondents attributes.

​ All participants of the first sample, representing the practitioners, plus researchers in the research field of study representing the “academia”, and finally random sampling to selected the potential users of the frameworks in the proposed context.=

Final research approach considerations

Ethical, Limitations

​ The research is a sequential mixed method study, qualitative followed by quantitative, which requires specific guidance for sampling perspective. According to (Onwuegbuzie, 2007), which states that sampling is typically more complex in mixed studies than in monomethod studies, sampling schemes for each method must be defined in conjunction, and the size of the sample should be informed primarily by the research objective, research question(s), and, subsequently, the research design. It also offers an 7 steps processed to help define the sampling, that followed generated the following specific definitions along the ones already declared previously:

• Purpose of mixed method: Expansion
• Sampling Design: Occasional Combination, Qualitative as non-random sampling and quantitative as partially random. The samples have an multilevel relationship, from an smaller to an wider sample
• First sample scheme: Started with critical case whose specific characteristics can offer compelling insight about the phenomenon of interest and evolved to an opportunist because they where convenient available and were willing to participate in the study.
• Recommended Sample Size - Interview - 12 participants
• Second sample scheme: Theory-based: The inclusion groups helps the researcher to develop a theory.
• Second sample Size - Causal-comparative, 51 participants for one-tailed hypothesis

​ In both data collections, prospective participants had informed choice whether to consent or participate. Participation in the research was conditional on reading and accepting the research terms which described how privacy, anonymity, and confidentiality were being treated, following ethical guidelines from the researcher academic institution and also from method literature references used (Siva et al., 2019, … ++++ do Interview)

​ It is important to recognize the limitations of Design Science projects, such as not producing artifacts that can, for example, be generalized. The focus of research is to identify “what is effective”, while other lines of research try to identify what to discover “what is true” (HEVNER et al., 2004). The tenets related to the research approach, specially in regards to sampling, are exposed and debated in the discussion section.

Results

RESULTADOS – 2000 palavras

Visão geral do capítulo, Abordagem qualitativa, Narrativa + trechos das entrevistas, Abordagem quantitativa , Análises estatísticas, Abordagem mista Narrativa + trechos das entrevistas, Análises estatísticas

VER: How to Communicate Evaluation Work in Design Science Research? An Exemplar Case Study

Describe how we organize this section.

​ In this section we report the results of our research aligned with the research methodology, where each of the research steps defined, will have it’s own results description.

Evaluate existing artifact in context

​ The results were presented following the guidance of (Shrestha et al., 2014), in two parts: completeness and the improvement plan based on usefully and intention to use comments.

Interviews Execution

• How I got into the people
• Summary of people
• How was the interviews, did they flow good?

Improved Framework The method do improve it… vectors, etc…. Survey Execution Survey data: data that were excluded? considered full responses… Survey Results Evaluate Design Process:

​ We ran twelve 1-hour semi-structured interviews with our SMEs. Table XX provides an summary of participants. Our interviewees were found by direct contact between the researcher and potential participants through the LinkedIn social network, not only because it is a social network dedicated to professional relationships, but also because it offers an adequate way to minimally validate the inclusion criteria. Recruitment was carried following prioritization: a) Contact with professionals who have a declared position as Platform Manager or equivalent; b) Contact with professionals who have a specific statement in their responsibility profile on the subject; c) Contact with people who have published, retransmitted or commented on content related to the theme that suggests some connection to the theme; or d) Post messages within groups related to the theme.

​ The goal were fulfilled our participants goal by only using criteria A and B, the other ones were not necessary. The population found by our criteria was very small, a, for example, returned 1900 people, which is around 1.5% of the results for an equivalent search for “product manager” . Direct contacts for contacts that did not had an common contact connection did not get any response. And, in two cases, an introduction was made by someone an common contact.

​ Only two respondents affirmed knowing an product management framework, but they were mentioning an scaled agile methodology. Almost all mentioned delivery methods as their framework for product management. There were groups that had more identification with the framework, while others mentioned “not real world”, out of our reality.

​ Once the person accepted to participated they signed electronically the an consent term and an calendar invite was sent with all preceding details necessary for the interview.

​ The interview script served the purpose to guide the conversation, it was enough to generate meanifull conversations and all interviews bought new perspectives for the work. None of the participants were aware of an product management framework, and the three ones that said they had, it was actually was an delivery methodology that potentially covers product management activities. One participant initially thought an framework as something that helps build the product, as framework is a term used to also refer to readily available structure that you can use to build software.

​ The interviewer ensured that all questions in the script were covered during the interview; however, related topics of discussion were permitted in order to increase the richness of the information captured.

​ He didn’t understand what a framework is (thought it was a technical framework)

Results of the Interviews: Key Dimensions of Utility Responses to the first set of interview questions provided motivation and shaping of the business and organizational problem our proposed artifacts address. Several key insights came out of this part of the interview. On average, the partici pants indicated the importance of historical, current, and future IT landscape analysis to IT investment decision making as 3.7, 4.6, and 4.5 (on a scale 1 to 5), respectively. (Table 6 provides summary statistics of numeric questions we asked in the interview.) The majority of participants (9 of 12) indepen dently noted that the staff and management of most IT consuming companies do not have the time or expertise to perform the necessary analysis of the IT landscape, and so they must outsource this process to third parties. Addi tionally, every participant independently noted the reliance of IT organizations on reports produced by the companies like Gartner, Forrester, and IDC. Multiple participants (6 of 12) also noted that current IT investments and partnerships play

Results of the Interviews

• The data that came out

adomavicius2008

Cresswell

At the specific level, some writing strategies might be as follows: • Use quotes and vary their length from short to long embedded passages. • Script conversation and report the conversation in different languages to reflect cultural sensitivity. • Present text information in tabular form (e.g., matrices, comparison tables of different codes). • Use the wording from participants to form codes and theme labels. • Intertwine quotations with (the author’s) interpretations. • Use indents or other special formatting of the manuscript to call attention to quotations from participants. • Use the first person “I” or collective “we” in the narrative form. • Use metaphors and analogies (see, for example, Richardson, 1990, who discusses some of these forms). • Use the narrative approach typically used within a qualitative strategy of inquiry (e.g., description in case studies and ethnographies, a detailed story in narrative research). • Describe how the narrative outcome will be compared with theories and the general literature on the topic. In many qualitative articles, researchers discuss the literature at the end of the study (see the discussion in Chapter 2).

​ All interviews transcriptions were loaded into an qualitative data analysis tool named Delve to gain productivity in the data analysis. The initially mapped code were loaded into the tool , and each of the transcripts were read a few types, coding text with tree dimensions: framework section, evaluation dimension and element type (deductive coding). While reviewing the texts, other relevant themes were identified, and new codes were defined for then (inductive coding), resulting in an hybrid coding strategy.

​ The final coding structured is presented in the Table X???

​ Our semi structured script helped to segment the conversations, to facilitate the coding. The framework section identifies the the part of the framework the conversation was about. The element type, is to classify if the comments into perspectives: needs to the the work (input), stakeholders needed to the work (stakeholders), how the work is produced (inner flow) and what are the products or the work (outputs). Coding these items required almost no judgment, while, defining which evaluation dimension and in the direction was the researched interpretation.

​ The results of our data analysis consolidated by the three evaluation characteristics are presented as an matrix table, following an DSR evaluation reporting structure (Shrestha et al., 2014), which argues that an matrix as an useful way to analyze qualitative evaluation criteria. The summary of the evaluation of the SPM framework is presented in Table XX.

​ Completeness was the item that received most comments. Data showed an lot of missing elements to properly represent the practice in their context. Few items, that

​ Contributions … any correlation, whose people did more opposed… any “tought” about it?

Framework Improvement

​ With the analysis of interview data, solutions were formulated in order to design a improvement framework. The solutions were associated to each comment to ensure to ensure coverage, and that became the improvement plan.

​ The body of knowledge generated are detailed in the discussion section, but, as for framework improvement, the outcome was defining design principles to guide the elaboration of the proposed framework, as presented in Table X:


​ The proposed framework was then designed, and it’s represented on Figure X. For the elaboration, the research had to ha previous knowledge on building frameworks and used ready templates available from Microsoft office. There was some introspective review cycles, reviewing all the transcripts and coded data, in order to ensure everything that could be fulfilled was present on the framework

​ After the elaboration, the framework was socialized the two SMEs that were not for a quick

Improved Framework Evaluation and Performance

​ In this section we report the results the web based survey to evaluate the the existing and the proposed framework. The survey was open for participation from May 23 to June 12, 2023 In total, 17 participants and five different countries completed our survey. Table XX provides an summary of participants, with additional details.

​ The participants had three clusters: 1/ interviewees of the qualitative phase that provided data to build the framework improvement (33%) - SME, software product management researchers or references (5.6%) - CONTROL, and then CIOs, IT Executives and IT Managers (55.6%) - TARGET , which we believe are the main beneficiaries of this research outcomes, that should be our target audience of the survey.

​ SME and CONTROL respondents were recruited by direct contact, while TARGET were recruited by post messages in social network groups related to the theme. We had no success via this channel, so we changed the strategy for inviting survey participants via networking groups.

​ Responses were considered valid when respondent matched the attention check questions, had overall response time minimum of 3 minutes and did not had spent less than 5 seconds to respond any of the questions, numbers that were stablished minimums based on response dry-run in fast mode.

Survey Results

​ The first analysis of the survey results refers to an statistical viewpoint of the data regarding reliability and validity. Our study is evaluation for generalization, but it is crucial do ensure our data is

​ (Include here the key reports for reliability and validity)

​ The second analysis of the survey results refers to understanding the perception results of each evaluated framework. The original framework received an average score of 2.5, 3.7, 4.0, for perceived completes, usefulness and intention to use, respectively, while the new framework had 3.7, 4.1, 4.4, which indicates that participants generally evaluated better the new framework. And further drill down on the Likert response distributions are presented in figure XX.

​ The modified framework has an clear indication of improvement on completeness, receiving +42% participants in the positive side, both in the agreement and totally agreement, while reducing the number of respondents that said negative extreme responses. Neutral respondents also reduced from 14% to 7%.

​ Both frameworks demonstrated are seen as useful for most of participants, with the new framework capturing 11% of the ones that did not consider it useful, and removing the neutral respondents.

​ Finally, intention to use had no neutral responses, or they are going to use or not, and both of then received almost equal positive evaluations, but the modified was 3% above and with more than half declaring strong agreement with intention to use, witch was 25% previously.

​ To further understand the results, we analyzed the numbers by making cohorts of the respondents clusters, showing the average evaluation response delta, modified minus original, for each response, as you can see in figure X.

​

​ SME had an relevant increase in completeness, and this can be explained because they provided the input for the modifications, and this indicate that their input were captured and applied properly. In terms of usefulness, SME the progress were lower than TARGET, there was not so much improvement.

​ TARGET group followed SME in direction, but with slight lower impact in completeness, small increase in usefulness, and almost same progress in intention for use.

​ Finally, CONTROL group, is the group that provides some type of evaluation in the direction of in what we are producing are inline with the theory, and unforthenelly, there’s disagreement with the progress.

​ We conclude the data analysis with the key outcome of the evaluation in this research: determine if there has been any progress. As intention to use is a measurement for practical contributions, and this research also comprehends providing this type of contributions, an hypothesis has been formulated to help measure the contribution: if I improve complexes and usefulness, would then lead to intention to use? Important to note that this hypothesis is the researcher attend to provide an reasonable key indicator for the progress.

​ By linear regression analysis, data from both frameworks were analyzed and an model accuracy has been determined, which is an way of assessing the performance of a model, predicting the number of classifications predicts correctly. In our KPI, means that complete and useful leads to intention to use, it’s practical. The results are show in figure XX, which provides an summarized evidence of progress made by the research.

Framework and Research Process Performance

Reached the objective?

What were the challenges?

The tool?

​ The first result is that the design process worked; By interviewing SMEs, we were able to produce and evaluate an artifact with an very optimized effort and evaluate it. Table XX.

​ Performance measures:

​ Multimedia presentation It was a problem, lot of dropout

​ Research promotion: we got an certain traction on bringing potential respondents, but they did not moved forward.

​ The survey participation was lower than what we expected, and some potential causes we outlined:

​ 1/ Limitations to respond: The survey only could be responded in a computer, by design, and that limits a lot the availably for people to respond iT. Some people that tried to respond in their corporate office

​ 2/ Reputation and the who is behind it… not having an official domain to run the survey, could appear like an Phishing scam

​ 3/ Awareness of the topic - why it would be important for then.

​

​ . It’s challenging.

​ Learnings…

​ Aenean blandit interdum est ac euismod. Mauris congue, nulla ut porttitor luctus, orci libero consequat tortor, id placerat libero lacus eu urna. Morbi pellentesque luctus tortor, nec finibus lectus tincidunt eu. Nam dapibus at lorem et varius. Praesent pretium pellentesque est, id consequat nulla dapibus sed. Cras velit odio, rutrum ut pharetra in, tincidunt quis urna. Phasellus et porta nisl. Duis quis gravida magna, laoreet pellentesque sapien. Aliquam erat volutpat. Integer suscipit mi vel aliquam vehicula. Praesent cursus auctor ligula quis ullamcorper. Praesent quis elementum turpis.

Discussion

DISCUSSÃO – 2000 palavras

Visão geral do capítulo

Contraposição teoria e resultados

Discussão 1, Discussão 2 … Discussão 5

Fechamento

It is important to keep in mind that every design science project requires a certain level of creativity.

Discussion topics:

• Using agile, need to invest product management? Is it conflictant
• framework, without prescribing an specific flow
• Management Research as a Design Science_Articulating the Research Products of Mode 2 Knowledge Production in Management

​ This sections brings discussion topics, organized in the following sequence: key Insights about software product management in the study context, broken down in the evaluation dimensions (completeness, usefulness and intention to use) and formulated definition for platform, the designed artifact and it’s relation to product management mean and finally the design process.

Prescriptive Knowledge generated about the context with the SME interviews

​ Academic management research generates knowledge that can be categorized as either descriptive or prescriptive. In the descriptive category, researchers describe and potentially explain a particular organizational phenomenon using independent variables. Descriptive knowledge is typically theory-driven and focuses on understanding existing situations. On the other hand, prescriptive knowledge is driven by real-world problems in the field and aims to provide solutions. It involves describing and analyzing various courses of action to address specific organizational issues. Based on the expert interviews transcript, we summarize the prescriptive knowledge while review one perspective of Software Product Management, represented by an framework, in comparison with what practitioners have been doing regarding the activities proposed.

Completeness

(+) Add to become more complete

(-) Remove, it’s not necessary to be complete with this

?? tava perdido, ver se eu vou conseguir reusar : Also, affecting all requirements, release, roadmap, product & Customer Market Analysis.

the state or condition of having all the necessary or appropriate parts.

​ The most preeminent theme, present in almost all interviews, was the representation of multiple views of customers for the platform. The customer definition goes way beyond “one” single element. First, each product that uses the platform is a customer-product. Each customer-product may have it’s own characteristics and needs, for example, they serve different businesses or markets. Beside that, knowing what customer is about for each customer-product, market and context they are into is highly relevant. An customer representation can also be internal or external. This increases a lot the point of input and analysis, as you can see in Figure X.

FIGURE X:

​ •External customer, and potentially it’s customers

​ •External customer, served by an internal customers

​ •Internal Customer

​ Other patent theme, was about funding: mapping what’s behind the investment in the platform, what are it’s objectives and results expectations; how the platform will be initially funded, and how it will resource sustained over time including operating and capital investments; how this is properly tracked. One simple illustration is considering an organization taking the decision to invest in a platform product to promote reuse and by so, capture cost economies of a few named products, where were calculated by an estimate on how much each of then are currently expending to run an maintain the functionalities proposed. Creating the platform is a journey, and the adoption requires effort, so it tends to be more a mid/long term investments and need to consider funding for so, and how to properly handle the funding needed, weather is a more corporate type of funding, fully funded by client products, and an combination over the two, that also can be modulated over time, eg, start with a corporate funding and then moving to a pure client funding. One example that came out from the interviews, were an payment an month fee to maintain the platform, where the platform should dimension it’s costs to that budget.

​ Also, comments denote the “power” funding has on prioritization, and while choosing each model, it also needs to evaluate it’s side effects on the platform objectives, like, serving better certain lines of business that put more money in the platform, that can be fair, unless it compromises the platform objectives.

​ Connected with the previous theme, it was said that as part of business case formulation to help guide the decision process in deciding to invest in a Platform-Product an Initial Planning is made with a set of information’s and artifacts that can include, but not limited to: Drivers, Potential Client Products, Roadmap, Requirements, Goals, Investments and Resources Plan, Funding approach, Intellectual Property aspects. This set of information was entitled in the modified framework as “Product Platform Mandate” and should be used as an baseline to evaluate the results of the investment.

​ Platform financial performance was also highlighted as elegant it should be treated equivalently to other company investments, reporting back. Over time, financial performance may be used to evaluate if the platform is still worth, while comparing it’s expenditures with alternative solution that can overcome the platform. As an example, suppose an vendor introduced an Content Management Systems platform that can replace the one the company has, and potentially, can enable the organization to reprioritize resource allocation to more urgent and business valuable activities. When talking about the financial performance, also, an capability that is often required is do determine the cost of running the platform with client granularity, so the client products also may evaluate the impact of using the platform. Depending on the decision rights settings the organization has, they also may decided to discontinue using the platform. Despite the fact to be part of the same company, platform products seen to operate in a very competitive perspective.

​ Connecting with the competitive perspective, some type of “client management” is also required, both to sell, drive adoption, managing expectations and prevent dropouts and alignment. Sell, because not all the cases described had the power to obligate adoption. Drive adoption, because even when somebody decided to use the platform, it needs to be prioritized in the product planning, and may require negotiation to use investing feature-time to implement the platform, that generally brings business mid-term results or even are pure technical debt related decisions, in which occupies band of potential shorter business impact. Managing expectations and prevent dropout was related to the fact platforms are software, and it may generate turbulence by quality perspectives, like bugs and incidents causes by mal functioning or unavailability, relative normal in building software. One of the responders related to an situation that first client platform had operational problems, and the information circulated among other teams, that increased the resistance to adopt, so this may intensify specially when the software platform is not mature, after all, you are delegating responsibility for your deliveries to another team. And finally, alignment, because it requires the teams to work together for delivering the promise. The most common expectation declared was the platform should make the client product cheaper.

​ Prioritization can be very complex. One example that came up was taking that there’s only room to accept one of two requests from different business; One of the business is the flagship business while the other an smaller, almost irrelevant, looking only for the business weight perspective, the first should be contemplated, but it may not be as easy leaving the other client, when, for example, they have annual event fair which is the most important event to lead fair which company participation requires that feature. prioritization is a source of conflict. As much relevant information to help prioritization, and may serve as input for planning, in the previous case, planning additional resources to increase delivery capacity. Prioritization permeates both release planning and

That brings the need for the software platform, not only having it’s own roadmap, but having an integrated roadmap, where it can stay connected with client-Products roadmaps and other time constraints (E.g., Company Key Dates, Regulation Dates, Technology Retirement, ..)

When producing the requirements list, it’s important that it already have priority’s… they denoted that conflicts may arise when priorities ties, find ways to untie. Qualified than are very important…

Colocar aqui tb… que a priorizaçao não é somente feita no release planning, … priorizacao já pode nascer no proprio feedback, mas tambem nos requisitos de produtos.

Produto A e B, juízo de valor. Dimensão de funding. Globopay vs Revista crescer.

​ The term market also seems to broad; which market, the context the software platform is into, example, observability platforms? Or market could be the market the core business of our organization is into.

Requirements

​ The ways you relate to each of the customer layers is also import and get input. It has highlighted that customer input need to be frequent and it may be present in all PM related activities, and, in addition to input, feedback is also vital and must be distinguished from input, because it represents the reactions for the outcomes of the inputs. Various forms of getting both customer inputs and feedbacks were mentioned, like contact Forms, Pre-Release Testing (e.g., Beta), Service Desk Tickets, Sales Interaction, Surveys, Direct interactions and Release Validation sessions. There are also methods that you can get information about the customers in indirect ways, like knowing what and how they are using your platform, witch includes adoption and usage analytics.

​ On trying to refine and evolve the platform requirements from just from an requirements validation is required and customers or potential customers may be a good way to increase the confidence of what you are defined is what they need and will use. It was cited discovery & validation sessions (E.g., Focus Groups, Design Thinking, ..). Also design activities that materialize aspects product, how the platform will look like, how it will be consumed, etc., are ways to increase value in the requirements phase with design, not only having the requirements gathered an analyzed, but also, with some degree of confirmation that there’s a good way to fulfill the requirements. One member highlights that one of the advantages they are seeing they software platforms is taking care of non-functional requirements, as an value proposition, specially are in a high regulated enviroment, and, it is expected for then knowing more about the requirements than the clients itself.

​ Talking about the role IT Organization plays in the context, much was said about functional areas like security providing requirements in form of standards or by providing valuable insights and validations, for example, enterprise architecture. The general advice is involve early and often these functional area in the platform evolution. Some highlighted that some requirements are simple not negotiable, specially non-functional requirements. It’s import also to gather information about the technology landscape life of cycle, for example, if the organization is considering discontinue or ban an certain technology. Platform Engineering is an technology static available to fulfill strategy needs, and so, it would be expected that it is taken at the IT Strategy level.

​ New stakeholders were suggested for organizational administrate functions like Legal, Compliance, Audit. They did not see the “board” so close to platform decision that could be replaced by an C-Level directing the IT Strategy seen to be more accurate via the business strategy.

​ As for inputs, they was also indication of need to have more interaction with the business areas, for example, joining their quarterly business reviews, in order to better assess the current and future potential business impact that the software platform can create, and also identify areas of opportunities. And definitely, being close to the delivery teams, as one exemplified they are always joint the client product planning activities.

​ In terms of other relevant inputs, knowing and setting customer expectations. Generally sales and marketing know what they can sell or need to improve to sell more the goods, services and or products of the company, that can provide insightful information about the business context, for example, knowing that one competitor is taking advantage of an certain technology, that, related to the software platform context.

​

Release Planning

​ An platform can be distributed to its client products in multiple ways: it can provided as an service, it an be an SDK that is “embedded” in a mobile APP, it can be shipped as an software package that somebody else needs to install. Here comes the need also to track the client-products lifecycle decisions, because some platform release may have some technology requirement to be used, for example, a minimum version of an operational system.

​ The distribution method, was then, related to operational aspects, what type of guidance and interaction required with the client-products, are then to end users, are then to developers, do they need assistance for designing quality assurance aspects of the end product, and if there’s an operational problem, who they should call.

​ Release does not necessaly mean “being used”, generating value.

​ Gerenciamento de versões, que clientes estão usando qual, existe alguma questão que deve ser contemplada.

​ Customer feedbacks need to be more pervasive, for example, going direct to the the requirements. More ways to capture feedbacks, not only expressed ones, but captuing it by instrumentalization of the processs (ex. feature analytics), and also running more especific engagements, co-creationg, best testing, …

​ ecosystem..

​ Capacitação posterior para adoção .. release notes.

​ The framework also demostrate to be determinist in terms of steps and flows, that makes sense, but not close to the “real world”, specially when agile methodologies are in place, the view brought is more an continua’s cycle, when inputs and outputs are continually happening…

​ Other thing was related to the fact that some PM artifacts are not managed outside the delivery methodology, for example, having one single backlog, that includes PM information and delivery information. An example given was that the PM writes the “Epics” with all atributes they need to keep that information organized, while the delivery manage the stories and thaks, but everything in a single place, just named backlog.

​ The same stakeholders suggested for inclusion in the previous step… can add important dates that should considering in the roadmapping.

​ For the roadmap… key dates… can be a regulatory, an event participation … or a sazonal business aspect, like blackfriday…

Also, dynamism around the stages… and

​ Gestão mais estruturada de backlog. Organização dos itens. DEEP → Detalhado, estimado, eee.. priorizado… Nivel de ordenação, e nível de detalhamento. Duas trilhas de Discovery, uma trilha de delivery. Detalhamento e refinamento backlog.

​ Inner Flow → the flow see , not considering inputs like dates imposed..

​ When envolve an external customer also… some way… when an request is made by an external customers…

Outputs→ Lista priorizada…

​ Talking specifically about release management, release gained a new perspective that is continuo release… sometimes you are “releasing” weekly, but just activating in another date… more responsability to PM to track whats release, and what’s being used…

​ Post-release feedbacks… adherence… adoption… training, roadshow…

​ Some way to put the product in the context, value chain also … an platform just exists because there are product, find an way that this can be more explicit. But at the same

​ Comunidade opensource.

​ Prometeu para algum cliente.

​ Roadmap connection with the product-ss and with the company key objectives

​ Selling, drive adoption. Thinking about how it’s consumed and how you can streamline

Usefullness

(+) Can add usefulness (-) Reduces the usefulness

able to be used for a practical purpose or in several ways.

Too prescriptive — Optional items — Outputs of PM artifcats — Terminology

Value added

• Proactivity

• Roadmapping connect with business results

In the core of the matters of PM and platforms:

• Outputs and steps required software platforms lifecycle decisions

• Missing the link with software delivery

• Stakeholders relevancy weighing

• Type of platforms and specific requirements:

  confusion decreases usefullness

Not here: Some of then mentioned requirements coming before the Roadmap.

​ In summary, usefulness was affected and/or could be improved in the following dimensions; 1/ being not too prescriptive, 2/ include value added product management activities, and finally 3/ increase representation of core matters for the context. Let’s explore the points, in detail:

• Less Prescriptive

  • How could parts of the framework be represented as optional. For example, the launch preparation may give an impression that the framework is useful for launching products, and may note cover other life cycle stages. Even if we consider “launch” as “release package”, it was mentioned that not all releases go to the customer, and the framework give the impression that is always that way. One mentioned that even release notes creation are skipped sometimes when both platform and product teams are working in very integrated way. Furthermore, the most recent release practices encourage Continuous Delivery, where features can be activated in different time of it’s delivery
  • Outputs of the PM artifacts are seem being more dynamic, they could be updated in more ways that then the explicit denoted. In the presented framework, not only the inputs for developing an roadmap is incomplete, that sometimes it’s development is incremental and influenced by all other activities. Another example is requirements, the product requirements can be seen as an big step, as all requirements could be determined all once to move once; instead, it should be worked in small increments, similarly to the “just-in-time” concepts, I work and refine what is close to be used for the next step.
  • Other aspect that drained attention, specially the ones that seem to have more mature agile practices related to some terms used in the framework, specifically in the requirements sections: instead of requirements, they call then features, which does not help on using it as an reference for conversations because the terminologies does not match. It can appear something “irrelevant”, but considering that agile is in certain way an evolution of traditional project methodologies, having terms used for methodologies that have been discontinued in the organization may appear to be something not in line with current ways of working

• Value Added

  • How to outline proactive activities that can anticipate decision making, to be ahead or something that is requested by an stakeholder
  • In regards to roadmapping, the key question on the execution of the roadmap is to show the value that the roadmap is generating for someone, that should be expressed in terms of metric being impacted, not only leading metrics, like usage metrics and with lagging metrics related to business impact, like cost, revenue and risk. One stated that “Roadmap speaks to product metrics, and product metrics states for business results”. While not having this represented, it turns product management more like an process to follow, than something that helps the organization create value

• More in the core of the matters of PM and platforms

  • When looking at the portfolio management section, they saw it very limited on represent the inputs and steps required software platforms lifecycle decisions, specially initiating an new platform.
  • When talking about the stakeholders, the current framework seems to put an equivalent weight in the stakeholders, and for then, some areas have more relevancy than others.
  • They also mentioned missing the link on how SPM framework integrates with software delivery methodologies. This one, can be explained in part because the framework comprehends only product planning activities in current comprehension of SPM scope. But, denoting this integration could be useful for better understand how it integrates.
  • On our sample, there were also variants on types of platforms, supporting business operations more closely, others more distant, focusing in providing non-functional requirements and/or technology driven, and the third group, functional platforms like data management that could be in between or the other two in terms of distance in business operations. Within these variants, complexities also vary, for example, when your platform has an SDK for Mobile Development requires different level of involvement and relationship with client products and their teams than an platform that is just consumed via APIs, no code integration. All of then should be represented in the framework in some way.

Intention to use

(+) Traces that can lead for reasons to use

(-) Traces that can lead for reasons for not using

The degree to which a person has formulated conscious plans to perform or not perform some specified future behaviour

​ The most preeminent part that showed a block for intention to use was questioning if software product management practice, partially represented by the framework, is needed when there are agile methodologies in place. The understanding put is that some agile frameworks like SAFe - Scaled agile framework covers the product planning. There’s a clear overlap, specially in the release planning part, and without the clarification of how product management fits and add significant value to an organization that uses it, lower intention to use was declared.

​ and respond to questions if there are overlaps or optimization opportunist like, if I this delivery methodology, can I consider I am already doing, what are the activities of SPM that area already being covered.

​ Going beyond, they also mentioned the importance the product management activities being integrated the closest as possible of the delivery team, acting as one team. The best example was about “product requirements”, which they see it integrated with what the delivery team call an “backlog”, combining all level of the details required. The term “product requirements” was also put not actual, they describe it as “product features”.

​ None of the participants said the framework is irrelevant, but some of then expressed that does not represent their real world. Some more thoughtfully details abouy it:

1. The inner flows of the framework seems too determinist, that everything happen sequentially; in fact, I may be receiving customer feedback now and working in requirements, tomorrow being in a release planning meeting to prioritize requirements to be on the release, etc. It’s very dynamic and much things may be happening at shorter time cycles.
2. Gathering, identification and organizing requirements are not enough to create successful products. The requirements need to be transformed into definitions that need to be evaluated. Furthermore Not all requirements will be requests. They referred to activities like experimentation, prototyping, hypothesis testis as ways to get for evaluation and refining. They consider this a critical step to ensure the requirements were properly understood and conceived into product definition with high success potential of fulfilling all stakeholders needs.
3. The framework emphasize a “order taker” relationship, common to early stages of IT Organizations, where business areas pile up their requirements and expect to receive back a valuable outcome out of it. Two noted changes toward a more productive and impactful relationship: first the stakeholders and technology working together for joint ownership, and second, the over time increase need in compromise that what they is being requesting will generate benefits for the organization.

​ And finally, the framework is unable to represents multiples realities. Putting some contextualized examples:

• Overall flow: One described that that requirements comes first than the roadmapping step. Some steps seems to be unnecessary for some situations, or are related to an specific product phase, like “Launch Preparation” that is when you are introducing the product in the market or has a new version launch. Most of the time, it will not happen.
• Stakeholders: Some said Sales & Marketing should be splitted, others believe there all multiple support team with different purposes. Other mentioned not seeing industry relevant stakeholder.
• Inputs/Outputs: The roadmap could represent the prioritize requirements and the business objectives associated with then.

Despite the fact scope we have selected for requirements and release, comments from other sections arrised.

3 cohorts

→ SME, that were interviews before

→ People in the field in study of product management

→ People in the IT Wordl

​ It’s clear the produced framework does not represent the full practice, but the process of building it, it generated details that can help researchers and PR actioners thing about it

​ Reason for choosing an ancient, primario… create space. It definially has its relevance, otherwise the conversation would not happen thhur it.

Software Platform Definition Proposal

​ As an intent to better outline the term platform, that is is broad, and multiple concurrent trends about it happening at the same time, an definition proposal has came out for outline the type of Software Platform were covered in this research:

​ “Software-based product or service are set of assets organized in a common structure, shared and integral part of one or more products, serving as a foundational element, on which other internal and, eventually, external parties, can use to build software products. These product platforms are intentionally created and maintained to increase overall value creation”. Adapted from Meyer and Lehnerd 1997, Gawer & Cusumano, 2013, Tiwana (2013, p. 5) , HARLAND; UDDIN; LAUDIEN, 2020.

Modified Artifact

​ The results indicated that the designed artifact progressed in terms of it’s objective of representing software product management in context, but without further details, it may still be seen as incomplete. This led to an idea of an version with additional details around it.

​ Looses and Wins…

Tenet

Representation, legitimation, integration and politics.

Design Process

​ The guidelines shown in Table 4 relate to this project as discussed next:

​ Hevner et al. (2004) suggested seven guidelines that can be used to evaluate design process in DSR. These guidelines were used in this research as shown in Table 4 to develop a framework to evaluate alignment with guidelines for an exemplar DSR project. With guidance of this guidelines, we promote an discussion about the design process used:

Design as an artefact. This project has resulted in an improved framework

Problem relevance. Within conversation with the experts, it was clear that the existing framework was not suitable, and some of then indicated that potentially an framework could help then better performing on that matter (no one used an specific product management framework as an refernce). It can be argued that within the speed of technology evolution and relevance inside almost any industry, advances on specificity how to make more use of technology for value creation is relevant.

Design evaluation. Three dimensions for evaluation were chosen , to capture information’s to measure the improvement made in the artifact in the research execution. We’ve used an DSR evaluation reporting structure proposed. As for research contributions, while defining and executing an research approach for improving an existing artifact, it can provide one specific reference for this type of research objective, specially the way an web survey was used to evaluate two different artifacts simultaneously.

Research rigout - The research approach includes a careful justification of each step using standard guidelines, theoretical insights and evidence from method specific research when available and from research projects when not. As part of the research project, the design, construction and evaluation of the design artefact has used established research frameworks and we referenced research projects that used then.

Design as a search process. This study is contributing to an ongoing evolution of product management practices, focusing on expansion of its uses in new contexts. An initial design, that is know that further evolutions were proposed, because of it’s simplicity that is related to early stage of it’s, but approached links with current litterer were made, expanding the horizons of reflection.

Communication of research. The research findings have been disseminated through academic and practitioner outlets.

Evaluation of the Design Method for evaluation

​ Overall, the using an web based survey for doing an framework evaluation were successfully, because XXX the data that shows it. This was possible, because of the availably of research about these steps.

​ At the research date, no other research were found providing an method to compare two district frameworks

​ An important finding is the benefit of including and planning participant recruit- ment at an early stage of evaluation approach planning. In the context of this study, we aimed to include experts from the field of innovation and product management, business development and strategic planning. If experts are to be reached by a survey or are to be included in the evaluation approach,

​ Restricts… computer… I personally does not use personal computer at night and it was reported by some that the survey was blocke.

Conclusions

CONCLUSÃO – 2000 palavras

Síntese: objetivo, método e resultado. Contribuição para o avanço do conhecimento / teoria, Contribuição para a prática, Limitações do estudo , Sugestões para futuras pesquisas

Highlights I want: Qual o secret sauce de PM, no contexto? What is the value of a framework?

Platform → The nee

Summing up, we summarize the

• Dependency mapping … an new platform version may need some upgrade or specific version in order to be used.
• Integrated Roadmap
• Product Capabilities & Features, integrated or embedded in backlog
• Know Problems and Issues Map
• Client versioning tracking
• Product Performance
• Financial Performance, especially product-development cost and
• product-usage cost
• Business Outcomes & Performance tracking and cost-benefit analysis
• Customer Facing Product Information, Use & Adoption Guidelines &
• Technology requirements
• Continuous communication
• Navigate on politics and organization
• dynamics and maintaining the product in the value creation focus

​ Thriving technology companies whose product offerings are software products or products with embedded software (product development), use product management to conceive and manage products. Product Management have gained overtime an specific line of research and Knowledge, called Software Product Management. Organizations whose their corporate IT organizations manages software to support it´s business operations, have been investing in Product Management as an way to improve it´s capability do translate business needs in technology solutions, and potentially create new businesses and ways to operate the business, specially because the emergence of digital transformation is continually changing the competitive landscape and this pushes emphasis on increasing technology investments and use as an strategy to compete. Applying Software Product Management in Corporate IT has different dynamics and research covering this theme is limited in contrast which seem an good research opportunity, since adoption of product management practices have been growing there.

Using platforms as an way for value creation is an strategy that was born in the manufacturing industry that have been explored

​ As IT departments seeks to continually become more agile, efficient, and customer-focused, platform-products may be an interesting option, as it can streamline development, increase scalability and flexibility, proportionate cost savings and promote ecosystem expansion. Ultimately, when done right, it enables to deliver high-quality products and services with reduced development cycles and costs, while fostering innovation and scalability. It’s also important to bring the downside of platforms, that they can go wrong in several ways; not being timeless to the opportunities to bring value, generate more problems than solutions for the client products, not having an appropriate funding model, client products rejecting to adopt for not loosing control that can be describe lack of confidence in the platform team to properly fulfill their roadmap needs, being subject to company wide linear cuts without considering the needs are some of the reasons that came our from the SMEs in the context of Corporate IT. This lies declared by the literature review of bringing more complexity.

​ In order to create successful platforms, Software Product Management is not only suitable but recommended approach (REF), and there are well know examples of the potential of managing then this way, like the AWS platform from Amazon, that first was created an an platform for Amazon business, but they were so successful in fulfilling the internal customers needs, that, they explored the possibility that they could do the same for others organizations, making AWS platform a business itself.

​ This work addressed understanding what are the specifies and nuances of software product management in IT organizations applied for management platform-products. What is required to properly manage platform-products in this context, beyond the existing practice? It’s know that an an platform strategy can generate many benefits, can also generate difficulties (LEHNERD; MEYER, 2011).

Contributions to the theory

​ The contribution for the theory is not the introduction of new theory, rather, is providing information’s about how professionals who are managing platform-products in IT Organizations perceive what is required to improve software product management practice, specifically product planning, in that context. This is an important contribution for researchers dedicated to evolve software product management theory and for researches that focuses on IT organizations. SME interviews were synthetized with all relevant aspects should be reviewed, better understood and evolved. Another contribution is that, the SPM Framework proposed by van der Weed 2006, despite being introduced almost twenty years ago, it was it presented as relevant for the purpose of discussing product planning activities, and received an representative evaluation in usefulness, despite being perceived as incomplete, which could raise the hypothesis of an certain shift in time between the adoption of Corporate IT versus organizations, which, indeed, seems logical, but can advance of other questions if they will be able to outpace the business needs for the competitiveness challenges, or even the level of transformation required.

by evaluating part-time courses taught in Brazil, while much of the theory on the impact of MBAs focuses on analyzing full-time courses in the United States. This becomes especially important as trends point to an increase in the number of students taking part-time MBAs, allowing them to reconcile with work and the growing importance of MBA courses outside the United States (ACITO; MCDOUGAL; SMITH, 2007).

and alumni perceive the impacts of MBAs on their careers, reinforcing the importance of subjective impacts in relation to objective impacts, in this evaluation, and the need to consider the individual’s perspective , in addition to the perspective of the organization. This is an important contribution for researchers dedicated to evaluating the impacts of MBAs on professional performance and on students’ careers. This study also adds to the theory by evaluating part-time courses taught in Brazil, while much of the theory on the impact of MBAs focuses on analyzing full-time courses in the United States. This becomes especially

Contributions to the practice

​ The modified framework provides added value for professionals in the study context who want to obtain knowledge about Software Product Management applied to platform products, helping then shape ideas, information, and principles that form the structure of an organization. Outcomes of the evaluation survey highlighted a strong perceived completion of the modified framework on top of an substantial improvement compared to the original, and confirmed by an other participants. In terms of usefulness, the research added incremental progress, and intention of use increase. Since the contributions were information rich and much beyond on what is suitable to include in a framework drawing, an version of the framework with guidance has been created to include as most relevant information we include, helping even more any person with the framework in hard to comprehend and discuss. And finally, the framework and the experts indicated increased propension toward them returning to the framework in future.

Contributions to the theory design science

​ As not only encouraged, but at the heart of design science, projects that use design science should contribute to the design science research. The project has two contributions for DSR, the first, the overall research approach, that seem to be uncommon in the aspect that we used an existing framework from other author to build upon, and because of that, we took as an assumption the awareness of the problem and move directly to evaluation step, and from data, worked on suggestions, development and evaluation again, taking the terminolyg (DSRR) as illustrated in figure X.

​ The second was the advancement of an research method. As stated by HEVNER & CHATTERJEE, 2010, that that every design science project requires a certain level of creativity, designing an customized tool that could operationalize the research settings, in the absence of an readily available solution that could fulfill represents the creativity applied to this research. The evaluation method worked for the research purposes, and ways to measure it’s performance were stablished, and it can be used for future design science research projects that need an method to evaluate two artifacts at the same time, the same way this research itself used other research methods from researches that had not developing an research method as primary objective, but as secondary outcome of the process.

**Limitations **

Sure, if a sample size of 100 or greater is achieved, we can use PLS-SEM and CB-SEM which are second generation statistical tests. They are explained in the videos I shared with you above

​ It’s important to node that, many comments may not be fulfilled by an framework alone, are themes that required practice discussion level.

Know that certain aspects are already part of the newer… but if I bring it to the table, I could loose the opportunity to capture the nuances

Yes, small sample size and limited context in addition to a strict timeframe and resources for large scale studies

Apesar de falarmos de alguns aspectos como roadmapping e portfolio management, eles náo faziam parte intencional da nossa coleta de dados, portanto, estão em diferente nivel de captura de dados.

​ Prescrive knowlege… thinks that came our, but without a clear measure of what is the coverage. This research does not have the intention to become the ultimate reference.

​ The comments that come out may be not all be related or exclusive to the context.

​ Their affirmations does not became thurth.

​ Despite the intent to do a global research, almost ssd of the participants, were from Brazil, which is a limitation.

​ This research comprehends an partial evaluation of what is proposed utility, quality, and efficacy of a design artifact must be rigorously demonstrated via well-executed. The framework cannot be considered “true”… it was based, it was evaluated but not not validated.

​ Concerning limitations, Wang et al. (2011), Manfio & Lacerda (2016) present their research disadvantages pertinent to participants. For Wang et al. (2011), the system’s evaluation was mainly about the perception of users about the system based on research and interviews, and it was used in a single case, limiting the research, making generalizations difficult. Manfio & Lacerda (2016) work are limited as to the lack of knowledge of the population of specialists who worked with product development projects, making it difficult to perform a more relevant sampling; that is, it was conveniently done due to the character itself. Food product development sector, which is restricted. Thus, in these two cases, participants affect the research outcome.

​ In seeking reference methods and research projects, the most common found were… starting for an artifact. .. not starting from an proposed artifact from other… but the literature does offer support for the approach (entry point,… life cycle). It is just important to highlight that this research operationalizes part of a regular Design Science project, assuming that the business problem and sss. Additionally evaluating something other research proposed is just valid because of the time, and a clear evolution of the subject itself, and the context, no type of “inconsideration”, rather, how, from that good starting point we can construct upon.

Even though the modified framework cannot be said as valid, the process of building it generated information’s that and an framework version from it, that can help researchers and software product management practitioners to thing about its Reason for choosing an ancient, primario… create space. It definably has its relevance, otherwise the conversation would not happen thhur it

Future work

they state that “The utility, quality, and efficacy of a design artifact must be rigorously demonstrated via well-executed

Agile How to operationalize roles…

Using agile, need to invest product management?

Generate more data if agile frameworks are enough to do good product management

Evaluate the framework in other dimensions:

• Efficacy – the degree to which the artefact produces its desired effect;
• Validity – the degree to which the artefact works correctly.

Insight - Estudo futuro, frame para ajudar a decidir fazer ou não um produto plataforma.

​ How to properly select the pieces that will be placed on the shelf and that, once used, are troublesome to change? How do you anticipate product needs in order to design a part that can be used readily and thereby increase product success? How to help justify the investment in a piece, with information about what it does and what it solves? Once a product depends on a platform-product, part of its evolution is also linked to the ability of the platform-product to evolve, so its conception, while generating many benefits, can also generate difficulties (LEHNERD; MEYER, 2011):

​ Support executives do access the potential return of investments, in value, financially, including risks.

​ Different serrations, new need, existing needs, dehidtrating,…

Original Background: [X] Technical - [ ] Other

Industry: Real State Brokerage Size: Small Area in Functional Structure: [ ] IT [ ] Other: _______________

Type of platform-product: [ ] Application [ X ] Data [ ] IAM [ ] CIAM,…

Make or buy: [ ] Make [ ] Buy [ ] [ X ] Various, more customize than make

Platform ownership: 100% custom, OpenSource,.. 100% acquired

Stage of the platform: [ ] Planning [ ] In operation

Organization size

Research Method →

Additional information

References

Bibliografia

3 a 5 seminais

5 a 20 relevantes

20 a 30 complementares

Appendix

Anexos

Roteiros de entrevistas

Questionários

A, B, C, D, E, F, G, H, I, J, K, L, M, N, O, P, Q, R, S, T, U, V, W, X, Y, Z

Appendix A - Semi-structued Interview Protocol

1. Introduction - Introduce the research project, confirm acceptance of the informed consent term, familiarize the interviewee with the concepts being used in the research, specially what we me mean by “platform-product”, give one example of platform-product.
2. Context Awareness Question: We wanted to ensure that the member could elaborate his experience around platform-products and get to know if he knows, and potentially used, product management frameworks.
3. Evaluation: The overall framework were introduced and informed that the scope of the research is limited to Requirements Management and Release Management parts of the framework. Each one were showed alone, and the interviewee was asked to share his thoughts about it, if that part of the framework represents what he practice. To guide the conversation, the interviewee was oriented to consider the elements of the framework: stakeholders, inputs, outputs and the overall. The process was repeated for both sections, and then, an overall framework summary were presented by element (eg. stakeholders) to provide an different view angle of the framework.

Section - Introduction

Q1 - Given the informed platform-product definition, could you describe a platform-products that you manage or have managed?

We elaborated an script that had five sections: 1) the interviewer presented concepts to make sure the terms used are leveled and an real life example 2) Question to confirm and qualify the subject matter expertise and to explore if they use or know an framework for the topic 3) Presented the Requirements Management section of the framework, asking the interviewed to share your comments and observations on inputs, inner flow, outputs and stakeholders 4) Repeated the previous step but with the Release Management section 5) presented the framework broke down on the following views: General Flow, Stakeholders, and Inputs/Outputs, asking for review and comments.

Appendix B - Customized Survey Tool Details

​ The process occurs as following: the user receives an weblink. Clicking to it, leads to an landing page with introductory text about the research and the consent terms. The acceptance of the term is combined with the authentication via LinkedIn, by proceeding he acknowledge acceptance. One small video presents him the overall process of the survey, specifically that he will do two equal surveys, but referring to different artifacts. Each survey starts with an introductory video explaining the framework that will be evaluated and and interactable image of the framework remains accessible during all the survey. Also, when he enters into an survey question, the part of the framework related to the question is automatically highlighted, to reinforce what the question is referring to. The questions are presented in a 5-point Likert scale ranging from 1 (Strongly disagree) to 5 (Strongly agree). and an additional comment box for qualitative comments the respondent may include. In the end, we present an final comments box to capture overall feedbacks, both about the process of evaluating the artifact and the artifacts under evaluation.

Appendix C - Survey