I ran ads before I shipped products. It made me a better engineer.

I spent years running paid acquisition across Google, Facebook, LinkedIn, Bing, Quora and Twitter before I shipped a product of my own. Engineers tend to treat that as the part of my background to skip past. I think it's the part that made the rest work.

Not because marketing is secretly technical. Because the two disciplines are answering the same question from opposite ends.

If it can't be explained, it can't be built#

An ad gives you a headline, a line of body copy, and about two seconds. Anything you can't compress into that does not exist, no matter how good it is.

Spend long enough failing to compress things and you develop an instinct that turns out to be a product instinct: a feature that needs a paragraph of explanation is usually a feature that hasn't been designed yet. The paragraph is the symptom. The disease is that the feature is doing two things, or solving a problem the user doesn't have a word for.

"Upload your résumé, get a website" fits in an ad. That wasn't a marketing decision I made after building Portflix. It was the constraint I designed the product against.

Attribution teaches you what instrumentation is for#

Paid acquisition forces a discipline most application code never gets near: every rupee has to be traced to an outcome. Not "engagement went up". Which campaign, which creative, which click, which conversion, and what it cost.

If you've had to defend a spend, you build a very specific relationship with data. You learn that an event you didn't fire is an event that doesn't exist. You learn the difference between a metric that moves and a metric that means something. You learn to distrust an aggregate that doesn't decompose.

Engineers usually instrument after something breaks. Marketers instrument before anything runs, because otherwise they can't tell whether it worked. The second habit is better, and it's the one I brought with me: the first sixty seconds of a product, meaning signup, first action and first result, should be as thoroughly instrumented as a campaign, because it is one.

Distribution is a system with a build order#

There's a persistent idea that building is engineering and getting users is something softer that happens afterwards. Having done both, the second one has more in common with systems work than most engineers expect: constrained inputs, feedback loops with lag, saturation effects, and a metric you're optimising that isn't quite the metric you care about.

The practical version: you can't bolt distribution on at the end, for the same reason you can't bolt observability on at the end. Both are properties of how the thing was built. A product with nowhere to naturally share its output, no artefact worth showing someone, and with no moment where the user has an obvious reason to tell a colleague, is not a marketing problem you can solve later. It's a design decision that was already made, by default, while nobody was looking.

What this actually buys a startup#

The reason I care about this is narrow and practical. At an early company, the loop that matters is build → put in front of people → learn → change it, and the expensive part is almost never the building.

Someone who can only do the first step needs three other people to close the loop. It's not that engineering-plus-growth makes you better at either one. It's that you can run the whole loop yourself, which means you can run it in a day instead of a fortnight. At the stage where the product is still an argument rather than a roadmap, that speed is the entire advantage.