Increasing Diversity in Software Product Planning and Development Approaches
For a long time, the standard approach for software product planning and development was requirements-driven. We elicit and collect market requirements, analyze them and decide which ones to implement when. These used to be the steps with waterfall methodology, and basically it is the same with agile, e.g. Scrum, though roles and responsibilities and timing are a bit different.
Over the last couple of years, we have been seeing more diversity in this area. As Jan Bosch (Chalmers University, Sweden) pointed out in a recent blog post, there are three different approaches now. The requirements-driven approach continues to be relevant, in particular for legal or regulatory requirements, requirements for commodity functionality, and technology requirements.
There is a second approach where we experiment with different implementations and based on the analysis of usage data we decide which implementation we keep in the product. This is a good approach when the focus is on innovation and optimization under uncertainty, and we as the vendor have an environment that allows this kind of experimentation, i.e. a vendor-controlled environment (see my blog post on these scenarios). We call this data-analysis-driven, Jan Bosch and some other authors call this outcome-driven. We feel that in a requirements-driven approach the decision on how to implement something can also be driven by the outcome, so we prefer the term data-analysis-driven here.
The third approach applies to artificial intelligence/machine learning where data is prepared and used as input for the learning process of an ML engine. We call this data-input-driven, Jan Bosch calls it data-driven, but we feel that this term can be misleading since the second approach is also driven by data for analysis.
These three approaches do not necessarily have to be used either/or. In a lot of real-world situations, they better be used in parallel for different parts of a product and/or different types of requirements in order to get to optimal results. So product management and development organizations better learn how to apply all three approaches in their environments.