Category Archives: Product Management

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


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.)


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.

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.]

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.

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},