Around 90% of Products Fail And More Than 60% of the Features of a Typical Software Product are Rarely or Never Used: Here’s What You Can Do


invest in Intel shares in India Mary, the development team leader, was already eager to start developing and happy when she got the requirements. She and her team went ahead and created the software right away. Afterwards, Paul tested the software against the requirements. As soon as the software fulfilled the requirements, Linda, the product manager, deployed it to the customer. The customer did not like the software and ignored it. Ringo, the head of software development, was fired. How come?

Most Ideas Fail to Show Value

Nowadays, we have tremendous capabilities for implementing nearly all kinds of business ideas with the help of software. We can apply agile practices for reacting flexibly to changing requirements, we can use distributed development, open source, or other means for creating software at low cost, we can use cloud technologies for deploying software rapidly, and we can get enormous amounts of data showing us how customers actually use software products.

However, the sad reality is that around 90% of new consumer products fail, and more than 60% of the features of a typical software product are rarely or never used. (You can read about the cost of features here.)


Buy Intel shares But there is a silver lining – an insight regarding successful features: Around 60% of the successes stem from a significant change of an initial idea. This gives us a hint on how to build the right software for users and customers.

Many software projects fail to deliver or only deliver little value due to the wrong assumptions made on requirements. A questionable assumption is, for instance, that customers or experts can come up with the right requirements. In consequence, projects usually have an upfront business analysis phase before the development starts. There are of course projects such as large-scale contract software projects in well-understood domains where upfront analysis is feasible and successful. But we should consider that these projects represent a very small percentage of all software projects.

“If we’re not solving the right problem, the project fails.”

     – Woody Williams

Nowadays, nearly all software projects are conducted in complex environments where the relationship between cause and effect with respect to features and their success can only be understood in retrospect. Nobody “knows” upfront if and how features will create value for customers. Making decisions on what to develop based on opinions is highly risky in dynamic and non-predictable environments. Developing wrong features creates cost for development and maintenance as well as opportunity cost representing the missed opportunity to develop something of value instead.

Intel shares A promising way to create products in complex environments is to quickly and systematically iterate an initial product idea towards success before running out of time and other resources. Simply speaking, this means that you need to create a plan A that describes the scope of the software, identify the underlying assumptions of this plan, test the riskiest assumptions, and iterate until you have a plan B that works. The initial ideas we come up with are seldom successful. Identifying, testing and refining multiple options helps to discover better ways to provide value for users or customers.

Every Business and Innovation Idea can be Tested with an Experiment

A means for doing this is continuously conducting experiments to test assumptions and making being wrong cheaper. Insights from experiments directly influence what is given to the users. This process of continuous experimentation consists of three meta-steps:

  1. Break down your product idea into a product roadmap that can be efficiently tested. Be aware that the roadmap changes over time and is basically a list of goals and assumptions. Constantly reprioritize the assumptions.
  2. Run frequent and additive experiments to test assumptions. This includes systematically observing users’ behavioral responses to stimuli such as features. An example for a hypothesis is “The new posting feature will increase sign ups of new users by 5% in two weeks“. If an experiment does not deliver the expected result, do not test another option at random. Carefully choose what to test next.
  3. Use results from experiments to iteratively modify your product roadmap. This might lead to an improvement of a product or a significant change of the strategy. It might also mean that you need to stop the project.


Success cases from companies such as Etsy, Amazon, Ericsson and Supercell show that an experimentation-based development approach helps companies to gain competitive advantage by reducing uncertainties and rapidly finding product roadmaps that work. However, experimentation is hard.

How do we Find Good Hypotheses and Conduct the Right Experiments?

Customers and users are a questionable source for novel ideas. What they say often does not match what they will do. Consider the wish of users for privacy and the way they use Facebook. However, customers often have a good understanding of problems and asking the right questions can help reveal good hypotheses in the problem space.

