The First 90 Days With a Marketing Engineer: One System, Three Proofs
A marketing engineer's first 90 days should build and prove one system, not five. By day 30, sign a one-page memo naming the system, the number it should move, and that number today. By day 60, run it on real data with a person approving every output.
By day 90, it runs a week without its builder.
A 30-60-90 day plan for a marketing engineer: one system, three proofs
Day 61. The new marketing engineer has five demos and three new tools on the company card. Nobody on the team uses any of them.
That is what a weak first quarter looks like. It is rarely a talent problem. It is a scope problem.
This is the 30-60-90 day plan we use instead. It works for the owner who brings a marketing engineer on, and for the engineer who has to write the plan.
One system. Ninety days. Three proofs.
The name is older than the job. Gary Lilien and Arvind Rangaswamy have taught marketing engineering since their first edition in 1998. In Principles of Marketing Engineering and Analytics, written with Arnaud De Bruyn, it means turning data and judgment into tools that help marketers decide.
The same book saw the next step coming. It describes a future where most analysis runs without an analyst. It also describes agents that act on the result.
Today's marketing engineer builds that next step. A marketing engineer is a marketer who builds systems: data, agents and automations that keep working after the builder stops touching them.
The Three Proofs is our plan for that first quarter. By day 30 the engineer proves the problem, by day 60 the output, and by day 90 independence.
One system, three proofs, ninety days
- Four inputs Before day 1 One number, read access, one approver, twenty real conversations.
- Proof of the problem Day 30 A signed one-page memo: system, number, baseline, approver, monthly run cost.
- Proof of the output Day 60 The smallest version live on real data. A person approves every output.
- Proof of independence Day 90 A handover document, a week run without the builder, the number read against its baseline.
The Three Proofs, our 90-day method.
The textbook built tools to decide with; the role now builds systems that act
| Marketing engineering, the textbook | A marketing engineer today |
|---|---|
| Turns data and judgment into decision models | Turns data and judgment into systems that run every week |
| A manager uses the model, then decides | A person approves what the system makes |
| Automate only where a wrong decision is cheap | The same rule, applied to agents and automations |
| Predicts agents that act on the analysis | Builds those agents, one system at a time |
Source: Lilien, Rangaswamy and De Bruyn, Principles of Marketing Engineering and Analytics, 3rd edition. Right column: our reading.
Before day one, hand over four things only the owner can give
First weeks are usually wasted. Gallup found that only 12 percent of employees strongly agree their company onboards new people well. A brand-new kind of role makes it harder.
So four things must be ready before the start date. Only the owner can give them.
One number: the business number this person should move by day 90, such as booked calls, qualified replies, cost per sale or hours lost to reporting. Can't name it? Then you are not ready to hire.
Read access: the CRM, ad accounts, analytics, call recordings and support tickets. Read-only at first. Write access gets earned.
One approver: a named person who reads what the system makes before a customer sees it. They need 20 minutes a day for it.
One name, not a committee. Gino Wickman makes the same point about goals in Traction: when two people own a goal, nobody owns it.
Twenty real conversations: sales calls, lost-deal notes, support threads. They feed the whole first month. They are also what most companies take longest to dig up.
Four inputs decide whether the first month is reading or waiting
| Hand over | Why it matters | Without it |
|---|---|---|
| One business number | The system answers to it on day 90 | Day 90 becomes an argument about feelings |
| Read-only access | The first month is reading | The first weeks go to waiting for logins |
| One approver, 20 minutes a day | Nothing reaches a customer unchecked | Every output waits for a meeting |
| Twenty real conversations | Raw material for the customer memo | The engineer guesses what buyers say |
Our pre-start checklist.
The Three Proofs is a 90-day plan that builds and proves one system before a second one starts. Proof of the problem by day 30: a signed one-page memo naming the system, one business number, that number's baseline, the approver and the monthly run cost. Proof of the output by day 60: the smallest working version live on real data, every output approved by a person, every correction written down as a rule.
Proof of independence by day 90: a handover document, one full week run by someone other than the builder, and the number read against its baseline, followed by one call: keep, fix by a date, or kill.
Why one system? Five half-built systems cost more than none
Every owner wants five systems at once. The research on change says do the opposite.
The authors of Accelerate, Nicole Forsgren, Gene Kim and Jez Humble, surveyed software teams for years. In one year's data, medium performers did worse than low performers on some measures. The authors' best explanation: they were in the middle of a big change.
Low performers spent 27 percent of their time on unplanned work and rework. Medium performers spent 32 percent. The authors call the dip a J-curve: things get worse before they get better.
Our reading: the same dip hits a marketing team. Every half-built tool needs checking, fixing and explaining. Five dips at once is just a hole.
The book's foreword names the fix. Courtney Kissler called it limiting the blast radius: start with one or two teams, not the whole company.
Andy Grove said it in High Output Management. Try to focus on everything, and you end up focused on nothing.
How to waste a marketing engineer's first quarter in four easy steps:
1. Buy three tools in week one. Read the customer calls later.
2. Ask for five systems. Accept five demos.
3. Skip the baseline. Judge day 90 on vibes.
4. Let the builder be the only person who can run it. Call it a system anyway.
That is not a quarter. That is an expensive hobby.
Medium performers did more rework than low performers: the J-curve
Share of time spent on unplanned work or rework, by performance group, one year of survey data
- High performers 21
- Low performers 27
- Medium performers 32
Source: Forsgren, Humble and Kim, Accelerate, Appendix B.
Five systems at once means five dips at once
| Five systems at once | One system first |
|---|---|
| Five half-built tools to check and fix | One tool, checked every day |
| Five baselines nobody set | One baseline, signed on day 30 |
| Only the builder can run them | Someone else runs it for a week |
| Day 90: five demos | Day 90: one keep, fix or kill call |
Our comparison.
Days 1 to 30: watch first, cut steps, then sign one memo
Month one is mostly watching. Donella Meadows gives the rule in Thinking in Systems: before you change a system, watch it work for a while.
So the engineer sits in on sales calls, reads tickets, and watches the weekly report get built. They look for work your team repeats every week. They look for the step where a lead goes cold.
Next, they chart one process, every single step. Grove's rule for simplifying work: count the steps, then aim to cut 30 to 50 percent of them. Do that before anything gets automated.
Automating a messy process just makes the mess faster.
Which problem goes first? Lilien's book says to pick one with good odds of fast, visible success. Prabhakant Sinha and Andris Zoltners, reviewing hundreds of their own model projects, found the biggest wins where the problem was moderately complex and easy to measure.
Our rule adds one line. The first system answers to a number your finance person already tracks. Nobody argues with that number on day 90.
Month one ends with one page. We call it the decision memo: which system, which number, that number today, who approves, and what it costs to run each month.
That number today is the baseline, the starting value you judge the result against. The owner signs the memo. Without a baseline, day 90 is an argument about feelings.
One small win is allowed. Mike Michalowicz, in Clockwork, tells owners to give a new hire one task to run alone in week one. An alert for leads that waited too long is a good one, and the case for it is in speed to lead.
Small wins, yes. Second systems, no.
Proof 1 is one page: the number, its baseline, one approver and what waits
- One business number, the one the finance person already tracks.
- The baseline. Day 90 is judged against this line.
- One named approver with time on the calendar, not a committee.
- Writing down what waits keeps the quarter to one system.
Example page built for this article with a made-up company and made-up numbers. The fields are the decision memo defined in section 3 (system, number, baseline, approver, monthly run cost); the step cut follows the 30 to 50 percent target in the same section.
Five steps from day 1 to a signed memo
- 1. Watch Sit in on sales calls, read tickets, watch the weekly report get built.
- 2. Map Every tool, who logs in, what data moves between them, what each costs a month.
- 3. Chart Every step of one process. Aim to cut 30 to 50 percent of the steps before automating.
- 4. Pick One problem tied to the number: easy to measure, only moderately complex.
- 5. Sign The decision memo, with today's number as the baseline. The owner signs it.
Our method. The step-cut target is from Grove, High Output Management.
Start where the problem is easy to measure and only moderately complex
- Skip for now Nobody will agree on day 90 whether it worked.
- Best first pick If it is moderately complex, not huge. The biggest wins sit here.
- Not the Rock Hard to prove and small. Leave it on the list.
- Week-one win Good for the small first win. Too small for the quarter.
Sinha and Zoltners' finding, as reported in Principles of Marketing Engineering and Analytics. Cell advice: ours.
Days 31 to 60: build the smallest version, and approve every output
Month two is the build. Start smaller than feels useful.
Before building, the engineer writes a job spec for the system, the way you would for a hire. Our template is in how to write a job spec for an AI agent.
The first version runs on real data by about day 45. Every output goes to the approver before a customer sees it. Every correction becomes a written rule the system reads next time.
Do not tune it yet. David Jenyns, in Systemology, says improving a process is useless until you have a baseline. He also warns against working on more than one stage at a time.
How does a system earn trust? The way a new technician does. The authors of Make It Stick describe how Jiffy Lube trains: nobody touches a customer's car before certification.
A quiz score of 80 percent or better earns supervised work on the job, from a written guide. A supervisor rates every step. Technicians recertify every two years.
We hold a new system to the same ladder. It earns lighter checks only after it passes a written standard on cases with known answers. Then it gets a date to be checked again.
What may skip the approver? Lilien's book gives the test. Automate where a wrong decision is cheap, and keep a person in where it is expensive.
Quality needs its own test, covered in how to evaluate AI agents. At day 60 you want two weeks of runs on schedule and an approver who edits less each week.
Too early to judge the result. Not too early to see if the thing runs.
A new system earns lighter checks one rung at a time
- Read only It reads the data and makes nothing yet.
- Every output approved The approver checks everything before a customer sees it.
- Passes the standard It clears a written standard on cases with known answers.
- Lighter checks The approver checks a sample. Any miss moves it back down a rung.
- Runs alone where a wrong call is cheap With a date on the calendar to check it again.
Our trust ladder, modeled on the certification steps described in Make It Stick.
Let the system decide only where a wrong call is cheap
| A wrong call is | The book's examples | A marketing example (ours) | Who decides |
|---|---|---|---|
| Cheap | Product recommendations, keyword pricing | Which of two subject lines a newsletter uses | The system, with spot checks |
| Expensive or worse | Positioning strategy; heart surgery, aircraft maintenance | A message to your biggest client | A person, with the system's help |
Source: Lilien, Rangaswamy and De Bruyn, Principles of Marketing Engineering and Analytics, 3rd edition. Marketing examples: ours.
Days 61 to 90: make it run without the person who built it
A system its builder has to babysit is still a project. The last month turns it into something your team owns.
Lilien's book draws this exact line. Syntex Labs ran its sales model as a one-time project. The team turned over, nobody kept it up, and the authors say proper monitoring could have added over 10 percent to its profit, at no extra cost.
ABB Electric ran the same kind of work as a program for over two decades. Its president, Daniel Elwing, said it had to be a program, not a project.
The model is the small part. Sinha and Zoltners looked back on more than 2,000 projects. Often more than 95 percent of the effort went to finding the problem, managing the data, managing change and putting it to work.
So three things happen this month. First, the engineer writes the handover document: what it does, where it runs, what it costs, what breaks it, and how to switch it off.
Paperwork? Yes. It is also the line between a project and a program.
Second, the engineer steps away for a full week while someone else runs it. Software teams have a name for this risk: the bus factor. It counts how many people could vanish before the work stalls.
A bus factor of one is a person, not a system.
Third, the number gets read against its baseline in the weekly memo. Then the owner makes one call. Keep it, fix it by a set date, or kill it and write down why.
Proof 3 is a page someone other than the builder can run the system from
- The part most handovers skip. Written down, it stops being one person's memory.
- Every system needs an off switch a non-builder can find.
- The bus-factor test: someone other than the builder ran it for a full week.
- The number goes back next to its baseline before the keep, fix or kill call.
Example page built for this article with a made-up company and made-up numbers. The five parts (what it does, where it runs, what it costs, what breaks it, how to switch it off) and the hands-off week are the Proof 3 method in section 5.
A model nobody keeps up decays; a program keeps paying
| Project: Syntex Labs | Program: ABB Electric |
|---|---|
| Built once, by one team | Part of the company for more than two decades |
| Team turned over and nobody kept it up | Shaped sales effort, new products, ad copy and positioning |
| Could have made over 10 percent more profit from it with monitoring, at no extra cost | Its president said it had to be a program |
Source: Lilien, Rangaswamy and De Bruyn, Principles of Marketing Engineering and Analytics, 3rd edition. Chapter 9.
The model is the small part of the work
- Model projects Sinha and Zoltners looked back on 2000
- Share of effort spent on everything except the model 95
- Extra profit Syntex could have kept with proper monitoring 10
Source: Lilien, Rangaswamy and De Bruyn, Principles of Marketing Engineering and Analytics, 3rd edition. Chapter 9.
What should a marketing engineer deliver by day 30, 60 and 90?
By day 30, a signed decision memo with a baseline. By day 60, one system live on real data, with every output approved. By day 90, a handover document, a week without the builder, and a keep, fix or kill call.
Write each one as a Rock. In Wickman's method, a Rock is a 90-day goal clear enough to mark done or not done.
He caps people outside the leadership team at one to three Rocks a quarter. We use the same cap: the system is one Rock, plus two small ones at most.
Set honest expectations. Wickman reports that his clients hit about half their first Rocks, and 80 percent or more within two or three quarters. That is his record, not ours.
Timelines slip too. Meadows passes on a rule from Jay Forrester: ask how long a delay will take, make your best guess, then multiply by three.
The table below holds the red flags. One flag is a conversation. Three is a decision.
Need a full scorecard? Use how to evaluate a marketing engineer's work. The questions behind the first month's reading are in our marketing engineering audit.
What should exist at each proof, and the flags that say it does not
| By day | Should exist | Red flags |
|---|---|---|
| 30 | Signed decision memo with a baseline; a map of the tools; a customer memo with a quote behind every claim | No named number; no baseline; tools bought before the conversations were read |
| 60 | One system live on real data for two weeks; every output approved; a written list of rules | It runs only when its builder runs it; output reaches customers unchecked; the monthly cost 'depends' |
| 90 | Handover document; one week run by someone else; a keep, fix or kill call | No handover; the number never read against its baseline; systems two to five already planned |
Our checklist. One flag is a conversation; three is a decision.
Plan for about half the goals and three times the delay in a first quarter
| Expect | Number | Where it comes from | How sure |
|---|---|---|---|
| Share of first-quarter goals met | About half | Wickman's clients, Traction | His client record, not audited |
| Share met after two or three quarters | 80 percent or more | Wickman's clients, Traction | His client record, not audited |
| Real delay versus the best guess | About three times longer | Jay Forrester, retold in Thinking in Systems | A modeler's rule of thumb |
Sources: Wickman, Traction; Meadows, Thinking in Systems.
Can a marketing engineer show results in the first month?
A small result, yes. A proven system, no.
Month one can show a visible win, like the slow-lead alert. It can show a memo that tells you something about your customers you did not know.
It cannot prove a system. Pipeline does not move that fast, and a result read after two weeks is mostly noise.
Our view is blunt. If the number has to move in 30 days, you need a campaign, not a marketing engineer.
Sometimes the clock should not start at all. No read access? Nobody with 20 minutes a day to approve?
No number you can name? Then wait. The hire would spend the quarter waiting with you.
Still deciding whether to hire anyone? Our math on consultants versus an in-house team lays out the costs.
Month one proves the problem, not the result
| Month one can show | Month one cannot show |
|---|---|
| A small visible win, like a slow-lead alert | A proven system |
| A customer memo with a quote behind every claim | A pipeline change you can trust |
| A signed baseline | A number read after enough time to mean something |
Our rule.
Write your 90-day plan with AI
Paste the prompt below into your preferred AI. It asks about your business, your number and your access. Then it writes the plan with dates, Rocks and red flags.
It never invents a baseline. If you do not know today's number, measuring it becomes task one.
Using an agency instead of a hire? The prompt works the same way. The calendar does not care who does the work.
Paste into your preferred AI. It asks six questions, then writes one system's plan with Rocks, a calendar and red flags.
Act as a planning partner. Write a 90-day plan for a new marketing engineer using the Three Proofs. Ask me one question at a time, with the example: 1. What does the business sell, and to whom? (Example: roof repairs for homeowners) 2. Which one business number should move by day 90, and what is it today? (Example: booked inspections, 14 a month) 3. Which systems are we considering? (Example: a slow-lead alert, a weekly report, follow-up emails) 4. What can the engineer read on day one? (Example: CRM and call recordings, not the ad accounts yet) 5. Who approves output before customers see it, and how many minutes a day do they have? (Example: our office manager, 20 minutes) 6. Who does the work: a new hire, an agency or a consultant? Rules: - One system for the quarter. Pick the one tied to the number that is easy to measure and only moderately complex. One small visible win in the first week is fine. No second system before day 90. - Never invent a number. If I do not know today's value, the first task is to measure it. Ask me for the day-90 target. - Proof 1 by day 30: chart the process and cut steps before automating anything. Then a one-page decision memo (system, number, baseline, approver, monthly run cost), signed by the owner. - Proof 2 by day 60: the smallest version live on real data. A person approves every output, and every correction becomes a written rule. Output may skip approval only where a wrong call is cheap. - Proof 3 by day 90: a handover document (what it does, where it runs, what it costs, what breaks it, how to switch it off), one full week run by someone other than the builder, and the number read against the baseline. - Day 90 ends with one call: keep, fix by a set date, or kill. - If read access, an approver or the number is missing, tell me to wait before starting the clock. Show your reasoning, then answer: The one system, and why The number: today / day-90 target Rocks (90-day goals, each done or not done): up to three Week-by-week calendar, days 1 to 90 Red flags to check at day 30, 60 and 90 Next three actions: 1. 2. 3.
What to do this week
1. Name the one number. Write down its value today.
2. Name the approver. Block 20 minutes a day on their calendar.
3. Pull twenty real conversations into one shared folder. Our growth repo shows how to keep what the engineer learns in one place.
Want to see the same rules on a real operation? Read how we run our agency as marketing engineers.
Remember day 61 and the five demos. Five demos make a nice slideshow. One system that still runs on day 91 makes a business.
Then pick system two and run the same three proofs
- Problem One number, one baseline, one signed memo.
- Output The smallest version, every output approved.
- Independence A week without its builder, then keep, fix or kill.
The Three Proofs.
Filip Kovacevic is the founder of Anar Agency in Phoenix. He spent five years running SEO, Meta ads, email, and content for medical practices across the United States, and now does the same work for healthcare, home-service, legal, and professional-service businesses, alongside AI implementation. More from Filip →
Want the first 90 days run for you?
Bring the one number you want moved. In 15 minutes we will tell you which system we would build first and what day 90 would look like.
See how we build them →Want to do this work yourself? See how we train marketing engineers.