The hidden pain behind launches

Over the years, I’ve consistently been asked why we founded Metronome. I wrote this blog to outline what initially spurred the idea. In the coming weeks I’ll share some additional in-depth posts on billing problems we’ve seen over the years and how we think about solving them.

The idea of Metronome was born in spring of 2017. At the time I was a very hungry former founder, climbing the ranks of Dropbox engineering. Senior leadership gathered a large group of EMs, PMs, and Designers and announced that Dropbox was going to do a complete brand refresh, setting us up to go public. There was only one problem — they needed a technical lead to run point on the project. As the only person in the room who hadn’t been through a refresh, I naively raised my hand — unknowingly committing myself to 6 months of 24/7 stress.

The scope of this project was pretty massive - complete brand refresh across iOS, Android, and web. A completely new homepage. Updated pricing and packaging. Like any good engineering manager, I coordinated with dozens of teams to ensure that all of our ducks were in a row. And as time estimates came in, the inevitable sandbagging came with it — 2 weeks to update a single image? 2 months to build a new home page … let’s find a way to make that 1 month.

Powered by cold brew and naiveté, I slowly cut through the estimates until we were left with our long pole — 6 months to update our pricing.

I called up our billing team and asked them to walk through the timeline, readying my red pen to cut scope. I never used that pen. In gory detail, the billing team walked me through exactly what was needed to make a pricing change:

• First, jump the queue: Dropbox engineering was an elite crew, but the billing team was firefighting every moment of every day. They had a multi-year queue, with mission critical bugs, billing accuracy issues, and tooling improvements for finance. Simply put, the team couldn’t commit to the pricing change without escalation. I made the call to my boss’ boss, and the pricing change was reluctantly shifted to the top of the list with a time estimate of 6 months.
• Next, update the backend: It turns out that most of the code that specified pricing, packaging, and user-state management was hard-coded. Instead of changing a single field in a database, we’d need to manually vet 1000s of pricing scenarios for accuracy. The company had grown so quickly for so long, that manual patching and testing was the rule, and the ~decade of code was extremely fragile and borderline impossible to edit safely.
• Then, make the change user-visible: Even if we could change the price internally, it turns out that the code that presented pricing & invoice information was completely separate. We needed to co-time the pricing change so that users didn’t get confused when they received their bill. This pricing change had to be replicated and coded into the desktop app, both mobile apps, our web app, our website, and all of our resellers across the globe.
• There’s more — we needed to test downstream finance systems: It turns out that any change in pricing and packaging needed to be rectified through our data teams to ensure that customer cohorting, price experimentation, and revenue recognition were all operating on the same source of truth data. I expected this to be an automated process. Not so. This data was generated through a ‘pipeline’ of spreadsheets, manual manipulation, and sweat from the FinOps team.
• Finally, entitlement management: Dropbox has always been a usage-based subscription product — for a flat fee you get a fixed amount of storage. As part of this rebrand we were excited to experimentally explore tiered pricing and storage. When I explained the desired pricing model, the pricing PM shook his head and said it wasn’t possible. Incredulous I asked what the timeline might be for this. He repeated, it wasn’t possible. Sure, it must be hard, but impossible? That’s kind of extreme. He then walked me through exactly how entitlements were managed and explained that all limits in the application were hard-coded and that the pricing system definitely couldn’t interface with the storage-limit system. After 20 minutes, I let the concept drop and filed it as ‘maybe for v2’.

To their immense credit, the billing team was able to deliver the pricing change and improve the backend in the process, but this project planted a dark seed that something was rotten in the state of billing. For the next 3 years, I’d work closely with the team, build up empathy on the problems they had to deal with, and gradually come to the idea that things could be different. I came to believe that this problem was a critical bottleneck for growth and velocity in software businesses, and founded Metronome to solve it.

Over the next month, I’ll go deeper into key problems in billing, and how Metronome solves them.