I define a product as a software-based system or a service that a supplier develops and markets and that customers use. In plain terms, I mean the whole deliverable that carries value for stakeholders. For example, I refer to an application, a cloud service, or an integrated solution as a product. Moreover, I include both standalone systems and services provided by systems.
In agile work, I treat a product as the sum of its increments. First, teams build a small slice. Then, I gather feedback. Next, I adapt it based on findings. Thus, I follow the Build-Measure-Learn cycle. Consequently, solution validation becomes central. For instance, I use each increment to verify business value and to check whether requirements reflect stakeholder needs. In Scrum, the sprint review supports that. For large-scale development, integrated reviews help coordinate the work. In that case, I combine team deliverables. Then, I demonstrate an end-to-end increment. As a result, stakeholders gain a clear impression of the entire product.
Furthermore, I emphasize product-level validation. I do this so product owners share full accountability from business requirements to integration. Therefore, I validate the whole solution, not only small slices. In addition, I coordinate integration work with a delivery roadmap. Thus, I align teams on release milestones. Meanwhile, I use reviews to uncover missing requirements and integration issues. Consequently, I reduce risk before a release.
I also distinguish between product family and product line. First, I describe a product family as a set of connected offerings that complement each other and cover a common application area. For example, I consider an office suite such a set. Next, I describe a product line as different variants of one offering. Then, I note that variants in a product line often substitute for each other and differ in features or price. For instance, I think of smartphone models that share a base but vary in functions.
In addition, I explain commonalities and variability. I identify commonalities as the shared basis across variants. I identify variability as the defined parts that allow different products. Therefore, I can create several products from one product line model. Moreover, I include both hardware and software in commonalities or variability when relevant.
I keep a requirements pool for large portfolios. Accordingly, I store more requirements than any single product needs. In other words, I record ideas and requests that may enter a future release. Furthermore, I separate domain engineering and application engineering. For domain engineering, I identify commonalities and variability and build the product line model. For application engineering, I adapt that model to create specific variants. Thus, I support reuse and faster creation.
Finally, I focus on the product as the unit of value. Indeed, stakeholders value the integrated product and its end-to-end features. Therefore, I validate, integrate, and manage variability with that aim. Consequently, I deliver products that meet market needs and stakeholder expectations.