A few years ago, I watched a talk by Larry McEnerney on writing. In the talk, he made a point that has stuck with me:

What are the subjects of your sentences? Underline the subjects of your sentences and ask yourself if they match what the reader is interested in.

Does this translate to engineering work as well? When we work, what are the subjects of our daily discussions? Are the subjects things like: ticket, sprint, points, goal, review? Or are they more like: customer, error, decrease, bet?

Could it be that the subjects of our sentences signal what we actually value and what we optimize for in our work?

Who is truly responsible for delivering business value to the organization: the product owner or the engineering team?

I recently spoke with a product owner about his experiences working with engineers who are also focused on outcomes rather than just delivering requested features. Here's what he shared:

• "When engineers focus on the outcome, I find myself trusting them more with technical decisions."
• "Focusing on outcomes opens up new opportunities and ideas. The outcome is the key to having discussions about solutions."
• "I love discussing outcomes with engineers because they simply have a different perspective than I do."
• "I can create tickets for all these ideas, and then we'd have to discuss them. But then an engineer looks at it and thinks: I can fix this in half an hour. These everyday low-hanging fruits are really valuable."

The role of a product owner, as we know it, is to serve as the exclusive conduit of business value between IT and the business. But what if that model isn't working as well anymore?

Here's an excerpt from Mark Schwartz's The Art of Business Value on the topic.

I recently discussed with an engineering lead on how to become more customer-centric. They mentioned there was a lightbulb moment for them when we zoomed in on different customer types.

Many people see customer-centricity as being about external customers, that is, the people who pay money for the services. But it turns out there are other types of customers as well. In our exploration, it turned out the team was doing work for four different types of customers:

1. paying customers
2. internal ops (customer care, finance, etc.)
3. other engineering teams
4. the team itself (improving efficiency, speeding up onboarding, etc.)

(Although not technically a customer, we included the team itself as well, because a lot of energy has been put into improving the team's way of working.)

We went further in the exploration:

• Who's driving value for which customer type?
• Does the team want to serve all these customer types?
• Who's responsible for measuring impact for the different customer types?

Understanding who the customer is seems to have given the lead more clarity, particularly about responsibilities, roles, and the team's focus.

If you want to go from output to outcome, you can start bottom-up. For a thing you work on, try to understand:

1. What's the intended outcome?
2. How can success be observed/measured?

After that, mentally let go of the output you were working on. (This detachment could be hard.) Instead, look into the measure and try to identify the best opportunities to achieve success. Choose the best opportunity and execute it. Afterwards, validate if the opportunity has moved the measure as intended.

Going through these steps, you might run into issues, such as:

• There are multiple outcomes we are after, which one to choose?
• How to measure something intangible?
• What if the opportunity will positively impact one metric, but negatively impact another metric?
• We currently don't have anything to measure this or see where the opportunities are.
• The measures are out of our team's control.
• Is this outcome something we want to focus on right now?

This newly gained unclarity is good. You have just turned unknown unknown into a known unknown.

I have found these steps to be generally applicable, from low-level engineering work to higher-level business decisions.