Towards Reasoning About Pivoting in Startups and Large Enterprises with i*

Abstract

Many start-ups fail, or are abandoned, due to flawed reasoning underpinning their products, business models, and engines of growth. Similarly, many strategic initiatives in large enterprises fail, or are decommissioned, because they are predicated on faulty assumptions that do not comport with reality. The lean start-up and lean enterprise approaches encourage decision makers to test their fundamental hypotheses and effect strategic pivots to identify new and superior fundamental hypotheses. This paper presents a model-based approach to support reasoning about strategic pivoting. It outlines key constructs from the i* modeling language that can be used to model various pivot types. Experience with a real-life application provided a preliminary validation about the benefits of modeling to support pivoting. The case study demonstrated how this approach can be used to compare alternatives for pivoting as well as to generate further ideas for alternative pivots.

1 Introduction

Modern enterprises operate in dynamic environments where technologies and relationships undergo rapid and continual shifts. This requires enterprises of all sizes to assess and adapt their fundamental hypotheses on an ongoing basis. Changes to an enterprise’s product, business model, or engine of growth that are catalyzed by disproving of their fundamental hypotheses are referred to as pivots [1,2,3]. Pivoting is useful for effecting strategic redirection in many situations such as when new competitors enter the market; novel substitute products are launched; key suppliers exit the market; technologies disrupt an industry; as well as when laws and regulations are changed. Due to high opportunity costs of scarce resources – mistakes and errors by an enterprise, within a competitive industry that is undergoing disruption, can be fatal. Pivoting can help enterprises of all sizes to validate their assumptions, logics, and hypotheses.

A catalog of ten types of pivots was identified and popularized by Reis [1] (Table 1). In this paper, we follow the naming and description of pivot types by Reis [1].

Table 1. Catalog of ten common types of pivots (Source: Adapted from Reis [1])

Ries [1] promotes the notion of Lean Startup [2] which encourages decision-makers at startup companies to pivot their products, business models, or engines of growth if tests disprove their fundamental hypotheses. He [1] notes that “Lean Startup approach can work in any size company, even a very large enterprise, in any sector or industry.” Owens and Fernandez [3] relate the principles of Lean Startup to large enterprises by promoting the notion of Lean Enterprise. They assert that executives of large corporations should adopt the practices of startup entrepreneurs to innovate more productively [3]. Humble et al. [4] share this view and encourage the application of lean approaches for managing enterprises of all sizes. They argue that lean approaches typify scientific and systematic problem exploration and solution experimentation to arrive at better decisions and judgement [4]. Edison [5] proposes a conceptual framework for implementing the Lean Startup approach within an established corporation to manage the venturing process. Gbadegeshin and Heinonen [6] studied the relevance of the Lean approach in the context of small and midsize enterprises (SMEs).

Ries [1] argues that a start-up or corporate venture may need to pivot multiple times and may also need to execute multiple pivots quickly. Pivoting affects an enterprise in significant ways because it establishes new fundamental hypotheses for its products, business model, and engines of growth [1]. Thus, the stakes are high if an organization executes an incorrect pivot or executes a required pivot incorrectly. However, there is a dearth of enterprise modeling (EM) support for evaluating or designing strategic pivots in enterprises. A structured and systematic approach for analyzing pivots can be valuable for decision-makers in startups as well as large enterprises because it can help them to identify and generate relevant pivots as well as ways of implementing those pivots successfully.

We present an EM approach that supports the representation of pivoting in a systematic and structured manner. We discussed the concept of pivoting and its relevance for startups and large enterprises. We outlined ten archetypes of pivoting from the Lean Startup approach [1]. We propose generic pattern models and offer abstract representations of select archetypes of pivoting from this catalog. In the main section, we present a model showing various types of pivoting options that are available to a healthcare software (mobile application) startup. We also share the results from validating our approach for modeling of pivoting. We indicate research in the EM literature that pertains to modeling of strategic management concepts. We conclude by noting our key findings as well as laying out future work related to this line of research.

2 Towards Modeling Pivoting in Startups and Large Enterprises with i*

