The product manager's guide to proactive risk management

How to mitigate risk from building the wrong thing, poor technical planning, and bad process

Download white paper

Navigate evergreen delivery

The risk of bad process

Even the best individual contributors can be corrupted by bad processes and the overarching organizational ecosystem in which the team performs work. For example, despite establishing agile adoption committees in the next step, the enterprise falls victim to waterfall planning strategies. Leadership finds themselves wondering why adoption rears turbulent and unpredictable results. The most frequent risks stem from inadequate processes that surface as technical debt, product debt, poor code quality, and volatile team output.

Risk management image 9

Technical debt is defined as the long-term cost of rework. It is caused by teams cutting corners to get the product out the door faster (a sometimes acceptable strategy) or by poor and accidental technical decisions. Technical debt is closely related to engineering maturity. It is worth establishing and reviewing best practices across the following:

  • Data strategy

  • Testing strategy and metrics

  • Scalability requirements and metrics

  • Performance metrics

  • Security standards and testing

  • Monitoring tools, reporting

  • Code quality standards, testing

  • DevOps strategy

Product debt is not technical in nature but implies a similar future cost of rework to improve the market fit (or user adoption). For example, an eCommerce platform integrates authentication and authorization services from an existing social platform, such as Facebook, to speed up the initial go-to-market timeline. Debt itself is not a risk, as long as the team is aware of the accrual.

Actively log technical and product debt as stories in separate debt backlogs. Stories are estimated, and the total size of the technical backlog is monitored during each sprint. Teams allocate part of their sprint capacity for debt removal, and the delta of change is reported during a demo.

Avoid scenarios where technical debt accrues faster than it is cleaned up. Eventually, the product reaches a point of no return where teams experience never-ending churn without the ability to ship new features (also known as legacy software).

Risk management image 10

Poor code quality also puts evergreen products at risk. Adopting a set of strategies for quality metrics (e.g., test automation, reporting) and code quality standards (e.g., code reviews, styling) enables organizations to monitor risk and correct errors when necessary.

Consider the tracking of defects as stories in the backlog. For example, a report that contrasts the number of escaped defects with resolved defects depicts several insightful stories on the effectiveness of the testing strategy. The ability to resolve defects without delays implies healthy elasticity in the pipeline. However, increasing the overall defect quantity uncovers a poorly designed test automation strategy or lack of unit coverage. Similarly, tracking defects discovered by internal testing engineers pre-release reveals individual engineers are getting sloppy and vice versa.

Tracking metrics enables the product team to self-govern and course correct.

Risk management image 12

Risks presented by volatile team output manifests in an unpredictable sprint velocity. For example, the root cause of volatile throughput could be estimation. Teams overestimate and under commit, trying to game the metric for when pressure is being applied from senior leadership. In other instances, root causes indicate a bottleneck in dependencies stemming from poor refinement of the backlog.

Monitor volatility as a metric because it allows a product manager to step in and diagnose underlying agile process challenges.

Volatile team input

Risk management image 13

Continue to:Manage risk to make great things