Hey, senior PMs: Shipping faster won’t get you promoted – cio.com

It was 2022 and I was sitting in a quarterly business review feeling invincible.
I was the director of product for a SaaS platform scaling toward $25 million in annual recurring revenue (ARR). My team was a machine. Our Jira hygiene was impeccable. Our velocity was at an all-time high. We were shipping complex features every two weeks like clockwork.
I pulled up my slide deck, proudly displaying our burn-down chart. I walked the executive team through the velocity metrics, showing them exactly how many story points we had crushed in Q3. I sat back waiting for the applause.
Instead, the CFO looked at the slide, then at me and asked a single, quiet question: “Richard, that’s great that you shipped all that code. But looking at the cloud bill, our gross margins just dropped by 4%. Can you explain the margin impact of this release versus the revenue lift?”
Silence.
I froze. I could tell him the latency of the API calls. I could tell him our net promoter score (NPS) to the decimal. But I couldn’t tell him if the feature made money. I had no idea that the architecture we chose was heavy on compute and I certainly hadn’t modeled the cost against the projected usage.
In that moment, I realized I had walked into what I call the Senior PM Trap. I was excellent at spending the company’s money (building software), but I had no idea how the company actually made money. As the product lead, that margin compression was ultimately my responsibility, yet I had treated it as someone else’s problem.
This is the predictable plateau in the career of almost every high-performing product manager. I see it constantly now: We master the craft of execution, agile, scrum and user research, but we fail to master the language of capital allocation. Until I made that shift, from shipping features to managing an investment portfolio, I was never going to break through to the executive level.
Here is how I learned to stop acting like a project manager and start acting like a product economist. By product economist, I don’t mean someone who builds spreadsheets all day. I mean a product leader who can translate technical decisions into financial outcomes that executives can actually act on.
I was raised in what Melissa Perri famously calls the Escaping the Build Trap. In these environments, I learned to measure success by output rather than outcome. The burn-down chart was my scoreboard. If my team shipped 20 story points, I told myself we had a good week.
This mindset worked for me when interest rates were zero and venture capital was infinite. It does not work today.
When my company hit that $25M ARR mark, the physics of our business changed. My CEO didn’t care about my backlog anymore; he cared about the P&L. By focusing on velocity, I was optimizing for the wrong variable. I was running a feature factory that celebrated output even if that output was destroying our margins.
This is also where many CIOs get trapped. They inherit product teams optimized for delivery, not for financial outcomes. Velocity looks healthy, but margin quietly erodes. The question isn’t whether your PMs can ship. It’s whether they understand the economic consequences of what they ship.
To cross the chasm from senior PM to product leader, I had to stop showing my executives a roadmap of features and start showing them a model of returns. I had to learn the three metrics that matter.
Early in my career, my pitch for a new feature was always qualitative. I would stand in front of stakeholders and say: Users are complaining about the onboarding flow. It’s clunky. If we fix it, they will love us.
While true, this wasn’t a business case. User love didn’t appear on the balance sheet and my CFO didn’t sign off on vibes.
The shift happened when I finally walked over to the sales desk. I sat down with our VP of sales and asked a question I should have asked years earlier: How much does it actually cost us to get a customer?
We dug into the numbers to calculate our customer acquisition cost (CAC) payback period. I was shocked to learn that it cost us roughly $15,000 in marketing and sales commissions to acquire a new enterprise customer. More importantly, it took us 14 months of their subscription payments just to break even on that cost.
Suddenly, the onboarding project wasn’t about UX friction anymore. It was about cash flow. If customers churned before month 14, we were literally losing money on them.
I went back to my desk and rewrote the pitch. Instead of talking about delight, I framed it like this: “This onboarding friction is causing a 15% drop-off in the first 30 days. By fixing this, we project a higher conversion rate that lowers our CAC payback period from 14 months to 9 months. That frees up cash flow to reinvest in Q4.”
The feature was approved instantly. The lesson hit me hard: Every feature is an arbitrage play. If I couldn’t quantify the efficiency gain, I was just guessing.
Nowhere was my financial illiteracy more dangerous than in the current AI boom.
Earlier this year, I led a team that rushed to integrate a generative AI feature. We treated it like standard software: We built it, tested it for accuracy and shipped it. Users loved it. Engagement skyrocketed. I thought we had won.
Then the cloud bill arrived.
I hadn’t modeled the unit economics. I failed to realize that every query triggered a chain of vector database lookups, massive compute spikes for inference and API tokens that cost us roughly $0.08 per interaction.
In the traditional SaaS model I was used to, costs are relatively fixed. You pay for the server capacity and whether 100 or 1,000 users log in, your cost doesn’t fluctuate wildly. But with large language models (LLMs), I had introduced variable costs that scaled linearly with usage.
As we scaled, we weren’t just paying for tokens; we were paying for raw compute power. A power user who loved the product was no longer our best customer; they were our biggest expense. I was effectively paying them to bankrupt us.
This forced me to learn the concept of cost of goods sold (COGS). As Bessemer Venture Partners noted in their State of the Cloud report, this is an industry-wide crisis: AI startups are operating with gross margins as low as 25%, compared to the 80%+ standard for traditional SaaS.
I modeled our own cost curve and realized something uncomfortable: at $0.08 per query, usage growth didn’t improve margins; it destroyed them. Without intervention, our most engaged users would become loss leaders.
Whenever I audit product roadmaps today, this is the first red flag I look for: Are you pricing for software (fixed cost) while building for AI (variable cost)? If you don’t cap those costs via model optimization or caching, your gross margins will collapse.
I had to pivot the roadmap immediately. We shifted engineering effort to model optimization, driving the cost down to under $0.01 per query. A senior PM would have kept shipping features; a product leader fixed the economics.
The final ceiling I had to break was understanding capital allocation.
For years, I viewed my engineering team as a resource to be utilized. I fought for more headcount constantly, believing that more bodies meant more features. But an executive views an engineering team as an investment portfolio. We are spending millions of dollars a year on salaries. The question isn’t: “Are they busy?” The question is: “What is the return on that capital?”
I started auditing my own roadmap using the framework of CapEx versus OpEx.
Why does this matter? Because OpEx hits the P&L immediately, reducing earnings before interest, taxes, depreciation and amortization. CapEx, however, is an asset that can be depreciated over time.
When I mapped our roadmap against capital allocation, the imbalance was obvious. Nearly 80% of engineering spend was technically OpEx — we were maintaining existing revenue, not creating new assets. We were treading water, but expensive water.
I walked into the next planning meeting with a different proposal: “We are currently spending 80% of our budget on maintenance. That is a bad investment strategy. I am proposing we freeze non-critical bugs for one quarter to shift our allocation to 60% growth with 40% maintenance.”
This was language the C-suite respected. It treated the engineering team not as coders but as capital. It shifted the conversation from “Why is this feature late?” to “Are we allocating capital to the right bets?”
The era of the technical PM is ending. In a world where AI can generate code, tickets and even roadmaps, execution is no longer scarce. Economic judgment is.
The product leaders who advance won’t be the ones who ship faster. They’ll be the ones who can sit with a CFO, read a P&L and explain why a roadmap improves margin, not just morale.
If you’re stuck at senior, don’t ask for more features to build. Ask for access to the financials. Learn how your product actually makes money. That’s the moment you stop being a cost center and start becoming an executive.

This article is published as part of the Foundry Expert Contributor Network.
Want to join?
Richard Ewing is a product executive and author of the upcoming book The Product Economist. He advises B2B SaaS leaders on bridging the gap between engineering velocity and financial viability.
Sponsored Links

source
This is a newsfeed from leading technology publications. No additional editorial review has been performed before posting.