EM research on pivoting in startups and large enterprises is sparse. However, EM researchers have proposed several approaches for representing and reasoning about business strategy. Kim et al. [14] offer a modeling approach to represent a value chain of a virtual enterprise. Giannoulis et al. [15] present a unified language for modeling of strategy maps. Pant and Yu [16] propose preliminary models of coopetition between organizations as well as competition driven by contention over resources. Cardoso et al. [17] proffer methodological guidelines and a hierarchical architecture to model various kinds of goals in organizations. Svee et al. [18] associate the concept of consumer value to strategy maps and balanced scorecards (SMBSC). Pijpers et al. [19] apply a value modeling language, e3Value, to demonstrate the alignment between the organizational strategies of an Internet company and its information system. This paper presents an innovative EM approach for expressing the impacts of the external aspects of an enterprise (such as its relationships) on its internal facets (such as its objectives and alternatives).

Johannesson [20] notes that enterprise models can be of many types such as value, process, and goal models. Value modeling languages are useful for articulating economic transactions such as monetary exchanges. Process modeling languages are useful for representing workflows such as sequences of activities. Goal modeling languages are relevant for depicting graphs of intentionality. Additionally, actor-oriented modeling languages are relevant for expressing dependencies between actors. Some key criteria for modeling pivoting can be extracted from Table 1. Then the sufficiency of typical value, process, goal, and actor modeling languages for meeting those criteria can be preliminarily evaluated. This extraction of requirements and preliminary appraisal of EM languages is based upon the intuitions and experiences of the authors.

An examination of Table 1 reveals that the key requirements for modeling of pivoting include the ability to represent the concepts of value (e.g., economic, non-economic), resources (e.g., data, physical), stakeholders (e.g., enterprise, customers), objectives (e.g., goals and qualities), and relationships (e.g., between stakeholders). Additional requirements for modeling of pivoting includes the ability to depict hierarchies (e.g., of needs, requirements, offerings), alternatives (e.g., choices, options), impacts (e.g., consequences, outcomes), conditionality (e.g., prerequisites, obligations), and temporality (e.g., time, sequence). By reducing pivoting to these constructs it is possible to select an EM language that is suitable for modeling pivoting. An EM language for modeling of pivoting needs to be expressive with respect to these constructs.

Different EM languages satisfy various abovementioned requirements for modeling of pivoting. Value modeling languages typically focus on the portrayal of value (e.g., objects, exchanges, etc.) as well as stakeholders (e.g., actors, customer segments). However, they do not cover the objectives of the stakeholders or their relationships that are not directly value-oriented. Process modeling languages generally focus on the depiction of activity flows at operational or tactical levels rather than strategic levels where pivoting occurs. They usually depict associations between stakeholders in transactional terms rather than relational terms.

Goal modeling languages typically focus on the objectives (functional and non-functional requirements) of a stakeholder as well as on alternatives (operationalizations) and their impact (contributions) on objectives. Actor-oriented modeling languages focus on the expression of relationships between stakeholders. They are useful for showing the alternatives and resources that are available to stakeholders for pursuing their objectives. None of the widely-used EM languages directly satisfy each of the abovementioned requirements for modeling of pivoting.

In this paper, we adopt i* for representing distinct types of pivots in startups and large enterprises because it meets many of the criteria for modeling pivoting that are listed above. i* is a goal- and actor-oriented socio-technical modeling language [8]. It can be used to express stakeholders as distinct actors, objectives as goals and softgoals, relationships as dependencies between actors and resources as physical or data entities. Additionally, it supports Means-ends decomposition to show alternatives, contribution links to show impact of alternatives on quality objectives, and label propagation to show goal satisfaction or denial. Core i* does not support the articulation of conditionality and temporality. Overall, i* is suitable for modeling pivoting because startups and large enterprises are fundamentally human enterprises (i.e., socio-technical entities) that exist at the confluence of people, process, technology, and organization.

The key elements of i* are actors, goals, tasks, resources, and softgoals. An actor is an entity comprising the characteristics of autonomy, sociality, intentionality, strategic reflectivity, abstract/physical identity, contingent boundary, and pursuit of rational self-interest [9]. A goal is a state of affairs in the world that an actor wishes to achieve, a task is an alternate way of achieving an end, a resource is a physical or data entity that is required for completing a task, and a softgoal is a quality objective that is considered to be achieved or denied solely from the perspective of an actor. i* is explained in [10].