Developers are usually good at coming up with solution proposals. They are familiar with technical options for solving a problem and can be a good source for revealing hypotheses in the solution space. Intensifying the communication between users and engineers promises to be another good source for hypotheses.

A further source for identifying hypothesis is usage data. It can be used to gain insights and new ideas on what to develop if the right data is collected and appropriately analyzed. Further hypotheses to test, often hidden and not directly visible, can be found in the respective business models.

What about the HiPPOs? HiPPOs are the highest paid person’s opinions. HiPPOs currently dominate decisions about what to develop. However, there is no guarantee that their ideas are better or successful. Listen to HiPPOs and take their ideas into account when prioritizing what to test. But make development decisions based on validated assumptions.


“One test is worth one thousand expert opinions.”

     – Wernher von Braun

The experimentation process follows the scientific method. It is important that you state upfront what you expect. Otherwise you just see what is going on. And many people are excellent at rationalizing what they see and would be surprised if they would have stated their expectations upfront.

“It’s not an experiment if you know it’s going to work.”

   – Jeff Bezos

There are many techniques available that support experimentation such as multivariate tests, prototyping, or customer interview techniques. But consider that choosing the right experiment technique requires that you know what you want to learn. Do you want to better understand the problem? Do you want to test the feasibility of a solution? Do you want to compare solution alternatives? Do you want to understand a behavior change? Do you want to test the efficiency of a distribution channel? All these questions lead to different experiments.

Overall, developing successful products and services requires a deep integration of testing critical assumptions in the overall development process. It emphasizes rapid and constant learning by empirical means in order to create software that provides value for users, customers, and the developing organization. Success with software is not luck. We all have the opportunity to deliver high-value software. What is your most critical assumption?

Key Takeaways

  • It’s more important to do the right thing than to do things right. – Peter Drucker
  • Success in highly dynamic application domains traces back to disciplined experimentation.
  • Defining and running the right experiments is hard.
  • Experimentation must be deeply integrated in the design and product development process.
  • Platforms for experimentation can be seen as a core part of future development environments.


Scott Anthony, David Duncan, and Pontus M.A. Siren. The 6 Most Common Innovation Mistakes Companies Make. S . Harvard Business Review, June, 2015.

Emil Backlund, Mikael Bolle, Matthias Tichy, Helena Holmström Olsson, and Jan Bosch, “Automated User Interaction Analysis for Worflow-Based Web Portals”, Presentation Slides, 5th International Conference, ICSOB 2014, Paphos, Cyprus, June, 2014.

Fabian Fagerholm, Alejandro Sanchez Guinea, Hanna Mäenpää, Jürgen Münch. Building Blocks for Continuous Experimentation. In Proceedings of the 1st International Workshop on Rapid Continuous Software Engineering (RCoSE 2014), Hyderabad, India, pages 26-35, June 2014.

Jim Johnson, Chairman from the Standish Group, “ROI, It’s Your Job” (keynote), Third International Conference on Extreme Programming, Alghero, Italy, May 26-29, 2002.

Eveliina Lindgren, Jürgen Münch. Raising the Odds of Success: The Current State of Experimentation in Product Development. Information and Software Technology, 77:80-91, 2016.

Carmen Nobel, Clay Christensen’s Milkshake Marketing, Harvard Business School Working Knowledge, 2011.

Ash Maurya. Running Lean. O’Reilly, 2012. Scaling Lean, 2017.

Eric Ries. The Lean Startup: How Today’s Entrepreneurs Use Continuous Innovation to Create Radically Successful Businesses. Crown Publishing, 2011.

Sezin Gizem Yaman, Myriam Munezero, Jürgen Münch, Fabian Fagerholm, Ossi Syd, Mika Aaltola, Christina Palmu, Tomi Männistö. Introducing Continuous Experimentation in Large Software-Intensive Product and Service Organizations. Journal of Systems and Software, 133:195-211, November 2017.

