We have been told by all the coaches to focus on business outcomes. Outcomes before activity. Name the metric you are going to impact before you build anything.
I believe in it. But look at your actual career and face reality: the business metrics were never yours to own. Somebody else defines the strategy. Somebody else owns the results at the top of the business line. A product team that claims revenue as its own metric ends up accountable for a number it cannot move.
Business metrics live at the strategy level. Revenue, retention, and margin are defined at the top of the business line, and someone on the business side is responsible for measuring them. They get counted whether your team has a great quarter or a hard one.
Your job as a product person is different. Focus on getting the work done efficiently, and on making sure you are working on the right things. On calls with product leaders, the sentence I hear most is some version of the same one: "We're super busy, and I don't know if we're working on the right things." That sentence is the sound of a team carrying a metric that was never set at its level.
The good product managers name the metrics they are going to impact and measure them. I am all for it. The trouble starts when the metric a team reaches for is a business metric, owned inside one product silo.
Where it breaks
The most common way I see this break down is when the product person tries to create the business metrics. That never scales past your silo. There are three or four other product teams. If every team invents its own business metrics, nobody is growing the same business.
It is one of the ways a company drifts into measuring product teams by output instead of impact. Every team ships, every team reports green, and the number at the top barely moves, because no team was ever pointed at it together.
The business above those teams has a harder job than any of them. It has to grow in the most strategic way possible, allocating resources effectively to each product line and focusing on the right projects. That allocation only works when the goals are shared and each team brings honest numbers from its own level.
The only way it scales
I have worked with over 25 product teams in the last two years, and I have found that this only scales one way.
First, there are overarching business goals, likely tied to revenue or cost savings, and every product team points at them. One set of goals for the whole product organization.
Second, underneath those goals, each team creates its own metrics, and those are leading indicators, the things a team can actually drive. We built this, and people are using it. People are coming back. Satisfaction is high.
Teresa Torres makes the same distinction in her work on outcomes: business outcomes tend to be lagging indicators, measured after the fact, and product outcomes should be leading indicators of them. At the product level, it sounds like this: "We know it is working if 20 people are using it every month. New people are joining across the company. Users come back within three days."
Lightly touch the business metrics. Know them, watch them, be clear about which one your work is supposed to feed. Just do not own them, because ownership implies control, and you do not have it. What you have is the work in front of your team, and the numbers that work produces this month.
Those metrics matter. You have control over them, and it is a bonus when you can link them up to the business metrics. The link is part of the job. A pile of team metrics that never adds up to the goal at the top is how you end up with a backlog nobody can connect to the business. Each team's numbers should roll up, or someone should be asking why they exist.
When the rollup is real, the roadmap changes character too. It stops being a list of projects and becomes the place where the business can watch its bets land, which matters because so little of the average roadmap survives the quarter it was planned in.
Write the gaps down
Third, before a major initiative, sit with the business folks. What is the business value? Does it line up with company strategy? Go looking for the answers. If you find that the problem is not defined, or the business metrics do not exist, write that down at the start. That is a gap, and gaps are fine. We work on projects with gaps every day. Naming the gap at the start is a huge thing on its own. It turns a hidden risk into a shared one.
But when the spend is $5 million, fill the gaps first. The bigger the commitment, the more expensive an undefined problem gets.
What you actually control
At the VP level, making sure we are working on the right things below you is the job. And once it is decided, get it done without drift onto other, less important things. Scope gets added, timelines double. Every add means something else is lost, and enforcing that trade is the job too.
This is the problem I spend my days on. At Iteright, we help product leaders decide what deserves investment, keep execution aligned to those decisions, and prove the impact, so the leading indicators a team drives and the business goals above them stay connected in one view.
You cannot control the business metric. You can control whether you are building the right thing, and whether it ships. Own those two completely.
