The War Between Marketing and Product

San Francisco · May 19, 2026

The product review is at 2 p.m. and I already know how it's going to go. I've been in this meeting before, at three different companies, and it always ends the same way: two teams that share a Slack workspace and a company mission staring at each other across a conference table like they're negotiating a hostage situation.

On one side, my growth team. We have a request. A simple request, or so we think: add a "Share Report" button to the analytics dashboard. One button. One feature. Our data shows that accounts where multiple users view reports retain at 91% after six months. Accounts with a single viewer retain at 54%. The math writes itself.

"We've had this on the roadmap for two quarters," I say, pulling up the Jira board. "It keeps getting bumped."

The head of product, a woman named Claire who is very good at her job and who I genuinely respect, takes a slow breath. The kind of breath that means she's choosing her words carefully.

"It keeps getting bumped because the auth layer for multi-user report sharing requires a permissions refactor that touches fourteen microservices," she says. "It's not a button. It's three sprints of infrastructure work."

"But the button is what the customer sees."

"The customer also doesn't see the database migration that'll take the site down for four hours if we rush it."

This particular fight started, as most do, with a metric going the wrong way. Our expansion revenue — the money we make from existing customers upgrading — had flatlined. For three months straight, net revenue retention sat at 103%. Not terrible, but we'd been at 112% six months ago, and the board had noticed. (The retention story goes deeper — see the retention curve nobody wanted to see.)

"What's driving the compression?" the CEO asked during our last exec sync.

I had the answer ready. "Seat expansion is down 34%. Customers are buying initial contracts at the same rate, but they're not adding users. And the reason they're not adding users is because there's no reason to. The product is designed for a single power user. If you want to share insights with your team, you export a PDF and email it."

"So we need collaboration features," the CEO says.

"We need the share button," I say. "That's the wedge. Get a second person into the product, and the expansion motion takes care of itself."

The CEO nods. She turns to Claire. "Can we prioritize this?"

Claire's jaw tightens, almost imperceptibly. "We can discuss it in the product review."

That's product-speak for "no, and I'm going to explain why in a room where I have more leverage."

Every growth team thinks the product roadmap is a suggestion box. Every product team thinks the growth team doesn't understand technical debt. They're both right.

There are eight people in the room. Me. Claire. Two engineering leads. Our data analyst Priya. The VP of Engineering, who attends these meetings the way a diplomat attends peace talks — present but noncommittal. The CEO, who is on her laptop and half-listening, which is her way of signaling that she expects us to work this out ourselves. And Marcus, my growth PM, who built the business case and is about to present it.

Marcus is good. He's 28, came from Stripe, and has the rare ability to speak both growth and engineering fluently. He presents the data: the retention gap between single-user and multi-user accounts, the expansion revenue decline, the competitive analysis showing that four of our five main competitors already have sharing built in.

"The estimated impact is $840K in incremental ARR over twelve months," Marcus says. "Conservative estimate. We're using a 15% adoption rate, which is well below industry benchmarks for collaboration features."

Claire lets him finish. Then she pulls up her own slide — because of course she has a slide.

"Here's the current roadmap," she says. The screen fills with a Gantt chart that looks like a subway map. "We have committed deliverables for the next two sprints: the API rate limiting overhaul, which three enterprise customers are blocking renewals on. The SOC 2 audit remediation items, which are legally required by July. And the performance optimization work that Engineering has been asking for since Q4 because our p95 response times are at 1.2 seconds, which is unacceptable for a product that people use eight hours a day."

She pauses. "If we pull engineers onto the share feature, one of these three things doesn't happen. Which one do you want to cut?"

The room goes quiet. This is the move. The product team's best move, every time. They don't say no — they make you say what you're willing to sacrifice. And the answer, of course, is nothing. You can't sacrifice the enterprise renewals. You can't skip the compliance work. And you definitely can't ignore performance, because slow products churn.

"What if we scoped it down?" Marcus tries. "A read-only share link. No permissions refactor. Just a URL that anyone with the link can view."

One of the engineering leads — a quiet guy named Vikram who rarely speaks in these meetings — looks up from his laptop. "That's actually doable. Two weeks, maybe three. We'd need to build a token-based access layer, but it doesn't touch the auth system."

Claire looks at Vikram. Then at me. I can see her doing the calculation: is this a reasonable compromise or a Trojan horse? (It's a Trojan horse. Once we have share links, we'll push for permissions, then comments, then real-time collaboration. But she knows that, and I know she knows that.)

"I'll need to see a spec," she says.

Marcus nods. "End of day tomorrow."

The spec takes three days, not one, because the engineering lead who said "two weeks, maybe three" revises his estimate to five weeks once he actually looks at the codebase. This is normal. Estimates are lies we tell to get meetings to end.

Claire approves the project. She puts it in Sprint 14, which starts in three weeks. My team celebrates. Her team sighs. The CEO sends a one-line Slack message: "Good outcome. Let's not make this a pattern."

But it is a pattern. It has always been a pattern. And here's the thing I've learned across twelve years and three companies: the tension between growth and product is not a bug. It's a feature.

I mean that literally. The tension is what keeps both sides honest. Without growth pushing, product would spend eighteen months on a perfect architecture that nobody uses. Without product pushing back, growth would ship a hundred half-baked features that create technical debt you spend years paying down.

At Flowsmith — the company I was at before this one, the one that got acquired — we didn't have this tension. Product and growth were the same team. The founder ran both. We shipped fast and broke things and it worked until it didn't. By the time we hit $20M ARR, the codebase was so fragile that adding a new feature was like performing surgery on a patient who's also running a marathon. The acquirer spent $6 million in the first year just on technical debt remediation.

At Corral — the company that died — we had the opposite problem. Product ran everything. Growth was an afterthought. We built the most beautiful, most well-architected product in our category, and nobody used it because we never figured out how to get it in front of people. We ran out of money with 847 users and a Net Promoter Score of 72.

We ran out of money with 847 users and a Net Promoter Score of 72. The product was beloved by almost nobody.

The share feature shipped last week. Read-only links, just like we scoped. Marcus's team set up tracking on day one: 23% of active accounts generated at least one share link in the first five days. That's above the 15% we modeled. Early signal, tiny sample, but the direction is right.

I sent Claire a Slack message when the numbers came in. "23% adoption in week one. Thank you for making this happen."

She wrote back: "Thank Vikram. And start writing the spec for permissions, because I know that's next."

She's right. It is next. And we'll have the same fight, in the same conference room, with the same dynamics. She'll push back. I'll push forward. We'll compromise on something smaller than what I want and larger than what she planned. The product will get a little better. The numbers will move a little more.

This is the job. Not the dashboards, not the experiments, not the growth hacks. The job is sitting across the table from someone who sees the world differently than you do and finding the narrow strip of ground where you can both stand.

I used to think the goal was alignment. Now I think the goal is productive disagreement. If marketing and product agree on everything, one of them isn't doing their job.

The share feature is live. Expansion revenue is a lagging metric, so it'll be sixty to ninety days before we know if the thesis holds. It's the same kind of waiting game I describe in the Q3 experiment log — running the tests is easy; waiting for the data is hard. I'll be here, refreshing the dashboard, arguing about the next feature, and trying to remember that the person on the other side of the table is building the same thing I am.

Just from a different angle.