[An earlier version of this post has been published in Perspectives on Data Science for Software Engineering, chapter Continuously Experiment to Assess Values Early On, pages 365-368. Morgan Kaufmann, 2016.]

Continuous Experimentation Cookbook: How to do Lean Startup Experiments

Bildschirmfoto 2017-07-10 um 10.03.23

We have co-authored a cookbook on continuous experimentation based on our research in the N4S program:

Continuous experimentation Cookbook – An introduction to systematic experimentation for software-intensive businesses provides an introduction to continuous experimentation, which is a systematic way to continuously test your product or service value and whether your business strategy is working.

An increasing number of companies are involved in building software-intensive products and services – hence the popular slogan “every business is a software business”. Software allows companies to disrupt existing markets because of its flexibility. This creates highly dynamic and competitive environments, imposing high risks to businesses. One risk is that the product or service is of only little or no value to customers, meaning the effort to develop it is wasted. In order to reduce such risks, you can adopt an experiment- driven development approach where you validate your product ideas before spending resources on fully developing them. Experiments allow you to test assumptions about what customers really want and react if the assumptions are wrong.

This book provides an introduction to continuous experimentation, which is a systematic way to continuously test your product or service value and whether your business strategy is working. With real case examples from Ericsson, Solita, Vaadin, and Bittium, the book not only gives you the concepts needed to start performing continuous experimentation, but also shows you how others have been doing it.

Take a look at the book!

Traditional, Agile and Beyond: Book on “Managing Software Process Evolution”

Bildschirmfoto 2016-03-15 um 16.27.34

  • Collects and summarizes the state of the art in analysis, design, implementation, management and governance, improvement and enactment of software processes
  • Provides the foundations of current research on software process improvement and management and lays the basis for further problem-driven research
  • Addresses researchers and practitioners by providing recent research results as well as experiences and best practices

This book focuses on the design, development, management, governance and application of evolving software processes that are aligned with changing business objectives, such as expansion to new domains or shifting to global production. In the context of an evolving business world, it examines the complete software process lifecycle, from the initial definition of a product to its systematic improvement. In doing so, it addresses difficult problems, such as how to implement processes in highly regulated domains or where to find a suitable notation system for documenting processes, and provides essential insights and tips to help readers manage process evolutions. And last not least, it provides a wealth of examples and cases on how to deal with software evolution in practice.

Reflecting these topics, the book is divided into three parts. Part 1 focuses on software business transformation and addresses the questions of which process(es) to use and adapt, and how to organize process improvement programs. Subsequently, Part 2 mainly addresses process modeling. Lastly, Part 3 collects concrete approaches, experiences, and recommendations that can help to improve software processes, with a particular focus on specific lifecycle phases.

This book is aimed at anyone interested in understanding and optimizing software development tasks at their organization. While the experiences and ideas presented will be useful for both those readers who are unfamiliar with software process improvement and want to get an overview of the different aspects of the topic, and for those who are experts with many years of experience, it particularly targets the needs of researchers and Ph.D. students in the area of software and systems engineering or information systems who study advanced topics concerning the organization and management of (software development) projects and process improvements projects.


  • [PDF] [DOI] Marco Kuhrmann, Jürgen Münch, Ita Richardson, Andreas Rausch, Jason He Zhang, editor. Managing Software Process Evolution: Traditional, Agile and Beyond – How to handle process change?. Springer-Verlag, 2016.
    [Bibtex] [doi] [url] [pdf]
    editor = {Marco Kuhrmann, Jürgen Münch, Ita Richardson, Andreas Rausch, Jason He Zhang},
    title = {Managing Software Process Evolution: Traditional, Agile and Beyond - How to handle process change?},
    publisher = {Springer-Verlag},
    year  = {2016},
    url = {},
    doi = {10.1007/978-3-319-31545-4},

Springer Website of the Book


Don’t Start Without Mentoring in Open Source Projects


In several studies, we examined how mentoring and project characteristics influence the effectiveness and efficiency of the onboarding process.

