THE ROLE OF USER-PRODUCER INTERACTION IN DEVELOPING INNOVATIVE ICT PRODUCTS/SERVICES: EXPLORING A LEAN APPROACH

A dissertation submitted to The University of Manchester for the degree of Master of Science in the Faculty of Humanities

2012

Hamid Mohamed Ali Awad

MANCHESTER BUSINESS SCHOOL

TABLE OF CONTENTS
TABLE OF CONTENTS.................................................................................................... 2 LIST OF FIGURES ............................................................................................................ 4 LIST OF TABLES .............................................................................................................. 4 ABSTRACT........................................................................................................................ 5 DECLARATION ................................................................................................................ 5 COPYRIGHT STATEMENT ............................................................................................. 5 ACKNOWLEDGMENT .................................................................................................... 6 CHAPTER 1, INTRODUCTION ....................................................................................... 7 1.1 1.2 1.3 Introducing Research Topic ................................................................................ 7 Research Objective and Questions...................................................................... 8 Research Organization ........................................................................................ 9

CHAPTER 2, LITERATURE REVIEW ............................................................................ 9 2.1 2.2 2.3 2.3.1 2.3.2 2.3.3 Definitions: User-Producer Interaction, Innovation, ICT and New Products ..... 9 User Producer Interaction in New Product Development (NPD) ..................... 11 New Product and Service Development Process .............................................. 13 Crawford and Di Benedettos NPD Model ............................................... 14 Coopers NPD Model (Stage Gate) .......................................................... 16 New Service Development Process .......................................................... 18

2.4 Lead User Theory: How can Producers accurately determine User needs for New Products/Services in a rapidly changing sector like ICT? .................................... 19 2.5 2.6 2.7 2.8 2.9 2.9.1 2.9.2 2.9.3 2.10 Agile Software Development ............................................................................ 21 Literature Review Findings and Summary ....................................................... 22 Introducing Lean Manufacturing ...................................................................... 24 The Lean Approach in Software ....................................................................... 24 Lean Startup Methodology ............................................................................... 25 Validated Learning.................................................................................... 26 Minimum Viable Product (MVP) ............................................................. 26 Build-Measure-Learn feedback loop ........................................................ 27 Chapter Summary ............................................................................................. 28

CHAPTER 3, RESEARCH METHODOLOGY .............................................................. 29 3.1 3.1.1 Design ............................................................................................................... 29 Case Study Selection................................................................................. 30 2

3.2 3.3 3.4 3.5 3.6

Research Question Revisited ............................................................................ 33 Conceptual Framework ..................................................................................... 33 Data Collection ................................................................................................. 34 Data Analysis .................................................................................................... 36 Chapter Summary ............................................................................................. 36

CHAPTER 4, CASE STUDY 1 ........................................................................................ 38 4.1 4.2 4.3 4.3.1 4.3.2 4.3.3 4.3.4 4.4 Introduction ....................................................................................................... 38 Buffer: Product Background ............................................................................. 39 Product Development........................................................................................ 41 First MVP ................................................................................................. 41 Second MVP (first product release) .......................................................... 45 Sources of Ideas ........................................................................................ 46 Product Development Efforts to Drive Growth (Build-Measure-Learn) .. 48 Chapter Summary ............................................................................................. 51

CHAPTER 5, CASE STUDY 2 ........................................................................................ 52 5.1 5.2 5.3 5.3.1 5.3.2 5.3.3 5.4 5.4.1 5.4.2 5.4.3 5.5 5.6 5.7 Background: Company and Product ................................................................. 52 NPD Process: the Case of RBT ........................................................................ 53 RBT Launch: Analyzing Challenges and Product Development Efforts.......... 56 Customer Involvement in NPD ................................................................. 56 Product Development Efforts Post- Launch ............................................. 58 Product Development Efforts to Drive Growth ........................................ 59 Introducing Lean Startup to RBT Development ............................................... 59 An MVP for the RBT ................................................................................ 60 RBT Growth Issues Revisited ................................................................... 63 Applying Lean Startup Methodology to Drive RBT Growth ................... 64 Issues in Applying Lean Startup Methodology in RBT Development ............. 68 Advantages of Applying Lean Startup to RBT Development .......................... 69 Chapter Summary ............................................................................................. 70

CHAPTER 6, CONCLUSION.......................................................................................... 71 6.1 6.2 6.2.1 6.2.2 Research Questions Answered .......................................................................... 71 The Lean Startup: A methodology for User-Producer Interaction.................... 71 Minimum Viable Product (MVP) ................................................................. 71 MVP Versus Marketing Research to Validate Ideas..................................... 72 3

6.2.3 6.3 6.4

Systematically Figuring Out What to Build .................................................. 73 Converging the NPD Process and Lean Startup Methodology ......................... 76 Research Limitations and Future Direction ...................................................... 77

6.5 Implications of Adopting Lean Startup Methodology by Established Companies (Non Startups) ............................................................................................................... 78 6.6 6.7 Concerns in Applying Lean Startup Methodology ........................................... 80 Final Remark..................................................................................................... 80

APPENDICES .................................................................................................................. 81 Appendix A ................................................................................................................... 81 Appendix B ................................................................................................................... 84 Appendix C ................................................................................................................... 86 BIBLIOGRAPHY ............................................................................................................. 88

Word Count: 22,887 LIST OF FIGURES

FIGURE 1 - NSD AND CUSTOMER INVOLVEMENT ............................................................. 20 FIGURE 2- RESEARCH CONCEPTUAL FRAMEWORK ........................................................... 37 FIGURE 3- USING BUFFER .................................................................................................. 40 FIGURE 4- BUFFER DASH BOARD ...................................................................................... 40 FIGURE 5-BUFFER GROWTH IN 2011 ................................................................................. 41 FIGURE 6- BUFFER FIRST MVP ......................................................................................... 43 FIGURE 7- BUFFER FIRST MVP 2ND VERSION ................................................................... 44 FIGURE 8- BUFFER USER VOICE ........................................................................................ 48 FIGURE 9- BUFFER BUTTON .............................................................................................. 51

LIST OF TABLES
TABLE 1- CASE STUDIES DESIGN COMPONENTS .............................................................. 32 TABLE 2-VALIDATING POST-LAUNCH RBT CHANGES ..................................................... 61 TABLE 3- BUILD-MEASURE-LEARN PROCESS DRIVING BUFFERS GROWTH ................... 75

ABSTRACT
A wealth of knowledge in business, management and entrepreneurship best practices exists and widely available. Furthermore, the rapid development in Information and Communication Technologies (ICT) creates tremendous opportunities to innovatively serve market needs. Nevertheless, the number of new ICT products and services which fail to address customer needs, and therefore commercially fail, is not decreasing. The purpose of this research is to investigate how producers (product/service developers) may interact with their users (customers) when developing new innovative ICT products/services, in order to increase the chances of the products commercial success. The study explores the emerging Lean techniques; aiming to develop a methodology that guides product/service developers in effectively engaging with customers in the process of new product development.

DECLARATION
No portion of the work referred to in the dissertation has been submitted in support of an application for another degree or qualification of this or any other university or other institute of learning.

COPYRIGHT STATEMENT
The author of this dissertation (including any appendices and/or schedules to this dissertation) owns certain copyright or related rights in it (the Copyright) and he has given The University of Manchester certain rights to use such Copyright, including for administrative purposes. Copies of this dissertation, either in full or in extracts and whether in hard or electronic copy, may be made only in accordance with Copyright, Designs and Patents Act 1988 (as amended) and regulations issued under it or, where appropriate, in accordance with licensing agreements which University has from time to time. This page must form part of any such copies made.

The ownership of certain Copyright, patents, designs, trademarks and other intellectual property (the Intellectual Property) and any reproductions of copyright works in the dissertation, for example graphs and tables (Reproductions), which may be described in this dissertation, may not be owned by the author and may be owned by third parties. Such Intellectual Property and Reproductions cannot and must not be made available for use without the prior written permission of the owner(s) of the relevant Intellectual Property and/or Reproductions.

Further information on the conditions under which disclosure, publication and commercialization of this dissertation, the Copyright and any Intellectual Property and/or Reproductions described in it may take place is available in the University IP policy.

ACKNOWLEDGMENT
The author would like to express his gratitude to Professor Ian Miles for his guidance, as well as Joel Gascoigne of Buffer, Inc. and Company Zs staff for sharing their experiences that made the foundation of this study.

CHAPTER 1, INTRODUCTION 1.1 Introducing Research Topic

Information and Communication Technologies (ICT) have been advancing radically. Today we have powerful computing power even on mobile phones. The internet is becoming much cheaper and faster. Open source software and tools provide zero cost access to even people with basic technical skills. Moreover, business, management and entrepreneurship practices are advanced and widely available however the number of new ICT products and services which fail to address customer needs and therefore commercially fail is not decreasing. Startups as well as established companies are facing high uncertainty when developing new innovative products and services; what features and functionality should the product provide? How should the product be designed to provide such features? How much are customers willing to pay for it? Those are just some of the questions that need to be answered when developing new products and services. Ultimately the big question is: will the new product/service sell? Although the ICT sector is mature, the debate of technological push versus demand pull is ongoing and manifesting in technically complex products that do not fit user needs. Googles Wave is one example of a recent product that has been regarded as technically innovative however it has been shut down because the market uptake was far below expectations as per Googles official statement (Google, 2010). Continuously getting customer feedback and incorporating it in product development becomes essential when trying to produce innovative products or services. The absence of similar products in the market to bench mark with, increases the uncertainty of commercial success. Conventional marketing research methods like customer surveys or focus groups are of a little help because it is difficult for users to articulate their needs and wants as their contribution is limited by their experience with available products in the market (Von Hippel, 1988).
7

Furthermore, the rapid pace of technological innovation brings numerous challenges to product developers who are striving to mix and match the possibilities brought about by the evolving Information and Communication Technologies with the realities of customers needs. While there seems to be consensus to some extent on the crucial role that user producer interaction plays in new product development a little is known on how can that be done especially in the ICT sector. The speed of change in markets as well as Information and Communication Technologies calls for finding away to blend user producer interaction and new product/service development to increase success chances.

1.2

Research Objective and Questions

The research aims to explore how product and service developers may involve customers when developing new innovative ICT products and services in order to increase chances of commercial success. The objective is to explore and further develop a methodology of how product and service developers can effectively engage customers in new product development stages. Research outcome could serve as a foundation for further studies to test and refine a methodology that can be adopted across the ICT industry. Hence ultimately increase the commercial success rate of new innovative ICT products and services. Furthermore, systematically bringing producers close to users shall support the former in uncovering market needs and understanding how to best apply technology in novel ways to address them thus promote ICT product and service innovations. To summarize, here is the main research question: How can producers (product developers) interact with their users (customers) when developing new innovative ICT products/services, in order to increase the chances of the products commercial success?

1.3

Research Organization

This paper is organized in six chapters. In the next chapter (chapter 2) we review relevant previous research and shade more light on research perspective. We then discuss research design and methodology. Chapter 4 and 5 report and discuss two case studies used in the research. Chapter 6 concludes the paper.

CHAPTER 2, LITERATURE REVIEW

This chapter aims to review relevant literature and situate the research among related work.

2.1

Definitions: User-Producer Interaction, Innovation, ICT and New Products

A common definition of User-Producer Interaction (UPI) is the interaction between units innovating and other units, which are potential users of the innovations (Lundvall, 1985: 4). User involvement which is a specific part of the UPI concept, and would also be used interchangeably with UPI in this study, refers to participation in the system development process by representatives of the target group (Ives and Olson, 1984, p. 58). Definitions of innovation vary, with some focusing on novelty of technology itself, and some more on the successful commercialization of new products (Tether, 2003). This study is focused on innovation as the consequences of ICT technologies as measured by market uptake of the product. Hence we consider this definition A product innovation is new technology or combination of technologies introduced commercially to meet a user or market need (Utterback and Abernathy, 1975, p. 642). We also add that product innovation includes an element of novelty that is relative to time and space (Tether, 2003). Tether (2003) identifies three dimensions to product innovation: Conceptual Novelty, Market Uncertainty and Technological Uncertainty. In identifying
9

