Implementing product management best practices

Issues encountered when trying to implement product management best practices typically fall into three main categories. The first is the category of Practice Management and includes the issues associated with identifying what really is a best practice. Second is the Portfolio Management category which includes sifting through all the best-practices to prioritize and determine the implantation of change. Lastly, the third category is Change Management which addresses issues associated with the adoption of change itself.

Practice Management addresses how to identify and manage today’s best practices while anticipating those of tomorrow. Poorly defined IT structure, undocumented product management processes, and disconnected training programs are typical deterrents to rapid implementation of newly defined “best-practices”. In Product Management, disagreement and uncertainty are unfortunately the norm. Even the definition of Product Management (the combination of Product Marketing and Product Planning) is not uniformly accepted. Gaining consensus about best practices within this domain becomes even more problematic as it is laden with hidden agendas, politics and misaligned objectives.

In the case of Portfolio Management, the issue of how to determine what is a ‘best practice’ for an organization with a certain amount of resources with specific objectives is explored. The most common contributors to this type of an issue are undefined selection criteria, an inability to identify available resources, and a lack of visibility into corporate objectives.

Finally, with the case of Change Management, how a team can embrace continuous change and rapidly adopt best practices as they become available in order to maintain a competitive advantage is examined. Product Management as a discipline is maturing and new practices are being published monthly. Even if the changes relevant to an organization are identified, how can the kind of responsiveness required to leverage new practices be created, and is it really possible to train a team on the usage of new technology and “best practices” on a monthly basis?

Using a process model to address these three types of issues has proven to be extremely effective. Model directed process development provides a common set of process requirements that can capture “best practices” and practical knowledge in a format that can be used to guide priorities. By using a model, organizations can modify or create processes using practices that have been proven to increase capability while also comparing those capabilities to other organizations within their industry.

The capability model referred to in this article is a product of evolution created by gathering and adopting lessons learned from hundreds of product management implementations throughout the world. This product management capability model takes very complex product management objectives and makes them accessible to the first-time practitioner.

The structure of the model accommodates multiple types of users, both those wanting to consume previously defined practices, and those wanting to define practices that are newly developed. In the past, Ryma Technology Solutions has used this model internally in their service offering. Currently, the model is being expanded by both partners and customers with a goal of making it public by the beginning of the third quarter of 2008. With the full release of the model, for the first time, the public will be able to determine what is and isn’t a “best practice”.

The model provides nine product management capabilities: cost, schedule, resources, asset management, alignment management, risk, markets, competition, and innovation. Each of the capabilities belong to five descriptive stages; reactive, passive, proactive, sustainable, and leadership. Organizations grow their capabilities from a reactive stage to finally being able to anticipate direction and provide leadership within their markets.

Within the Reactive stage, product managers find themselves trying to balance the three capabilities of Cost, Schedule, and Resources to deliver a better product. As these product managers identify and implement the correct best practices, they grow capabilities within Asset and Alignment Management. When this growth is complete, the product manager is in control of many of the drivers that were causing the reactive stage therefore transitioning the organization into the Passive stage.

To effectively transition from the passive stage into the Proactive stage organizations need to select best practices that are aligned with their profile for managing Risk and Markets. This includes activities such as capturing the voice of the customer, competitive analysis, market attractiveness assessments, and risk mitigation planning for technical, organizational, business, market and financial risk events.

In transitioning into the Sustained stage, organizations need to select best practices which will increase both their Competition and Innovation management capabilities. Gaining the ability to respond to forecasted performance trends within product management helps the organization sustain product Leadership in the market place.

Each of the nine product management capabilities are broken down into seven themes:

1. Applications: software applications used to accomplish product management,
2. Infrastructure: IT assets and networks used to support product management,
3. Information: data captured, and metadata used to support product management,
4. People: those activities conducted to grow and nurture individuals and relationships that better support the product management effort,
5. Processes: those activities performed to conduct product management,
6. Projects: activities, work products, and processes used to manage projects sponsored by product management efforts,
7. Portfolios: collections of product management activities, projects, and products managed together to achieve optimal balance.

Within each of the seven themes listed above, relevant product management objectives are also listed. Currently, contributors have identified over 5,000 objectives within this structure. No wonder it’s difficult for product managers to get their arms around “best-practices”.

For each identified objective, there are five stages of maturity. When Ryma, a customer, or a partner adds an objective, they also add the maturity stage descriptions. All stage one (Supply stage) objectives are focused on listing, identifying, and defining the required inputs needed to accomplish the objective title.

All stage two (Demand Satisfaction stage) objectives are focused on accomplishing the objective using the listed, identified, and defined inputs of stage one.

