Marketing Engineering

Pick a real workflow from your job. Break it apart. Take it as far as you can. One presentation, five to fifteen minutes.

Target Audience

Marketing Engineers

Skills

Workflow Decomposition, Discovery, Agent Design, Systems Thinking, Stakeholder Communication

Submission Type

Project Based Assignment

About

You took the course. Now do it for real.

Find a recurring workflow at your job: something your team actually does on a regular basis. Break it apart the way we taught you, and record a presentation walking us through it. Take five to fifteen minutes, use slides, screen share, do a little whiteboarding… we want you to use whatever you feel gets the point across best.

Your presentation has two halves:

First half: show us the problem.

Pick the workflow. Tell us what it is, who does it, and how often. Tell us why this one caught your eye. Then decompose it. Not the version the practitioner would describe in a meeting. The version you found when you actually looked. The hidden steps nobody mentions. The decisions that happen on autopilot. The places where the work forks depending on what someone finds. If you scored it on frequency, complexity, and impact, share that reasoning.

This half is required. Everyone does it.

Second half: show us how far you took it.

Pick one of three paths, depending on where you are.

You ran a discovery conversation. You sat with the person who does this work, asked the questions, and found things they couldn't see themselves. Show us how that went. What did they describe? What did you actually find underneath? Pull up your notes, your recording, your handoff doc. We want to see the gap between what the workflow looks like from inside and what it looks like once someone from the outside maps it.

You designed a plan for the agent. You took the decomposition and turned it into a buildable architecture. Nodes, connections, variable names, the works. You haven't built it yet, but you've thought through the traps: messy data, the cold start problem, sequences that multiply, places where order matters. Walk us through the plan and explain why each piece is there.

You built the agent. It runs. Show us. Walk through the decisions you made, run it live, show what comes out. Tell us what broke the first time and what you changed. Tell us what you'd still fix.

Those three paths go in order of depth: conversation, plan, build. Pick the one that matches how far you've gone. But whichever one you pick, don't phone it in. A vague conversation summary, a half-drawn plan, or a demo with no explanation behind it won't pass.

What passing looks like.

We're being upfront about this because honestly, knowing the bar makes it easier to clear.

A failing presentation: "I picked our weekly report because it takes a long time. It has about five steps. I built an agent that automates it. Here are the nodes."

A passing presentation: "Our demand gen team spends three hours every Monday pulling data from five platforms into a summary for the director. I sat with the person who does it and she described it as four steps. When I watched her do it, it was eleven. She was checking a Google Sheet before every comparison, and she didn't think of that as a step, but it's the baseline. There was a severity judgment in her head: if the numbers looked normal she'd write two sentences, if something spiked she'd open the campaign dashboard and investigate first. She never mentioned the part where she updates the Sheet afterward, which is the step that makes next week possible. I scored this high frequency, moderate complexity, Tier 2 impact. The time savings matter but the real win is consistency. The report used to be different depending on who did it and how rushed they were. Now it's the same quality every Monday. Here's the architecture I planned, and let me show you the three traps I found..."

The difference is whether someone went through the process or jumped straight to the build.

What you submit.

One video of five to fifteen minutes with a screen share and you chatting through. Face cam if you want but not required.

If you did the course assignments along the way, you already have most of this sitting in your notes. Your decomposition. Your scoring. Your discovery doc or your plan. Your agent if you built one. This cert is just those pieces told as one story.

You did the work. Now walk us through it.

Submit for certification

Rubric

Submissions are evaluated across 4 dimensions, each scored on a 0-3 scale

