Your team isn't resisting AI, they're waiting for someone to show them where it fits.
AI adoption training built and run by a product marketing manager who does this inside real marketing teams, not a consultant who read about it.
Every function already owns the standard that would make AI work for them. Brand has the design system, content has the reasons to buy, SEO has the questions buyers actually ask yet nobody has handed it to the tool. Give each of them one weekly deliverable that runs on their own standard and keeps getting better, and the work starts to show it.
Reach out to me to learn more
You bought the licences. The work didn't change.
Not because the team is unwilling. Four things stop capable people before they start.
01
Nobody knows where it fits in their own week.
AI feels enormous. AI inside Tuesday's standard is a specific, answerable question and it's a different answer for brand, for content and for SEO.
02
Work has no syllabus.
Everyone who ever learned something difficult learned it from a sequence somebody else designed. "Go learn AI" hands a busy person a subject with no visible first rung.
03
Nobody has said what they're allowed to put in it.
80% of marketers use AI regularly. 7% have any formal guidance. So the safe move is to keep it away from anything that matters which is exactly where it would have mattered.
04
What does get built stops improving immediately.
One person builds something awesome on a Thursday. It is exactly as good six months later, because nothing in it learns and nobody owns it.
Three things, or it doesn’t hold
01
One per function, not one per team.
Brand's, content's, SEO's. Each running on the standard that function already owns, like a written thing, not a good session.
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.
Not by taste, by rule. A written standard the maker checks before sending, so review is a yes or a no instead of a rewrite.
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
Answer the permission questions out loud
What can go in, what can't, written down on day one so nobody quietly stalls on it three weeks later.
04
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
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.
You keep what we build
Every workshop ends with something written down and running: a coding scheme, a review standard, a specified process, a working checker. Yours, in your systems. No licence, no seat, no retainer.
And each one has a loop in it, so the thing you own in six months is better than the thing you built. A system that only works as well as the day it was made is a system you'll be replacing.
You could build this yourself. Someone on your team probably has
The building was never the hard part. The problem is that the thing one person builds on a Thursday has no spec, no second user, and no owner the day they leave. I've spent years marketing security software and regulatory reporting tools to people who had no intention of reading the documentation. Making a technical system usable by whoever inherits it is the actual job. Prices vary by per hour or by workshop.
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.
Pricing
01
Per hour
Hourly rate is 1 200 SEK per hour billed in 5 hour clusters (excluding moms). This is great for teams who may be just getting started with using AI and are looking for guidance on where to get started and quick wins.
02
Single workshop
Rate for a workshop varies on scope, but usually between 15 000 to 30 000 SEK per workshop (excluding moms). Workshops are best for teams who have a clear scope on what they want to accomplish. Workshops always include material that can be used after the session, includes 5 hours of work after the workshop to support with implementation.
03
Subscription
Monthly rate is 3 000 SEK, can be cancelled anytime (excluding moms). This is built for solo marketers in small teams who just need a coach to help answer questions and get support on executing on various tasks. Sessions are done over Slack/ email and video.
Every job I’ve ever had has been the same job.
01
Recruiting
Years spent at Airbnb, Clever (Kahoot!), and the Obama White House convincing engineers to join teams they had never heard of, against Google, Meta and AWS. The only thing that ever worked was explaining what a company actually did to someone with better offers and no patience.
02
7 years of technical product marketing
Then security software and regulatory reporting, sold to people with no intention of reading the documentation.
03
Eighteen months building
Twenty-one working systems inside a marketing team as a product marketing manager, not as a consultant. Built against real customer calls, in the weeks they were needed.
The job was never the tool. It was making something one person understood usable by someone who wasn’t in the room when it was built, and designing the path that gets them there in days rather than months.
Reach out
Send me your category and one deliverable your team makes every week. I’ll come back to you with a read on where the time is going and what I’d do about it.
No deck, no pitch.
Reach out to me to learn more