The primary relationship types in i* include means-end decomposition, task-refinement, and dependencies. Means-end decomposition links a goal with any of the tasks that can be used to achieve it. A goal can be achieved through the achievement of any of the tasks that are associated with it. Task-refinement links a task with its components such as sub-goals, sub-tasks, sub-softgoals, and resources wherein each of the components need to be satisfied for that task to be completed. Inter-actor dependencies link an actor that depends (i.e., depender) on another actor (i.e., dependee) for something (i.e., dependum). These types of relationships in i* support the depiction of strategic rationale (SR) of an actor as well as its strategic dependencies (SD) with other actors.

The characteristics of i* that make it useful for expressing and evaluating pivoting in startups include means-ends reasoning; task-refinement and elaboration; inter-actor dependencies; distinction between concrete/abstract actors (i.e., agents, roles, positions); and actor associations. Additionally, the semantics and notation of i* are helpful for articulating and analyzing pivoting requirements that are listed above. Figures 1, 2 and 3 present i* SR diagrams representing abstract patterns for four types of pivots. Core requirements for modeling each type of pivot as well as the corresponding features of i* are discussed below.

• Zoom-in/Zoom-out: Modeling zoom-in/zoom-out pivots requires the ability to show products on offer as well as bundles of those products on offer. Representing a zoom-in pivot requires the ability to express products in a bundle being offered by themselves. Conversely, expressing a zoom-out pivot requires the ability to depict multiple products being combined and offered as an amalgamated bundle. Zoom-in/zoom-out pivots can be shown in i* via means-end decomposition and task-refinement. Figure 1 presents abstract i* models of Zoom-in/Zoom-out pivots.

  As shown in Fig. 1, a focal actor’s product/service features can be represented as goals that can be chained in a hierarchy of tasks, sub-goals, and sub-tasks such that a higher-level goal represents composition and aggregation of features and functions. Similarly, a lower level sub-goal represents decomposition and refinement of higher level goals (i.e., features). Goals and tasks are interleaved to show the purpose of a feature (i.e., goal) as distinct from its implementation (i.e., task). In Fig. 1a, upward pointing arrows depict examples of zoom-out pivoting while, in Fig. 1b, downward pointing arrows represent examples of zoom-in pivoting. The inability to represent temporality in i* hampers the expression of time-dependent aspects (e.g., factors that can accelerate/decelerate a zoom-in/zoom-out pivot) of the model.

• Customer Segment: Central to the modeling of customer segment pivots is the ability to show distinct stakeholders (e.g., enterprise, customer) and their relationships. Representing a customer segment pivot requires the ability to express a shift from one objective of the enterprise to another and the impact of that shift on customer segments. Value propositions for the customer segments can be represented as goals/softgoals that are mapped to the customer segments via inbound dependency links from the enterprise. Similarly, the objective that the enterprise wishes to achieve (e.g., payment) by serving its intended customer segment can be depicted as outbound dependency links from the enterprise. Value propositions are depicted as goal/softgoal dependencies because they can be satisfied by various kinds of value exchanges. i* models can be used to show objectives that are satisfied by different types of value exchanges. This approach to modeling is complementary to modeling of value exchanges (e.g., via e3Value) because this higher level depiction provides the rationale behind value exchanges that can be represented in more detail in value exchange models.

  As shown in Fig. 2, two customer segments can be shown as distinct actors with specific dependencies on the enterprise. An enterprise (A ₁ ) has two distinct customers (Customer ₁ and Customer ₂ ). It can satisfy the dependum (S ₁ ) of Customer ₁ via its value proposition (G ₂ ) or it can satisfy the dependum (S ₂ ) of Customer ₂ via its value proposition (G ₃ ). When the enterprise (A ₁ ) decides to switch the customer segment that it wishes to serve (i.e., from Customer ₁ to Customer ₂ or vice versa) then it can do so by switching the value proposition that it delivers to the intended customer segment (i.e., from S ₁ to S ₂ or vice versa). The inability to express conditionality in i* hinders the depiction of enabling/disabling mechanisms (e.g., factors that can impel/impede a customer segment pivot) in the model.