A stage three (Steering Committee stage) objective is focused on gaining an oversight ability to optimally accomplish stage two.

A stage four (Metrics Gathering stage) objective is focused on defining metrics measuring the performance of the oversight function of stage three, not the performance of stage two.

A stage five (Anticipate & Respond stage) objective is focused on collecting stage four metrics overtime to anticipate future capabilities and respond to discernable trends.

Implementation strategies and technical approaches are now linked to each objective stage. An estimation of required staff hours, skill type, and level is provided and both comparisons and selections between implementation strategies are repeatable, defendable, and maintainable. By using this model, Ryma addresses most of the Practice Management issues.

To address Portfolio Management issues a history of successful strategies for various types of customers is maintained. Currently, organizational traits that are relevant in the selection of various objectives and strategies are being identified. The intention is to develop a small set of defining attributes that will aid in the selection process of applicable “best practice” models.

Connecting the model to historical data helps address the alignment question. For each strategy, additional information is provided including customer feedback and ranked strategies based on usage levels. This information and structure further helps Ryma address Portfolio Management issues.

To address the Change Adoption issues, a product management implementation roadmap has become essential to customers as they try to schedule and budget new technology, processes, and training. To develop this roadmap, a gap analysis between the organization’s current state and our capability model was conducted. The structure of the model ensures that the current state implies the next step.

Typically, it takes 3-4 hours to complete the model comparisons and, when completed, the list of objectives can be prioritized for use in an implementation roadmap. The resulting list is extensive, and normally requires 3 more hours for further categorization and prioritization. By maintaining links between strategies and objectives, implementation strategies can be quickly selected and a defendable statement of work aligned to the objective roadmap that is inclusive of required skill levels and estimated staff hours is generated.

Utilizing this structure further, the process activities have been mapped in a master process diagram to each objective within the capability model. When objectives are selected, others are not. These unselected objectives are cut from the master process diagram, and a reduced process diagram is generated to capture the product management activities that are being targeted in this phase of implementation. There is a slight complication here in that within the capability model there are multiple types of objectives, some map to product management processes, others to team building and leadership activities, still others to infrastructure development. It is necessary to create multiple master process diagrams, each to support the different themes of the capability model.

Each activity in one of these process diagrams is linked to an underlying data model. This data model needs to capture the repository entities, attributes, and data types required to support each activity. Furthermore, the values of common “pull-down” type attributes can be defined. Relationships between attributes, such as mathematical equations, are identified and defined to facilitate the generation of contributing factor diagrams.

This data model is priceless when used to leverage existing IT investments and estimate future demands on IT when expanding product management capabilities. This structure also enables change impact analysis to IT Systems as new processes are being considered. If a matrix is constructed to map required data attributes with existing software applications and repositories the world becomes less time consuming, less risky, less expensive, and a whole lot happier. This alone makes the proposition of process change more palatable.

Another benefit of a model approach is the ability to create a Role Context Diagram. Think of this as a cost-benefit analysis for each user of the product management system. In this diagram, the roles that will impact the product management system, and those that will be impacted by the product management system are identified. This information is gathered from the process diagrams and data models. The data items required to be input into the system by each role, and the objectives that this system will accomplish for this role are both identified. If the benefit to this role isn’t greater than the effort the system isn’t sustainable, change adoption won’t be lasting, and the system needs to be fixed.

By leveraging all this information together, a role-based custom training in the context of an organization’s IT system has been developed. These training programs are quickly adaptable due to the documented relationships between objectives, roles, data, software applications, and training procedures. All this together helps Ryma address typical Change Adoption type issues.

As mentioned earlier, this structure has evolved. It was first used internally, and kept very private. As the structure became more stable, partners were encouraged to add objectives and strategies. This required a review of the objective input process itself. Issues involved in a multi-vendor statement of work using several pricing models for both applications and services had to be addressed. Channel programs had to be redesigned and sales processes were impacted, yet the results were encouraging.

The model once again was opened up and extended to a few professional organizations that were encouraged to add additional objectives encountered throughout the entire innovation value chain. The model stretched to the limits as unanticipated issues had to be resolved. Overall, this effort has been successful and many more professional organizations will be included in its development.

The model has now stabilized and is expected to include contributions from across the global community in the form of analysts, practitioners, authors, private and public educators, consultants, workers, managers, directors, and executives. As more diversified representation is enabled within the model, the selection of practices will become richer and more meaningful.

Now, for the first time in the history of the world, humankind can truly evolve product management “best-practices” with a single voice.

If you’ve contributed to this effort, you‘ve already received many of the benefits. If you’re not contributing, your contribution is needed. Contact us if you’d like to participate in the development of a revolutionary tool that has the potential to positively impact product management practices on a global scale.