Outcomes Orientation

A common pitfall for product development teams is to churn out features that do not end up moving the needle on key outcomes in any discernible way. While this may be unavoidable in certain scenarios, it should be relatively infrequent in well-functioning product development teams. So, why does this scenario play out so often?

The root cause can often be traced back to a focus on outputs rather than on outcomes. Product teams, and product companies as a whole, typically love building new features to enhance the customer experience. The implementation cadence is familiar and comforting, and the results are tangible. Consistent feature releases engender feelings of steady progress. 

Another factor is PM (and potentially other internal stakeholder) evaluation and promotion criteria. Many companies and product organizations do not incentivize focusing on outcomes because they measure PM progression, particularly at the junior and intermediate levels, by the ability to shepherd projects with expanding scope to market rather than by the impact those projects have on business outcomes.

So, how do we identify when a product organization is focusing on outputs rather than on outcomes? One key indicator is a culture that accepts not instrumenting features to enable monitoring of one or more metrics. Establishing and monitoring the right success metric post-release helps to demonstrate the impact of the feature, which should directly translate into business impact. Adding this instrumentation to the feature, however, typically expands the scope of the project. When teams are consistently forgoing instrumentation for metric tracking in favor of reduced scope and increased speed to market, this is a clear sign that the organization is not outcomes-focused. 

Companies and product organizations are most effective when they are thinking in terms of outcomes, not outputs. After all, the goal is to deliver value to customers and build a sustainable business, not simply to build and release new functionality for its own sake. To establish and reinforce this outcomes-focused mindset, product teams should be formally tasked with specific business outcomes and then evaluated based upon progress against those outcomes. This reduces the incentive for teams to constantly churn out new features and instead encourages more rigorous discovery work to ensure the right projects are prioritized to generate the desired business outcomes. This framework is sometimes referred to as “Empowered Product Teams,” and I will likely expand on it in a future post. 

Additional Recommended Resources:

The best resource I have seen on this topic is a book by Melissa Perri entitled Escaping the Build Trap. I would strongly recommend it if you are interested in diving deeper. Here is a link to her website with additional detail. Please note this is an unsolicited recommendation. 

Leave a comment