• Customer Need: A modeler needs to show the objectives of various stakeholders (e.g., enterprise, customer) for modeling customer need pivots. Representing a customer need pivot also requires the ability to express a shift from one objective of the enterprise to another for serving different needs of its customer. This can be expressed in i* by modeling the intentional structures of multiple actors as well as dependencies between those actors. Specific value propositions for a customer can be represented as softgoals and can be mapped to the particular goals of a customer via inbound dependency links from the enterprise. Similarly, the objective that the enterprise wishes to achieve (e.g., payment) by serving an intended customer need can be depicted as outbound dependency links from the enterprise. Since the same product can be offered for different customer needs under different terms and conditions – rather than offering products an enterprise offers value propositions with respect to distinct customer needs.

  As shown in Fig. 3, two customer needs can be shown as distinct goals with specific dependencies on the enterprise. An enterprise (A ₁ ) has a customer (Customer) with two distinct needs (G ₅ and G ₆ ). It can satisfy the dependum (S ₁ ) of Customer via its value proposition (G ₂ ) or it can satisfy the dependum (S ₂ ) of Customer via its value proposition (G ₃ ). When the enterprise (A ₁ ) decides to switch the customer need that it wishes to serve (i.e., from G ₅ to G ₆ or vice versa) then it can do so by switching the value proposition that it delivers to the intended customer need (i.e., from G ₂ to G ₃ or vice versa). A focal actor’s decision to execute a customer need pivot must consider the impact of that pivot on its own targets and not be motivated merely by a desire to meet additional or different customer requirements. The inability to depict quantities in i* hampers the representation of economic topics (e.g., reason for offering one value proposition over another) in the model.

  Similar abstract patterns for remaining pivot types as well as instantiated examples of these decontextualized representations were omitted from this paper due to space constraints.

• Value Capture: The ability to show distinct options of achieving specific objectives and the opportunity costs of each option are necessary for modeling value capture pivots. Representing a value capture pivot requires the ability to depict change in the objectives of the focal enterprise from one way of achieving its value capture objectives to another. This can be represented in i* via means-end decomposition and task-refinement as well as contribution links. A product’s features as well as their respective value inputs to the revenue stream can be represented as softgoals. These features and value inputs can be related to each other via contribution links. Equally importantly, the impact of features on value inputs of other features can also be related via contribution links. This information can be used to compare groups of features to evaluate the optimal bundles of features for achieving the value capture goals of the business. The inability to perform quantitative reasoning in i* can encumber the analysis of economic actions (e.g., amounts of value captured through various activities might be different) with the model.

• Engine of Growth: Modeling engine of growth pivots requires the ability to show distinct alternatives for achieving various growth-related objectives and the tradeoffs between those alternatives. The ability to express a shift within the focal enterprise from one way of achieving its growth-related objectives to another is necessary for representing an engine of growth pivot. This can be represented in i* via the expression of goals and softgoals as well as means-ends and contribution links. Objectives of the business (such as growing market share, increasing revenues, and boosting margins) can be represented as goals and softgoals. The alternatives for achieving those objectives (e.g., paid, viral, sticky engines of growth) can be expressed as tasks. The impact of these alternatives can be portrayed via means-ends and contribution links. This information can be used to compare the impact of different alternatives on the current and future objectives. Moreover, as tasks can be decomposed it is possible to explore their strategic, tactical, and operational details to design blended engines of growth. The inability to represent temporality in i* may deter the expression of time-dependent aspects (e.g., are certain engines of growth faster/slower than each other) of the model.

