When you look at the actual practices applied during a Product Readiness process you are very likely to find out that none of them are new to you (assuming that you are part of the software manufacturing industry). The main reason is that Product Readiness is a discipline that utilizes other disciples, breaks some of the traditional flows and connections and creates new process and values using the same known building blocks. Product Readiness is actually not very different from PLM (Product Lifecycle Management) or ALM (Application Lifecycle Management) in the sense that it contains phases like: product initiation and market introduction, growth, maturity and decline and aspects like: requirements management, design, development, testing, configuration management, build, release and deploy, implementation and support. Sounds simple? Well, statistics show that most software organizations (large or small, young or well established) are failing to successfully accomplish the traditional plans and expectations. Product Readiness is not about inventing new practices, rather, it looks at the challenges, difficulties and conflicts that are part of the organization culture and environment and builds a realistic process, that dynamically grows and changes in alignment to the organization's available resources. Since Product Readiness is about balancing between conflicting interests it is able to bridge the built-in gaps between software development, product and project management, marketing and sales and connecting between software architecture and technology innovation to business ambitions and the commercial environment.
In the next posts I will discuss these issues in more details and describe the levels of the Product Readiness model and the way they are applied.