Context engineering is not enough. Meet Output Engineering.

AI is like a box of chocolates. You never know what you're gonna get.

Forrest Gump said it about life. But he could've been talking about every ChatGPT session in 2026. You write a prompt. You hit enter. You get... something. Maybe it's good. Probably it needs work. You tweak, re-prompt, iterate, and eventually land on something usable. The industry's answer has been prompt engineering: ask better, get better. Then context engineering: feed the model more, get smarter. Both treat AI like a black box you negotiate with.

Nobody stopped to ask a different question. What if the problem was never the prompt?

I bet a prompt that says "dO mArKeTiNg" with the right context and a sample output will deliver better results than an 800-word prompt with neither.

Here's the thing about marketing deliverables: they're reproducible by design. A buyer persona has the same fields whether you're building it for a B2B SaaS company or a consumer fintech. A lifecycle messaging matrix maps messages to stages with triggers, timing, and channels. The content changes between companies. The structure doesn't.

Compare that to development. Even "standard" patterns like authentication look different from project to project. OAuth vs JWT vs session-based, different providers, different security models. Code solves novel structural problems. Marketing fills proven structures with new data.

That's what makes marketing uniquely suited to this approach. These are settled formats. Nobody needs to reinvent the persona template. And yet, every time someone opens ChatGPT and types "generate buyer personas," they're asking the model to do exactly that. Reinvent the format from scratch and gets upset and frustrated by the output.

The black box problem

The real bottleneck

Here's what actually happens. You open ChatGPT or Claude in a browser. You write a prompt. Maybe a good one. Maybe you spent twenty minutes on it, added examples, specified the tone, listed constraints. You hit enter. It's... fine. Tweak. Try again. A little better. Tweak again. Five or six rounds later, you land on something you can work with. Barely.

You copy it into a Google Doc. You reformat it. You reorganize sections. You rewrite half of it. Then you realize the structure doesn't hold up because the model was guessing at the structure the entire time.

The prompt was never the problem. Nobody defined what they wanted to receive.

You can write the most elaborate prompt in the world. If you haven't specified what the output should look like, you're asking the model to make two decisions at once: what to say and how to organize it. The model is good at the first part. It's terrible at the second. Structure is your job.

Output Engineering

Output Engineering flips the process. Define the artifact first. The exact format. The exact structure. The sections, the fields, the relationships between them. Then give the model the context it needs to fill that structure. Then define the process it should follow.

Artifacts + context + process. That's it.

Artifacts + Context + Process = Output

I saw prompts that say "Generate personas." What the fuck are you gonna get? Excel files? Blurbs? How do you iterate on that? Those prompts produce shapeless blobs that look useful for about thirty seconds until you try to do something with them.

Output Engineering means you already know what the finished deliverable looks like because you've built it by hand, probably dozens of times. You encode that knowledge into a template, a markdown file, a JSON schema. The model fills it in. The output is useful immediately because the structure was useful before AI touched it.

What this looks like in practice

Before and after Output Engineering

Four examples, all from real marketing work. Each one shows the evolution from prompt engineering through context engineering to Output Engineering.

Persona development

Prompt engineering: "Generate buyer personas for a B2B SaaS product." You get "Sarah, 35, VP of Marketing, struggles with ROI reporting." A LinkedIn bio, not a persona.

Context engineering: Same request, but you feed it company docs, product specs, market research. Smarter output. But the model decides the structure: five meandering paragraphs per persona mixing demographics with motivations with buying behavior. You spend an hour pulling it apart.

Output engineering: Define the persona template first. Demographics, psychographics, buying triggers, specific objections they'll raise on a sales call, decision criteria, internal champions and blockers, budget authority, evaluation timeline. Every field maps to a decision someone on your team needs to make. Give the model context AND a sample output. Same structured document every time. Your sales team can sell from it on day one.

Customer journey mapping

Prompt engineering: "Create a customer journey for our product." Awareness, Consideration, Decision, Retention. Four textbook paragraphs. Nothing you can build from.

Context engineering: Add product details, customer interviews, support tickets. The journey gets specific, but it comes back as a narrative essay. No clear handoffs between teams. Useful insights buried in a structure that doesn't map to anyone's workflow.

Output engineering: Define every stage as a structured JSON block. The trigger that moves a customer into this stage. The touchpoints and who owns each one. Emotional state. Customer actions. Team actions. Data signals that confirm progression. Failure modes that indicate they're stuck. Hand it to a PM, a designer, a lifecycle marketer, and they each know exactly what to build.

Value proposition generation

Prompt engineering: "Write value propositions for our product." You get "Save time. Reduce costs. Improve efficiency." Your competitor's AI just generated the same list.

Context engineering: Feed it positioning docs, customer research, competitive analysis. Better bullets. But they arrive as a flat list. Which propositions address which pain points? Which segments care about which gains? You're connecting dots manually.

Output engineering: Define a value proposition canvas as a YAML template. Customer jobs (functional, social, emotional). Pains by severity and frequency. Gains: required, expected, desired, unexpected. Map each to features, pain relievers, and gain creators. The model populates both sides and draws the connections. A strategic map you can use to build messaging, prioritize features, and train your sales team.

Lifecycle messaging