• Platform: A modeler requires the ability to show multiple stakeholders and their relationships in order to model platform pivots. The ability to articulate a change from one objective of the focal enterprise to another as well as the impact of that change on its stakeholders is needed to represent a platform pivot. This can be depicted in i* via strategic dependencies between different types of actors (such as customers, brokers, resellers, co-sellers, etc.). In the case of a product, the relationship between the focal actor (i.e., business) and the customer can be shown via direct dependencies. Here, the customer depends on the business directly to meet its product needs while the business depends on the customer directly to meet its economic needs. However, in the case of a platform, customer and the partners can have direct or indirect dependency relationships with the business which is the platform operator. Here, the customer depends on the other actors (i.e., partners) directly or indirectly to meet its product needs while the partners also depend on the customer directly or indirectly to meet their economic needs. This information can be used to analyze whether more of its own objectives are served when it functions as a product vendor or as a platform operator. The inability to perform quantitative analysis in i* can hinder the comparison of product- or platform-orientation (e.g., amounts of value generated by product and platform might be different) via the model.

• Business Architecture: The ability to show the goals of a focal enterprise is a starting point for modeling business architecture pivots. Representing a business architecture pivot requires the ability to express a change from one goal of a focal enterprise to another as well as the impact of that change on its various needs. This can be shown in i* via the use of goals and softgoals as well as means-ends and contribution links. The objectives of a business architecture (e.g., maximize quantity, maximize price) can be represented as goals as well as softgoals. The impact of different alternatives for achieving those objectives can be compared using means-ends and contribution links. This information can be used to analyze the impact that each alternative has on the currently selected objective and the prospective candidate objective. The current alternative may be equally suitable for serving both the present and future objectives or it may only be suitable for either of these in which case other alternatives may need to be considered. The inability to perform quantitative reasoning in i* can hamper the evaluation of various objectives of the enterprise (e.g., amounts of value created by price or quantity maximization might be different) from the model.

• Channel: A modeler requires the ability to show stakeholders as well as their relationships to model channel pivots. A channel pivot entails a shift within from one goal of the focal enterprise to another as well as the impact of that shift on other stakeholders (e.g., customers, distributors, etc.). This can be depicted in i* by articulating strategic dependencies between different types of actors such as customers, brokers, resellers, co-sellers, etc. A channel can be depicted as the chain of dependencies from a focal actor (i.e., business) to a customer. Dependencies between the business and its customers without any intermediary actors can be thought of to constitute a direct channel. Whereas, if the business and its customers have dependencies with mutual intermediaries but not each other – then these can be regarded as constituting an indirect channel. This information can be used to reason about whether the benefits of using intermediaries (e.g., business softgoals of revenue scaling, market penetration, etc.) are outweighed by the vulnerabilities of a hold up problem. The inability to express conditionality in i* can hinder the expression of enabling/disabling mechanisms (e.g., factors that can support/undermine a channel pivot) in the model.

• Technology: The ability to show the goals of relevant stakeholders (i.e., enterprise, customer) as well resources (e.g., hardware, software) is necessary for modeling technology pivots. A technology pivot changes the mechanisms that are required to better serve the needs (e.g., innovation, differentiation) of a focal enterprise. This can be modeled in i* via softgoals, tasks, resources, and contribution links. Technology alternatives can be represented as tasks as well as its resources and product features can be depicted as softgoals. The impacts of alternate technologies on product features can be shown via contribution links. Substitutive technologies (i.e., those that can be used to do the same thing) can be identified by finding tasks with similar contribution links to common softgoals. The impacts of different technologies on the overall bundle of features can be used to select the future technology. The additional softgoals that are supported by the future technology compared to the past technology can be regarded as sustaining innovation. Resources can be used to show the building blocks of technology alternatives. The inability to represent temporality in i* may deter the expression of time-dependent aspects (e.g., can certain technologies be commercialized/monetized sooner/later than others) of the model.

Fig. 1.

Abstract i* model of (a) Zoom-out and (b) Zoom-in pivots

Fig. 2.

Abstract i* model of customer segment pivot

Fig. 3.

Abstract i* model of customer need pivot

3 Case Study: Instant Messaging Application for Healthcare Practitioners

To test the use of i* modeling to support pivoting, we applied i* modeling to a real life case study. The case concerns a software startup in Toronto that is facing pivoting decisions. The company offers an instant messaging service to healthcare practitioners. Its Founder and CEO is the third co-author of this paper. Models were constructed in collaboration with the CEO of the company. They were elaborated by the first author in consultation with the CEO and were also validated by the CEO.