Category	Weight	What we're evaluating	Needs Improvement	Meets Expectations	Excellent
Problem Identification and Prioritization	20%	Did you pick the right thing to build, and can you explain why?	The workflow is vague or hypothetical. The rationale is "someone asked me to" with nothing further. No evidence the candidate thought about whether this was the right use of their time.	The workflow is real and recurring. The candidate has a reason for choosing it but it's general: "it takes a long time" or "it runs every week." They chose something worth building but don't fully show they weighed it against alternatives.	The workflow is real, recurring, and the candidate can tell you exactly why they chose it. Frequency, complexity, and impact are addressed with specifics: how often it runs, how many steps it actually has, what changes for the team if it's automated. If this is something that wasn't being done before because it wasn't feasible by hand, the candidate explains what becomes possible. You get the sense they looked at several options and picked this one for a reason. They understand the business context, not just the task.
Decomposition and Systems Thinking	30%	Can you see the real system inside what looks like a simple task?	The decomposition matches the surface description. Three to five steps, no evidence of looking deeper. No hidden steps. No decision points identified. The candidate describes what the workflow does without seeing the system underneath it.	The decomposition goes past the surface and reveals additional steps. The candidate found some hidden complexity: a decision point, a cleanup step, a dependency that wasn't obvious at first. The distinction between repeatable and judgment work is there but not deeply explored. Reasonable but may miss edge cases.	There's a clear before-and-after: what the workflow sounded like on the surface versus what it actually involves. The gap is specific. Hidden steps are named: the baseline document nobody mentioned, the post-delivery cleanup, the severity judgment that felt like instinct. Compressed verbs get expanded ("compare" turns into five operations). Decision points are identified and sorted into rules versus judgment. You can tell the candidate actually dug. They didn't just list steps. They found the ones that were invisible.
Depth path: agent demo, discovery session, or agent sketch	30%	How far did you take this? Evaluates whichever path the candidate chose. All three are held to the same bar.	The chosen path is shallow or missing. A demo doesn't run or has no reflection. A discovery session is described vaguely with no specific hidden steps named. A sketch is a restatement of the decomposition with no architecture, no variable names, no trap awareness.	The chosen path is present and reasonable but has gaps. A demo runs but not all decisions are explained. A discovery conversation happened but the described-vs-real gap isn't fully drawn. A sketch covers the main path but misses edge cases. The work is real but not deep.	The chosen path is complete and the candidate can explain every decision in it. A demo runs live with intentional design choices visible. A discovery session surfaces real hidden steps the practitioner couldn't see. A sketch is detailed enough that someone could build from it without asking questions. Whichever path: the work is specific to this workflow, not generic, and the candidate clearly went further than the minimum.
Presentation and stakeholder communication	20%	Can you tell this story clearly, and can you explain the value to someone who's never seen a workflow canvas?	Disorganized, or just a tour of features with no story. No visuals, or visuals are walls of text. No stakeholder explanation, or the explanation uses words like "nodes," "LLM," "structured outputs," and "API" to a hypothetical non-technical audience. Describes technology rather than impact.	The presentation covers the ground and gets the ideas across. Visuals are present and helpful. A stakeholder explanation is attempted but has some unnecessary technical detail or takes too long to land.	The presentation tells a coherent story from problem to process to result. Slides or visuals support the narrative without replacing it. The candidate includes a stakeholder explanation: about thirty seconds, zero jargon, focused on what changed for the team. Time recovered, quality leveled, something new that's possible. A VP who's never seen an agent would get it and care about it. The candidate sounds like a marketing engineer talking about their work, not a student presenting homework.

About

You took the course. Now do it for real.

Your presentation has two halves:

First half: show us the problem.

This half is required. Everyone does it.

Second half: show us how far you took it.

Pick one of three paths, depending on where you are.

You built the agent. It runs. Show us. Walk through the decisions you made, run it live, show what comes out. Tell us what broke the first time and what you changed. Tell us what you'd still fix.

What passing looks like.

We're being upfront about this because honestly, knowing the bar makes it easier to clear.

A failing presentation: "I picked our weekly report because it takes a long time. It has about five steps. I built an agent that automates it. Here are the nodes."

The difference is whether someone went through the process or jumped straight to the build.

What you submit.

One video of five to fifteen minutes with a screen share and you chatting through. Face cam if you want but not required.

You did the work. Now walk us through it.

Submit for certification

Category

Weight

What we're evaluating

Needs Improvement

Meets Expectations

Excellent

Problem Identification and Prioritization

20%

Did you pick the right thing to build, and can you explain why?

The workflow is vague or hypothetical. The rationale is "someone asked me to" with nothing further. No evidence the candidate thought about whether this was the right use of their time.