This one I built a tool for. Mango Lollipop is an open-source CLI that generates complete lifecycle messaging systems for SaaS companies. I'd done this work manually for 10+ years and the deliverable was always the same shape: an AARRR matrix mapping every message to a lifecycle stage, with triggers, timing, channels, guards, suppressions, and copy.

Prompt engineering gets you five onboarding emails that could belong to any product. No triggers. No conditions. Words without architecture.

Context engineering produces smarter copy that references your product. But no timing logic, no conditional branching. A lifecycle marketer has to manually rebuild the entire system.

Output engineering defines the lifecycle system as a data model first. Six stages. Every message has a trigger, timing, channel, CTA, segment, guards, and suppressions. Mango Lollipop produces 33 messages across all stages, complete with Excel workbooks, interactive dashboards, and developer handoff specs. Production-ready because the structure was production-ready before the model wrote a single word.

Why Output Engineering wins

Reproducibility. Same structure every run. Content adapts to each company and market. The deliverable format stays locked. Build processes around that consistency instead of reconstructing deliverables every time a model reshuffles the sections.

Iterability. Change the template, re-run, get updated output. Missing field in your persona template? Add it, re-run. Every persona retroactively gains that field. With prompt or context engineering, you'd re-prompt each one individually and hope for a compatible structure.

Shareability. Templates become reusable tools. Mango Lollipop is an npm package anyone can install. The persona workflow is a Claude Code skill I run with a slash command. Try turning a ChatGPT conversation into something your colleague can run.

Scalability. Works for one deliverable or fifty. Same persona template processes a single segment or an entire market. Once the template exists, the marginal cost of another run is nearly zero.

Superpowers you unlock

Output Engineering works best when AI reads and writes files in your local environment. Claude Code, Cursor, Codex. Tools that operate on your filesystem, in your terminal, with access to your project structure. Move from a browser to an IDE and the workflow changes completely.

Version control your outputs. Every deliverable lives in git. Diff versions. Roll back. Track how your personas evolved over three months.

Run validation scripts. Check JSON journey maps for missing fields. Validate that every lifecycle message has a trigger and a channel. Flag personas missing budget authority. Automated quality gates on AI output.

Pipe outputs into other tools. Persona JSON feeds into CRM segmentation. Lifecycle messaging YAML imports into your automation platform. Journey maps render as interactive dashboards. The output becomes a data source.

Build reusable skills. Claude Code slash commands turn workflows into one-line executables. /generate-personas reads the template, ingests the context, produces the deliverable. Anyone on your team runs it.

Share and publish. Mango Lollipop is on npm. Real users install it and generate messaging systems. Your persona workflow could be a shared repo your entire marketing org uses. These aren't conversations. They're tools.

Extend with custom code. Python scripts for data enrichment. Validation logic. Automated scoring. AI output becomes one step in a larger pipeline you control.

You go from copy-pasting in a browser to building a production workflow. That's the upgrade.

The experience problem

Here's the objection I hear before anyone says it: "I don't know what the output should look like."

That's the point. And that's the uncomfortable truth about AI productivity.

The people who get the most out of AI aren't the ones writing better prompts. They're the ones who spent years doing the work manually and know exactly what the finished deliverable should look like. They've built enough personas to know which fields matter. They've mapped enough journeys to know where handoffs break. They've written enough lifecycle systems to know that guards and suppressions are what separate a real system from a drip campaign.

The experience spectrum

Think of it as a spectrum. With zero experience, you ask AI what you SHOULD have as an output. You accept whatever it recommends because you have no basis for evaluation. With some experience, you ask AI what you NEED. You know the general shape of the deliverable, so you can guide the model and fill gaps. With deep experience, you tell AI what you WANT. You define the exact structure. You're in the driver's seat.

That spectrum matters because of scotoma: you can't see what you don't know exists. Someone who's never built a lifecycle messaging system doesn't know to ask for guards and suppressions. They accept the model's five-email drip sequence as complete because they have no frame of reference for what complete actually looks like. The gap isn't in their prompting. It's in their domain knowledge. Experienced professionals know exactly what's possible. They're not relying on the LLM to recommend. They're defining.

Design thinking as an on-ramp. For people building domain experience, design thinking provides foundational structure. It doesn't replace years of running campaigns. But if you've learned to map user needs, define problems clearly, and prototype solutions, you can apply that to output templates even in unfamiliar domains. Interview stakeholders. Map who uses the output and how. Prototype the template. Test it. That gets you to a useful structure faster than raw prompting ever will.

AI amplifies experience. But only if you tell it what "done" looks like.

What changes

The real shift isn't learning a new prompting technique. It's recognizing that the quality of your AI output is directly proportional to your understanding of what the output should be.

Output Engineering forces you to confront your own uknown unknowns. If you can't define the template, you don't understand the deliverable well enough yet. That's useful self-knowledge. It tells you where to invest: learn the domain, study existing deliverables, build a few by hand. Then encode what you learned.

Prompt engineering was about talking to AI. Context engineering was about feeding it. Output Engineering is about defining what you need to receive. It forces you to specify the artifact before you engage the model, to encode your expertise into a structure, to think about who uses the output and how. When you've done that work, the prompting becomes trivial. "Fill this template using this context" doesn't require prompt engineering. It requires knowing what the template should be.

The experience comes first. The engineering follows.

Start with what you want to receive. Work backwards from there.