Discover more from The Elements of Product Management
Understand why it's okay to be output oriented...in many cases.
Outcome over output rather than outcome versus output. When you can't control outcome, you control what you can, which is the quality and quantity of outputs.
This week’s post is shorter because I was experiencing the side effects from my flu and covid booster vaccine. However, don’t be discouraged. Please consider getting your flu and covid vaccine. It’s perfectly safe to get them during the same visit.
Over the 10+ years, there’s been a trend in product discussions to focus on results (outcomes). Marty Cagan wrote about it in 2014, when discussing Product vs. IT Mindset…“funding projects (output) [versus] product teams measured by business results (outcome)”. But this focus on outcomes/results isn’t new. A quick search uncovered writers outside of the product management space. In 2007, John Mayer discussed this in “Challenges and Lessons in Implementing Results-Based Management”. In it, he wrote that one major challenge when focusing on outcome / results-based management.
People are generally comfortable with being accountable for things they can control. Thus, managers can see themselves as being accountable for the outputs produced by the activities they control. When the focus turns to outcomes, they are considerably less comfortable, since the outcomes to be achieved are affected by many factors not under the control of the manager:
It seems it’s all about outcomes, but I wonder if the outcome versus output is a strawman comparison. It is truly an either-or choice?
Understand how outputs influence outcome.
I recently interviewed a CPO who said one common fallacy PMs hold is the assumption that a single feature or idea, when perfectly executed, will generate the desired outcome. In reality, it’s more likely a combination of different outputs with different coefficients, when working together, may generate that desired outcome.
In other words, the target outcome Y = aX₁ + bX₂ + cX₃ where Xs represent different outputs.
When you view output this way, you might rethink the outcome versus output comparison. You might start considering the need to brainstorm and plan for more than one solution/project (output) and the projected impact (coefficient) of each solution in getting to the desired outcome. A multi-solution frame of mind is different than a single-solution approach. Unfortunately, we are more geared through our formal education to seek single solutions when outcomes really required multi-pronged solutions.
This is why I think the “versus” terminology, which I’ve previously held, perpetuated the wrong perspective. I think a better word might be “Outcome over output”, where I’m borrowing language from the Agile Manfiesto… “That is, while there is value in the items on the right, we value the items on the left more. This is why I’ve always felt that good product managers need project management skills, having written about “Supplementing product roadmaps with project roadmap.” It’s not either-or.
It’s about control.
Here are a few statements I think you will agree.
Controlling the uncontrollable is uncomfortable or impossible. By definition, how do you control that which is uncontrollable?
Product managers should be held accountable for their actions.
Evaluation techniques are not sophisticated enough to isolate and measure each and every product manager’s action to perfectly determine contributing factors to an uncontrollable outcome.
This is a fundamental challenge with outcome orientation. While we value outcome over output (at the organizational level), we manage people, especially early career PMs, via output. This creates an unspoken dissonance, where PMs are rewarded and promoted for more output, but the organization talks about outcomes. The problem is compounded by organizations that preach a “learning mindset” where you learn through failure. If we want to earnestly reward people who learn quickly through trial and error, how do you hold a person accountable for actions, that to the individual are reasonable but failed? As I’ve experienced, a reasonable solution for me is probably an illogical fallacy or fantasy for you.
This is another reason why many organizations default to output orientation. It is easier to control and reward. It’s easy to measure, control, instruct, and reward how many holes in what time period you’ve dug. Measuring, controlling, and rewarding outcomes takes a lot more time and consistent effort.
Why “Outcomes Over Outputs” Is Flawed Advice (found a good article after I came up with my observation of outcome over outputs … to critique myself). In short, two important points:
Outcomes over outputs tell us that we should make sure the output we create is the right output, but we can’t stop producing output.…and producing high output is often the best way of getting there [increasing probability of reaching outcome].
The more delay or inability to measure outcome precisely, you focus on controlling what you can. One of that is inputs (i.e., all of the data and research that flows into the design and development)