The main stakeholders in this case study are the messaging service provider (i.e., vendor), managers of a healthcare facility (i.e., administrators), and practitioners at that facility (i.e., end users). The vendor offers an instant messaging service that is used by doctors via a mobile app. The need for such a mobile app exists because some healthcare facilities do not offer an instant messaging system to doctors while some offer a system albeit one that is inconvenient, complicated, or impractical for use by doctors. As a workaround, many doctors use public consumer mobile apps for communication (e.g., WhatsApp, Dropbox) that is non-compliant with privacy policies.

3.1 Considerations Relating to the Use of Instant Messaging Services

Doctors that use publicly available instant messaging services can be categorized into three groups. These include plain text messaging users, multimedia messaging users, and power users. Plain text messaging users use the short messaging service (SMS) built into their mobile phones to send and receive text messages. Multimedia messaging users exchange photos, videos, and audio via public consumer chatting tools (e.g., Skype, Viber, etc.) on their smartphones. Power users share data from medical systems (e.g., patient records, pharmaceutical reports, etc.) via public consumer tools (e.g., Dropbox, Slack, etc.) on their tablets. The usage of these tools is non-compliant with privacy regulations. Each category of users has different requirements for instant messaging services that correspond with their usage scenarios.

This heterogeneity of messaging tools within a healthcare facility creates many redundancies and inefficiencies for the doctors that use them. This also exposes administrators of those healthcare facilities to legal risks and uncertainties due to potentially non-compliant behavior. For example, in terms of users, a doctor may need to install multiple messaging apps on a mobile device to communicate with other doctors that use those specific apps. Similarly, messages sent in one app may not be compatible with other apps and this may slow down knowledge sharing. With respect to healthcare administrators, confidential data about patients or proprietary details about the organization can be accidentally disclosed and unintentionally exposed. Leakage of sensitive content can make administrators vulnerable to legal liabilities as well as diminish the reputation and goodwill of their institution.

This reasoning suggests that, an instant messaging service must meet the needs of many stakeholders to be accepted by the administrators and adopted by the medical practitioners in a healthcare facility. In some cases, these needs may converge such as in the case of quick delivery of messages because that is a feature that users would like and a function that the administrators would approve of. However, in many cases, these needs may be contradictory or even mutually exclusive. For example, users may want a service that can be used to engage in free flowing “off the record” watercooler discussions that are outside the purview of administrators. However, administrators may demand a service that supports logging of all messages for monitoring compliance with relevant statutes and auditing abidance with pertinent protocols. Designing an instant messaging service that satisfies such an intricate latticework of requirements, encompassing those from users and administrators, is a complex undertaking.

Additionally, while satisfying the requirements of users and administrators, the provider of an instant messaging service must also fulfil its own requirements. For example, the provider may wish to grow its revenues, generate margins, and run on income rather than investments. The achievement of these objectives is necessary if the instant messaging service is to become self-sufficient, sustainable, and solvent. This added set of requirements further obscures and obfuscates the design of an instant messaging service. However, an approach for systematic and structured representation and reasoning about the diverse intentions of myriad parties, and the relationships between them, can be helpful for elaborating and refining such a design.

3.2 Towards Modeling Select Pivots in Instant Messaging Service

It is imperative for the decision makers at the startup, that is the subject of this case, to spend its marketing and sales (M&S) budget properly. It operates with limited financial resources and thus its operational goals include economizing as well as increasing its return on M&S expenses. It dedicates the bulk of its M&S budget towards segmenting the market, targeting buyers based on their personas, and positioning its service in a way that is appealing to those personas.

The goal of its M&S activities is to encourage its prospects and intended customers to try and buy its instant messaging service. This is a resource intensive endeavor because it requires the company to research the market, identify buyer/user personas, elicit requirements for each persona, prioritize and target personas, build value propositions for selected personas, and advertise their service to chosen personas.

Positioning value propositions to selected personas is an example of a niche strategy and is attractive for companies with limited budgets because their financial resources might be insufficient for targeting the whole addressable market. This is also a productive approach because by using it a company can build concentrated value propositions that focus on the specific needs of chosen buyers/users.