Bildschirmfoto 2015-12-27 um 15.12.34

[blue = mentored, red = non-mentored]

Recommendations for project leaders and managers:

  • Identify core developers who can spend a limited time on intensive mentoring. Provide direct incentives for mentoring. For example, the opportunity to get help for pending tasks can be attractive for potential mentors. Clearly limiting the duration of mentoring reduces the negative effect on the mentor’s performance in other project tasks and can reduce some of the resistance to participate.
  • Organize or sponsor collocated events, such as Hackathons, and use them to kick off the mentoring period. Face-to-face events can help team members and mentors to focus on problems which are difficult to overcome in a distributed setting, and can further boost the success of onboarding new members into virtual teams. Many open source projects already arrange periodic collocated events and welcome participation by newcomers. Engaging with these provides direct access to the project community.
  • Expect considerable variation in performance increases over time. Assessing the cost and outcomes of mentoring requires understanding onboarding as a learning process which does not proceed linearly. Some onboarding activity will not be publicly visible. Engage directly with mentors and newcomers to gain insight of how onboarding is progressing.
  • Adapt the onboarding program to project characteristics and culture. Take the maturity of the target project and its existing onboarding practices into account. Low-maturity projects may require more support to instill a productive mentoring culture, while mature projects may already have an existing culture of integrating new developers and may be ready for tailoring towards more specific inclusion targets.

Keywords: Onboarding, Organisational Socialisation, Open Source Software, Case Study, Mentoring, Software Teams, Distributed Development


Read more about the general effect of onboarding support on newcomer activity and the moderating effect of project characteristics, such as age, number of contributors, and appeal, on the speed of the onboarding process:

  • [PDF] [DOI] Fabian Fagerholm, Alejandro S. Guinea, Jürgen Münch, Jay Borenstein. The Role of Mentoring and Project Characteristics for Onboarding in Open Source Software Projects. In Proceedings of the 8th ACM-IEEE International Symposium on Software Engineering and Measurement (ESEM 2014), Torino, Italy, September 2014.
    [Bibtex] [doi] [pdf]
    author = {Fabian Fagerholm, Alejandro S. Guinea, Jürgen Münch, Jay Borenstein}, 
    title = {The Role of Mentoring and Project Characteristics for Onboarding in Open Source Software Projects}, 
    booktitle = {Proceedings of the 8th ACM-IEEE International Symposium on Software Engineering and Measurement (ESEM 2014)},
    year = {2014},
    month = {September},
    address = {Torino, Italy}

Read more about the developer activity during onboarding, the potential cost of mentoring in terms of lost productivity, and find guidelines for using mentoring as an onboarding support mechanism.

  • [PDF] [DOI] Fabian Fagerholm, Alejandro Sanchez Guinea, Jay Borenstein, Jürgen Münch. Onboarding in Open Source Projects. IEEE Software, 31(6):54-61, 2014.
    [Bibtex] [doi] [url] [pdf]
    author={Fabian Fagerholm, Alejandro Sanchez Guinea, Jay Borenstein, Jürgen Münch}, 
    journal={IEEE Software}, 
    title={Onboarding in Open Source Projects}, 
    volume = {31},
    number = {6},
    publisher = {IEEE},
    URL = {},
    pages = {54-61},
    doi = {10.1109/MS.2014.107},
    keywords={open source software projects; virtual teams; mentoring; global software development; distributed software development; case study}}

Talk: “From Agile Development to Continuous Experimentation – How to Create Value with Software?“

I will give a talk on the topic
“From Agile Development to Continuous Experimentation – How to Create Value with Software“

After my talk, Fabian Fagerholm will give talk on the topic
“Software Factory – A Retrospective and Future Directions”

When: Thursday, December 10, 4:30pm
Where: University of Helsinki, Kumpula campus, Physicum building, auditorium D101 (Gustaf Hällströmin katu 2a)