The workflow is real and recurring. The candidate has a reason for choosing it but it's general: "it takes a long time" or "it runs every week." They chose something worth building but don't fully show they weighed it against alternatives.

The workflow is real, recurring, and the candidate can tell you exactly why they chose it. Frequency, complexity, and impact are addressed with specifics: how often it runs, how many steps it actually has, what changes for the team if it's automated. If this is something that wasn't being done before because it wasn't feasible by hand, the candidate explains what becomes possible. You get the sense they looked at several options and picked this one for a reason. They understand the business context, not just the task.

Decomposition and Systems Thinking

30%

Can you see the real system inside what looks like a simple task?

The decomposition matches the surface description. Three to five steps, no evidence of looking deeper. No hidden steps. No decision points identified. The candidate describes what the workflow does without seeing the system underneath it.

The decomposition goes past the surface and reveals additional steps. The candidate found some hidden complexity: a decision point, a cleanup step, a dependency that wasn't obvious at first. The distinction between repeatable and judgment work is there but not deeply explored. Reasonable but may miss edge cases.

There's a clear before-and-after: what the workflow sounded like on the surface versus what it actually involves. The gap is specific. Hidden steps are named: the baseline document nobody mentioned, the post-delivery cleanup, the severity judgment that felt like instinct. Compressed verbs get expanded ("compare" turns into five operations). Decision points are identified and sorted into rules versus judgment. You can tell the candidate actually dug. They didn't just list steps. They found the ones that were invisible.

Depth path: agent demo, discovery session, or agent sketch

30%

How far did you take this? Evaluates whichever path the candidate chose. All three are held to the same bar.

The chosen path is shallow or missing. A demo doesn't run or has no reflection. A discovery session is described vaguely with no specific hidden steps named. A sketch is a restatement of the decomposition with no architecture, no variable names, no trap awareness.

The chosen path is present and reasonable but has gaps. A demo runs but not all decisions are explained. A discovery conversation happened but the described-vs-real gap isn't fully drawn. A sketch covers the main path but misses edge cases. The work is real but not deep.

The chosen path is complete and the candidate can explain every decision in it. A demo runs live with intentional design choices visible. A discovery session surfaces real hidden steps the practitioner couldn't see. A sketch is detailed enough that someone could build from it without asking questions. Whichever path: the work is specific to this workflow, not generic, and the candidate clearly went further than the minimum.

Presentation and stakeholder communication

20%

Can you tell this story clearly, and can you explain the value to someone who's never seen a workflow canvas?

Disorganized, or just a tour of features with no story. No visuals, or visuals are walls of text. No stakeholder explanation, or the explanation uses words like "nodes," "LLM," "structured outputs," and "API" to a hypothetical non-technical audience. Describes technology rather than impact.

The presentation covers the ground and gets the ideas across. Visuals are present and helpful. A stakeholder explanation is attempted but has some unnecessary technical detail or takes too long to land.

The presentation tells a coherent story from problem to process to result. Slides or visuals support the narrative without replacing it. The candidate includes a stakeholder explanation: about thirty seconds, zero jargon, focused on what changed for the team. Time recovered, quality leveled, something new that's possible. A VP who's never seen an agent would get it and care about it. The candidate sounds like a marketing engineer talking about their work, not a student presenting homework.

About

You took the course. Now do it for real.

Your presentation has two halves:

First half: show us the problem.

This half is required. Everyone does it.

Second half: show us how far you took it.

Pick one of three paths, depending on where you are.

You built the agent. It runs. Show us. Walk through the decisions you made, run it live, show what comes out. Tell us what broke the first time and what you changed. Tell us what you'd still fix.

What passing looks like.

We're being upfront about this because honestly, knowing the bar makes it easier to clear.

A failing presentation: "I picked our weekly report because it takes a long time. It has about five steps. I built an agent that automates it. Here are the nodes."

The difference is whether someone went through the process or jumped straight to the build.

What you submit.

One video of five to fifteen minutes with a screen share and you chatting through. Face cam if you want but not required.

You did the work. Now walk us through it.

Submit for certification