product innovation this research is primarily concerned with high Market Uncertainty and partially with Conceptual Novelty. Conceptual Novelty is described as changing the established ways of doing things. To illustrate, Tether (2003) uses the example of James Dyson and how he changed the vacuum cleaner concept from sucking into a bag to using cyclones. From the perspective of this study, without market acceptance the product may not be regarded as a successful innovation even though Dysons cleaner concept is novel and able to overcome the Technological Uncertainty. New products are often classified as new-to-the world, new-to-the-firm (new product lines), addition to existing product lines (not significantly new-to-firm), improvement to existing products, repositioning and cost reductions (Booz, Allen and Hamilton, 1982). This research is concerned with new products that involve high uncertainty so products of our concern are New-to-the world and New-tothe-firm. The former is very rare and often emerge from a breakthrough in technology (Booz, Allen and Hamilton, 1982). Consequently research primarily focuses on New-to-the-firm products which include an element of novelty. For example the research is not concerned with a company that is, for the first time, trying to produce accounting software unless they are introducing something novel that is not a reduced price or an enhanced functionality (a trajectory improvement. OECD countries define the ICT sector as a combination of manufacturing and services industries that capture, [process], transmit and display data and information electronically (OECD.org, 1998). The present study is focused on software based ICT products. The difference between a product and a service does not affect the research design. Literature about new service as well as product development is reviewed. Consequently the words product and service are used interchangeably in the paper to refer to intangible products that are principally software based like mobile applications or a money transfer service via mobile phones.

10

2.2

User Producer Interaction in New Product Development (NPD)

The importance of interacting with customers in new product and service development seems well established in the literature (Von Hippel, 1988). A comprehensive empirical review of literature about success factors of new product development reveals that involving customers in new product development process is a determinant of success (Ernst, 2002). The same conclusion is reflected by new service development literature (Alam, 2002; Martin Jr & Horne, 1993). Although some comparative studies report differences between innovation success factors in tangible product and service development, customer engagement is a common success factor (Kwaku, 1996, cited in Alam, 2002, p. 251). In the marketing literature the notion of value co-creation is closely related to our enquiry about user-producer interaction. Unlike the inherited model of goods exchange from economics Vargo & Lusch (2004) call for a revised logic for marketing which is focused on intangible resources, the co-creation of value, and relationships (Vargo and Lusch, 2004, p. 1) . In the conventional value creation process, companies and consumers had distinct roles of production and consumption. Product and services contained value, and markets exchanged this value, from the producer to consumer (Prahalad and Ramaswamy, 2004a, p. 5). With co-creation, this distinction disappears as it replaces the exchange process. To put this notion into practice, the focus should turn to creating infrastructure for interaction that enables customers to co-construct and personalize their experience not merely the offering (Prahalad and Ramaswamy, 2004a). Unlike the traditional view of marketing, such interaction is ongoing and can occur anywhere not only at the point of sale or customer service (Prahalad and Ramaswamy, 2004b). Sawhney, Verona and Prandelli (2005) take the notion of co-creation a step further by describing and implementing it in the marketing process of our concern, new product development. They discuss how the internet can enable co11

creation of value during the various stages of new product development1. In the ideation stage product developers can use online platforms to collect ideas from customers. Moreover, socially generated knowledge from virtual communities, where users with common interests meet to share and discuss experiences, provides insights that firms can use to develop ideas for new products. Market intelligence tools that scan blogs and forums to identify trends are also useful in this first stage. To validate ideas firms can use online concept labs to solicit users feedback. In the design stage, customers can use online toolkits to directly participate in designing new products (Von Hippel and Katz, 2002) which help in extracting customer needs that are hard to explain. Online product and market testing is more efficient and cheaper. Different product configurations can easily be tested to identify best options that users like. Furthermore, users can use the internet to customize products. For example Dell.com enables customers to build their own desktop computers by selecting its components like monitor, graphics card, multimedia system, processor, hard disk capacity, etc (Dell, 2012) In summary, the Internet allows firms to engage customers more broadly, more richly, and more speedily. It allows firms to create ongoing customer dialogue, absorb social customer knowledge, and scan knowledge of potential or competitors customers (Sawhney, Verona and Prandelli, 2005, p. 14). Von Hippel & Katz (2002) argue that product developers can outsource key need-related innovation tasks to the users themselves, after equipping them with appropriate toolkits for user innovation. (Von Hippel and Katz, 2002, p. 821). So toolkits not only offer a mean to extract latent user needs, but also capture user solutions to satisfy those needs. In opposition, the author would argue that a vast array of toolkits and knowledge in the ICT field is publicly available e.g. programming languages, software development tools, open source software,
1

Generally, new product development stages are: idea generation, concept development, design, development and testing (Sawhney, Verona and Prandelli, 2005). Product development process is discussed in detail later on in this chapter.

12

communication protocols, etc. The challenge lies in spotting user needs/wants and using the appropriate technologies, in novel ways, to develop products that fit those needs. So the notion of innovation toolkits is of a little help in the research enquiry. Also beyond the scope of the present research are studies about users who innovate by themselves and commercialize their own innovations e.g. (Baldwin, Hienerth and Von Hippel, 2006). In the long running debate about science/technology push versus demand pull as a source of innovation, this research is more inclined towards the latter. Looking at new products, there are very few new-to-the-world products and even if they are the outcome of a brand new technology the innovation would be on how to use it to fulfill a need in a better way (Tidd and Bessant, 2009). Another adjacent concept of user-producer interaction is co-development (Anderson and Crocca, 1993). It is a process where the technology creator works together with users to discover and develop applications for a new technology. The objective of co-development process is to evaluate and develop a new technology, with respect to its commercial potential, rather than to address a user need/want (Anderson & Crocca, 1993; Neale & Corkindale, 1998). The concept of co-development highlights the importance of involving users early on in the product development process, and the benefit of using prototypes to accelerate the process of learning from users through feedback (Anderson and Crocca, 1993).

2.3

New Product and Service Development Process

In this section we lay the foundation of the research by presenting NPD and NSD models. We also emphasize user engagement activities suggested by the models. Research in this area has gone beyond studying how successful products are developed to incorporate lessons learned over the years in a process (also called model) that describes how to develop new products from idea to profit. In this section we look at two of the most prominent models of new product
13

development; the new product development process by Crawford & Di Benedetto (2006) and the stage gate process by Cooper (2001). They are general purpose models i.e. they are neither designed especially for ICT products nor they take into account product classification (new-to-world, to- company, etc). The authors claim the processes suitability for services as well as products. There are no special models for ICT or software products; while literature in the software engineering discipline provides many models and techniques, these are mainly dealing with management of the software development cycle. They typically do not map the end to end process from idea to market. Such models are subsets of the NPD models we are about to discuss. We provide brief account of the overall process using the Crawford & Di Benedetto (2006) model, and then emphasize user engagement points when discussing Coopers (2001) model. The objective is to understand how to effectively engage users in new product development process in the light of the new product and service development literature. 2.3.1 Crawford and Di Benedettos NPD Model Crawford & Di Benedetto (2006) depict the NPD process in five stages: opportunity identification, concept generation, concept evaluation, development and launch. Opportunity identification: This stage aims to develop a strategy that guides new product development efforts. It is about guiding product developers in the pursuit of ideas for new products; do we have advantages that we are trying to exploit, threats we want to fight, what are they? Or is it about finding applications for a new technology? Concept generation: A product concept is composed of three parts: need (or benefit), technology and form. The first part describes customer needs/benefits that will be provided by the product. Technology is the source by which the form would be attained (Crawford and Di Benedetto, 2006, p. 88). Form is what would actually be created e.g. the software and hardware. A concept that exemplifies the three facets respectively would be: To reduce the cost of business traveling we can use communication technologies over the internet to provide high quality video conferencing product on computers or even on customer
14

mobile phones. Any of the three, which actually emerges from the first phase, can start the concept generation process. However without all three the concept is incomplete. Interestingly Crawford & Di Benedetto (2006) emphasize the importance of customer needs/benefits and how product success is correlated to having a need first then looking at which technology and how it can be used to address the need and finally in which form. Even if discovery of a new technology is driving the opportunity, without matching it to customer needs/benefits product success is highly doubtful. This is the same position that this research is taking on the technology push versus demand pull debate. As discussed, users are involved in this phase - but how firms can engage with them? Crawford & Di Benedetto (2006) present many techniques which have the objective of finding customer problems: analyzing everyday customer complaints, interviewing customers and conducting focus groups to identify problems they have with current products in the area being researched then categorizing and prioritizing those problems. Observing customers is also another technique. Extracting real customer needs/wants is difficult because they are limited by their experience with currently available products therefore the importance of dealing with lead users arises (Von Hippel, 1986). Lead user theory is discussed later on in this chapter. Once customer needs/problems have been identified the NPD team involved (mainly technical staff) work on finding solutions. Finally, the generated concept with its three facets and solution(s) are captured in a concept statement which will be used in communication with customers and all parties involved in the NPD. Concept statement is the output from this phase and the input to the next one. Concept evaluation: Evaluation is a continuous process that ultimately aims to guide the development of successful products. However on each phase evaluation has a different goal. On stage one the objective was to select what is in line with the corporate strategy. In this stage the objective is to evaluate the concept that began to emerge from concept generation. In the development stage we will be tracking progress and evaluating if we are building what we planned to build. In
15

the launch phase we would be evaluating whether the firm is able to make and market the new product successfully. Interviewing customers aim to test the developed concept and thus identify and eliminate poor ones. Moreover, it would develop concepts further on by incorporating customers feedback. Before giving the green light to start development, a full screening for the product concept in light of the technical and commercial feasibility is conducted. The idea is to evaluate whether the product concept meets the firm technical, marketing and financial capabilities and still yield desirable profit. At this point heavy use of financial analysis and sales forecasting is typical. The output of this stage is a product protocol document. It is an agreement between all teams involved that describe the product in detail and the role of each functional team in development. Development: Towards the end of technical development a semi-finished version of the product would be ready i.e. a prototype. At this point use testing for the product should be carried out. That is real customers should be testing the product under normal operating conditions. The aim is to check that the product actually solves the problem which has been stated by the customer in the beginning. As a result of testing, product might go back to technical development or it may even be dropped! Otherwise firm can proceed to launch phase. In summary, users are engaged in the new product development process before development stage then in testing the new product after it is ready. Marketing research methods like interviews, focus groups and surveys are typically used to interact with users. 2.3.2 Coopers NPD Model (Stage Gate) This process marks clear stages and activities to be conducted on each stage. It also defines control checkpoints, termed gates, with deliverables required on each checkpoint and criteria to be fulfilled so the product can be moved to the next stage or killed. Cooper (2001) started with what he terms first generation model then developed the process to second then third generation. From a
16

customer engagement perspective the first generation version is similar to Crawford & Di Benedetto (2006) model. That is customers are mainly involved prior to development stage. Here we describe the second generation process that emphasizes customer involvement throughout the NPD stages2. This stage-gate process has the following stages: discovery, scoping, build business case, development, testing & validation, launch and post launch review. Discovery: This stage is about searching for ideas that could potentially be successful new products. The idea screening gate is primarily concerned with selecting ideas which are in line with strategy, just like Crawford & Di Benedetto (2006) Opportunity identification phase. Yet, Cooper puts emphasis on coupling voice-of-the-customer research with strategic directions in order to discover potential ideas. Voice-of-the-customer research refers to market research that aims to understand customer operation and problems. Scoping: In this stage, a quick preliminary market, technical, business and

financial assessment is done. The objective is to spend little money on collecting some information then re-evaluate the merit of the idea at the end of the stage i.e.at the gate. If gathered information supports the validity of the idea next stage is entered where rigorous exploration is done. Building the business case: Detailed investigation to verify the opportunity attractiveness and define the product is carried out at this stage including detailed customer research, business & financial analysis, competitive analysis and technical appraisal. At this stage, the process focuses on voice-of-the-customer research to reveal the product value proposition, benefits, features, performance attributes and design requirements. Furthermore, to understand how the product might fit in customers routines. Cooper (2001) suggests the use of focus groups and in depth personal interviews to conduct such research. Before going to development, the developed concept has to be tested with customers to safeguard against two high risks: not getting the real needs/wants from customers because they are not able to identify or communicate them. Not
2

The second and third generation stage gate processes share the same prospective on customer involvement. For the sake of simplicity and to keep the focus of this research, there is no need to present third generation model that adds flexibility and speed for experienced practitioners.

17

interpreting those requirements correctly or not translating them to features and specifications appropriately. The best way to do this test is by providing customers some sort of a model for the proposed product e.g. in software products showing customers screens from the product to experience. Development: The process emphasizes seeking customer input throughout the development stage in order to avoid two major commonly appearing problems: First, inconsistency between the final product and the successfully tested product concept. This occurs usually because of a problem in translating user needs/wants into product concept or a technical matter that led to a change in the product. Second, things may change during development (especially in a rapidly evolving industry like ICT) e.g. change in user needs, new product by competitors, etc. Utilizing customers input is done by getting their feedback on finished (or semifinished) parts of the product, and incorporating it into development. Such feedback is rich because customers experience the actual product not merely written descriptions. Following development completion, testing and validation start. Testing and validation: An important part of testing is done with customers. During development, parts of the product have been under testing. At this stage, the complete product shall be tested. Hopefully testing results would suggest minor design changes. If major changes are exposed, product should be returned to development. Post launch review: after launching the new product, a review is made of the whole project in order to extract lessons learned and improve the process. 2.3.3 New Service Development Process A literature review by Johne & Storey (1998) concludes that most of research in new service development has followed NPD process by Booz, Allen and Hamilton (1982) which is a simplified version of Crawford & Di Benedetto (2006) model. Early work in service specific development model is by (Scheuing & Johnson, 1989, cited in Johne & Storey, 1998, p.202). They emphasize importance of user involvement and pinpoint stages where customers should be involved. They
18

describe the same stage specific user engagement activities described by Crawford & Di Benedetto (2006). Alam & Perry (2002) proposed a customer oriented model based on development of financial services. See Figure 1 - customer activities that are relevant to ICT services are enclosed in red boxes. Customer engagement in Alam & Perrys (2002) NSD model is similar to Coopers (2001) NPD model.

2.4

Lead User Theory: How can Producers accurately determine User needs for New Products/Services in a rapidly changing sector like ICT?

Von Hippel (1986) argues strongly that marketing research is unlikely to answer the question above. Conventional marketing research is unlikely to uncover novel ideas for new products since users experience is limited by their real-world experience in terms of how and what existing products can do. His answer to the question is to study and/or engage lead users. His argument was initially supported by research in problem solving (Von Hippel, 1986). Later, he empirically proved it by conducting a lead user marketing research for an industrial software product. Results were better ideas and solution concepts from a traditional marketing research (Von Hippel, 1988). Lead users are users who are: 1. Currently facing needs that will face the bulk of users in a marketplace in the future (months or years later). So their current needs can serve as forecast for future market needs. Those are users on the leading edge of an industry or a trend that a new product is targeting. 2. They will benefit significantly from a solution that meets those needs. Therefore they attempt to develop such a solution themselves so they will be a valuable source of ideas (needs and wants) as well as solutions. Those users are a subset from users identified above i.e. they are at the forefront of the area understudy and will benefit extensively from the new product.

19

Figure 1 - NSD and customer involvement Source: (Alam and Perry, 2002, p. 527)

20

In order to develop concepts for new products using the lead user methodology, the following four steps were outlined by Von Hippel & Riggs (1996) 1. Identify trends in the market segment of interest so lead users characteristic could be identified. In a case study they used, a firm wanted a new product to target the home banking segment. By reviewing specialized journals and interviewing experts in the field the firm identified potential in electronic home banking. 2. Identify lead users as defined above. This can be done directly and/or by searching for actual user innovations which are driven by the need to gain those benefits. In the home banking example they would have two attributes: (1) they currently use advanced electronic home banking systems (ahead of the market trend). (2) Motivated by their need, they would have tried to develop solutions. 3. Work with lead users to develop product concepts. The firm in the case study conducted workshops with lead users. 4. Test developed concepts to see if they appeal to typical users in the target market. One criticism of the theory is that lead users do not represent the majority of the market - their needs/wants (and capabilities) may not apply to mass market (Magnusson, 2003) . However it is suggested that firms may adapt lead users ideas and practices in order to fit mass market (Von Hippel and Riggs, 1996).

2.5

Agile Software Development

The software engineering and information systems3 literature contain numerous software development methodologies. Here we review the so called agile methods

Software engineering (SE) differs from the field of Information Systems (IS) predominantly in the sense that IS community takes into account the social and organizational aspects. Moreover, SE traditionally focuses on practical means of developing software (Sommerville, 1996) (Abrahamsson, et al., 2002, p. 7). However, for the purposes of this research such a distinction is not necessary. 21

since they are widely accepted among practitioners as well as academia. More importantly they are frequently cited in discussions about user engagement in development of new software. Based on the agile manifesto which laid the foundation of the core concepts (Beck et al., 2001), Abrahamsson et al (2002) define a development method as agile when development is incremental (small software releases, with rapid cycles), cooperative (customer and developers working constantly together with close communication), straightforward (the method itself is easy to learn and to modify, well documented), and adaptive (able to make last moment changes) (Abrahamsson, et al., 2002, p. 17). Reviewing the different methods using a highly cited literature review by Abrahamsson et al (2002), we summarize that different agile methods call for close customer involvement by mean of using short iterative development cycles that incorporate customer feedback. One agile method that is purely customer driven is called extreme programming. It requires customer and developers to be co-located during the project period. It also requires a knowledgeable customer who understands and able to explicitly communicate clear requirements to developers! Overall, agile methods are concerned with addressing the rapid changing business environments (mainly rapidly changing customer requirements). In essence, the problem that the new product is trying to solve is clear. Agile methods aim to provide an efficient way to develop solutions by closely working with customers. So identifying customer needs/wants as requirements for new software products to fulfill, is beyond the scope of agile methods. Considering the NPD process, such methodologies may fit in the development phase.

2.6

Literature Review Findings and Summary

NPD and NSD models have been presented to lay the foundation for understanding the process by which new products/services are developed .Models

22

emphasize user engagement on every stage. They rely on marketing research as away to engage with customers. However, traditional marketing research techniques are of a very limited use in providing customer insight that shapes innovative new product/service development; surveys, interviews, focus groups and even sophisticated methods like multi attribute mapping of product perceptions and preferences are constrained by user familiarity with products available in the market (Von Hippel, 1986). Accordingly they are good in collecting clear needs about improving existing products. Moreover they cannot provide information about Latent customer needs (Leonard, 1995; Griffin & Hauser, 1993, cited in Matthing, et al., 2004, p. 481). The use of the lead user concept to overcome limitation of conventional marketing research is interesting. However, it is unclear if it will uncover latent needs of the target market. How to adapt a product that addresses lead user needs to serve the target market is also unclear, especially when developing technology products as Moore (1998) illustrates the challenges that lay in crossing the chasm. As markets are rapidly changing as well as ICTs, using the lead user concept may add to the innate risk of delivering a product- market fit; a product that has been developed based on the needs of lead users may miss the window of opportunity because of a change in target users needs or the used technology. The difficulty of identifying lead users is an additional criticism of the theory (Magnusson, 2003). It has been mentioned that customer wants/needs are better uncovered when customers interact with product prototypes rather than by asking what is missing in a current product or what an ideal product should do to tackle a particular issue. A little is known about how to involve users during NPD/NSD to improve product success chances (Greer & Lei, 2012; Matthing, et al., 2004; Alam & Perry, 2002). The concept of value co-creation extends the simple idea of user involvement in NPD. Although we touched on how the internet can enable cocreation of value during the various stages of new product development, a
23

fundamental shift in the mindset of product developers is required to truly embrace the notion of value co-creation. A rigorous methodology of how to effectively achieve that is also needed. The present study aims to fill that gap by using case studies to explore a methodology that embraces the concepts summarized above, and promises a lot more. It is discussed next.

2.7

Introducing Lean Manufacturing

Lean is the English word used by researchers of Massachusetts Institute of Technology to describe Toyotas way of managing automobile manufacturing (Womack, Jones and Roos, 1990). The essence of lean concept is to focus on customer needs in all activities. It is based on five principles: value, value stream, flow, pull and perfection (Womack and Jones, 1996). Value is what offered to customer (by a product) and that she is willing to pay for it. Firms work backward from the value to construct the production process that will deliver it (the value stream). Flow identifies what is needed so products can move smoothly through the stream. Note that every step in the value stream is created to contribute to the end value. A keystone in lean production is to remove waste. Waste is defined as anything that takes resources but does not contribute to value. Pull means the whole process only works to respond to customer demand. Perfection depicts the constant quality inspection throughout the whole process (not only at the end) and the verification that customer needs are met. Lean principles have revolutionized manufacturing around the world.

2.8

The Lean Approach in Software

Recently some studies have started exploring the application of lean principles in software, for example (Mehta, Anderson and Raffo, 2008). Staatsa, et al. (2011) documents a case study of a software making firm that tried lean approach. They conclude that it is possible and indeed improved the operational performance however, they measured that in terms of development time and number of defects not in terms of value to customer since the firm is a custom software maker.

24

A prominent and highly cited work in applying lean principles to software is by Poppendieck & Poppendieck (2007). We summarize their latest thinking in the next few lines (Poppendieck and Poppendieck, 2007). They put seven principles for lean software development. Three of them are very relevant to the present research objective: eliminate waste, create knowledge and optimize the whole. As explained earlier, waste is anything that takes resources but does not contribute to value. In software products this directly translates to features that in reality are not needed by customers. The more you add the more complex development, maintenance and upgrade get. The concept of Knowledge creation is considered radical as it is against the traditional models of software development. Instead of having the complete customer requirements prior to starting development then testing and eventually deploying (launching the product), the lean approach aims to generate and continuously utilize knowledge about customer needs similar to Coopers recommendation (2001) to use iterative development to incorporate users feedback. Poppendieck & Poppendieck (2007) suggest to start by developing a minimum set of useful features then based on customers feedback, the next round of features to be developed. Optimizing the whole is about continuously thinking in terms of user value while developing all parts of the software. Poppendieck & Poppendieck (2007) work layed the foundation of lean in software. Their work went beyond optimizing the software making process but rather extended lean thinking to the whole process of product development from concept to cash. However, they did not provide a methodology to guide practitioner.

2.9

Lean Startup Methodology

Ries (2011) recently brought more rigour and new insights in applying lean concepts in building software products. Based on numerous case studies of leading practitioners in the software industry he developed the lean startup methodology. As we will see in this section and throughout this paper, the lean startup methodology embraces many of the concepts discussed in this chapter and
25

promises a lot more. The present paper would explore the practical application of the lean startup methodology in order to answer the research question. The term startup does not refer to company size. A startup is a human institution designed to create a new product or service under conditions of extreme uncertainity (Ries, 2011, p. 27). This section will disucss parts of the methodology that are relevant to the research questions. 2.9.1 Validated Learning At the heart of the lean startup methodology is the concept of validated learning (Ries, 2011). Instead of relying solely on marketing research reports and market forecast, validated learning is gained through a process that empirically demonstrates that a product development team has discovered valuable truths about the business prospects. Those prospects are profound on what customers truly accept. Instead of thinking and measuring productivity in NPD projects in terms of building high quality products, that perhaps no one wants, productivity is defined in terms of how much learning from customer interaction with the product under development is acquired. 2.9.2 Minimum Viable Product (MVP) Lean startup methodology regards all information collected about customer needs/wants as well as concepts about suitable solutions as unproven hypothesis. Traditional NPD models actually invest resources in building products based on such hypothesis and, in reality, start validating them at the end of the process with a high quality product. On the contrary, a MVP is a barebones version of the end product that aims to kick off the learning process. Unlike prototypes, it is not built to only answer product design or technical questions but rather to test business assumptions about what customers want from/in a new product. Furthermore, a MVP is designed in a way to collect customer feedback. For example, if it is a website, it should have the capability to provide detailed information about which parts of the website, for instance, have the biggest/smallest number of clicks.

26

Note that this is not a low quality version of the end product. However, as customer requirements are still unknown, quality cannot be defined. MVP features and functionality characterize the main and riskiest assumptions that makeup the product value. As an example, consider an instant messaging (IM) product that is bringing different messaging networks into a single platform. The main assumption to be tested is that customers want to interact with and manage all their contacts from a single platform, instead of having different IM products like Facebook chat, Gmail chat and Skype. Investing in a MVP that is capable of supporting three or more IM networks is a form of waste because it is not known if customers need that. Also making the product easier to use or faster does not make any sense if nobody would use the product! A MVP that supports only two IM networks is sufficient to learn whether there is a need for the product and to start learning about customer needs. If product developers had discovered that customers actually prefer to use separate products for different messaging networks for any reason (perhaps Skype for business contacts and Facebook for friends and family), they would have avoided considerable amount of waste.
Ries (2011) describes a special type of customers who are attracted to an MVP.

They are technology enthusiasts who like to try new products especially if they are incomplete solutions. They will be the products early adopters4 (Moore, 1998). 2.9.3 Build-Measure-Learn feedback loop Ries (2011) illustrates NPD as an iterative learning process. Each round consists of three learning milestones: (1) Establish baseline. (2) Tune the growth engine using acquired validated learning. (3) Decide to pivot or persevere. (1) Initially an MVP will test the main assumptions and get feedback from customers. This feedback is qualitative and quantitative. Qualitative in the
4

Innovation diffuses across different social groups; Innovators, Early Adopters, Early Majority, Late Majority and Laggards respectively (Rogers, 2003). Moore(1998) adapted Rogers (2003) theory for technology products. He defines Early Adopters as people who like new technology products. In wanting to be first, they understand and accept new products bugs. They are comfortable in dealing with technology. Moreover, their purchase decision is based on them seeing the potential of new products.

27

sense that customers are able to express their opinions a lot better when they actually interacts with a product, this is one of the literature review outcomes. In order to get quantitative feedback i.e. measure results of launching an MVP, metrics should be in place. They are a set of reporting indicators that represent the drivers of the business growth model e.g. number of downloads for a mobile application or number of customers who used a website daily. This will provide the current status of how the business is doing and how far it is from what is desired. From this baseline progress can be measured and tracked. The purpose of a MVP is to enable product developers to test assumptions (ideas about what customers want and how to drive growth) and hence systematically figure out what to build using the least possible cost and shortest time. After a first MVP any further work on the product should lead to validated learning. (2) Once metrics data is collected from customers interaction with MVP, the baseline is established. It is time to start tuning the growth engine. A t this stage, product developers would have ideas (hypotheses) about how to improve the metrics. A set of experiments will be conducted to test those hypotheses by measuring their effect on the metrics. For example investing in making the product easier to use means that developers are assuming that making it easier to use will improve the new activation metric which is a growth driver that is currently below target. (3) If the experiment conducted to test the hypothesis did not improve the metrics of growth drivers then this idea is not making the product better. Also this direction of what product developers thought customers want should be questioned. A pivot should occur. Note how developers are learning from/about customers without directly asking them.

2.10 Chapter Summary

This chapter has reviewed relevant literature and laid the foundation of the study. In the next chapter we discuss the research design and methodology.

28

CHAPTER 3, RESEARCH METHODOLOGY

This chapter presents the detailed plan that guided the investigator in the process of collecting, analyzing and interpreting data in order to answer the research question (Yin, 1989). It discusses rational behind setting up the different parts of the research methodology including design, conceptual framework, data collection and data analysis methods. Since the research objective is to explore how the phenomenon under study occurs, using case studies is a preferred research strategy (Yin, 1989). A case study is an empirical enquiry that: investigates a contemporary phenomena within its real-life context (Yin, 1989, p. 23). Two case studies are here used to complement each others and our understanding of the topic, not as a way of representing a statistical sample that could be used to generalize the outcome (Yin, 1989; Robson, 2011).

3.1

Design

Table 1 depicts the two case studies design components as described by (Yin, 1989). The first three components are explained throughout this section. The new ICT product or service is used as a unit of analysis. The unit of analysis is neither broad nor narrow; it is suitable to study the phenomenon in its context. Furthermore, it would allow the research to build on previous studies on the field and finally to compare the outcome with other studies (Yin, 1989). Flexible research design has been associated with case study strategy (Robson, 2011). Flexible design strategy is used as the detailed design has evolved while data is being collected and analyzed. As non numerical data is mainly used, the research employs qualitative strategy and methods. Since the present research is not concerned with studying the difference between user engagement approaches used in products and services (if any) and the very definition of ICT as explained in the literature review signals the compound nature of ICT that includes products as well as services, the words product and service would be used interchangeably in the research to refer to intangible
29

software based products like web applications or a money transfer service via mobile phones. As the literature review concluded, the lean startup methodology embraces and potentially adds to past research on the topic. Accordingly, the present study would explore its use as a potential methodology that guides ICT product developers interaction with their users when developing new innovative products/services, in order to increase the chances of the products commercial success. 3.1.1 Case Study Selection The two products, and hence their companies, were not randomly sampled but rather chosen based on their potential to answer the research questions. Both are ICT companies. Also both products are new-to-the-firm (Booz, Allen and Hamilton, 1982) and may be regarded as innovative with an element of novelty; Case study 1s product addresses a market gap that no other product does. Case study 2s product was the first of its kind in the country and one of the early few in the region. Accordingly both companies faced high uncertainty in introducing the products into market. Case study 1 and 2 are explorative and explanative in nature. The first explores how the producer used lean startup methodology to engage with customers when developing a new ICT product that turned out to be commercially successful. Commercial success is defined as having an exponential growth in revenues. As Ries (2011) does not define what might be considered lean startup and what might not, research overcomes the epistemological concern of whether the approach used in case study 1 is truly lean by relying on the fact that product developers were consciously implementing lean startup methodology aiming to increase product success chances. Note that the same producer did not use the lean startup methodology when developing a previous ICT product that was not successful in the market. Initially
30

the research design included a third case study to explore the approach used to produce the unsuccessful product. However analysis of data collected about how the unsuccessful product has been developed could not establish theoretical replication between the successful and unsuccessful product case studies (Yin, 1989). User engagement in the latter was nearly absent. If marketing research was conducted to explore product ideas potential before development commences, as in a typical NPD model like Coopers (2001), the case would have been suitable as the primary factor that influenced the outcome would have been the use of lean startup methodology in the case of the successful product. Because of the flexibility in research design, investigator was able to adjust research to the exclusion of the unsuccessful product case study as initial data collection and analysis revealed its unsuitability to research objective (Yin, 1989). A brief summary for the development of the unsuccessful product is provided in case study 1 (see chapter 4). The producer in case study 1 is a startup company which allows research to focus on approach used in NPD (specifically customer engagement) as other factors that influence product success like brand name and well established marketing and sales organizations have modest effect. Also as the lean startup methodology is quite new, the author could not find an established company that has adopted the methodology in the development of a product that successfully went to market. From a user-producer perspective on new innovative ICT product development, startups as well as established firms share the high uncertainty in going to market. Case study 2 aims to capture how a typical established firm engages with users during development of a new product. It also provides an opportunity to theoretically test and refine the lean startup methodology explained in case study 1 in a different context with a more complicated product that requires the collaboration of cross functional teams. It is expected that applying the approach that worked on a startup would have implications on an established firm however the aim is not to replicate the exact approach but to further refine it and extract a conceptual outlook on the phenomenon under study.
31

Table 1- Case Studies Design Components NO 1 Research design components Study question Case study 1 How producers were engaging with customers when developing a new product? Case study 2 How producers were engaging with customers when developing a new product? Can the answer to Case study 1 question be applied to this case study? How? Approach to customer engagement of case study 1 can theoretically be applied to this case study. The application may improve NPD process and its outcome ICT product/service Describe new product development process including customer engagement activities and analyze changes applied to product after launch using concepts emerged from case study 1 Success criteria: Outline the process of new product development (including customer engagement activities). Test and refine concepts emerged from case study 1 by theoretically applying them to case study 2.

Theoretical propositions

3 4

Unit of analysis Logic linking data to propositions

Approach used to engage with customers led to successful market uptake of the product. Adopting such approach may yield success ICT product/service Analyzing how users were engaged during product development

Criteria for interpreting findings

Extract customer interaction approach.

32

3.2

Research Question Revisited

In light of the literature review and the research design we break down the main research question into two sub questions. Main research question: How can producers (product developers) interact with their users (customers) when developing new innovative ICT products/services, in order to increase the chances of the products commercial success? Main research question break down: 1. How an ICT startup that successfully produced an innovative ICT product/service interact with users throughout new product

development stages? Case study 1 which explores the use of lean startup methodology would answer this question.

2. Can ICT firms (not only startups) use the User-Producer Interaction approach that emerged from the first question to develop new innovative products/services? What are the implications on the approach and firms? Case study 2 would use the outcome of the first question to further explore the lean startup methodology.

Answering the above two questions would answer the main research question.

3.3

Conceptual Framework

Figure 2 describes the research conceptual framework. We start by doing a literature review aiming to first understand new product development process then review relevant literature to assemble concepts that could be useful in understanding how ICT firms interact with customers during new product development. Assembled concepts would inform the data collection and analysis of case study 1 and 2. Case study 1 would explain and explore the practical use of the lean startup methodology (that embraces concepts discussed in the literature

33

review stage). Completing case study 1 would form the basis for answering the first research question. Next, we apply developed concepts on case study 2. Case study 2 explores an established companys NPD process and how users are involved during development. By theoretically applying the methodology that has been elaborated in Case study 1, we aim to further develop the lean startup methodology and see if it can be extended to provide value for the established company. In the concluding chapter, we discuss and present the final methodology that answers the research questions.

3.4

Data Collection

A case study protocol for guiding the data collection, analysis and reporting has been prepared before data collection stage (Yin, 1989). It contains information concerning study objectives, researcher profile and data confidentiality arrangements. Moreover, it contains two sets of questions, one set per case, to maintain investigators focus on research objectives. Those sets served as questions for the interviews as well as check points that guided the whole data collection (including written evidence collection), analysis and reporting process. See Appendix A. Two data collection methods are used to build the case studies: (1) semistructured interviews because they aid the explorative nature of the study by allowing flexibility, on following- up on answers and new angles on the topic as they emerge, while maintaining focus (Kvale, 1996). (2) Qualitative content analysis for written material to complement and sometimes validate data collected via interviews. Case study strategy has the ability of dealing with a mixture of evidence (Yin, 1989). For case study 1, two in-depth interviews conducted via Skype coupled with a follow-up email interview with the companys founder (and product creator) were conducted. With interviewees permission, interviews were recorded to allow
34

thorough analysis. Each one lasted approximately 75 minutes. They have been used to understand in detail how the product has been developed from an idea until recently applied changes. Moreover, qualitative content analysis for products website (Buffer, 2012a), products blog (Buffer, 2012b), companys tweets on Twitter (Buffer, 2012c), products Facebook page (Buffer, 2012d) and dedicated user engagement website (Buffer, 2012e) have been conducted. The products website is used to understand product functionality and use; it enabled the author to use the product during research period. In order to understand how the company engages with users, content across the different user engagement channels in companys blog, Twitter, Facebook and the dedicated user engagement website have been analyzed. It worth mentioning that product developers share their experience in building the company and product on the companys blog which has been a valuable source of data to validate and complement other used data sources. In case study 2, three in-depth phone interviews with the product manager and one interview with the products project manager and technical lead have been conducted to understand how the product have been developed and how changes applied after launch came about. The former is the product owner and completely responsible of the product (except product technical development and operations). The latter is responsible of the product development project and all product technical activities during and after product launch. Also an engineer who is heavily involved in the technical development and operations of the product, in addition to the products technical lead have been asked to feedback on the technical do ability of some suggestions that emerged from applying the lean startup methodology on Case study 2. Furthermore, qualitative content analysis for product website and NPD process supplementary documents attached in Appendix B and C has been conducted. Note that, based on the company request, the company name, company website and staff of case study 2 referenced in this research would remain anonymous. Therefore aliases are used.

35

3.5

Data Analysis

As the last two components of case studies design in Table 1 show, analysis of case study 1 and 2 rely on their theoretical propositions (Yin, 1989). Case study 1 follows what producer has been doing from having the product idea until recent product development efforts that occurred in July 2012. Concepts assembled in the literature review stage (including lean startup methodology) are used as a general framework for analysis that enabled Pattern-Matching without losing flexibility to explore how the case study applies assembled concepts (Yin, 1989). In case study 2, general new product development process has been used as a descriptive framework to organize the analysis (Yin, 1989) of how the producer developed the product under study. Customer engagement activities have been explored on the framework i.e. during development stages. Changes implemented on the product after launch has been used to organize the theoretical application of lean startup methodology and related concepts. Changes are defined as product modifications or new features that aim to improve the product.

3.6

Chapter Summary

This chapter has discussed the research design and methodology. In the next chapter we discuss the first case study.

36

Figure 2-Research conceptual framework

Unit of of Analysis: ICT Unit analysis: ICTproduct productor orservice service Understand NPD/NSD. Review Assemble useful concepts relevant to User-Producer interaction in ICT. NPD/NSD. Review Review

Buffer, Inc.
Explore & Explain Case study1

Key literature

Company Z
Case study2 Explore & Explain

How the product was developed and how users were engaged is explored. Post-launch product issues are extracted.

Methodology that guides Review User-Producer interaction is elaborated

Describe

Apply methodology to Case study2 to test and refine it. Use methodology concepts to Identify issues in NPD process and causes of post-launch product issues. Verify if the issues can be solved theoretically by applying the methodology.

Research questions answered is described

37

CHAPTER 4, CASE STUDY 1

This chapter explores the implementation of the lean startup methodology through explaining the development of an ICT product called Buffer.

4.1

Introduction

Before having the idea for Buffer, the product of our concern in this case study, Joel Gascoigne co-founded One Page. A product that enables users to create, manage, exchange and store business/contact cards digitally (OnePage, 2012). It took four months to launch the first version. Product uptake was very slow. As soon as users create their One Page profile, there was no reason to use the product unless to update their contact details, something that occurred infrequently. Consequently, retention rate for customers was low. Product developers kept adding new features that they thought valuable without noticeable effect on growth. Informing customers about new features and changes to the product, was the primary goal of product developers interaction with customers. After 18 months of marketing and product development efforts, it was clear to founders that customers are not into their product. We basically built something that people did not want or need...if we talked to users and really tried to speak in terms of the problems they had rather than trying to present the solution that we come up with, which we imagined was something that solved a problem for people, I think we would have come up with a different product (Interview, Gascoigne, 4 June 2012). Gascoigne had another idea for a new product however this time he wanted to validate its concept early on and not to waste any resources on building something that no one wants. To do so, he adopted the lean startup principles in building Buffer.

38

4.2

Buffer: Product Background

The idea for Buffer, an internet based product, came out of a personal need. Buffer, Inc. founder, Joel Gascoigne is a heavy Twitter user who used to send many tweets about the interesting topics and stories that he reads every morning. He loved to share such content via Tweeter however he did not like flooding his friends (followers in Twitter terminology) with content around the same time every morning. He searched for products that would enable him to queue those tweets then actually tweet them on his behave on predefined times. There were no such products, the closest one would enable scheduling of each tweet by its own which is time consuming and difficult to do. Consequently he thought to build Buffer. As of July 2012, Buffer enables sharing on Twitter, Facebook and LinkedIn social networks. Users add content to Buffer then schedule sharing time on the social network of their choice. Buffer then automatically post content throughout the day. Upon installation, Buffer icon will appear on the bottom right corner of the users internet browser. To share content of any page, a user has to click on the icon then selects a social network for sharing (see Figure 3-using Buffer). Users can also change the schedule, reorder content on their buffer and manage service settings (see Figure 4-Buffer dash board). Buffer is also available on mobile phones for sharing content browsed on mobiles. Buffer is successful in the market and growing solidly (see Figure 5-Buffer growth in 2011)

39

Figure 3-using Buffer

Figure 4- Buffer dash board

40

Figure 5-Buffer growth in 2011

4.3

Product Development

4.3.1 First MVP In order to validate whether there is an actual need for the product without investing time and effort in building what product developer thought customer would want, Gascoigne built two web pages in one hour (see Figure 6- Buffer first
MVP). On the first page that website visitors land on, he described what the

product would do as if it existed. When visitors click on Plans and Pricing button they got a second page with an apology message saying the product is still under development. An option to enter ones email address to be notified when the product is ready also came with the apology message. The website was designed to keep track of the number of clicks per page and button. Gascoigne just tweeted (via Twitter) about the website asking people to try it out. He got about fifteen email addresses. He replied using his personal email address to all emails telling more about his idea of the product and stressing for feedback. Many conversations emerged through emails that provided insight on issues facing customers and how can they be addressed. Making the product description

41

clearer was an immediate result from received feedback. Some people did not understand the concept (Interview, Gascoigne, 4 June 2012). The feedback from the first MVP was enough validation that there is a need for the product. The next step was to validate whether people would actually pay for the product. To do so, a third page with three pricing plans was added in between the first two pages. So when visitors clicked on Plans and Pricing button on the first landing page, they got the pricing plans page. Upon clicking on any of the pricing plans, visitors would be directed to the apology page with the email collection option. See Figure 7- Buffer first MVP 2nd version. In seven days from having the idea, the MVP validated that there is a need for the product and people are willing to pay for it. It also provided learning about how much users are willing to pay. Furthermore, by adding an extra step that users have to go through to provide email addresses, the demand for the product has been confirmed.

42

Figure 6- Buffer first MVP

43

Figure 7- Buffer first MVP 2nd version

44

4.3.2 Second MVP (first product release) After the first MVP validated the idea, it was time to build the actual product using the feedback collected. Instead of spending too much time building a product with multiple features that may or may not proof to be valuable, the founder kept it at minimum. He boiled it down to a single feature representing the core of the idea. The first release of the product was a bookmarklet5 that can manually be installed on web browsers. It can be linked to a single Twitter account. It enabled customers to tweet directly once and queue up to five tweets per day. To get more, users have to pay using a $5 or $10 a month plans. Furthermore, instead of investing in the development of a payment system, the payment and upgrade process were done manually. PayPal6 was used to collect payments from users. When Gascoigne gets an email notification that a customer has paid, he went manually and upgraded the user account on the product so she has the premium features. Zero investment was made in marketing. People who previously expressed their interest by providing their email addresses were notified by email. Also Gascoigne tweeted about the product and what it does. At that time he had about 120 email addresses and 1700 Twitter followers. A week from launch 50 customer signed up and used the free version and 1 customer paid. In a month time (by Dec 2010) 100 signups and 4 people upgraded to the premium version. In Jan 2011 a marketing professional joined the company to be dedicated for product marketing.

A bookmarklet is a small computer application that is stored on a web browser. It is designed to provide a simple, often one-click, functionality to the browser e.g. the search bar on browsers that provides one-click search functionality without the need to browse to a search website then enter a search string. To be installed, a number of steps have to be followed unlike a browser extension that needs one-click to be installed and provides much better user experience (wikipedia, 2012a). After the first release, and thus validation of the product concept, Buffer became a browser extension with a different version per browser.
6

Paypal.com enables payment on websites. To be used on Buffer website, the founder needed to open an account on Paypal (easily done online for free) and put readymade lines of code provided by Paypal on Buffer website to enable payment.

45

4.3.3 Sources of Ideas Building a community around Buffer has been a core marketing activity for product developers. From analyzing user engagement channels, the author would say that a rich dialog between the company and not only product users but also anyone initiating a communication is ongoing and spans across many channels: Twitter, Facebook, product blog and email in addition to a dedicated website for user voice. Feedback about user experience with Buffer and suggestions for enhancements or new features is discussed in any of the channels. Any updates on the product (changes and new features) are communicated across the channels. Variety of content is also shared with users on a daily basis. Content topics range from the use of social media networks and tools to tips on personal productivity and life in general. Furthermore, customer technical support is also done through any of the channels depends on channel used by the customer. As of July the twenty second 2012, Buffer has 2,800 follower on Facebook and 62,622 on Twitter. Interestingly Buffer team also shares their experience in building the company and product with their customers through a blog which helps in fostering a sense of community among customers. People felt that they could influence the product future that is why they engaged (Interview, Gascoigne, 19 July 2012). As a result of the ongoing dialog, product developers got to know their customers. Moreover, intensive feedback about the product is always flowing as well as new ideas for Buffer development. Consequently, product developers were able to overcome the challenge of deciding what to build after the second MVP in order to drive growth and create a sustainable business out of Buffer. It came naturally! [We understood our customers] and people started asking for features (Interview, Gascoigne, 19 July 2012). Many requests for new features came in via the various channels including the user voice. Most of the time our ideas overlap with customers ideas, so we can go ahead and implement them (Interview, Gascoigne, 19 July 2012). User voice is a web portal for product users where they can suggest new ideas to improve Buffer. See Figure 8- Buffer user voice. Users can also comment and
46

vote on posted ideas. Product developers review all submitted ideas and respond to them. The number of votes provides indicators on the idea potential. Also the ability to add comments on posted ideas fosters a discussion among users and product developers. As of July the twenty second 2012, 55 user suggested ideas have been implemented. The founder paraphrased the quote: I do not know the key to be happy but the sure way to be miserable is when you try to please everybody (Interview, Gascoigne, 19 July 2012). The founders vision decides which bits of feedback to listen to, which requests to implement and how to prioritize new features. It is a bad idea to just implement everything that any person asks for because you soon end up with lots and lots of features and you do a lot and you do not do anything very well (Interview, Gascoigne, 19 July 2012). For example many requests which are specific to a user type have been received; marketing agencies that typically have many twitter accounts, unlike individual users, have different needs. Such requests have been turned down as Buffer, Inc. is currently targeting consumers not the enterprise segment. Customers suggestions are not the only source of new ideas. Many new features emerged solely out of product developers thinking, yet they had to be validated before development. For example no user requested a Buffer button that can be put on any website or blog to share content via Buffer (just like Facebook Like button on BBC news pages for instance). Next section illustrates the example in details. In summary, there are two sources of ideas for new features: (1) User suggestions that overlap with product developers ideas. Product developers judgment is used to select and refine ideas according to vision and strategy. The fact that ideas are suggested by customers provides enough validation for product developers to implement them. (2) Product developer suggestions. Validation is needed before development commence.

47

Figure 8- Buffer user voice

4.3.4 Product Development Efforts to Drive Growth (Build-MeasureLearn) To increase the number of new users, product developers thought about building the Buffer button. A baseline reflecting the product current status from a business perspective has already been established since releasing the second MVP and adding a number of new features. Clearly the baseline metric of concern here is number of new users. To tune the growth engine, product developers came up with the Buffer button idea. So the hypothesis was Building a button (with different versions to suite different types of websites) that enables sharing content through Buffer and placing it across blogs and websites would increase the number of new users. Before investing in developing many different versions of the button to enable many different types of blogs and websites, the idea had to be validated (especially that it has not been requested by users). Therefore, building a MVP version of the idea was the first step. Product developers spent about two hours in building a very basic button for Buffer that they put on their own blog. A key feature for such buttons is having counters that displayed how many persons shared the content however it was not part of the basic button since it was not
48

needed to get validated learning. Tracking buttons usage for a while enabled them to validate its worthiness and thus they built it. They continued to measure how many new users came in through using the button. Accordingly they added different versions of the button so it can be embedded on more websites. Product developers gained validated learning about how to make the product/business better. Adding the new feature successfully turned the growth engine so product developers persevered. This feature increased the number of new users significantly that Buffer, Inc. acquired a software component (called plug-in) that enabled popular sharing buttons on blogs (even more perseverance). Adding Buffer button to the plug-in made it immediately available on thousands of websites that has it installed. See Figure 9-Buffer button. Product developers had another idea to turn the growth engine; increasing users interaction with the product. The more value the product provides for users, the more they spend time on it, the more likely they pay for the premium version since Buffer would become the primary gadget for social content sharing. They thought to start with introducing a notification feature like what Facebook has. It notifies users with updates in their social network. The idea was to aggregate updates from Facebook, Twitter and LinkedIn on Buffer. On the one hand, using a quantitative metric to measure the effect of such a feature is tricky because the value it will add, if any, cannot directly translate to increasing number of users who convert to premium plans. Moreover, adding notifications is a first step towards making Buffer the primary gadget for social content sharing. On the other hand, there was no way to validate the feature before actually building it7. Product developers added the notifications feature that combines notifications from the three networks and observed engagement channels with users for qualitative feedback.
7

Although one could argue that adding notifications of one social network would have been enough to get validated learning, it is a matter of product developers judgment that adding notifications from the three social networks that Buffer support is the actual value (not one or two networks notifications).

49

We rarely heard people praising the feature, so we chose to kill it. We killed it in a lean way by just hiding it, but the code still existed. After two weeks only a single person had mentioned it being missing, so we removed the code entirely (Interview, Gascoigne, 26 July 2012). Product developers pivoted as soon as they learned that customers do not want the notifications feature. They removed the feature along with its code and they stopped development efforts in that direction i.e. making Buffer a hub for users different social networks. There were other thoughts we had to expand upon the initial notifications but we stopped all further development. Our assumption that it was actually useful for people was wrong (Interview, Gascoigne, 26 July 2012). Until recently, marketing activities were focused on getting the word out about Buffer on technology related blogs and websites i.e. targeting early adopters. Also building a community around the product, that fosters intimate customer experience, aims to generate word of mouth marketing, typically among like minded customer groups. It appears that currently product developers are preparing to cross the gap between early adopters and early majority called the chasm (Moore, 1998). As Moore (1998) suggests, focusing efforts on a niche segment in attempt to dominate it is the way to penetrate early majority market. Recently, product developers removed the higher end Professional pricing plan ($99/month). The only paid plan became the $10/month plan and has been renamed the Awesome plan, a more consumer friendly name. Because customers praised the change (qualitative validated learning) and numbers of customers converting from free to Awesome plan increased, the change has been kept. Moreover, feature requests from customers that are specific to marketing agencies type of user have been turned down. We pivoted our market segment from a mix of consumers, small businesses and marketing agencies managing social media accounts for many people. Instead, we pivoted to focus entirely on consumers and
50

small businesses. We noticed an increase in conversion to the $10/mo plan (Interview, Gascoigne, 26 July 2012) Ries (2011) describes a type of pivot called customer segment pivot that is needed as the product diffuses from early adopters to early majority since the latter has different needs. From analysis we extend the concept to depict the change of focus in product development activities to address a specific segment in an attempt to cross Moores chasm (Moore, 1998). As Buffer invades early majority market we expect another customer segment pivot to address a different set of needs.
Figure 9-Buffer button

4.4

Chapter Summary

The chapter shed more light on the lean startup methodology that has been introduced in the literature review. We now have a better understanding of the methodology main concepts; validated learning, Minimum Viable Product and
51

Build-Measure-Learn feedback loop. The next chapter puts the methodology concepts to test by applying them to another ICT product in a different context.

CHAPTER 5, CASE STUDY 2

This chapter puts the lean startup methodology that has been explored in the previous chapter to test. By trying to apply the concepts to a different and more complicated context, the chapter aims to advance our understanding of the methodology, test its applicability in a different ICT product environment and perhaps further refine the methodology. The chapter starts off by illustrating the NPD process that Company Z 8 used to develop an ICT product called RBT. It also maps out the user engagement points in the process. Moreover, the chapter applies lean thinking to analyze issues that faced/facing product developers. Finally lean startup methodology is applied theoretically to RBT development.

5.1

Background: Company and Product

Company Z is a mobile telecommunication service provider with operations in seven countries across the Middle East and Africa. The case study is about a product in one of its African operations. The product is called Ring Back Tone (RBT). Company Z was the first in the market to launch the RBT so it was newto-market and new-to-company as well. RBT enables mobile subscribers to change the standard ring tone that callers hear. If A is calling B, this is the tone that A hears until B answers the call. Initially Customers were able to interact and manage the service through calling

Based on Company Zs request, the company name and staff referenced in this research remain anonymous. Therefore aliases are used.

52

Interactive Voice Response (IVR) system9. It enables customers to subscribe, browse the tones catalog, purchase and record a personal tone. Customers can also assign different tones for callers. Moreover, a customer can purchase a tone for another customer as a gift. The gift can be rejected or accepted. Customers pay for the following actions: subscription to service, subscription renewal every month, buying a tone, renewal of a purchased tone every month and dedicating a tone to another customer. Currently, in addition to the IVR, customers can manage the service through SMS and via Company Zs website.

5.2

NPD Process: the Case of RBT

The marketing department of company Z is the product owner. They initiate the NPD process and manage the product from a commercial perspective after launch. Cross functional teams are involved in the process however the IT department is responsible of turning the marketing department idea into an operating platform. The following is a summary of Company Zs standard NPD process that has been used to develop the RBT, based on interviews with the RBT product manager. 1. New product initiative Ideas for new products emerge from different sources e.g. scanning trends in the industry and competitors. New products are the vehicle of the growth strategy. The RBT has been a popular new service in the region but was not present in the local market. Music is popular here and classical ring tone services were very popular among our subscribers (Interview, Aimy, 1 July 2012). 2. Marketing research Its objective is to check if the market will accept the new product and in which price range. Focus groups, typically in batches of maximum10 persons at a time, are conducted to explore the product potential. Participants are selected from the initial target market, youth in RBT case. Questions are
9

Interactive Voice Response (IVR) system allows the RBT platform to interact with humans through the use of voice and mobile phone keypad. Users hear all the functionality available to them and can respond by pressing the appropriate key in their mobile phones. Definition adapted from (Wikipedia, 2012b).

53

carefully formulated so as to keep the privacy of the initiative from competitors. At this stage details about the shape of the product are not known and focus groups are not asked about desired product functionality. 3. Business case In simple terms, its goal is to explain to the top management why the company should build the proposed product. It justifies the cost of building and taking the new product to market. Moreover, it demonstrates how the product fit in the corporate strategy and that it will yield viable profits. The business case document contains product description, product corporate strategy fit, pricing, market forecast, overall cost (capital expenditures and operational expenditures including marketing communication) and break even analysis (typically breakeven should occur in 18 to 24 months). Cost is estimated based on initial quotation from vendors (RBT platform providers). Market forecast is based on products in the same category which are already in the market. There were no products similar to RBT so forecasting was based on customers who use value added services10. Those formed the initial number of users who are expected to adopt the new product. Growth was estimated organically to be about 1% monthly. Also seasonal boosts in product use are incorporated. Note that pricing is determined based on marketing research (focus groups) results and payback period i.e. it is a synthesis between what customers could/would pay and what makes the business profitable. See Appendix B for an executive summary version of the business case financial template used by Company Z. Next stage is entered upon top management (marketing, sales, IT, network and finance directors) approval. 4. Initial product concept specification The product owner from marketing department compiles the product concept document that describes the product functionality and features in details; how
10

Value Added Services is a general category that hosts all services offered by a telecommunication service provider other than voice and SMS services. For example, video calling and voice mail services.

54

it supposes to operate, how customers are charged e.g. subscription or usage based, what are the business rules e.g. pay-as-you-go customers have to have a minimum balance to be allowed to use the product and so forth. Marketers use multiple sources to compile this initial concept paper: Accumulated knowledge about customers and what they generally need, RBT specification documents from multiple vendors, description of similar products launched in the region and general guidelines that emerged from early customer focus groups are used. 5. Concept formulation At this stage a product champion from IT department takes the lead. From now on the concept paper is used to communicate with all product stake holders in the company: Technical teams (IT, Network, Billing, etc), customer care team, marketing communication and revenue assurance team 11. Each team has a different perspective and concerns about the new product. For example, from experience in dealing with customers, customer care team typically add some requirements that enable them to better respond and help customers as they are the first line of contact. Also each technical team will feedback on what can and cannot be done. So the input of all teams would shape and perhaps change the initial concept however not from a customer standpoint, as much as possible, but rather from an operational perspective. That is requirements that reflect each functional teams need to operate with the new product. Finally all teams reach a consensus and agree on a final product concept which will be used to technically develop the product, upon top management authorization of the final product concept. Note that in rare cases the business case has to be updated and resubmitted along with the final product concept paper for approval. This may occur because of significant changes in the finances as new information emerges.
11

Revenue Assurance team is responsible of ensuring that all revenue generating systems are free of fraud and bugs that may affect revenues. Because of the high complexity in the interconnection between multiple systems, a dedicated team is needed to make sure that customers are charged accurately by reconciling multiple systems.

55

6. Development Technical development is a process by its own. The IT product champion works with technical teams to develop technical design and specifications. Then proposals are requested from different vendors to build the RBT platform. This stage ends with successfully testing the product from a technical standpoint. 7. Pre launch Testing is done by marketing team to make sure that the product meets what has been agreed on in the final concept document. Also marketing communication plan is prepared. 8. After launch The product marketing team has two main duties: (1) Manage all activities related to the product, except the technical aspects, to ensure sustainable revenue that is equal to or greater than forecasts. Such activities include monitoring market product uptake. (2) Drive revenue growth by making necessary changes to product, including the introduction of new features.

5.3

RBT Launch: Analyzing Challenges and Product Development Efforts

This section discusses customer involvement during NPD as well as product development activities that occurred post product launch. It also describes the challenges that faced product developers as a result of launching RBT and how they tackled them. 5.3.1 Customer Involvement in NPD The described NPD process that delivered the RBT is similar to Crawford & Di Benedetto (2006) model; customer engagement occurred before development stage. Surprisingly, the degree of involvement may even be regarded as light. The author tried to get the actual questions used in the focus groups to validate how general they were but data was not available. Concerns about product idea leaking
56

to competitors in addition to product owners (marketing team) vast experience with the local market are justifications mentioned when author enquired about reasons behind the light level of customer involvement. A main theme has emerged from the discussion: RBT was very successful in adjacent markets. For sure what worked in a neighboring country will not necessarily work in ours. However, in the RBT case the customization is about bringing relevant content not about the product-user experience itself (Interview, Aimy, 1 July 2012). Furthermore, targeted customers are actually Company Zs subscribers; meaning that RBT customers were already known, to some extent, since they are actually a subset of the total customer base. On the contrary, Buffer was unlike anything in the market and therefore Buffer.inc, had no clue whether there will be any demand and hence they had no idea about their customers. In fact Company Z can easily reach potential RBT customers; before the start of the launch advertising campaign, Company Z broadcasted an SMS to its entire customer base, bearing zero cost, informing them about the new RBT service. As a result, considerable number of subscribers joined the service. Consequently, it would be more accurate to change RBT classification from New-to-the-firm (new product lines) as initially categorized in the research methodology (see chapter 3) to somewhere in between New-to-the-firm(new product lines) and Addition-toexisting-product-lines (not significantly new-to-firm) as per Booz, Allen and Hamilton (1982) new products classification. Nevertheless, RBT is completely new to the local market. The author was puzzled since with a completely new to market and partially new to company product; one would have expected a heavier degree of customer engagement perhaps during and post development, especially that RBT launch was very successful in the market that it paid back the platform cost in a few weeks time. However more in depth analysis followed by more discussions with product development team in marketing and IT, revealed interesting issues.

57

5.3.2 Product Development Efforts Post- Launch The overwhelming success turned into a serious issue a few weeks post launch. The number of actual users exceeded the RBT platform capacity drastically resulting in poor service quality and fulfillment; RBT subscribers were not able to use the service nevertheless they have been charged. It took several months for platform expansion to take place during which service reputation was negatively affected. After stabilizing the service and heavily advertising, revenues were increasing steadily. At this stage, marketing team efforts turned to focus on analyzing customer complains aiming to spot patterns and issues that warn changes to the product. As a result, three changes (content provider bulk upload, IVR flow change and Product owners to control which content category can content providers upload tones to) have been implemented. As analysis would reveal in the coming sections, those changes are all direct outcomes of platform users interaction with the actual product. Platform users are customers, product owners and content (tones) providers. Note that from a technical perspective each change is a project on its own. The RBT platform is integrated to two billing systems, many elements of the mobile network, CRM and revenue assurance systems. We have to study the impact of each change on the RBT platform itself in addition to all those systems to manage the interdependencies. Moreover we have to pay the RBT vendor per change since those changes need development and reconfiguration. Not to mention that sometimes vendors of other systems should be involved should changes require modifications on other systems. A financial impact is likely in such case. Furthermore, it takes effort and time to iterate through reconfigure, test and go back to adjust development loop until the change is successfully accommodated and finally rolled out to all subscribers (Interview, Hakeem, 3 July 2012).

58

On the other hand, it appears that implemented changes had some positive effect on revenues. At least the number of customer complaints declined. 5.3.3 Product Development Efforts to Drive Growth After all changes emerged from customer complaints analysis have been implemented, it seemed like no more complaints reflected a need for more changes. Product development efforts were derived by either product owners initiatives or marketing research that collected feedback from customers. A unit called customer satisfaction is responsible of conducting surveys via phone and personal interviews to measure and identify areas of improvement in the RBT. Detailed information from diverse representative customer samples is collected regularly and cross checked with customer complaints. Non RBT subscribers were asked why they do not opt for the service, loyal subscribers were asked about what they like and dislike, customers who subscribed but did not buy tones were asked of the reason, and customers who tried it once then unsubscribed were interviewed and so on. Customer feedback in addition to new initiatives resulted in more changes and new features that have been introduced however without much effect on revenue growth.

5.4

Introducing Lean Startup to RBT Development

In this section more analysis is conducted through the eyes of lean startup principles for all changes implemented to the RBT product after launch (see Table 2 Validating Post-Launch RBT Changes). Moreover, lean startup methodology is theoretically applied to RBT development aiming to improve the process and its outcome. Introducing RBT to the market was less uncertain, compared to Buffer, because a regional experience with similar products existed. Moreover, Company Z had a better visibility on potential RBT customers. In addition to the less uncertainty involved, RBT is not developed in house but is sourced by a third party. The fact that RBT vendor is not a custom software

59

developer, but rather a platform provider with a readymade product, coupled with the complexity of the platform integration with existing systems suggest that a slightly different type of MVP, compared to Buffer, would be suitable. 5.4.1 An MVP for the RBT An MVP is suggested to be an off-the-shelf RBT platform from a vendor. The platform would be on a small scale serving a limited number of users. As no customization is requested from the vendor, the MVP would be ready within a short period of time. Product developers may utilize their existing knowledge of customer needs in configuring the off-the-shelf RBT platform, an option that is usually provided by platform vendors. From a technical integration perspective the MVP would enable the same amount of learning that technical teams had to acquire while working with a larger scale platform. This ground has been confirmed by Hakeem who was the RBT project manager and technical lead (Interview, Hakeem, 8 July 2012). Having the users interacting with the MVP, Company Z would have a better chance to estimate demand thus preventing service overload and its negative consequences. Increasing the IVR tariff was an attempt to improve the service quality so it could probably be avoided by the MVP use. Additionally, analyzing each of the three changes that surfaced from customer complains analysis, we would strongly argue that user interaction with the MVP could have revealed them: (1) The old IVR flow had long prompts at the start unnecessarily describing the service, many sub menus had no back-to-previousmenu option so customers had to return to the very beginning to listen to the long prompts and many other issues that made it difficult for customers to navigate the service options. (2) As soon as content providers (third parties who provide tones) used the platform they complained that it only allowed them to upload one tone at a time. They had to fill in five fields of tone information each time then wait for upload to be finished. Note that they typically upload hundreds of tones frequently. The change enabled content providers to upload bulk of tones in one step. (3) The new change provided product owners more control over content
60

providers by limiting their access to certain tone categories. Beforehand, content providers were able to upload tones in any category which created chaos. Just like the other two changes, the need for such control was clear as soon as product owners and multiple content providers started to actively use the platform. Developing the changes would probably have taken the same amount of time from the vendor as they actually did however iterating through the reconfigure, test and go back to adjust development loop would have been much faster because the platform is not in full production.
Table 2 Validating Post-Launch RBT Changes

NO

Change Summary

Change Source

Change Launch Date (Approx)

1 2

Add SMS channel Platform expansion

product owner initiative Technical team

Jul-2007 Oct-2007

IT Team Feedback ; can change be validated before development? yes N/A

Comments

MVP result in better estimation

CP bulk upload

Customer complaints

Oct-2007

IVR flow change

Customer complaints

Feb-2009

5 6

New features: Wish and Beg Increase IVR tariff to reduce load

product owner initiative product owner initiative

Apr-2009 Apr-2009

N/A as change may have been discovere d by MVP N/A as change may have been discovere d by MVP Can not N/A Even after expansion IVR channel was 61

NO

Change Summary

Change Source

Change Launch Date (Approx)

IT Team Feedback ; can change be validated before development?

Comments

overloaded. Change may have been avoided by MVP 7 Product owners to control which tone categories CP can upload to Customer complaints 2010 N/A as change may have been discovere d by MVP Can not

Remove authentication with a pin code from service flow

customer satisfaction & complaints

Mar2010

Super SMS command

10

Partnership with a major content provider & changing the IVR flow to accommodate it Product owners to be able to change the order of tones in the IVR so customers can easily find tones of potential high demand Corporate RBT

customer satisfaction & complaints senior management

2010

yes

Apr-2010

yes

11

product owner initiative

May2010

Can not

12

Aug2010

yes

Product owners could have experimented with the readymade version of 62

NO

Change Summary

Change Source

Change Launch Date (Approx)

IT Team Feedback ; can change be validated before development? yes

Comments

CRBT 13 Website integration product owner initiative 2011

5.4.2 RBT Growth Issues Revisited Discussions with marketing team about how do they find out whether the changes implemented, be it new features or product modifications, are effective and actually making the product better, suggest that in reality they never knew for sure, and this is probably why they seem to be frustrated with sustaining product growth. Changes come primarily as a result of: (1) Product owners initiatives when they think of a new feature or learn about the availability of a new one from the platform vendor. (2) Customer satisfaction surveys which might be triggered periodically or based on owners ad-hoc requests. Once decided on building the change, the product owners attention would turn to testing the change, after it had been developed, to make sure it works as requested. Next, they would be busy devising advertising campaigns to make customers aware about the newly implemented change. They would anticipate some positive market traction appearing in the forth coming monthly report however there is no pre set expected growth rate to compare against and thus evaluate the effect of the applied change. Product and hence product owners performance depends on meeting an annual revenue target for the product that is broken down to be tracked per month i.e. performance is not tide to product development efforts. From product owners perspective, the change has already been implemented so unless it is negatively affecting revenues, there is no reason to undo it.

63

Another serious issue was discovered when asking product owners how they evaluate the effectiveness of new changes applied. They use vanity metrics as Ries (2011) describes reporting indicators which give a positive general picture of the business. In the RBT case, total number of active subscribers and total revenue were mainly used as performance indicators. During interviews product owners explicitly mentioned that RBT is sensitive to customer awareness, so how do they know for sure that the boost in the total revenue for instance is a direct result of adding a new feature not because of advertising accompanying the new feature launch which increases the awareness about the product anyways? Total number of active subscribers and total revenue metrics are not adequate to establish a clear cause and effect association to evaluate product development efforts. From analyzing the list of changes implemented it seems like two main drivers were behind the majority of changes; make it easier for customers to interact with the service (mainly to subscribe and buy tones) and enrich the tones library. However the changes implemented have not been validated empirically to see if they successfully tackled the issues. Moreover, significant investment in time, effort and money have been put in developing and deploying those changes without making sure if they were the right thing to develop in the first place. 5.4.3 Applying Lean Startup Methodology to Drive RBT Growth We discussed how to build and launch an MVP and demonstrated how validated learning would have been useful. This section continues product development efforts following the Build-Measure-Learn feedback loop. The section would present all changes that have been applied to RBT post-launch (see Table 2
Validating Post-Launch RBT Changes) and discuss the applicability of lean startup

methodology to each change; the following learning milestones would be followed on each change: (1) Establish baseline. (2) Tune the growth engine using acquired validated learning. (3) Decide to pivot or persevere

64

Adding SMS Channel and Super SMS Command Changes

Instead of using vanity metrics of total number of active subscribers and revenue, a metric like the number of new subscribers within a defined time frame is suggested as a growth indicator. Launching the off-the-shelf RBT platform as an MVP would establish the baseline; assume that the number of new subscribers every 2 weeks metric has 20 subscribers whereas 40 new subscribers is desired as a healthy growth indicator. A customer satisfaction survey suggested that customers find it difficult to deal with the service through the IVR. Moreover, accessing it was very difficult because of the capacity problem. Instead of deciding that adding a new SMS channel would solve the problem and start its development, a falsifiable hypothesis reflecting that could be formed; since RBT is mainly targeting the youth segment who uses SMS extensively, enabling customers to interact with RBT using SMS would achieve the desired growth indicator (40 new customer every 2 weeks), especially that SMS channel would be free of charge unlike the IVR channel . Before the IT team start studying the change with other technical teams and eventually engage with the vendor to develop the not-free-of-charge new feature, a simple experiment could be conducted. IT team could broadcast an SMS to one hundred non RBT customers, for instance, informing them about the RBT service and mention two ways to subscribe: calling the IVR or sending an SMS. Measuring customers response would empirically validate the hypothesis. As per the IT team, customers who used SMS to subscribe could be extracted from the system and manually be subscribed. The present SMS feature provides all functionality that is provided by the IVR. If the first experiment supported the hypothesis, more experiments extending customer interaction with RBT through SMS would be conducted i.e. persevere. For example, next experiment might target RBT subscribers to check if they prefer using the SMS over IVR to buy new tones.

65

Similarly, Super SMS Command feature could have been validated. It enables non RBT customers to subscribe, buy and activate a tone by sending a single SMS command instead of three different commands in the past i.e. it makes using the SMS channel easier. In case the first experiment proved the hypothesis wrong (Adding SMS channel would increase number of new customers), Company Z would have saved resources which have been used in developing the two features (SMS Channel and Super SMS Command). Equally important, product owners would have learned facts about what customers really want. They could conduct in depth personal interviews with customer who did not want to use the SMS channel to shade more light on the matter and perhaps form new hypothesis about what customers want i.e. what might turn the growth engine. Note that the Super SMS Command feature would be the next logical hypothesis to be validated should Adding SMS Channel feature is proven to turn the growth engine i.e. persevering from the latter would logically lead to experimenting with the former. Likewise, pivoting from the Adding SMS Channel feature makes the Super SMS Command idea invalid.
Partnership with a Major Content Provider Change

In an effort to enrich the tones library, Company Z signed an exclusive deal with a major records company in the region that cost a big sum of money. Content purchased made very little sales. Although product owners were not excited about the idea, they agreed to it because a very senior executive was pushing it forward. We would argue that applying the lean startup methodology could have made a difference in such a situation. The hypothesis is that RBT customers are lacking the type of content provided by the record company. Consequently adding such content would increase number of purchased tones and may even increase number of new customers resulting in revenues that make the investment worthwhile. Perhaps getting the latest ten tones from the suggested category then directly offering them to a suitable group of customers, by phone or SMS, would have validated the hypothesis. Instead of speculating about the quality of an initiative, which leaves room for debate, applying the lean startup methodology would
66

provide empirical data to evaluate the merit of new ideas regardless of who recommended them.
Adding Web Channel Change

Another instance where lean startup methodology would have added value is when a third channel for customers to interact with RBT (after IVR and SMS channels) was added; fully integrating Company Zs website with RBT platform so customers are able to perform all RBT actions online, was another change implemented on RBT. Although product owners were almost sure that adding the web channel will have very little effect on RBT revenues, senior management were enthusiastic about it as part of building a new website for the company. On the one hand, integration incurred no charges by platform vendor since integration utilities were already in place, nevertheless IT engineers spent considerable time and effort working on the integration. On the other hand, major development was required on the website which had financial implications on Company Z. The main argument that supported the change implementation is the need to enhance the corporate image by having a modern website that allows customers to have almost all services that they could have on a physical service outlet. As expected, adding the web channel almost had no effect on RBT revenues. We would argue that applying the lean methodology to product development initiatives which are not triggered by product owners, would improve the decision making process even for a hard-to-measure objective like enhancing the corporate image. We would start by forming a falsifiable hypothesis; enabling customers to interact with RBT through the website would improve the corporate image. Also a metric would be set; number of customers engaging with RBT through website. Inspired by Buffer case study, a button can be placed on Company Zs website to test the hypothesis. For instance, it could say click here to use the RBT service then directs users to two options: Click here to subscribe to RBT and Click here to buy a tone. The two options will lead to pages with written instructions on how to perform the appropriate action via established channels like IVR and SMS. Measuring the number of clicks would have helped in evaluating the merit
67

of the idea without going through the actual integration and development, to enable all RBT actions on the website. Accordingly, management could decide to pivot or persevere.
Corporate RBT Change

CRBT enables all employees (or groups of employees) in a Corporate to have a similar tone during business hours. The tones are set, managed and paid for by the Corporate. It provides a new way for companies to represent and promote their business to people who are calling their employees. The product has failed in the market; it failed to attract more than a few customers and eventually failed to retain them. It seems that the marketing research has provided misleading results. Significant investment went on development (including changes to a billing system to accommodate CRBT) only to discover that no one wants the product after launch. Rather than wasting resources in developing CRBT, product developers could have launched the readymade version of CRBT (included as part of the RBT platform) without any customization and integration efforts (including changes to the billing system) as a free trial for customers. Using customers feedback, product developers would have been in a better position to kill or pivot the idea before committing irretrievable investment.

5.5

Issues in Applying Lean Startup Methodology in RBT Development

According to the IT engineers the following three changes cannot be technically tested or simulated unless the actual changes are implemented: (1) Product owners to be able to change the order of tones in the IVR so customers can easily find tones of potential high demand e.g. tones related to seasons or events like world cup or new years eve. (2) Removal of pin code authentication from service flow to make the service easier to access through IVR. So customers do not need to remember pin codes and enter them each time they want to interact with the

68

service via IVR. (3) New features wish and beg. They both aim to increase number of purchased tones. Wish enables customers to make a wish list of tones that can be accessed by others. Beg allows a customer to ask another customer to buy her a tone. The three changes did not have a noticeable impact on RBT revenue. As illustrated by Buffer case study, changes are made to tune the growth engine and hence directly rev it or because customers want them (hence indirectly rev the growth engine). Even if a change did not turn the growth engine (directly or indirectly), it would provide validated learning about how to do so. In the RBT case, despite the inability to experiment with some changes before developing them, validated learning would be acquired from implementing the changes. To pivot means to (1) undo the change, because from a technical standpoint, more code makes maintenance and future changes design more complex and hence costly. (2) Change the direction in search for a change that will make the product better i.e. rev the growth engine. Starting from a MVP, product owners would start learning about customers and hence will try to tune and rev the growth engine. Each attempt builds on previous ones and should knowingly bring the product development efforts closer to what customers want. So following the lean startup methodology, may or may not lead to those three changes.

5.6

Advantages Development

of

Applying

Lean

Startup

to

RBT

Above discussion suggests that lean startup methodology is applicable to Company Zs product. Here is a summary of the advantages that the methodology may bring: Cost saving. The essence of lean thinking is not to waste anything that does not contribute to what customers need. As demonstrated, applying the methodology could have prevented many cost incurring changes that have been applied on RBT. Note that changes add complexity to RBT platform hence cost of future maintenance and changes increase.

69

Lean startup provides a discipline that validates ideas merit empirically. Methodology implementation aids the discovery of weak ideas before heavy investment regardless of the source of ideas. Company Zs current NPD process requires product owners from marketing team to describe the new product in details i.e. functionality, features, etc early on the process. Technical team would translate such description to technical requirements, specifications and design. Any late changes from marketing team cause issues as technical work needs to be reworked. Moreover, cost and development time increases as contracts with platform vendors is based on early technical work. In reality changes are inevitable as market dynamics change rapidly and detailed description cannot simply be prepared from the beginning as product ideas are crystallizing. Applying the methodology as described would accelerate the product introduction to market at the same time the outcome is a product honed by user implicit and explicit needs. Platform capacity planning for new-to-company products is challenging since no similar product exist to benchmark with. Consequently it depends on marketing uptake forecast which might be flawed. Using the methodology provides more accurate estimates resulting in the avoidance of negative consequences of building an oversized/undersized platform. In conclusion, analysis suggests that engaging with customers using the lean startup methodology is expected to drive RBT growth and assist in realizing its full potential.

5.7

Chapter Summary

The theoretical application of the lean startup methodology in RBT development has shed more light on the methodology. It also suggests that it may well be applicable to an established company. Implications of adopting the methodology by Company Z as well as how the case study refined the lean startup methodology are discussed as part of the next chapter, Conclusion.

70

CHAPTER 6, CONCLUSION
In this chapter we present the lean startup methodology that emerged from the two case studies; research contribution towards understanding how lean startup concepts might be applied and refined is summarized and crystallized. Furthermore, practical implications of adopting the methodology are discussed. We also point out research limitation and future directions.

6.1

Research Questions Answered

This research suggests that lean startup methodology is the answer to the first research question, how startups that produced innovative ICT products or services interact with users throughout new product development stages. The Buffer case demonstrated how lean startup methodology can be applied to develop a successful product. The RBT case tested the methodology in a different context and refined it. Analysis demonstrated that applying lean startup methodology in RBT development would have prevented issues encountered upon product launch. Furthermore, applying the methodology exposed current issues and suggests alternative approach to RBT development. Applying the methodology does have implications on the product development organization of Company Z as summarized towards the end of this chapter.

6.2

The Lean Startup: A methodology for User-Producer Interaction

In this section we summarize and crystallize the methodology that emerged from the two case studies.

6.2.1 Minimum Viable Product (MVP)

As the two case studies showed, the objective of an MVP is to discover whether the product provides value to customers that they are willing to pay for and earns the company a viable return, using a minimum amount of resources. In Ries (2011) terms, an MVP aims to validate the product value hypothesis. How minimum should it be is a matter of judgment. It could be as simple as a web application that took seven weeks for an individual to develop on a part time basis as in
71

Buffer case. It could also be complicated as the RBT that needs the collaboration of cross functional commercial and technical teams and investment in outsourcing the technical development to a third party. In Buffer case scaling up the product was not an issue unlike RBT. Because of the highly complex technical nature of the RBT, a soft launch period is needed where the MVP is released to a limited number of users. Therefore RBT product developers need to decide on a cutoff point where the latest MVP would be technically scaled up and launched to all customers. As Buffer illustrated, an MVP is embraced by early adopters suggesting that product developers should target technology enthusiasts when marketing the MVP. Those are the customers who have the treats of Early Adopters as described by Moore (1998)12.

6.2.2 MVP Versus Marketing Research to Validate Ideas

The marketing research conducted to substantiate the RBT product idea was, to a great extent, aiming to support product owners believe in its merit, and Company Zs NPD process rather than to genuinely find out if the new product will sell and in what volumes. Primarily, RBT product owners relied on the regional success of the service to justify its introduction into the local market. Nonetheless, the same approach failed in bringing the corporate RBT to market. Certainly there has been a demand for the product, however in volumes that exceeded the forecast causing negative consequences. Company Zs case demonstrates that marketing research can be biased and flawed. On the other hand, the idea for Buffer was by far newer than RBT meaning that product developers had no idea about potential customers. Consequently a marketing research outcome might be regarded as less reliable. Using an MVP in
12

Early Adopters are users who are enthusiastic about new technology products. In wanting to be first, they understand and accept new products bugs. They are comfortable in dealing with technology. Moreover, their purchase decision is based on them seeing the potential of new products (Moore, 1998).

72

Buffers case empirically validated the concept. So arguably, the more uncertainty is involved in bringing a new product to market, the more useful the use of a MVP to validate the idea would be, the less useful marketing research would be and vice versa. Nevertheless, marketing research is useful in exploring the idea preliminary. It may be enough to kill the idea or change direction early on. Also, its outcome would form the basic product concept and hence the MVP. In the case of Buffer, although the founder did not label his initial activities as marketing research, he searched the market for products that address the needs he felt. Moreover, he tried the products he found however they were unsatisfying. In the RBT case, a MVP is more expensive to build so a marketing research would be valuable as a first step to validate the idea and develop product concept before committing resources into transforming the concept into an MVP.

6.2.3 Systematically Figuring Out What to Build

Provided that the value hypothesis has been validated using the MVP, the next step is to figure out how to drive growth using the Build-Measure-Learn cycle (Ries, 2011). As what have been released to customers is an MVP rather than a perfect product by developers perception, product developers should avoid the temptation to start building on things that they think improve the product. In order to apply the Build-Measure-Learn concept, the below process is suggested. See
Table 3 that uses examples from case study 1 to demonstrate how the process

works. (1) Have an idea. It starts by having an idea of how to improve the product. Ideas can emerge directly from customers e.g. feature request or indirectly from engaging with customers e.g. analyzing many requests or complaints from customers. Also they emerge from product developers sole thinking. (2) Validate idea against vision and strategy. This is the first step to verify ideas. Engaging with users does not imply implementing all users requests but rather

73

synthesizing product developers vision and strategy13 with what customers want and accept. (3) Form falsifiable hypothesis in order to clarify the idea and its objective. A hypothesis also establishes a clear cause and effect relationship and triggers thinking about how to measure effect. While desirable, not all ideas can directly result in improving growth metrics as demonstrated in Buffers case. Nevertheless, their implementation seems to make sense for two reasons: (1) ideas came out of customer needs and they would be empirically validated to fulfill these needs. (2) Ideas are formulated to provide validate learning. For example, attributing improvement in the number of new customers or retention rate cannot be directly attributed to the implementation of Buffers combined notifications feature. Similarly, making the box that allows users to add content to Buffer movable on the computer screen cannot directly affect growth metrics. However the ideas came from understanding customers needs, through direct or indirect engagement14, and are empirically validated to address such needs. They also provide validated learning15 that feed in the product strategy and thus influence formation of future hypotheses. (4) Build enough to get validated learning15. Always try to get validated learning, whether it is qualitative, quantitative or both, using the least amount of development effort. While not every idea can be validated before it is actually built a pattern can be recognized in the variety of forms that enough building took in the two case studies; an idea may be broke down into smaller hypothesis that can be tested one at a time. If a hypothesis proved not to be a good idea then a partial amount of effort has been exerted. Adding Buffer support for different
13

Author views strategy as the guidelines that realize the vision. It governs all product development efforts. It is dynamic and it is updated using gained validated learning.
14

Users votes on their requests and patterns in users complains are tools that help in prioritizing and deciding on the worthiness of ideas emerged from engaging with users.
15

Validated learning: As discussed in the literature review and the case studies, learning about what customers want and how to improve product is gained from customer interaction with product. It is validated because it results from empirically testing a hypothesis.

74

social networks in turn, building the combined notifications feature in Buffer before building anything else to centralize the management of social networks and manually performing a single RBT action through SMS are a few examples. A good example for the notion of enough building is how the Buffer button was developed from a two hours development outcome to the acquisition of a venture. (5) Measure. The RBT case demonstrated the danger of using vanity metrics to measure the impact of product development efforts. Furthermore, a baseline is needed to be used as a point of reference before the impact can be measured. (6) Use validated learning to pivot or persevere. If the idea proves successful in revving up the growth engine (or is accepted by customers), product developers are encouraged to persevere (keep deployed change, continue its development and perhaps next hypothesis would be on the same direction). Otherwise, they pivot (deployed change is reverted and direction or strategy behind it is questioned and perhaps changed). Note that validated learning is used to update strategy, and this is how it may be used to steer future development efforts. Customer segment pivot denotes the transition from addressing early adopters needs to early majority needs that are fairly different.
Table 3-Build-Measure-Learn Process Driving Buffers Growth

NO

Idea

Idea Source Product Developers

Buffer button

Validated learning type Quantitative

Build-Measure-Learn Process Outcome Implement. Positive quantitative feedback results in perseverance. Iterate in steps 3 to 6 until idea implementation is complete Pivot occurs in step 6. As a result, strategy is updated as follows - product development efforts should not aim to make Buffer a hub for social networks. Implement. Positive
75

Combined notifications

Product Developers

Quantitative & Qualitative

LinkedIn

Product

Quantitative

NO

Idea

Idea Source Developers & Customers

integration

Validated learning type & Qualitative

Build-Measure-Learn Process Outcome quantitative & qualitative feedback results in perseverance i.e. integrating more social networks (currently Google Plus integration is underway). Implement. Positive qualitative feedback results in perseverance i.e. feature to be kept Implement. Positive quantitative & qualitative feedback results in perseverance i.e. change to be kept Do not implement. Exit from step 2 (Validate against vision and strategy). Note that success of idea #5 supports the strategic direction of focusing on consumer segment hence this idea is rejected.

Enable editing buffered posts while in queue Price plan change (the Awesome plan) Feature requests from marketing agency type of user

Customer

Qualitative

Product developers

Quantitative & Qualitative

Customer

N/A

6.3

Converging the NPD Process and Lean Startup Methodology

Using the literature review and case studies, here is a first attempt to bring lean startup methodology to NPD process. Company size does not seem to matter, though this requires further validation. Some of the stages below are borrowed from Coopers model (2001) - their basic definition remains valid, but here we add some clarification to assimilate lean startup methodology where this is appropriate.

76

(1) Discovery (Opportunity identification). This stage is about searching for ideas, in line with strategy, that could potentially be successful new products. (2) Scoping and Marketing research. In this stage, a market, technical, business and financial assessment is done. The objective is to spend little money and time on collecting some information to re-evaluate the merit of the idea. Furthermore, to crystallize core product value that an MVP would validate. Provided that marketing research supports idea worthiness, outcome would be a MVP concept. (3) Build and launch Minimum Viable Product (4) Concept formulation. This stage is entered if MVP shows positive results (otherwise product to be killed). As product developers start learning about customers real needs and how to serve them, it is time to bring in the different perspectives of the different functional teams. (5) Business case. As all teams have validated learning about customer needs and how to address them, a more accurate evaluation could be done on product viability for the company. Senior management would have a wealth of data to decide whether to stop or continue NPD. It also seems sensible to build a business case after stage 2 so to justify MVP cost to senior management however no empirical data is available at that stage. (6) Build-Measure-Learn. Iterate through the six steps of the Build-MeasureLearn process.

6.4

Research Limitations and Future Direction

The outcome of this research cannot be readily generalized. More empirical research is needed to produce results that could be replicated across ICT product developers. However, the findings are indicative. applicable in these two quite different cases. Also more research is needed to understand the conditions that warrant the use of the lean startup methodology. There might be sectoral; differences, or issues to do with rapidly changing markets or platforms. Ideas about new product categories Lean methods appear

77

(Booz, Allen and Hamilton, 1982) and sustaining versus disruptive innovation (Christensen, Anthony and Roth, 2004) might be useful in this regard. The present study has taken a holistic approach in looking at the commercialization of ICTs into products/services that address market needs. As Lean methods appear promising in this regard, more research is needed to attend to the notion of the business model16 that creates and delivers value to users (and producers) out of the technology (Chesbrough & Rosenbloom, 2002). Future research should also investigate the development of the lean startup methodology to serve as an end-to-end product development model. For instance, how Agile Development Methods may be integrated into the methodology. Another topic calling for future research concerns how companies can be transformed into lean organizations - including the implications of this for project management practices.

6.5

Implications of Adopting Lean Startup Methodology by Established Companies (Non Startups)

Much of the research on success factors in NPD emphasizes the importance of strong collaboration between cross functional teams (Crawford & Di Benedetto, 2006; Cooper, 2001). As the RBT case study demonstrates, strong cross functional team collaboration is vital for the successful implementation of the methodology. For instance, experimenting with a single idea to turn the growth engine would possibly involve: product owners perhaps in marketing team who came up with the idea, product technical team to implement the experiment, reporting team (possibly belongs to IT organization) to design, build and execute metrics reports and customer care team that handles all interaction with customers. Without the ability to work as one team towards a common goal, the methodology would hinder the NPD project.
16

A business model reflects managements hypothesis about what customers want, how they want it, and how the enterprise can organize to best meet those needs, get paid for doing so, and make a profit (Teece, 2010, p. 172)

78

Having cross functional teams working for a common goal is challenging. It needs the right culture and performance measurement system to be in place. From the interviews the author could sense the tension between different teams especially when something goes wrong. Each team is primarily measured on delivering on its functional related efforts e.g. Company Zs IT team performance depends on building technical platforms on time, budget and up to organization technical standards. They would build whatever they receive from marketing team. Just like customer care team who are primarily measured on how efficient they are in handling customer complaints. Project management (including NPD project management) is typically based on milestones of how much time, cost and scope (deliverables that makeup the final product) is spent/remaining. Alternatively, using the lean startup methodology suggests the use of validated learning as a project goal and a yardstick to track progress. Buffer, Inc. uses a range of internet based tools to effectively engage with customers for product development purposes; social media networks, blogs, dedicated website for customer suggestions and Skype for customer interviews are used. Managing those channels is the primary role of marketing staff. This suggests that companies may need to put more efforts on online user engagement channels including capable resources with understanding of products under development to be able to effectively manage user engagement activities. Merely having a presence on social media networks to primarily advertise company products or to enable customers to complain is not enough to create a meaningful dialog with customers. The use of metrics that track the impact of product development efforts instead of vanity metrics may turn to be a good business practice however it is a fundamental concept in the lean startup methodology. Changing how key performance indicators are set is part of the transformation companies should undergo to be able to apply the methodology. Business performance indicators

79

should be the concern of all teams involved in NPD rather than the commercial teams only.

6.6

Concerns in Applying Lean Startup Methodology

Building and launching an MVP may trigger concerns about product developers Intellectual Property rights. In RBT case, product developers expressed serious concerns about product idea leaking to competitors. On the contrary, Buffer, Inc. founder voluntarily suggested the product idea to a number of companies that had products serving Twitter users but got no response. It is for product developers to decide between improving the odds of bringing an innovative product successfully to market or arguably risking their first mover advantage. Another concern that a well established company might have regarding MVP is brand reputation. As MVP is not a well polished product that is targeting mainstream customers, it may negatively affect brand/company image. As a solution, Ries (2011) suggests to launch the MVP under a different brand name.

6.7

Final Remark

The present study has contributed towards using the lean startup methodology for User-Producer Interaction in new product/service development. Understanding the methodology resulted in the proposal of the Build-Measure-Learn process, the use of marketing research and how the methodology may be integrated with a NPD process. Overall, this exploratory study may be regarded as pointing to a very promising line of development for innovation management; our understanding of innovation may even be challenged as the methodology questions the notion of sunk cost as a symptom of innovation (Tether, 2003). The study introduces discipline to manage the fuzzy front-end of innovation promising to mitigate uncertainty and boost the chances of developing successful innovations.

80

APPENDICES Appendix A
Case Study & Interview Protocol

Field Procedures Check list to be carried out before every interview: Headphones present? Laptop charged? Laptop Charger present? Enough disk space for recorded files? Make Skype test call & run recording software Check recorded test call USB internet connection stick present (backup)? Interview Introduction Hello and thank you. Researcher Background Research Objective: The objective of the research is map out best practices of how to engage with customers when developing new ICT products in order to increase the chances of commercial success. Interview objective: To understand in detail how Buffer/RBT has been developed from idea to market. Interview Prerequisite Ask for permission to record interview. Ask how to treat data obtained through interview when writing research? Interviewee name, Company name and product name? How much time is available for conducting interview? Interview/case study questions The following questions are used to guide and keep the interview on track. They are not the exact questions used to ask interviewees. Case study about the failed product (excluded from research) 1. What was the idea behind OnePage? 2. How did you built it from an idea to product? o Focus on how did he engaged with users o Marketing research activities before staring product development 3. What happened after launch? 4. What lessons have you learned from the experience? 5. How have you marketed One Page? Primary methods used Case study 1 (Buffer)
81

1. Tell me what happened in the time between having the idea and starting to build the MVP? 2. How have you validated the assumption that you actually have a problem worth solving? 3. What is the criteria you used to exit the initial idea validation stage and enter the building MVP stage 4. How have you decided on the MVP functionality and features? 5. How have you decided on revenue model & pricing 6. How much time building the first MVP took? 7. How have you gone about discovering Buffers early adopters? 8. How have you marketed it? 9. Launching a first release of the product, how did it go? 10. What is your growth engine? i.e. what are the main metrics you try to improve ? 11. How have you decided on what to build next? 12. How do you come up with hypotheses that may tune the growth engine? 13. Can you validate them before actually building them? 14. Tell me about the user voice web site 15. I would think that customers have sometimes conflicting needs. Or requests that not in line with your vision. Any examples? How did you go about that? 16. How do you measure the effect of changes (including new features) you apply to product? 17. Have you pivoted while developing Buffer? Why & how? 18. May I ask for a report about Buffers growth? Any form of data that you feel comfortable sharing. 19. What were the implications of discovering that customers don't care about the notification feature? 20. Engaging with customers from day 1 means putting your idea out there for anyone. Any concerns about someone stealing it? 21. Have I missed anything you think was important in leaning to startup? From your experience what are the limitations of lean startup concepts? Case study 2 (RBT) Aimy, RBT product manager 1. 2. 3. 4. What is RBT? How it works, How customers are charged, etc Tell me about developing RBT, from having the idea until product launch Follow-up questions: Is the business case before the concept paper? i.e. product description in the business case is not detailed (features and scenarios). 5. Request samples of business case and concept paper.
82

6. When is top management involved i.e. for kill/go decisions 7. Please shade more light on RBT market Forecasting conducted for the product business case? 8. From the process I can see that you did not involve the customer heavily. Why? 9. Tell me about RBT launch. How successful it was, any issues? 10. As a product owner, what is your role after product launch? 11. Details about all changes applied to RBT post- launch are required. How each change came about and why? 12. How do you monitor product performance? 13. How do you find out whether the changes, be it new features or product modifications, implemented are effective and actually making the product better? 14. What is the root cause behind CRBT failure in the market? Hakeem, RBT project manager and technical lead 1. Tell me about the RBT implementation project. From an idea by the marketing team to launch 2. Tell me about post-launch issues and how did you overcome them 3. Tell me about changes requested from marketing team to be applied on RBT post-launch. How do you go about them? 4. In your opinion, what is the root cause behind CRBT failure in the market? Eddy, RBT Engineer, CRBT implementation lead 1. In your opinion, what is the root cause behind CRBT failure in the market? Wrap-up
Thank you and how to go about follow-up questions

83

Appendix B
Summary of Company Z Business Case

Business Case Executive Summary

Project Name: Business Owner Name: Business Owner Department: Cost Value : Budget

Date:

Expected Start Date: Expected End Date:

Your Company Strategy, if applicable (for eg. If part of a new initiative)

Project Description:

Project Objectives:

CAPEX Value Particulars CAPEX Value Allocation CAPEX Item 1 CAPEX Item 2 CAPEX Item 3 Total CAPEX Value Recovery Projections Projected Revenues Revenue Item 1 Revenue Item 2 Revenue Item 3 Total Revenue Projected Direct Costs / Expenses / Fees DC 1 DC 2 DC 3 Total Direct Costs / Expenses / Fees Gross Margin Gross Margin (%) Projected Indirect Costs / Expenses / Fees IC 1 IC 2 IC 3 Total Indirect Costs / Expenses / Fees Net Income Net Income (%) 2012 2013 2014 2015 2016 TOTAL

84

Subscriber Projections (if any) Particulars Opening Subscribers Gross Addition Churn Net Addition Closing Subscribers Remarks / Justification: 2012 2013 2014 2015 2016 Total

Project Key Performance Indicators CBC/1 CBC/2 CBC/3 Expected Discounted Payback Period Expected Return on Investment (ROI) Net Present Value (NPV) over 5 Year Period Years % $ Million

Review & Approve (Group) Reviewed By: ( Content Partner Head ) Reviewed By: (Commercial Dep.) Reviewed By: (Technical Dep. )

Division

Name

Designation

Signature

Date

85

Appendix C
Company Z New Product Concept Paper Company Z New Product Concept Paper TABLE OF CONTENTS
1

Document History Core Team REVIEW AND DISTRIBUTION Product and Operational Concept 4.1 4.2 4.3 Overview Purpose and Scope Success Criteria

2 3 4

5 6 7

Constraints Business Process Business Rules 7.1 General Rules 7.2 Operational Rules/ Plan 7.3 Staffing and Resourcing Rules 7.4 Provisioning Rules 7.5 Deactivation Rules 7.6 Migration Rules 7.7 Billing Rules 7.7.1 Billing Procedures 7.7.2 Tariffs 7.8 Product Dependencies 7.9 System Architecture 7.10 System Interfaces 7.10.1 Other Systems 7.10.2 Mediation 7.10.3 CDR Structure 7.11 Product Communication Rules 7.11.1 Distributor/Dealer Notification 7.11.2 Customer Service 7.11.3 Retailers and Franchise Stores 7.11.4 Point of Sale (POS) Material 7.11.5 Other Third Parties 7.12 CS Product Matrix 7.13 Reporting Requirements 7.13.1 Financial Management Reports 7.13.2 Management Information Systems (DWH) Reports 7.13.3 IVRs Affected 7.13.4 General reporting 86

7.14 Revenue Assurance Requirements 7.15 Training Requirements 7.16 Archiving and Audit Requirements 7.17 Business Continuity 7.17.1 Disaster Recovery 7.18 Security Requirements 7.19 Policy, Process and Procedures that needs to be developed 7.20 Regulatory Affairs Requirements 7.21 Commercial Legal Requirements. 7.22 Fraud Requirements 8 9 10 11 12 Simulation Team Requirements MARKETING COMMUNICATION ASSUMPTIONS AND DEPENDENCIES RISKS OUTSTANDING ISSUES

14 Future DEVELOPMENTS

87

BIBLIOGRAPHY
Abrahamsson, P., Salo, O., Ronkainen, J. (2002) 'Agile software development methods:review and analysis', Oulu: VTT Publications. Alam, I. (2002) 'An Exploratory Investigation of User Involvement in New Service Development', Jornal of The Academy of Marketing Science, vol. 30, no. 3, pp. 250-261. Alam, I. (2006) 'Removing the fuzziness from the fuzzy front-end of service innovations through customer interactions', Industrial Marketing Management, vol. 35, p. 468480. Alam, I. and Perry, C. (2002) 'A customer-oriented new service development process', Journal of Services Marketing, vol. 16, no. 6, pp. 515 - 534. Anderson, W.L. and Crocca, W.T. (1993) 'Engineering practice and codevelopment of product prototypes', Communications of the ACM, vol. 36, no. 4, pp. 49-56. Baldwin, C., Hienerth, C. and Von Hippel, E. (2006) 'How user innovations become commercial products: a theoretical investigation and case study', Research Policy, vol. 35, no. 9, p. 12911313. Beck, K., Beedle, M., Cockburn, A., Cunningham, W., Fowler, M., Grenning, J., Highsmith, J., Hunt, A., Jeffries, R., Kern, J., Marick, B., Mellor, S., Schwaber, K., Sutherland, J., Thomas, D., van Bennekum, A. and Martin, R. (2001) Manifesto for Agile Software Development, [Online], Available: www.agilemanifesto.org [30 June 2012]. Booz, Allen and Hamilton (1982) New Products Management for the 1980s, New York: Booz, Allen and Hamilton. Buffer (2012a) A Smarter Way to Share, [Online], Available: http://bufferapp.com/ [10 June 2012]. Buffer (2012b) A blog about productivity, life hacks, writing, user experience, customer happiness and business, [Online], Available: http://blog.bufferapp.com/ [10 July 2012]. Buffer (2012c) BufferApp, [Online], Available: https://twitter.com/bufferapp [11 July 2012]. Buffer (2012d) A smarter way to share, [Online], Available: http://www.facebook.com/bufferapp [11 July 2012]. Buffer (2012e) Feedback, [Online], Available: http://buffer.uservoice.com/forums/85149-feedback [15 July 2012]. Chesbrough, H. and Rosenbloom, R.S. (2002) 'The role of the business model in capturing value from innovation:Evidence from Xerox Corporations technology spinoff companies', Industrial and Corporate Change, vol. 11, pp. 533-534. 88

Christensen, C.M., Anthony, S.D. and Roth, E.A. (2004) Seeing what's next?: using the theories of innovation to predict industry change, Harvard Business School Publising Corporation. Cooper, R.G. (2001) Winning at New Products: Accelerating the process from idea to launch, Third Edition edition, New York: Basic Books. Crawford, M. and Di Benedetto, A. (2006) New Products Management, Eighth Edition edition, McGraw Hill. Dell (2012) Select your system, [Online], Available: http://www.dell.com/us/soho/p/desktops-n-workstations.aspx?ref=us-soho-dt [28 June 2012]. Dhillon, G. (1997) Managing informatiion systems security, London, UK: MacMillan Press. Ernst, H. (2002) 'Success factors of new product development: a review of the emprical literature', International Journal of Management Reviews, vol. 4, no. 1, pp. 1-40. Google (2010) Update on Google Wave, [Online], Available: http://googleblog.blogspot.co.uk/2010/08/update-on-google-wave.html [3 May 2012]. Greer, C.R. and Lei, D. (2012) 'Collaborative Innovation with Customers:A Review of the Literature and Suggestions for Future Research', International Journal of Management Reviews, vol. 14, p. 6384. Griffin, A. and Hauser, J.R. (1993) 'The voice of the customer', Marketing Science, vol. 12, no. 1, pp. 1-27. Gruner, K.E. and Homburg, C. (2000) 'Does Customer Interaction Enhance New Product Success?', Business Research, vol. 49, pp. 1-14. Ives, B. and Olson, M.H. (1984) 'User involvement and MIS success: A review of research', Management Science, vol. 30, p. 586603. Johne, A. and Storey, C. (1998) 'New service development: a review of the literature and annotated bibliography', European Journal of Marketing, vol. 32, no. 3, pp. 184-251. Kvale, S. (1996), in InterViews: An introduction to qualitative research interviewing, London: SAGE Publications. Kwaku, A.G. (1996) 'Differential Potency Factors Affecting Innovation Performance in Manufacturing and Services Firms in Australia', Journal of Product Innovation Management, vol. 13, pp. 35-52.

89

Leonard, D. (1995) Wellsprings of Knowledge Building and Sustaining the Sources of Innovation, Boston: Harvard Business School Press. Lundvall, B.-A. (1985) Product Innovation and User-Producer Interaction, Aalborg, Denmark: Aalborg University Press. Magnusson, P.R. (2003) 'Benefits of involving users in service innovation', European Journal of Innovation Management , vol. 6, no. 4, pp. 228 - 238. Martin Jr, C.R. and Horne, D.A. (1993) 'Services Innovation: Successful versus Unsuccessful Firms', International Journal of Service Industry Management, vol. 4, no. 1, pp. 49 - 65. Matthing, J., Sandn, B. and Edvardsson, B. (2004) 'New service development: learning from and with customers', International Journal of Service Industry Management, vol. 15, no. 5, pp. 479 - 498. Mehta, M., Anderson, D. and Raffo, D. (2008) 'Providing Value to Customers in Software Development Through Lean Principles', Software Process Improvement and Practice, vol. 13, no. 1, pp. 101-109. Moore, G.A. (1998) Crossing the chasm: marketing and selling technology products to mainstream customers, Second Edition edition, Capstone. Neale, M.R. and Corkindale, D.R. (1998) 'Co-developing products: involving customers earlier and more deeply', Long Range Planning, vol. 31, no. 3, pp. 418-25. OECD.org (1998) The OECD Definition of The ICT Sector, [Online], Available: http://www.oecd.org/dataoecd/34/37/2771153.pdf [3 July 2012]. OnePage (2012) Press FAQ's, [Online], Available: http://myonepage.com/press [25 July 2012]. Poppendieck, M. and Poppendieck, T. (2007) Implementing Lean Software Development: From Concept to Cash, Addison-Wesley. Prahalad, C.K. and Ramaswamy, V. (2004a) 'Co-creating unique value with customers', Strategy & Leadership, vol. 32, no. 3, pp. 4-9. Prahalad, C.K. and Ramaswamy, V. (2004b) 'Co-creation experiences: The next practice in value creation', Journal of Interactive Marketing, vol. 18, no. 3, pp. 5-14. Ries, E. (2011) The lean startup: How constant innovation creates radically successful businesses, Portfolio Penguin. Robson, C. (2011) al world research, 3rd edition, WILEY. 90

Rogers, E. (2003) The Diffusion of Innovations, Fifth Edition edition, New York: The Free Press. Sawhney, M., Verona, G. and Prandelli, E. (2005) 'Collaborating to create:The the internet as a platform for customer engagement in product innovation', Interactive Marketing, vol. 19, pp. 4-17. Scheuing, E.E. and Johnson, E.M. (1989) 'New product development and management in financial institutions', International Journal of Bank Marketing, vol. 7, no. 2, pp. 17-21. Sommerville, I. (1996) Software engineering, New York: Addison-Wesley. Staatsa, B.R., Brunnerb, D.J. and Uptonc, D.M. (2011) 'Lean Principles, Learning, and Knowledge Work: Evidence from a Software Services Provider', Journal of Operations Management, vol. 29, no. 5, pp. 376-390. Teece, D.J. (2010) 'Business models, business strategy and innovation', Long Range Planning, vol. 43, pp. 172-194. Tether, B.S. (2003) 'What is Innovation:Approaches to Distinguishing New Products and Processes from Existing Products and Processes', Centre for Research on Innovation and Competition Working Paper Series-University of Manchester and UMIST, 29 August. Tidd, J. and Bessant, J. (2009) Managing Innovation: Integrating technological, market and organizational change, 4th edition, Chichester: John Wiley & Sons. Trott, P. (2005) Innovation management and new product development, Third edition edition, Pearson Education. Utterback, J.M. and Abernathy, W.J. (1975) 'A Dynamic Model of Process and Product Innovation', Omega, vol. 3, no. 6, pp. 639-656. Vargo, S.L. and Lusch, R.F. (2004) 'Evolving to a new dominant logic for marketing', Journal of Marketing, vol. 68, pp. 1-17. Von Hippel, E. (1986) 'Lead Users: A Source of Novel Product Concepts', Management Science, vol. 32, no. 7, pp. 791-805. Von Hippel, E. (1988) The Sources of Innovation, Oxford: Oxford University Press. Von Hippel, E. and Katz, R. (2002) 'Shifting innovation to users via toolkits', Management Science, vol. 48, no. 7, pp. 821-833. Von Hippel, E. and Riggs, W. (1996) 'A lead user study of electronic home banking services : lessons from the learning curve', Sloan Working Paper, Sloan School of Management, Massachusetts Institute of Technology, pp. 1-19. 91

wikipedia (2012a) Bookmarklet, [Online], Available: http://en.wikipedia.org/wiki/Bookmarklet [16 July 2012]. Wikipedia (2012b) Interactive voice response, [Online], Available: http://en.wikipedia.org/wiki/Interactive_voice_response [8 August 2012]. Womack, J.P. and Jones, D.T. (1996) Lean thinking: banish waste and create wealth in your corporation, New York: Simon and Schuster. Womack, J.P., Jones, D.T. and Roos, D. (1990) The Machine that Changed the World: The Story of Lean Production, New York: HarperPerennial. Yin, R.K. (1989) case study research design and methods, London: SAGE.

92