Before the talk, cocktails will be served in front of the auditorium.
I am looking forward to seeing you.

Interview at Herman Hollerith Center

I was interviewed about my avenues for future research at the Herman Hollerith Center (HHZ) (in German).

The Herman Hollerith Center for digital business and innovative software in Böblingen is operated in partnership between Reutlingen University, University of Stuttgart, Esslingen University, and the five companies Daimler AG, Hewlett-Packard, IBM, Novatec, and Robert Bosch GmbH. It is supported by the city and the district of Böblingen.

The Herman Hollerith Center offers a PhD program and two master’s degree programs in Services Computing and Digital Business Management. The center is hosted by the Department of Computer Science of Reutlingen University.

The Herman Hollerith Center is located in Böblingen, the city with Europe’s largest pool of innovation. Böblingen is very close to Stuttgart with many companies around. Daimler and IBM are in Böblingen as well as Hewlett-Packard and Elektrobit. Porsche, Bosch, and many other companies are close by. Several start-up incubators are in Böblingen to facilitate radical innovations.

The research within the Herman Hollerith Center focuses on sound and effective methods for the development and evolution of software-enabled services and products and the digital transformation of organizations. The research addresses significant problems that reflect important needs of companies. The research areas include software engineering, service science, data management, smart data services, business intelligence, internet of things, enterprise architectures, business modeling and enterprise social networks.

See the interview here.

Talk: “The Wheels of Value Model: Driving Product Ideas to Their Fullest Strength”

The Wheels of Value Model is a tool for driving product ideas to their fullest strength by systematically unearthing critical product assumptions. Instead of identifying assumptions for each element of a business model it generates a closed value chain among the right actors and ensures that you do not miss important links. By doing this you can rapidly see what you need to validate. This talk explains the main elements.

Presenter: Prof. Dr. Jürgen Münch
When: 16 Sept. 2015, 10:15 am
Where: Pori, N4SQ3, Yyteri Hotel, Finland

wheels of value excerpt

Is Water-Scrum-Fall Reality? On the Use of Agile and Traditional Development Practices – Accepted at PROFES 2015

by Georgios Theocharis, Marco Kuhrmann, Jürgen Münch, Philipp Diebold

Abstract. For years, agile methods are considered the most promising route toward successful software development, and a considerable number of publications studies the (successful) use of agile methods and reports on the benefits companies have from adopting agile methods. Yet, since the world is not black or white, the question for what happened to the traditional models arises. Are traditional models replaced by agile methods? How is the transformation toward Agile managed, and, moreover, where did it start? With this paper we close a gap in literature by studying the general process use over time to investigate how traditional and agile methods are used. Is there coexistence or do agile methods accelerate the traditional processes’ extinction? The findings of our literature study comprise two major results: Studies and reliable numbers on the general process model use are rare, i.e., we lack quantitative data on the actual process use and, thus, we often lack the ability to ground process-related research in practically relevant issues. Second, despite the assumed dominance of agile methods, our results clearly show that companies enact context-specific hybrid solutions in which traditional and agile development approaches are used in combination.



  • [PDF] [DOI] Georgios Theocharis, Marco Kuhrmann, Jürgen Münch, Philipp Diebold. Is Water-Scrum-Fall Reality? On the Use of Agile and Traditional Development Practices. In Proceedings of the 16th International Conference on Product-Focused Software Process Improvement (PROFES 2015), volume 9459 of LNCS, pages 149-167. Springer-Verlag, 2015.
    [Bibtex] [doi] [url] [pdf]
    booktitle={Proceedings of the 16th International Conference on Product-Focused Software Process Improvement (PROFES 2015)},
    title={Is Water-Scrum-Fall Reality? On the Use of Agile and Traditional Development Practices},
    keywords={Development Practices, Agile Methods, Software Process, Systematic Literature Review, Comparative Study},
    author={Georgios Theocharis, Marco Kuhrmann, Jürgen Münch, Philipp Diebold},