These are more likely to result in engagement than generic advertising claims that are not directed at anyone in particular. The main personas of interest to this startup include administrators of healthcare facility including Chief of Medical Staff (CMS), Chief Privacy Officer (CFO), and Chief Technology Officer (CTO) as well as intended users of this service which include users of plain text messaging, users of multimedia messaging, and power users. Each of these personas have different requirements including some that conflict.

Figures 1a and b present partial i* SR diagrams of instant messaging service provider. Figure 1c presents an enlarged view of a section of Fig. 1b to draw attention to the representation of pivots. The overall model is spread over two diagrams (Figs. 1a and b) to simplify visual presentation. The dashed lines in the bottom left corner of Fig. 1a and top right corner of Fig. 1b can be linked during interpretation to obtain a full depiction of this model. As these figures show, the instant messaging service provider has a choice of positioning its value propositions to administrators of healthcare facilities (i.e., sell its enterprise tier) or its intended users which are medical practitioners (i.e., market its basic tier). To drive adoption among its target user community, this company must cater to their needs. At the same time, to get acceptance to deploy its service in a healthcare delivery facility, this company must also meet the requirements of the administrators of that facility. This startup has two possible go-to-market strategies which are top-down (market to users and then create an organic demand for acceptance) and bottom-up (sell to administrators and then require adoption by users). Since this startup has a limited M&S budget it can only adopt one of these strategies in at the beginning (i.e., target either user or administrator persona). If needed, this startup can implement a customer segment pivot to focus on the other persona after testing its fundamental hypotheses underlying the originally chosen persona.

Figure 4 shows customer segment pivots using a dashed arrow. The dashed arrow shows that the Messaging Service Provider can switch from offering its value proposition from enterprises to users or vice versa. By analyzing the contribution links to its softgoals the Messaging Service Provider can assess the impact of such a pivot on its quality objectives. It can also review the impact of its customer segment pivot on the dependums that are satisfied for various stakeholders through label propagation. For example, if the Messaging Service Provider pivots from its approach of Market to users to Sell to enterprises then it must focus on its service features such as data encryption, message logging, service level agreement, and mobile device management.

Fig. 4.

Partial i* SR diagram of messaging service provider

Figure 5 shows zoom-out/zoom-in pivots while Fig. 6 shows customer need pivot using dashed arrows. The downward dashed arrow in Fig. 5 shows that the Messaging Service Provider can switch from offering its XMPP application within a multi-protocol chat service to offering it as a standalone application (i.e., zoom-in pivot). Conversely, the upward dashed arrow in Fig. 5 shows it can merge that XMPP application into a multi-protocol chat service rather than offering it as a stand-alone application (i.e., zoom-out pivot). XMPP is typically used on Android OS and can be delivered in a dedicated application for those devices or bundled with other protocols in a multi-protocol chat service.

Fig. 5.

Partial i* SR diagram of messaging service provider

Fig. 6.

Partial extended i* SR diagram of messaging service provider

The dashed arrow in Fig. 6 shows that the Messaging Service Provider can switch from offering an SMS compatible application to offering an APN compatible application. By changing the protocol that is supported by its application the Messaging Service Provider can change which customer need is met by that application (i.e., customer need pivot). Power users that wish to access a chat relay using their phone are not able to do so if the SMS protocol is not supported. However, power users that wish to use iOS devices for chatting are able to do so if the APN protocol is supported. This shows that product/service choices made by the Messaging Service Provider impact the needs of the customers that are served by those products/services.

4 Discussion

In this paper, we asserted that modeling can be used by decision makers in enterprises to represent and reason about the fundamental hypotheses underlying products, business model, and engines of growth. Despite the ubiquity and impact of pivoting in the industry there is a shortage of EM support for design and support of pivoting. Therefore, a structured and systematic EM approach for reasoning about pivoting can be a valuable tool for decision support within enterprises. This is also because the absence of such an approach can expose decision makers at startups to risks and costs from mistakes and omissions.

