There are things you don't know you're blind to. Until someone turns the light on. For me it was a leadership meeting at a company building a network of proximity kitchens and last-mile delivery hubs. We were growing fast, the roadmap was full, and then our CEO walked in referencing a memo from Uber's Dara Khosrowshahi: "We have to make sure our unit economics work before we go big". That was the beginning. Around the same time, Sequoia sent its "Adapting to Endure" memo to its entire portfolio and Y Combinator followed with its own warning to founders. All saying the same thing that growth without sound unit economics will no longer be rewarded.
“We have to make our unit economics work before we go big” Uber’s Dara Khosrowshahi
As the message trickled down, we asked our CPO the obvious question. Why should Product care? Isn't this for Finance and Operations? We don't control delivery costs or marketing spend. His answer was: "Think cost-to-serve": It took sometime to understand.
So what actually is unit economics?
The easy way to think about it: how much are you making or losing every time you serve a customer?
Let's start at the most granular level, the unit, which is simply one transaction. For Uber it is one trip. For a food delivery app it is one order. For e-commerce it is one purchase.
What does it cost to serve the customer in every transaction, every dirham spent acquiring, delivering, and supporting that one customer?
What you earn from that transaction minus what it costs to serve it is your contribution margin per unit. Positive means each transaction is contributing to the business. Negative means you are paying to serve each customer - unless your customer comes back often enough to recover it.
“Strip everything away and you are left with one question — does serving one customer make or cost you money”
Sometimes scale fixes a negative margin, if fixed costs spread without variable costs rising. But if your cost-to-serve grows with every transaction, scale only amplifies it.
“Strip everything away and you are left with one question — does serving one customer make or cost you money?”
Garima Sajwan, Director of Product Management @ PetBae
What it looks like in practice
Take a typical food delivery app. A customer places an order. Here is what the full picture looks like, from what they pay to what actually remains:
Why should product managers care about this?
You must be wondering why this is your problem as a product manager. I was in the same place. And I have seen it go wrong and show up months later. Lets take a few examples.
Food delivery - real-time driver chat
A team ships live order tracking with real-time driver chat. Users love it but four weeks later, support tickets have tripled on orders where the feature was used. On investigation the teams find that customers are messaging drivers, getting confused, raising disputes. If each ticket costs AED 4 to resolve, on a AED 2 margin, one ticket negatively impacts the unit economics. The correct question here is whether the retention uplift justifies the support cost, and if the feature can be redesigned to reduce the ticket volume before it launches.
“Every feature carries a cost-to-serve implication. Every time!”
SaaS - AI feature pricing
GitHub Copilot was reportedly costing Microsoft up to $80 per user per month in compute, while charging $10. Every AI feature being shipped today carries the same exposure. A PM decision drove that pricing. Microsoft's broader strategy around Copilot may justify that loss but the PM shipping the feature still needs to know that number exists.
The pattern is always the same.
A feature solves a real problem → a cost line is impacted in the background → Finance finds it eventually. By then you have wasted resources, launched something that increased cost and sometimes you can roll it back, sometimes you cannot.
How I try to use it day to day
I want to be clear, I am not a unit economics expert. These are tools I have picked up over the years and try to apply consistently.
The Feature Gate: Before a feature goes to build
Every feature lands on a backlog because the PM quantified its upside. Either revenue goes up, retention improves, or CAC comes down. PMs are good at this part. What usually gets missed is the other side, the cost of the feature, which is the second component of unit economics. So before every feature goes to build, I run through this:
IDENTIFY which cost line goes up because of this feature? It might not be apparent but you need to dig deeper. Support, delivery, infrastructure, acquisition, name it and state the direction.
QUANTIFY Get the current unit cost for that line from Finance or Ops. Estimate how much the feature moves it. These are approximations so you do not need precision, just order of magnitude. Then net it against the benefit because of which you added it to the backlog. Is the overall impact still positive? If yes, proceed. If not, redesign before build, not after. The driver chat example: support cost per ticket is AED 4. Feature triples tickets on affected orders. Does the retention uplift you projected justify that cost? That is a five minute conversation. It just needs to happen before the build starts.
ALIGN with the owners of the cost line. They need to see the feature details before build. They know things about how that cost scales that you do not and you need that context before you commit to building it.
The Unit Health Check: A monthly habit for PMs
This is the early warning system. If things slip through the cracks and still get launched, or due to external factors something changes, this will catch it and help define your priorities.
SEE Make sure you have a view of these four numbers and how they are tracking over time:
- revenue per unit,
- cost to acquire
- cost to serve
- contribution margin.
Finance or BI likely owns this but you should have access to it. If it does not exist, you need to ask for it.
Read On a regular basis (Monthly/ Quarterly) look for movement. Not absolute numbers. Which line moved, and since when?
Act When something moves the wrong way, bring the right teams together and ask if product can fix this. If yes, it goes into the backlog. If not, it gets escalated. Either way, product is not waiting for the quarterly review to surface it.
I did not come to this naturally. It took a CEO referencing a memo in a meeting, and a CPO connecting it to product, before it clicked for me. I still do not get it right every time. But I ask the question more: what does this cost to serve?
ABOUT THE AUTHOR
Garima is a product leader with 20+ years across startups and large enterprises in the GCC, US, and India spanning real estate, marketplaces, telecom, media and F&B. She's been the first product hire multiple times, coming in early to build the foundation: operating model, roadmap, team, and first launch.
She advises early-stage founders on product strategy, discovery, and go-to-market, helping them move from idea to traction. She works at both ends - shaping strategy with leadership and getting into the detail of execution because in her experience, you can't do one well without the other.
