Writing

An Engineering Approach to Marketing

Engineering assumes the thing you built will fail somewhere and treats finding out where as the work. Most marketing planning assumes the opposite, and describes only the version where everything goes right.

I trained as an engineer before I ran marketing teams, and I still take the problem apart the same way.

That is not a claim about being more analytical. Plenty of marketers are analytical. It is a claim about a specific set of habits that are standard practice in engineering, rare almost everywhere else, and unusually well suited to a discipline where most of what you build is invisible until it fails.

An engineer starts from an uncomfortable assumption: whatever you designed will fail somewhere, and your job is to find out where before the world does. Marketing plans are usually built the other way, describing the version where everything goes right and treating the failure case as pessimism.

What follows is the actual method.

There is always one best move

In chess, at any point in a game there are more possible moves available than anyone can evaluate. A beginner sees a few and picks the one that feels good. A grandmaster understands that if you look far enough ahead, there is one best move, one second best, one third, and a set of new possible contingent strategies depending on how the next steps unfold.

The moves did not become fewer. The evaluation got deeper.

Marketing planning usually stops at the beginner's depth. Somebody proposes an activity, it sounds like the kind of thing companies do, and it goes in the plan. A hundred thousand dollars on an industry event, because everyone in the category seems to be at one. Then months of recurring meetings preparing for it, without anyone having written down what the spend is supposed to produce or whether a cheaper route to the same outcome exists.

The second question is the one that changes things: what outcome would justify this, and is this the cheapest way to get there? Answering it usually alters the decision and sometimes removes it, because an activity nobody can attach an outcome to is not a plan. It is a way to look busy at a known price.

Depth is what produces a real strategy. Given a specific set of strengths, weaknesses, macro conditions, budget, timeline and company stage, the number of genuinely good options collapses fast. Most of what looks like a menu of choices is one good choice and several expensive ways to occupy a quarter.

In practice: before committing to any significant spend, write down the outcome that would justify it and at least two other routes to that same outcome, with what each would cost. If you cannot name the outcome, there is nothing to approve yet.

Break it into trades

Most people misread marketing because they misread human behavior. They treat a funnel as a series of steps a person passes through, when it is actually a series of trades a person either accepts or declines.

Every step is a microtransaction. Clicking a headline. Giving an email address. Booking a demo. Entering a credit card. Renewing. Referring someone in their network. At each one the person runs the same calculation, and it is not complicated: is what I get back worth more than what I am handing over?

If yes, they move. If no, they stop. There is no third outcome.

Once you see the funnel this way, most breakage becomes obvious. Look at how many company websites ask for an email address with the line sign up for news about us. That is a trade with nothing on one side of it. You are asking for a person's attention and contact details and offering them the opportunity to receive your marketing. Nobody accepts that trade, and the low conversion rate is not a copy problem or a design problem. There is nothing being offered.

The fix is not a better button. It is putting something real on your side of the exchange. A set of tips that solves a problem they actually have. Early access to a tool. A discount. Something that makes the trade worth accepting.

In practice: walk each step of your funnel and write down, in one sentence each, what the person gives and what they get. The steps where you cannot fill in the second half are the steps that are broken.

Attack the plan before the market does

Once a plan exists, my next job is to try to break it. Not to circulate it for comment, which produces consensus rather than strength. To find the conditions under which it fails and decide whether I can live with them.

People who watch me do this sometimes read it as pessimism, or as hunting for reasons something will not work. It is the opposite. The purpose of finding the failure modes is to remove them. Every one you surface in advance is one you can design around, and a plan you have already tried to break is far less likely to break on its own. You are not forecasting failure. You are reverse-engineering success by making the routes to failure fewer, which is the closest thing to making an outcome inevitable that anyone gets.

An engineer designing a structure asks what loads it will face, what happens at the extremes, and which single failure would take down the whole thing. Marketing plans are usually built to describe the version where everything goes right.

Why engineering learned this and marketing did not

The difference comes down to consequence. If I misspell a word in the body of a marketing email, it is embarrassing and the day continues. If someone miscalculates the structures supporting a highway overpass, or sets the curve radius of a road too tight for the posted speed once the surface is wet, people die.

