Software start-ups have embedded themselves in the economic zeitgeist as drivers of innovation and growth. 'Unicorns', such as Facebook, Uber, Pinterest, Dropbox, and Palantir, have ably demonstrated the market disrupting and industry transforming potential of upstarts that 'punch above their weight class'. These successful businesses began as start-ups and matured into enterprises with multi-billion dollar valuations even though most start-ups fail or are abandoned within a few years of founding. A notable reason for the failure or abandonment of many start-ups is erroneous logic and faulty assumptions underpinning their products, business models, and engines of growth. The lean start-up approach encourages decision makers to test their fundamental hypotheses and effect strategic pivots to identify new and superior fundamental hypotheses. This paper outlines exploratory research into the modeling of strategic pivoting using i*. It discusses the key concepts that are relevant for developing a framework for analyzing strategic pivoting in a structured and systematic manner using i*. Such a framework can support decision-makers in start-ups to test the fundamental hypotheses underlying their products, business models, and engines of growth.
Ries [
Ries [
ments of a customer segment and thus it is assimilated into another product whereby the original product becomes a feature in the larger product.
is different from the customer segment that it was targeted to and thus that product is positioned to a customer segment whose needs its satisfies.
by monetizing features individually or commercializing functionality holistically.
ing market share, increasing revenues, and boosting margins.
Feasibility pertains to the ability of a start-up to initiate a pivot. Some pivot types, though attractive, may not be possible because the start-up is not capable to start them. Desirability refers to a start-up’s interest in undertaking a specific type of pivot. While a start-up may be capable of undertaking a type of pivot– it may not regard that type of a pivot as being suitable for it at that time. Viability refers to the ability of a start-up to successfully complete an on-going pivot. A start-up may commence a pivot but may not be able to finish it properly due to mismanagement. If adequate caution is not exercised in planning or implementing pivots then it can have deleterious impact on that start-up.
Towards Modeling Pivoting In Startups With i* There are certain general characteristics of i* that make it useful for expressing and evaluating pivoting in startups. These include means-ends reasoning; refinement and elaboration; strategic dependencies between actors; distinction between actors, agents, roles, positions; and actor associations. Additionally, the semantics and notation of i* are helpful for articulating and analyzing pivoting techniques that are listed in table 1. Features of i* that are especially relevant for each type of pivot are discussed below. i* Strategic Rationale (SR) diagrams representing abstract patterns for four types of pivots are included below. Similar abstract patterns for remaining pivot types could not be included in this paper due to space constraints. The following diagrams only depict unidirectional dependencies (i.e., from customer to vendor) to simplify visual presentation. We have also omitted some goals and tasks within each actor or role for brevity and have shown this via a break in dependency links. • Zoom-in/Zoom-out: i* supports the portrayal of decomposition and refinement as well as contribution and dependency links. Figure 1 presents an abstract i* model of Zoomin/Zoom-out pivots. A focal actor’s (i.e., start-up) product (PrdX) features (FtrX) can be represented as softgoals that can be chained in a hierarchy such that the topmost softgoal represents a product. The objectives of a customer (RqtX), which is represented as another actor, can be expressed as softgoals which can be related to the focal actor’s product via dependency links. These dependency links can be to the product as a whole or to constituent features of that product. This information about the dependency of particular user requirements on specific product features can be used to inform the analysis of the start-up’s impact of offering distinct features as discrete products (zoom-in) as well as of combining multiple features into a consolidated product (zoom-out). In figure 1, solid (blue) downward arrows depict examples of zoom-in pivoting while dashed (red) upward arrows represent examples of zoom-out pivoting. Arrows depict examples of pivots among products. •
Make CLoinntkribution Break CLoinntkribution SWatiesafikcleyd WDeenaikeldy Role
Figure 1. Abstract i* model of Zoom-in/Zoom-out pivots Customer Segment: i* supports the representation of goals and softgoals within the individual scopes of various actors. This allows an analyst to group customers by their needs where customers with identical needs are represented as a segment. The support for actor associations (e.g., ISA, Plays, etc.) also make it possible to represent sub-segments of customers where customers share certain needs in common while maintaining their unique Rqt1 Rqt1a
Rqt1b Rqt1a1
Rqt1b1 Rqt1a2
Rqt1b2
Means-End Link Denied Is part of Link
Role
Customer Vendor
Ftr1 Ftr1a
Ftr1b Ftr1a1
Ftr1b1 Ftr1a2
Ftr1b2
Legend Actor Actor Actor Boundary
Prd1 Prd1a Prd1b Prd1a1 Prd1b1 Prd1a2
Prd1b2 Goal Goal
Softgoal Softgoal
Task Task
Resource
Resource Help Contribution
Link
Hurt Contribution
Link
Satisficed identities. Figure 2 presents an abstract i* model of Customer Segment pivot. This information can be used to reason about the requirements (RqtX) that different groups of customers have for a product and to build customer value propositions (VPrX) based on product offers (OfrX) that are relevant to meet those requirements. In figure 2, arrows portray examples of pivoting amongst customer segments.
Vendor
Ofr1
Ofr4 Ofr2
Ofr3 Ofr5
Ofr6
VPr1 Vpr2 Vpr3 Vpr4 Vpr5 Vpr6
Rqt2
Rqt3 Rqt1 Rqt4
Customer Segment 1 Customer
Segment 2 Rqt5
Rqt5
Customer
1 Customer
2 Customer 3 •
Value Capture: i* supports the portrayal of decomposition and 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.
Engine of Growth: i* supports the expression of goals and softgoals as well as meansends 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.
Platform: i* supports the articulation of strategic dependencies between any kind 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 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 only have direct dependency relationships with the business which is the platform operator. Here, the customer depends on the other actors (i.e., partners) indirectly to meet its product needs while the partners also depend on the customer 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.
Business Architecture: i* supports the expression 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.
Channel: i* supports the articulation of strategic dependencies between any kind 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.
Technology: i* supports the portrayal of softgoals, tasks, and contribution links. Technology alternatives can be represented as tasks 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. 4
Section 3 offered possible methods applying i* to express and evaluate strategic pivoting by startups. There can be other approaches by which i* can be used to represent and reason about pivoting. While many aspects of i* make it an attractive modeling language for articulating and analyzing pivoting – it is also limited in three main respects in its ability to support such an endeavor. These include lack of support for temporal, sequential, and quantitative reasoning. Our future work is concerned with addressing these limitations as well as further developing the ideas discussed in section 3 prior to testing and validating them. 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 the burn rate of a startup (i.e., the speed with which it is spending its financial resources) exceeds its income and investments. If a startup 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 or not pivoting is a necessary option for a startup. Moreover, the amount of time that a startup 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 a startup 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. i* does not support the notion of precedence or subsequence but both concepts can be relevant in analyzing pivoting. A startup may only be able to execute a pivot after certain conditions are met. Similarly, it may only be able to perform other actions after it has pivoted. Without being able to show the sequential preconditions for pivoting it can be difficult to fully understand the feasibility of pivoting. Moreover, a start-up may need to execute a combination of pivots albeit in a certain order. For example, a start-up may first need to implement a zoom out pivot in order to implement a customer need pivot. Without being able to represent the sequence dimension in i* means that it is difficult to show one pivot as a prerequisite for another pivot. 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, market share). 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. 5