User Outcomes are Positively Flipped User Problems

​Dear Reader,​

​Last week, I mapped how OKRs connect to the layers of an Opportunity Solution Tree. But especially the Outcome layer deserves its own issue: turning a customer problem into a team-level Key Result. I first wrote about it in 2023, before I had a name for it.

Since then, the positivity flip has become one of the most-used tools in my OKR and Discovery workshops, so consider this the refreshed version. In fact, I am coming straight off a client workshop where this layer unlocked a new aha moment for the company.

Many product teams perceive the focus on User Outcomes as arbitrary goal-setting and the opposite of serving users. That perception is easy to understand when you look at the most widely shared examples of User Outcomes:

• "Users buy more tickets."
• "Customers use more integrations."
• "Returning shoppers add more items to their basket."

A product leader once approached me after a conference talk to share his team's concern that Outcomes would be repackaged business goals. Looking at the examples above, his team was right. These read like how the business wants customers to behave. Nothing in them gets better for the customer.

Two things are missing from goals like these:

A proven problem. A useful Outcome describes a change in behavior that is useful to the audience you intend to serve. You can only know a behavior change matters to users if it connects to a problem you have first-hand evidence for. Without that connection, you're describing what you wish customers would do, phrased like an Outcome.

Influenceability. A product team can rarely move "buy more tickets" directly. It can remove a specific, proven obstacle that stands between a customer and the purchase. The first kind of goal leaves a team watching a number it can't move. The second kind informs everyday decisions.

And while "Outcomes" is a well-established term in our industry, I notice that companies have their own definitions, too. What I have seen as a helpful unlock is to use plain English:

What is the change in behavior we want to create?

The Positivity Flip

Then, the simple question teams need to answer becomes: "How would customers whose problem got solved behave differently?"

Take a proven problem like "Updating our shift planning availability manually creates a high error rate." Flip it, and you can describe the solved state as observable behavior:

High error rate from manual data input → Increase shift planning automation by x% → Reduce error rate in shift planning to 1 per customer per week

The positively flipped statements make useful team-level Key Results precisely because they started as problems. They're Evidence-Informed (the problem is proven), Influenceable (the team can attack the obstacle), and Leading (the behavior changes before the revenue does).

In OST terms, this is the Layer 2 connection from last week. OKRs don't fill your opportunity space. They get informed by it, one flipped problem at a time.

One caveat carries over from the original piece. Don't focus on User Outcomes for their own sake. A flipped problem still needs to serve your mid-term business goals, which is what the Outcome at the top of your tree (or the Impact level of your Impact Map) is there to check. If solving the problem changes nothing the business cares about, it may be real, but it isn't yours to solve this quarter.

Thank you for Practicing Product,

​Tim​

If you consume one thing this week, make it this...

Who is Tim Herbig?

As a Product Management Coach, I guide Product Teams to measure the real progress of their evidence-informed decisions.

I focus on better practices to connect the dots of Product Strategy, Product OKRs, and Product Discovery.