Marketing teams are expected to be full-stack now. The tools were the easy part.
Built and run by a product marketing manager who did this inside real marketing teams, not a consultant who read about it.
Workshops for marketing leaders and their teams who have been told they should do everything, with the same headcount, using tools they already pay for. That's the reality of marketing today.
Book thirty minutes
Most AI training teaches prompting. That isn’t where full-stack breaks.
Teams come out of a session energized and go back to working exactly as they did before. Four things usually cause it.
01
Everyone is at a different level, so the work is too.
Full-stack means everyone ships everything. Without a shared standard, quality tracks whoever happened to make it that week. What reaches your customers is the team’s floor, not its ceiling.
02
Everything online gets you started and leaves you stranded.
There is no shortage of guides that produce something impressive and unusable. A landing page that won’t connect to your site. A form with nowhere to send the data. Getting started was never the hard part.
03
The output gets quietly rejected.
Colleagues can tell. Once a draft gets sent back for sounding machine written, people stop using AI on anything that matters and go back to using it for nothing that matters.
04
What does get built dies with the person who built it.
No spec, no handover, no second user. One enthusiast, then a folder nobody opens.
Three things, or it doesn’t hold
01
A shared floor.
Not everyone at the same level. Everyone above the same line. That’s a written standard, not a training day.
02
The ability to ship without a queue.
If the team still needs another function to finish anything, they aren’t self-sufficient. They’ve just moved where they wait.
03
Output that survives review.
By brand, by legal, by the person who knows the subject. Work that gets rewritten downstream didn’t save anyone time.
Everything below is built to produce one of those three. Nothing here is a tour of the tools.
Start from the work. Never from the tool.
Nothing here gets designed in the abstract. Every workshop starts with something your team already ships.
Do it by hand
We take one real deliverable your team produces and watch how it actually gets made, not how the process document says it does.
02
Build in the room
Against your data, your calls, your content. Not a sample dataset. What gets built in the session is usable the same week.
03
Write the spec
Everything leaves as a written specification another person can run. That’s the difference between a good day and a change that survives you.
This is the sequence I used to build twenty-one working systems in a year. It’s the only one I’ve seen survive a team where everyone is expected to do everything.
The four workshops, bespoke availabile
Each one starts from a deliverable your team already makes, and leaves as a written specification someone else can run. Bespoke workshops available after consultation.
01 · Customer evidence
Your sales calls are the best research asset you’re not using
The problem
Marketing writes buyer language from memory and instinct while the company sits on thousands of recorded calls that nobody has read. The evidence is already paid for. It just isn’t searchable.
What we build
A structured, searchable repository of your call transcripts, organized so it stays usable as it grows. Then the first real analysis run against it, on a question your team currently answers by guessing.
What you leave with
The repository and its structure, a weekly maintenance routine, the first themed brief, and the two rules that stop this going wrong: index before you search, and treat a keyword hit as a lead rather than a source.
Proof
I built and maintained one of these across four commercial roles for twenty weeks. It became the shared evidence layer under positioning, content, enablement and campaign work. No human reads that many calls. This isn’t a task made faster. It’s a capability that didn’t previously exist.
Format
One day, or half a day if transcripts are already exportable.
02 · Codification
Stop re-solving the five things you make every week
The problem
Your team produces the same handful of deliverables over and over and starts each one from a blank page. The knowledge of how to do it well lives in a few people’s heads and leaves when they do.
What we build
We pick one recurring deliverable, reverse engineer how it’s genuinely made including the parts nobody writes down, and turn that into a specified, repeatable process the whole team can run.
What you leave with
One or two working specifications, tested in the room on live work, written so a new hire can run them in week one.
Proof
Every tool I built this way is still in use. The ones I designed in the abstract first are not. The instruction that made the difference was always the same: review how this has actually been done, then codify that.
Format
One day per deliverable. Most teams start with content or launch briefs.
03 · Vertical messaging
Vertical messaging built from evidence, not from a whiteboard
The problem
Industry messaging usually comes out of a workshop where the most confident person in the room wins. It reads plausibly and converts badly, because nobody in it has said anything a real buyer said.
What we build
We run one vertical end to end: customer evidence for the pain, CRM for account proof, competitor analysis for the gap, live pages checked for accuracy. Then we document the method so the next vertical costs a fraction of the first.
What you leave with
One finished vertical, and a written method that produces the next one on a single line of instruction.
Proof
My first vertical took three days and produced a process. The next ones ran against that same process unchanged. Turning a piece of work into a method that survives being handed a different input is what separates output from capability.
Format
Two days, run a week apart so the evidence work happens in between.
04 · Credibility
AI writing that survives review by the people who know the subject
The problem
The reason your team quietly stopped using AI on important work usually isn’t quality. It’s that colleagues can tell, and once a draft comes back for sounding generated, nobody risks it again.
What we build
A voice profile drawn from your own published work, a library of the patterns that give AI writing away in your specific category, and a checker that flags them without rewriting anything. Flags only. The writer stays the writer.
What you leave with
The pattern library, the voice profile, the checker, and a held-back control set so you can tell whether it’s actually working.
Proof
I built this because content had started getting rejected internally for sounding machine written. It addresses the adoption blocker rather than the productivity opportunity, which is why it mattered more than anything else I built that quarter.
Format
One day. Best run after Workshop 03, once there’s output worth protecting.
Three ways in
01
Diagnostic
Online call
I look at how your team actually works, then tell you the three things AI would change and the two it wouldn’t. You get a written recommendation whether or not we go further. Credited in full against any program booked within sixty days.
02
Single workshop
One day for groups
Any one of the four or bespoke. Includes the pre-session prep on your data and a written specification afterwards.
03
Program
Three workshops over several weeks
Sessions spaced so the team builds between them, with a check-in in each gap. This is the one that changes how the team works, because the gaps are where adoption is either won or lost.
Thirty minutes
Send me your category and one deliverable your team makes every week. I’ll come to the call with a read on where the time is going and what I’d do about it.
No deck on the call.
Schedule a call