We proposed a model-based approach for modeling of pivoting and validated it in a mobile app startup. The Founder and CEO of the software startup that is featured as the case study in this paper noted that modeling of pivoting supported his decision-making in four main ways which include: (1) comparing pivoting options in an objective and unbiased manner, (2) contrasting existing pivoting alternatives as well as generating new options for pivoting, (3) planning/forecasting empirical tests of pivots before committing to them, and (4) grouping pivoting advice from mentors and advisors into themes of recommendations and suggestions.

He noted that he found many aspects of i* modeling to be supportive of pivoting. These include the ability to represent the concepts of resources, stakeholders, objectives, and relationships. Additional requirements for modeling of pivoting includes the ability to depict value, conditionality, and temporality. i* was able to meet many of these requirements fully or partially and a few of these requirements none at all. The only addition to i*, in this paper, was the use of the dashed arrows for indicating the transition from Before (As-is) to After (To-be) configurations. The analysis was provided based on the underlying concepts of pivoting and the model was annotated with dashed arrows to highlight pivots. Without extending i* it was demonstrated that i* could provide various analytical capabilities to reason about pivoting.

i* was found to be limited in three main respects with respect to modeling of pivoting. These are its inability to support temporal, conditional, and quantitative reasoning. i* does not support the notion of relative or absolute time but both concepts can be relevant in analyzing pivoting. One condition that necessitates pivoting is when an enterprise spends money faster than it takes in via income and investments. This is referred to as its burn rate and if an enterprise does not pivot quickly enough then it can go bankrupt. So, time is an important dimension for reasoning about pivoting because it can be used to analyze whether pivoting is a necessary option for an enterprise. Moreover, the amount of time that an enterprise has to be able to pivot can determine which type of a pivot it can execute. For example, a product pivot may take more or less time for an enterprise than a customer segment pivot. Without being able to represent the time dimension in i* means that it is difficult to identify which of these pivots are viable. Tropos offers real-time linear temporal reasoning support by extending i* [11].

i* does not support the notion of conditionality but an enterprise may only be able to execute a pivot after certain requirements are met. Without being able to show the preconditions for pivoting it can be difficult to fully understand the feasibility of pivoting. One or more pivots might be prerequisites for a particular type of pivot. Therefore, an enterprise may need to execute a combination of pivots albeit in a certain order. For example, an enterprise may first need to implement a zoom out pivot in order to implement a customer need pivot or it may need to execute a platform pivot in order to implement a customer segment pivot. Without being able to represent such conditions in i* means that it is difficult to show the prerequisites of pivots. Some researchers have combined BPMN and i* to depict conditionality in process flows [12].

i* does not support quantitative reasoning but it can be relevant in analyzing pivoting. Reasoning about certain types of pivots is especially dependent on the concept of economic value. These include business architecture pivot, value capture pivot, and engine of growth pivot. In each of these pivots, different economic objectives are evaluated in quantitative terms. For example, they may need to exactly measure the attainment of numerical targets (e.g., revenue, margin). While the attainment of these metrics can be represented in i* in binary terms (i.e., as goals), their partial attainment cannot be depicted practically. Without being able to reason about quantitative aspects of pivoting in i* means that it is difficult to analyze the economic impact of certain types of pivots in a precise manner. Goal-oriented requirements language (GRL), which is a derivative of i*, offers various types of quantitative reasoning support [13].

5 Conclusion and Future Work

This paper provided an overview of modeling pivoting by startups and large enterprises. It proposed EM requirements for key types of pivots. It also presented abstract patterns and decontextualized representations of select pivot types and applied some of these to a case study. Experience with a real case study provided validation about the benefits of modeling to support pivoting. Future work on this research will include the validation and verification of this approach in the industry. Early validation will be conducted via published case studies of pivoting by startups and large enterprises. Subsequent verification will be performed via empirical case studies in partnership with startup entrepreneurs and decision-makers at large enterprises. A focus of this verification will be on the usefulness of this EM approach for entrepreneurs and decision-makers within startups and large enterprises as well as consultants and advisors that are commissioned to guide and monitor strategic pivots in a variety of enterprises. We will consider extending i* to address more fully the needs for pivoting (e.g., quantitative, temporality, conditionality, etc.). However, we wish to do so by balancing richness and complexity in our models of pivoting.