Escaping the Outcomes>Outputs Trap

For Product Leaders and Product Managers who are stuck in "Outcome Drama"

Cliched business sayings have been around for ages. You might have heard them often:

“The customer is always right”

or

“Think outside the box”

These were not very helpful.

“The customer is always right” actually sounds terrible to me. How would it help me operate? Should I listen to every customer? Maybe a better saying is:

If the customer is not in your target segment, the customer is always wrong

This at-least makes you think.

And then some really good Product Management thought leadership came along and debunked cliched business sayings, questioning the status quo and coming up with better conclusions about how best in tech do product. Then we had new stuff:

“Fail fast, learn fast”

“Build → Measure→ Learn”

“Outcomes over Outputs”

and sometimes even something as complex as Strategy is simplified as “Strategy is not a plan, it is how you win”

And then many product people go to conferences, watch podcasts and adore these sayings because they are good takeaways.

The one common takeaway is “Outcomes over Outputs” that I have been hearing a lot, and I want to give you a framework on how to treat these or such similar takeaways the next time you hear them.

Start with anti-takeaway (or the Type 2) mindset

While some short cliched takeaways might be good, the problem is that we all have a short-memory of concepts.

We read a book, attend conferences or listen to podcasts and remember that one thing, the takeaway. But we, over a period of time, forget the context.

In Daniel Kahneman’s book Thinking Fast and Slow, he describes two kinds of thinking process - Type 1 and Type 2.

• Type 1 thinking is fast, automatic, and intuitive, allowing quick decisions based on patterns and experiences.

• Type 2 thinking is slower, more deliberative, and logical.

We’re all designed to do Type 1 thinking because it is just easier to generalize and take decisions. But doing Type 2 thinking is tough, and is generally more logical and accurate than Type 1 thinking.

When you apply takeaways like “Fail Fast, Learn Fast” at work, you’re doing the easy Type 1 thinking, but when you try to understand the context “Is this a situation in which I should apply this concept, or maybe the concept was more applicable for another kind of situation” is when you get into a bit more time consuming Type 2 thinking.

Most podcasts and conferences lead you to become Type 1 thinkers, and come out with easy to remember “Outcome over Output” concepts without knowing the context.

A good way to avoid the trap is to not ask yourself: What’s the takeaway from the book/podcast/conference?

But ask yourself:

What was the takeaway, and in which context was it applicable?

Make a mental model of

Situaton A←→ Takeaway A

So, let us say you read a book which talks about iterative experimentation approach to achieve a certain outcome and the takeaway is “Iterate and Experiment” but you should rather be asking in which context was this takeaway applicable?

Was it a D2C SaaS company doing this? in which sector or vertical? What kind of talent or team did they have?

So you don’t make a mistake of going to your B2B company and trying to fail often and fast with your biggest clients. Well most of you won’t.

But common sense is not so common.

The “Outcome over Outputs” drama

While having an end goal of how to deliver value to customers and business is always a good idea, but you can’t cookie-cutter these approaches to all situations.

Again, what is the context and the situation?

It maybe a customer or business situation, such as what kind of business model you may have, what kind of customer problems are you solving? Have these problems been solved before? Are you just doing a checklist roadmap because of regulation need?

You may sometimes need Outputs (When the ask and end output is clear) over Outcomes and some other times the other way around. Outcomes could even be imagined as a series of Outputs.

In case you have the organizational infrastructure mature enough, you may allow Product Managers to plan and commit to their outcomes, and in case of a bit immature organization, you may want to just help your Product Managers the next most important output in a series of outputs to achieve the outcome.

The level of assistance you may provide to avoid Outcomes Drama is up-to the organizational infrastructure, which mostly includes:

1. Product Managers Maturity in knowing how to work towards outcomes

2. Org. ability to have the right data and track it to help with outcomes

3. Ability of executives to understand outcomes and encourage them

4. Having challengers in the organization to critique before you commit to the right outcome

5. Encouraged iterative approach to learn and improve (Give your teams the time it needs to become outcome oriented)

and some more.

If you, as a Product Leader, ask your Product Managers to start writing outcomes but your organizational infrastructure is poor, you will get “Outcome Drama”

Because your Product Managers might be ex-Project Managers or marketers turned Product Managers and they just not might have the right approach and mindset to work towards outcomes.

Outcomes need a different mindset. Product Managers should be able to get access to right customer and business insights to decide the right problems to solve (and hence right outcomes to target) and then work towards them in many different rounds, sometimes getting to the outcome in first go, or sometimes in many different ways or iterations.

The Outcome drama may also be the case, even when your Product Managers might be mature. Let us say the executives only care about a roadmap that is delivered by a certain date or they want to know “what can be done by what date” and may think that Outcomes might be too far fetched for work that is simply needed to be done (Just get it done!.. we know what to do).

Other reason you might have an “Outcome Drama “ going on is if you don’t have strong challengers. Let us say you convince your PMs to do outcomes and write them, executives are convinced but then your outcomes may be too mediocre.

In strong product organizations, weak outcomes are challenged until a good strong measurable outcome is reached. You maybe tracking weak outcomes because you’re simply surrounded by those who haven’t tracked strong outcomes ever.

Here’s how Product Managers and Leaders can put an end to the Outcome Drama

(And start becoming a more effective product leader by creating context, then applying the concept through a tested flywheel approach)