Software startups are more popular than ever and growing in numbers. They operate under conditions of extreme uncertainty and face plenty of challenges, underlined by their high failure rate. Using Design Science Research, these challenges were investigated. A literature study showed that in recent years, several authors have suggested ways to increase the odds of succeeding as a startup, such as customer focused development, fact based decision making, pivoting and agile/lean thinking. Interviews with industry professionals showed that few used these Lean Startup practices: many found them difficult to implement in practice. In response, we developed the Early Stage Software Startup Development Model (ESSSDM) for managing early stage software startups by applying Lean Startup principles. The model is novel in that it supports managing a portfolio of product ideas and provides clear criteria for when to move forward with product ideas, when to abandon product ideas as well as recommends what concrete techniques that can be used and when, in order to achieve this. The process was instantiated and evaluated on a startup project in an incubator setting.
New software companies are started each day, and emerging technologies such as
smartphones, cloud infrastructure platforms and enhanced web development tools
have made it even quicker and easier to get started. However, contrary to what the
media portraits, far from all startups succeed, i.e. only one in 58 turn out successful
[
During the early 2000’s, agile software development methods [
The contribution of this paper is twofold. First, it presents a validated process model that manages a portfolio of ideas, whereas existing approaches focus on one idea. Second, the model provides a detailed approach to handling individual ideas with clear stage gates and exit criteria that provides much more guidance than existing approaches.
This paper is structured as follows. First, we outline the research method, followed by background and related work with respect to product development in early stage startups. Then we present the findings from interviews with nine existing startups and the problem statement, followed by the section that presents the ESSSDM model that presents the key contributions of the paper. Next we present the validation of the model using a case study, followed by the conclusion of the paper.
Design Science Research (DSR) was chosen as the primary framework for the
research. DSR differs from traditional research in that it focuses on learning through
design, i.e. the construction of artefacts. The act of designing is, within DSR, used as
a research method or technique [
Takeda, et al. [
Being iterative, the model allows for moving back and forth between phases. If new information emerges during the development of the artefact, phase one and two can be revisited, and a new or modified suggestion formed. Similarly, during phase four, if evaluation criteria are not met, phase three is revisited and the artefact improved.
DSR was deemed a good fit due to the context of the research project. With the authors taking part in the forming of a startup, the design of an artefact aimed at mitigating typical challenges and problems were seen as highly relevant. Furthermore, the close proximity to a real-world startup meant the artifact could be rapidly iterated over/evaluated.
Awareness of problem. The research questions investigated were (1) What are the typical challenges and problems in early stage software startups? (2) What solution would serve to mitigate the identified challenges and problems?
Suggestion. A generic literature review was conducted, focusing initially on agile practices and in later iterations on Lean Startup theory. In addition, semi-structured interviews with industry professionals were carried out. Although an interview guide with template questions was written, structure was kept loose so that discussions were free to go in new and interesting directions. Abductive reasoning based on the literature and the interviews led to a set of problems (see chapter 5) and a suggested solution in the form of a process.
Development and evaluation. During the deductive stages, data was gathered mainly through participatory observation and reflective journals. The process was built for and evaluated on the aforementioned startup project. Revisits to the suggestion phase were frequent. In total, the process saw three major revisions, and multiple minor ones.
Emerging technologies such as smartphones, cloud infrastructure platforms and
enhanced web development tools have made starting a company very easy. However,
only one in 58 newly started companies is successful [
Over the last decade, several agile software development methods have been
developed, but Scrum [
Agile development processes are solution focused. That is, they are mainly applied in situations where the problem is well known/understood but the solution is not. In a startup context, however, uncertainty is even greater: both problem and solution are typically not well understood. For the software engineer working in a startup, however, being focused on the solution is often not enough. A product is more than a solution, it is a business model, and in a startup the software engineer is often involved in both business and technical development efforts.
This customer and problem focused thinking has been advocated in the past by
people such as Steve Blank [
In his book The Four Steps to the Epiphany [
Ries published The Lean Startup in 2011 [
The Build-Measure-Learn (BML) loop describes the concept of validated learning. Ideas are turned into products by building them, data is gathered by measuring how products are used by customers using various techniques, and new ideas can then be formed from what is learned by analyzing the data. One major iteration through the feedback loop constitutes a potential pivot. By reducing the time it takes to get through the BML loop, time between pivots can be reduced, and the odds of success increases.
Ries suggests treating this process of validated learning as if one were a scientist: by applying the scientific method and thinking in terms of learning experiments. By formulating falsifiable hypotheses (statements that can be proven wrong by empirical data) learning objectives can be defined up front. By running experiments, hypotheses are validated (proved valid/invalid), by analyzing the data typically leading to the formulation of new hypotheses.
The Lean Startup suggests many techniques for speeding up the BML loop time. One of them is building a Minimum Viable Product (MVP). An MVP is typically the first version of a product released to customers, and should contain only the absolute minimum in terms of features and design for it to become viable to the customer, i.e. it solves the customer’s problem.
Running Lean [
Nine software startups in the Gothenburg region were interviewed using a semistructured format, both from a business and a software perspective. The purpose of these interviews was to get a good understanding of how software startups typically work in the early stages, and if any patterns, processes or best practices could be observed.
For each startup, the following will be discussed: (1) Context. Size of company, area of business, technology platform, type of product. Where the idea originated from. (2) Development practices. Business and software development practices. How the company conducts its operations. (3) Problems/challenges. Things that are viewed either as problematic or challenging when running a startup.
From a software development perspective, all companies used agile practices, especially Scrum and Kanban. From a business development perspective, a few companies were aware of Lean Startup methodologies and worked in that manner, but most were either unaware or found it difficult to apply in their situation. Some did, however, follow principles similar to Lean, without necessarily labeling it so. That includes working closely with customers and pivoting towards product/market fit.
Of those not following Lean Startup practices, few worked actively with validating product concepts early and often with customers (trying to pinpoint underlying problems) before building and scaling a solution. In some cases this was due to products and business models having been copied from existing ones, to be applied in different contexts/countries, thereby reducing uncertainty and the need for extensive validation. Also, the opinion was voiced that Lean Startup is difficult to apply in situations where the product is depending on a network effect. In such cases, scaling before reaching product/market fit might be necessary.
Startups that did put a lot of effort into understanding underlying problems either followed Lean Startup or created new products, i.e. not copying existing ones. Those same startups had also pivoted the most.
Many proclaimed to be data-driven to some extent, keeping close track of various metrics. Even so, most strategic decisions were based on intuition and gut feeling. Many dabbled in A/B testing of their user interfaces, but this was mostly viewed as an optimization technique. No one A/B tested features. Those following Lean Startup did perform experiments according to the scientific method but admitted it was difficult to base strategic decisions on data alone. Thus, there is still ways to go before startups are truly data-driven, or apply fact-based decision-making.
It became apparent that there is an early-stage process not heavily discussed in the literature, where different product ideas are weighed against each other before a decision is made on what product to develop. This often happens prior to the forming of the company. A structured approach to tackle this task seemed to be lacking. Some startups brought this early-stage idea selection process further, by actively investigating multiple ideas in parallel even after forming the company.
Startups are run in many different ways and there are many different types of startups. On the software development side, all companies adhere to agile methods, but on the business development side, few agreed upon best practices could be observed. What all can agree upon, however, is that it is difficult to work in an organized and structured manner in an early stage software startup.
Lean Startup principles significantly reduce the uncertainty that surrounds startups
and increasing their success rate. These principles, however, are rather philosophical
in nature and hard to put into practice. This was confirmed by the interviews:
entrepreneurs either were not familiar with the concepts or had a hard time
implementing them in their companies. Although some authors, e.g. [
In response to the identified challenges, we have developed the Early Stage Startup Software Development Model (ESSSDM). The model extends existing Lean Startup approaches, incorporates the results from interviews with entrepreneurs as well as is based on earlier experiences with startups by the authors. The process is defined in a clear step-by-step fashion with clear exit criteria for each stage. In addition, the model presents guidance concerning the techniques and practices to employ during the different stages. Moreover, the process supports multiple product ideas, constituting a product idea portfolio, being investigated in parallel by a team.
The overall process is comprised of two major levels. On the topmost level, managing product idea portfolio, one develops hypotheses concerning potential problems to solve, drafts up rough business models and documents these in a prioritized product ideas backlog. On the second level, a product idea is picked from the backlog and is validated systematically using the Build- Measure-Learn (BML) loop until the product is deemed scalable, put on hold or abandoned.
Typically when creating a startup, a product domain is selected and frequently the team has at least one product idea. Independent of the specific initial product idea, the first task is to generate additional promising product ideas. Ideas can be crude; the rest of the process is designed to iterate over an initial (crude) idea and improve upon it. Often, it is worthwhile to investigate multiple ideas in parallel as it allows for more than one person involved in the startup and because it decreases the risk of an overly emotional connection with a specific idea. This increases the odds of finding an idea worth pursuing.
Typically, ideas spawn instantly or emerge over time. A product idea contains, as a
minimum, a problem or collection of problems that need solving. One of the primary
techniques is to organize exploratory interviews with potential customers in the
domain. The selection of interviewees should be influenced by:
• Areas where the entrepreneur has domain knowledge
• Copying and tweaking an existing (successful) product
• Problems experience by the entrepreneur (scratch your own itch) [
In order to compare product ideas, it is important to document these in a comparable
format, e.g. Lean Canvas [
When an idea is picked from the product ideas backlog, it undergoes systematic validation. This process can be described as a feedback loop comprising risk prioritization and BML looping. The product idea moves through four stages, each with its own activities and defined exit criteria. The four stages are: (1) understanding the problem; (2) defining the solution; (3) qualitative validation; (4) quantitative validation. Each stage is associated with different sets of risks. Risks are prioritized and put on a risk backlog. With risks identified, assumptions (falsifiable hypotheses) can be formed and tested using the BML loop. The learning that is gained from validating the assumptions is fed back into the product idea and the risk backlog. By doing this, risks can be dealt with one by one, through the stages, until the product is deemed scalable, or until a risk becomes blocking and the product idea invalidated.
During the first stage of testing the plan, focus lies on gaining a deep understanding about the problem and who experiences it. The key risks during this stage are: (1) do we have a problem worth solving?; (2) who experiences this problem?; (3) what competition is there? Before proceeding to the next stage, at least half of potential customers should give a positive indication of the product idea. Also, the team should identify a promising customer segment, find at least one problem that customers want solved, as well as build understanding of how customers currently solve the problem.
In this stage, the purpose is to define a potential solution and communicate this to potential prospects. When defining the solution, the team focuses on the simplest possible solution to solve the problem: the MVP. The key risks during this stage are: (1) what is the minimum feature set for the MVP?; (2) who are the early adopters?; (3) what would customers pay for the solution?
In order to move to the next stage, the team interviews a minimum amount of potential customers, has identified a typical early adopter, has defined a MVP, has confirmed that customers are willing to pay for the product, has verified that the solution is feasible to implement within a realistic time horizon, as well as has secured a test user base for the product.
The purpose of the third stage is to develop an MVP and launch it to early adopters in order to verify that it solves their problem and that they are willing to pay for it. Key risks are: (1) Does the MVP demonstrate a Unique Value Proposition (UVP)?; (2) Are early adopters willing to pay?; (3) How to sustain an influx of early adopters?
During the fourth and final stage the product is launched to a larger group of people, including non-early adopters. The key risks are: (1) Do people want the product?; (2) How to reach customers through inbound channels?; (3) Will the business model hold? This stage marks the beginning of the scaling phase.
ESSSDM was evaluated as part of a startup project at the School of Entrepreneurship at Chalmers University of technology. The following evaluation criteria were considered: • The process must be perceived as practical by project members • The process must support working on, or investigating, multiple product ideas in parallel, as part of an idea portfolio • The process must provide clear guidance on when to move product ideas forward through process stages • The process must provide clear guidance on when to abandon a product idea • The process must provide clear guidance on what techniques to use and when, while validating product ideas
The project group consisted of five students: three business developers and two software engineers, working in an incubator setting. The incubator provides office space and business advisors. As of this writing, the project has been running for five months, and will continue to run for four more. The focus of the project was to find a promising product idea in the small business segment and turn it into a company.
At the beginning of the project, no ideas existed. Doing exploratory interviews with potential prospects made the team both knowledgeable with how small businesses operated (the targeted market segment) and provided many ideas. As more exploratory interviews were conducted, a picture of how small businesses operated in general began to emerge and the team began to focus on certain promising leads. When 40+ exploratory interviews had been conducted, the value of each new interview became less and less, with no new learnings gained, and focus shifted from problem understanding to solution defining.
Project members perceived the process as practical. Based on the amount of people in the team, the team always had ideas to work with and never lost its momentum. Having a cap of three simultaneous ideas worked out well for the size of the team due to the fact that one business developer was responsible for one idea each. When dividing responsibility this way, the importance of having a comparable format (Lean Canvas) became apparent during idea prioritization sessions. Furthermore, using canvases made the team think of the product not as a solution, but as a business model. This gave the team a broader perspective and made it easier to spot the potential in each product idea.
The process gave clear guidance on when to move product ideas forward through process stages. Using well-defined exit criteria for each stage contributed to the team’s good momentum and allowed each business developer to work independently.
The process gave clear guidance on when to abandon product ideas. The team constantly evaluated whether exit criteria had been reached or not. When additional interviews resulted in no more learning, and there was no clear path towards fulfilling the criteria, the team took a decision: pivot, persevere or abandon. If there was no obvious way to pivot, the team usually opted to abandon the idea in favor of another one from the product ideas backlog.
The process gave clear guidance on what techniques to use and when for validating product ideas. The proposed techniques proved efficient; no technique took more than two working days to apply. This was valuable in order to push the project forward and get fast feedback from customers.
Concluding, initial validation in the project context suggests that ESSSDM overcomes the challenges discussed in the problem statement.
Software startups are more popular than ever and growing in numbers. They operate under conditions of extreme uncertainty, and face plenty of challenges, underlined by their high failure rate. In this paper, these challenges were investigated through a literature study of the Lean Startup community as well as through interviews with industry professionals. The result of this investigation showed that few practitioners apply Lean Startup methods because these were found too vague and imprecise to implement in practice.
In response to the investigation, we developed the Early Stage Software Startup Development Model (ESSSDM) that addresses the identified challenges: • The process supports working on, or investigating, multiple product ideas in parallel, as part of an idea portfolio • The process provides clear guidance on when to move product ideas forward through process stages • The process provides clear guidance on when to abandon a product idea • The process provides clear guidance on what techniques to use and when, while validating product ideas In future work, we intend to provide more validation especially to stages 3 and 4 of level 2 of ESSSDM and to apply to the process to additional startups.