That gap in stakes produces a gap in practice. A discipline where mistakes are fatal develops habits that a discipline where mistakes are merely disappointing never has to: exhaustive attention to detail, simulation before commitment, named accountability for the failure case, and a professional culture that treats all of it as the floor rather than as diligence worth mentioning. A good engineer does not experience that weight as pressure. They experience it as the job.

Almost none of that crosses into marketing by default, which is exactly why carrying it across is worth doing. The bar in most marketing organizations is set by what is normal in marketing. Set it by what is normal in engineering instead and you end up building systems nobody in the category has considered, not because the ideas are exotic but because the standard of care is.

A real example. At one company I joined, marketing was building a customer loyalty campaign with a referral flywheel at the center. The best version was a referral loop built natively into the product: seamless, on-brand, and something no competitor could copy.

Attacking my own plan surfaced the problem quickly. The engineering team was already behind, and there was no in-house user experience designer. So the most important component of the plan depended on capacity that did not exist, and the schedule assumed it would appear.

The version of me that fell in love with the ideal design would have escalated, argued for headcount, and shipped the loop two quarters late or never. Instead I changed course to a third-party vendor. More cookie-cutter, less differentiated, and running on proven technology within weeks.

The principle underneath: a plan that depends on a resource you do not control is not a plan, it is a request. Find those dependencies before you commit to a date, because the market will find them for you at a much worse moment.

In practice: for every plan, name the single component whose failure kills the whole thing, and ask what happens if it arrives two months late. If the answer is that everything else was pointless, redesign now rather than later.

Push nothing downstream

Every decision has effects beyond the one intended. A discount hits the quarter and teaches buyers to wait for discounts. A lead magnet aimed at the wrong audience fills the pipeline and lowers close rate. A launch date pulled forward hits the board deadline and burns the team through the following month.

Engineering has no tolerance for this, because a second-order effect is a crack. You do not solve a load problem by moving the load somewhere the structure is thinner. You either strengthen it or you redesign.

Leaders push problems downstream constantly, usually because the person making the decision is measured on the first-order effect and somebody else absorbs the second. That asymmetry is why it keeps happening without anyone acting in bad faith, and it is why the fix has to be structural rather than a matter of anyone caring more.

Watch where it ends up. Goals get set without being derived. The consequences land on the functions furthest downstream, usually sales and marketing, because those are the functions carrying an outcome number. The number misses, the wrong people are held accountable, and they are replaced. The replacement inherits the same underived goals and the same displaced consequences, and misses too.

Three cycles of that is most of a decade of a company's useful life. The revolving door is not the disease. It is the symptom that the disease was never located, because the diagnosis kept pointing at whoever was standing furthest downstream.

In practice: for any decision, ask what it teaches. What behavior does this train in customers, in the team, in whoever makes the next decision? The answer is usually more consequential than the immediate result.

Build the machine, not the campaign

The clearest example of engineering thinking I can give is a system I built for partnership launches. It ran hundreds of announcements across a team distributed over 12 time zones, with zero status meetings.

Business development signs a memorandum of understanding and opens a shared channel with the partner. The partner sends their materials, social links, and a short description of what they have in mind, and we supply a list of options when they do not.

That intake gets loaded into a partnerships board, and loading it fires the triggers. The relevant people are alerted automatically and a delivery timeline is set from each role's known lead time: press release writer, social media manager, email marketer, graphic designer, video editor, copy editor, and a final quality reviewer. One liaison owns partner communication, collects approvals at the stages that need them, and locks a launch date so both companies promote on the same day.

Nobody assigns anything. Nobody attends a meeting to find out what stage something is at.

Every position had a named backup. When someone took a vacation or got sick, the work moved without a scramble, because the person covering already knew where things stood and what came next. Continuity was designed in rather than improvised each time it was needed.

The decision that actually made it work. Everything above is workflow design. The choice that made the system durable was scheduling every launch three to six weeks out, never inside 72 hours.

That buffer was deliberate and it was load-bearing. It meant every person had enough time to do their part properly. It meant a problem discovered on Tuesday had three weeks of runway instead of becoming an emergency. It meant nothing fell through the cracks, because there was time for cracks to be noticed.

An engineer would recognize this immediately as designing in slack. A system running at 100% capacity cannot absorb variance, so any disruption propagates through the whole thing. A system with margin absorbs the same disruption without anyone noticing it happened.

