You Can't Ask Product Managers to Think Like Owners and Hide the Numbers

Executive leaders often share the same complaint: "Our Product Managers don't think like owners." They want Product Managers to take full accountability for their product areas, make high-impact decisions, and set a strategic direction. Yet many of these same companies treat financial metrics, business model mechanics, and cost structures as secrets.

That contradiction is built into how these organizations work. You can't expect someone to act like the owner of a business while you hold back the data they need to run it. It doesn't make sense, and it puts the company's bottom line at risk. When product teams don't get financial information, their strategic decisions turn into guesswork.

‍

Why leaders assume everyone can see the numbers

Leaders, especially at the C-level, can easily fall into the "curse of knowledge." They see the company's financial health, unit economics, and operating costs all the time. So they assume, without realizing it, that everyone else sees them too.

Often, they don't. Individual contributors can't read corporate finance by telepathy. If the business model, the cost structure, and company spending are never shared or discussed, individual contributors have no way to find out about them.

Telling a Product Manager they "own" a feature or a user journey means very little if they can't access the business data behind it. Real ownership has two parts:

1. The authority to decide: the team gets to set the product's direction.
2. The context to decide well: the team can clearly see how its decisions affect the company's profits.

Without the second part, autonomy is a mandate with nothing behind it. That is the core business risk. The assumptions Product Managers make, and the decisions they take about how to build the product, end up wrong because they don't have the right information.

‍

"Not strategic enough" is often a transparency problem

A Product Manager who can't see financial performance will optimize for what they can see. Usually that's vanity metrics or basic engagement data. When those numbers don't turn into financial sustainability, executives reach for a familiar line: "This Product Manager is not strategic enough."

I think "not strategic enough" is often a label we use when we don't really want to understand what the problem is. It sounds smart. It also hides the actual gaps in performance. Ask leaders what they mean by "strategic thinking" or "strategic vision," and many of them can't give a concrete answer.

Being strategic isn't about corporate jargon. It means asking the specific questions that help a company make the right decisions for its future. At its core, it comes down to one question: How do we make this product, and this company, commercially successful?

You can't answer that in a vacuum. Strategic thinking needs a clear baseline:

• Current performance: How are the company and the product doing right now?
• Historical data: Are we doing better or worse than in previous periods?

If leadership won't share these numbers, asking a Product Manager to be "strategic" is pointless. You're asking them to plan the road ahead without telling them where the company stands today.

‍

Where cascading OKRs help, and where they hide the numbers

To fix alignment, many tech companies rely heavily on cascading OKRs (Objectives and Key Results). The theory is by the book: link each team's goals to department goals, and those roll up into company strategy.

This makes sense in some cases. But I wouldn't say it's always the best approach, and following it strictly by the book isn't always helpful. Spending hours building cascading OKRs for the whole company can even become a way to hide what actually matters.

OKRs are tools for setting goals and checking performance at the end of a set period. Whatever a team's Key Results say, the top goal of every business stays the same. It has to be commercially successful and profitable, and it has to make enough money to stay stable, grow, and experiment.

Where high-level strategic intent does help is in defining how the company will reach that financial success. There's more than one way to become profitable, so it helps when leadership defines at the top level which one comes first in the next period:

1. Market expansion: growing market share or entering new markets.
2. User acquisition: growing the number of customers.
3. Monetization optimization: raising the average transaction value, or check size, per customer.

When these priorities shift from one period to the next (market share one year, new markets the next, a higher average check the year after), the product team has to know. Following OKRs just for the sake of the process can easily hide the two questions that count. Are we commercially successful? And are we doing better than last period?

‍

What happened when a growth company ignored its costs

I saw this during an interim engagement with a company going through hyper-growth. They had very successful investment rounds and a lot of money to build something new, and their main idea of what to build was a "growth engine."

It was a micro-mobility provider. The core product has natural limits. There are only so many ways a user can interact with a shared scooter or bike. So they focused on getting more users. On the surface, that made sense: more users should mean more revenue.

But there was very little discussion about the cost structure. What does growing the number of users mean for our costs? How will costs scale, and can we keep them lower or even reduce them? The company had a very heavy logistics component, so operating the vehicles was expensive. Still, very little was invested in the cost structure, in operations, or in the products that supported operations.

As operations scaled to serve more users, logistics costs grew massively. The gap between revenue and cost was not good enough to make a sustainable profit.

I wasn't in a position to fix it, because I wasn't allowed to take part in the higher-level decisions. If I had been, I would have looked at the commercial structure of the company, shared it with the rest of the organization, and worked through a few scenarios. If revenue grows and the cost structure stays the same, how will costs grow? How can we optimize the cost structure? Can costs grow more slowly than revenue? What is our profitability today, if there is any? And how do we grow it? You can grow profitability by spending less money, not only by making more. In this company, that was completely overlooked.

‍

How Product Managers can build a business case without full access

Getting full transparency isn't easy when you're a Product Manager and an individual contributor. But some financial data is relatively easy to get, and it's enough to build a simple business case. That case is already useful for a conversation with leadership, and it might even encourage them to share more.

You need two inputs.

The Revenue Input

Work out exactly how much money the product area or feature makes per user. This ties directly to the pricing model and user transaction data, which product teams can usually access.

The Cost Input

Calculate what the engineering work really costs. Ask your engineering team for a clear time estimate to build the new initiative, then multiply it by an estimated day rate for the team. To keep the number realistic, add a 20% to 25% buffer on top of average salaries. That covers the extra employment costs the company pays on top of salary.

This model leaves out wider company costs like servers or other departments' expenses. Still, it gives you something very useful: a direct comparison between what the team costs and what the feature earns. That is enough to understand the business case behind your proposal, and to take it to leadership.