You might have heard about and seen discussions on ‘outcomes over output’. Product leaders in different roles often talk about this shift, a few frameworks, sharing their own experiences and sometimes examples to show how product teams should focus on the outcomes. This recent post by Marty Cagan is a quick reference to this approach, or you can see John Cutler’s LinkedIn post, and here are Josselin Perrus’s excellent examples of outcome over output.
In a product managers’ meetup last month, I noticed a few issues in their half-baked approach towards working for the outcomes.
One, when teams are new to this outcomes over output approach, they are not prepared for the post-outcome moments. For example, if PMF is their most-important outcome (supported by numbers) and they achieve it—how do they respond to that moment when they achieve it? How they build on this outcome? Likewise, if expansion to another country is an expected outcome and they set up successful operations in that new country, how do they carry that ‘outcomes’ momentum forward for what now?
These bridges are either unclear or totally missing, or are again defined in the language of outputs because the outcomes language and the framework are not baked at the system level.
If they design the outcomes for the ‘outcome lifecycle’—our response system for the post-outcome moments brings more preparedness to continue in the momentum in the language of outcomes. An outcome is work-in-progress, leading us to one or more bridges for the other outcomes. This outcomes lifecycle reference builds and then strengthens our peripheral awareness in the products which helps everyone in the organization.
Two, an outcome for one team may not be the right outcome for someone else in the same organization. For example a conversion is an outcome for sales team but not being able to retain (the churn) because of poor onboarding in the product just negates that outcome by sales. Likewise, a customer successfully upgrading from a freemium to a paid plan is an outcome for the product coach. However, a poor support experience after two days can neutralize that outcome.
Adopting outcomes over outputs call for the systematic changes first. In the above example, did the customer stop paying (or downgraded from a paid plan to a free plan) because of poor interaction design, or a false promise in a webinar, or the missing context in a critical user story in the product?
Speaking in the language of fragmented outcomes does not fix such leaks. The meaning of outcome is lost in the ‘life cycle of a single interaction with the customer’. This is why I feel that interaction design is so underrated in our work—interactions have a lifecycle. An interaction’s lifecycle is greater than the sum of all the interactions’ taken together in a single story. We need to map the interaction lifecycle with an expected outcome’s lifecycle to make it work for the customers and for the organization.
Organizations should first define the outcome lifecycle and let all the teams map their roles and skills in this lifecycle.