The visible result was a team doing creative work instead of fighting fires. No 2am escalations, no burnout cycle, nobody at each other's throats over a deadline that was avoidable. The measurable result was hundreds of launches, cross-pollinated audiences, and tens of thousands of email and social subscribers from a standing start. That is how you go from zero to one.

The test I did not expect to pass. I later trained an entry-level associate on the process in a single session. After that they ran it themselves, asynchronously, also without any meetings.

An operator produces results while they are in the seat. A system produces results after they leave it, and it frees them to work on the next constraint instead of maintaining the last one.

Over time, the compounding effects of that difference are immense.

Then check it against reality

Everything above is design, and design is a simulation. A plan is a model of how you believe people will behave, and models are wrong in ways you cannot see from inside them.

So the last habit is the most important: get the thing in front of real people as early and as often as possible, and find ways to make them show you the truth rather than tell you what they think you want to hear.

The most useful test I ever ran was for an ecommerce journal product. Instead of surveying anyone, I took a copy to a nearby bookstore and put it on the front table, then stood back and watched.

Did anyone pick it up? Which side did they turn it to? How long did they hold it? Did they open it, and where? When somebody engaged with it, I asked them about it afterward.

That produced better information in an afternoon than a month of internal discussion, because it measured behavior rather than opinion. People are unreliable about what they would do and completely reliable about what they are doing while you watch.

The principle: never become convinced you are right without data that says so. Not because conviction is bad, but because your rate of learning is set by how fast you find out you were wrong. Someone who tests weekly and revises is compounding. Someone defending a plan they wrote in month one is not.

What this adds up to

None of this is exotic. Think past the first move. Break the problem into its components. Attack your own plan. Refuse to push problems downstream. Build systems instead of campaigns. Test against reality rather than argument.

Most of it is standard practice in engineering and rare everywhere else, which is the entire reason it is worth writing down.

Sadly, most companies are too busy looking busy to stop and do any of it. And that is the actual constraint. When you are traveling too fast, everything around you looks blurry. When you slow down once in a while, it becomes crystal clear. Engineering bakes that pause into the process. Most other disciplines never learned to.

Frequently asked questions

What does an engineering approach to marketing actually mean?

Treating a plan as a system that will fail somewhere rather than a document to be produced. In practice that means thinking two or three moves past the first decision, breaking the funnel into the individual exchanges a person accepts or declines, deliberately trying to break your own plan before launch, mapping second-order effects, and testing assumptions against observed behavior rather than internal discussion.

Is attacking your own plan the same as being pessimistic?

No. The purpose of finding failure modes is to remove them. Every one surfaced in advance is one you can design around, so a plan that has already been attacked is far less likely to break on its own. It is reverse-engineering success by reducing the number of routes to failure, not forecasting that things will go badly.

What does it mean that every funnel step is a trade?

At each step a person decides whether what they get back is worth more than what they hand over: attention, an email address, time on a demo, a credit card. If yes they continue, if no they stop. Funnels break at the step where the exchange stopped being worth accepting, which is why asking someone to sign up for news about your company converts poorly. Nothing is being offered in return.

How do you stress-test a marketing plan before launching it?

Name the single component whose failure would make everything else pointless, then ask what happens if it arrives two months late or not at all. A plan that depends on capacity you do not control is a request rather than a plan. Finding that dependency yourself is cheap. Finding it after committing to a launch date is not.

Why do second-order effects matter so much in marketing?

Because most decisions have consequences beyond the intended one, and the person making the decision is usually measured on the first-order effect while someone else absorbs the second. A discount hits the quarter and trains buyers to wait for discounts. That asymmetry is structural, which is why the fix has to be structural rather than a matter of anyone caring more.

How can a marketing team operate without status meetings?

By making information available where the work happens rather than transferring it in a room. Automated intake and routing, delivery timelines derived from each role's known lead time, one named owner per stage, a named backup for every position, and enough scheduling buffer that problems surface with time to solve them.

Why schedule launches weeks in advance rather than working to tight deadlines?

A system running at full capacity cannot absorb variance, so any disruption propagates through everything. Scheduling three to six weeks out means a problem found on Tuesday has three weeks of runway instead of becoming an emergency. It is the same reason engineers design in margin rather than to exact tolerance.

What is the fastest way to test a marketing assumption?

Put the actual thing in front of actual people and watch what they do, as early as possible. Observed behavior beats stated preference, because people are unreliable about what they would do and completely reliable about what they are doing while you watch.