The Price Will Change

The week before a launch, we changed the price. It was the right call, and I'd make it again.

For about a month, I'd owned the economics of a new data feature. That's part of my job: negotiate what we pay the provider, then make sure every plan we sell it on stays profitable. I worked with the provider until the cost made sense for both sides. I modeled every plan. Every time the terms moved, I shared the full breakdown so product and engineering could see what each choice meant for the business. We agreed on a pricing approach early, and we built toward it.

Then the build came together, and the numbers in the product didn't match the original plan. On some plans we'd lose money. On others we'd look expensive.

So I laid it out: where we'd lose, where we'd look expensive, and three ways to fix it. One option was to accept thinner margins on day one and revisit once we had real usage. I put it on the table and argued against it, because protecting the margin is the part of this I'm accountable for.

Then we worked through it together. Product and engineering knew how a user would move through the screen for this integration: what should be free so people can get in and see the value, and which action is the one worth paying for. I brought the cost floor and what each plan had to earn. Within half an hour, we had a better structure than the one we'd all agreed on a month earlier.

Search stays free, like browsing a store. You pay at the checkout: the action people came for carries the cost of the browsing that got them there. One add-on got split in two so each could sit at a lower price. And an alert warns us before the data we've already paid for runs low, so the free part never quietly turns into a loss.

None of us would have landed there alone. When I was negotiating, the screen didn't exist yet. We had a plan for how it should work, and the path through it changed several times as the product took shape, because the goal is always to make it simpler to use. My model knew the economics. It couldn't know the final screen.

The point is that things will change. The work is making sure the numbers still make sense when they do.

Here's what I think is going on

Every launch has two numbers in it, and they're very different kinds of numbers.

The first is the cost: what we pay the provider. It's negotiated before anything is signed, and once it's signed it usually doesn't move much. That number deserves the month. Every hour I spent on it was worth it, because it's the reason the free part of the product is affordable at all.

The second is the price: what users pay. You can't finish it before launch, no matter how good the framework you start with. It gets shaped by decisions made late in the build, for good reasons: what's free, what's opt-in, how it shows up on the screen, what gets bundled together, what gives users the best experience, and what keeps the platform as fast as they expect. Any one of those can change where the cost lands. A plan gets you started. You reach the right price by iterating with the people building the product, as the real thing takes shape.

Lock the cost, float the price.

Floating the price is only safe because the cost is locked. A cost you've thought through carefully gives you room to adjust the price without putting the business at risk.

And there's a good reason to want that room. A lot of products start out freer than they'll end up. Dropbox gave away free storage, and people paid once their files lived there. Zoom gave every group meeting 40 free minutes, and teams paid once it was how they met. Figma was free for individual designers, and companies paid once whole teams worked in it. Each one got people using the product first, learned what mattered to them, and then charged for the value they'd come to depend on. By then, paying for more felt fair.

That's what I want with data too. Not a perfect price on day one, but data that becomes part of how someone runs their business every day.

This doesn't fit every situation. If you can't fund the launch while you wait to learn, you can't float anything; that's a survival question, not a pricing one. Some numbers really are fixed once you sign, like minimum commitments, and those deserve all the time you can give them. And when you do adjust later, change what's included, what's free and what's an add-on. Raising the price on the exact thing people already have is how you lose the trust the free part earned.

Here's how I think about launches and releases. Before anything is signed, I own the numbers that won't move: cost, commitments, minimums. That's where my hours go. Everything else (what's free, what's included, how it's packaged) gets a number I can defend, a note on what usage would make me change it, and an alert that tells me when.

Then we launch and let real usage teach us the rest.

The plan will always change. So the question I'd ask before any launch is a simple one:

Which of these numbers is locked, and which one is still learning?

Marc

P.S. What's a price you planned carefully that changed once the product was real? I'd like to hear it. If you're reading this in your inbox, just hit reply. If you're on the site, you can reach me through the Contact page.